必须通过StreamSupport.stream()显式构造才能启用自定义Spliterator；Collection.stream()硬编码使用JDK默认实现，重写spliterator()无效。
Java 8+ 的 Stream 不能直接“集成”自定义的 Spliterator——你得通过 StreamSupport.stream() 构造，否则它压根不会走你的 trySplit() 和 estimateSize() 逻辑。
为什么 stream() 方法不调用你的 Spliterator
集合（如 ArrayList、HashSet）的 stream() 方法内部硬编码返回的是 JDK 自带的 Spliterator 实现，和你的类完全无关。哪怕你重写了 Collection.spliterator()，只要没显式用 StreamSupport 启动，JVM 就当它不存在。
- 常见错误现象：
System.out.println(myCustomList.spliterator().getClass())确实打印出你的实现类，但myCustomList.stream().parallel().forEach(...)依然用的是默认分片逻辑，CPU 利用率低、分片不均 - 正确入口只有
StreamSupport.stream(<code>Spliterator, boolean)，第二个参数决定是否并行 - 如果你的
Spliterator没实现CONCURRENT或SIZED特性，parallelStream()可能退化成串行或反复试探大小，性能反降
StreamSupport.stream() 的三个关键参数陷阱
这个工厂方法看着简单，但漏掉一个标志位就可能让并行流失效或抛异常。
-
StreamSupport.stream(spliterator, false)：强制串行，即使 spliterator 支持并发也没用 -
StreamSupport.stream(spliterator, true)：要求 spliterator 至少声明NONNULL或IMMUTABLE，否则forEach中遇到 null 元素会直接NullPointerException - 最易忽略的是
characteristics返回值：如果返回了SIZED但estimateSize()总返回 -1，某些 Collector（如toList()）会反复扩容，内存翻倍
自定义 Spliterator 必须重写的四个方法
只重写 tryAdvance() 不够，trySplit() 和 estimateSize() 写错会导致并行流卡死或数据丢失。
-
tryAdvance(Consumer)：必须确保线程安全（尤其在并发场景下），避免共享状态被多线程同时修改 -
trySplit()：返回 null 表示不可再分；返回非 null 后，原 spliterator 必须放弃已分走的部分，否则重复消费 -
estimateSize()：不要返回随机数或缓存过期值；若真实 size 易获取（如数组长度），优先返回精确值，触发SIZED优化 -
characteristics()：用|组合多个 flag，比如Spliterator.SIZED | Spliterator.NONNULL；错写成&会导致特性清零
测试你的 Spliterator 是否真被用了
别信日志输出，要验证行为——并行流是否真的按你预期分片？有没有漏元素？
- 加断点或日志到
trySplit()，跑StreamSupport.stream(..., true).parallel().count()，看调用次数是否随线程数增长 - 用
IntStream.range(0, 1000).boxed().collect(Collectors.toList())构造基准数据，和你的实现对比collect(toList())结果是否一致 - 故意在
tryAdvance()里 throw new RuntimeException，观察堆栈是否包含ForEachOps$ForEachOp—— 如果是ArrayList$ArrayListSpliterator，说明根本没走你的代码
真正难的不是写完 Spliterator，而是让 JVM 在所有调用路径里都选中它——stream()、parallelStream()、Collectors.toSet() 这些看似相关的方法，其实全绕开了你。每次改完记得用 StreamSupport 显式构造，再压测分片效果。
