Spliterator 是集合向流框架暴露分割能力的底层契约，非直接调用API；需重写tryAdvance、trySplit、estimateSize、characteristics四方法，正确实现分割逻辑才能触发真正并行。
为什么 Spliterator 不是直接用的工具，而是被 parallelStream() 调用的底层机制
你没法也不该手动“调用”Spliterator 来启动并行遍历——它不是个 API 入口，而是集合类向流框架暴露分割能力的契约。比如 ArrayList 的 spliterator() 方法返回一个支持 trySplit() 的实例，StreamSupport.stream(spliterator, true) 才真正触发并行调度。如果你绕过集合直接 new 一个 Spliterator，大概率得不到正确并发行为，因为缺少源数据结构的分段语义（如数组索引区间、链表跳表逻辑）。
常见错误现象：NullPointerException 或无限递归出现在自定义 Spliterator 的 trySplit() 中，往往是因为没正确维护 current/est 状态，或在已耗尽时仍返回非 null 分割结果。
- 使用场景：需要自定义并行行为（如按文件块读取日志、按数据库分页游标切分），且原集合不提供合适
spliterator() - 必须重写四个方法：
tryAdvance()（消费一个元素）、trySplit()（返回子分割器）、estimateSize()（预估剩余大小）、characteristics()（声明特性，如Spliterator.ORDERED | Spliterator.SIZED） - 性能影响：若
trySplit()返回太小的子段（如每次只分 1 个元素），会导致任务调度开销远超计算收益；反之若不分或分得太大（如始终返回null），就退化为单线程
trySplit() 怎么写才不会让并行流卡死或漏数据
核心原则：每次 trySplit() 必须将当前分割器的状态推进到“已让出部分”，且新旧分割器覆盖的元素不能重叠、不能遗漏。对基于索引的结构（如数组），典型做法是取中点切分：
public Spliterator<T> trySplit() {
int lo = current;
int mid = (lo + est) >> 1;
if (lo >= mid) return null;
current = mid; // 当前实例负责后半段
return new ArraySpliterator(array, lo, mid); // 新实例负责 [lo, mid)
}容易踩的坑：
- 忘记更新
current或est，导致下次trySplit()返回相同区间，陷入死循环 - 用
mid - 1而非mid切分，造成中间一个元素被跳过 - 在
tryAdvance()中未同步更新current，使trySplit()基于过期位置计算 - 对无序/不可索引源（如
Iterator包装），强行实现trySplit()极易出错——此时应返回null，让框架回退到单线程
如何验证你的 Spliterator 真正触发了并行执行
别只看结果对不对，要确认线程确实分了工。最直接的方式是在 tryAdvance() 里打日志，带上线程名：
public boolean tryAdvance(Consumer<? super T> action) {
if (current < est) {
System.out.println(Thread.currentThread().getName() + " processing " + array[current]);
action.accept(array[current++]);
return true;
}
return false;
}运行 StreamSupport.stream(yourSpliterator, true).forEach(...)，观察输出是否出现多个线程名（如 ForkJoinPool.commonPool-worker-2）。注意：forEach() 不保证顺序，若需有序处理，改用 forEachOrdered()，但会牺牲部分并行性。
- 兼容性影响：JDK 9+ 对
Spliterator的characteristics()检查更严格。如果声明了Spliterator.SORTED却没实现排序语义，流操作可能抛IllegalStateException - 调试技巧：用
System.setProperty("java.util.concurrent.ForkJoinPool.common.parallelism", "2")固定并行度，排除环境干扰 - 不要依赖日志行数判断分割效果——
ForkJoinPool可能合并小任务，实际线程数常少于分割次数
什么时候该放弃自定义 Spliterator，转而用其他方案
绝大多数业务场景下，直接调用 collection.parallelStream() 就够了。只有当你明确遇到以下情况，才值得投入精力：
- 源数据无法一次性加载进内存（如 TB 级文件流、分库分表的结果集），且标准
Files.lines()或JDBC ResultSet的默认spliterator()不支持有效切分 - 需要控制分割粒度（例如每 10MB 文件内容作为一个任务，而非默认按行数均分）
- 现有集合类的
spliterator()返回不支持CONCURRENT特性，但你的数据源本身是线程安全的（如ConcurrentHashMap.values()），想进一步优化
否则，硬写 Spliterator 很容易引入隐蔽的竞态或分割偏差——尤其当源数据结构动态变化（如边遍历边插入）时，trySplit() 的正确性几乎无法保障。
