spliterator 不是 iterator 的替代品，因其专为并行流动态分片设计，具有一性次、无状态、依赖 characteristics() 等特性，不支持重复遍历或 for-each 循环。
为什么 Spliterator 不是普通迭代器的替代品
因为它的设计目标根本不同：Spliterator 不是为了单线程顺序遍历，而是为了支持 Stream.parallel() 的动态分片和负载均衡。你不能用它直接替换 Iterator 做 for-each 循环，否则会抛 IllegalStateException 或行为异常。
常见错误现象：把 collection.spliterator() 传给自定义循环逻辑，发现 tryAdvance() 调用一次后就失效，或 forEachRemaining() 没反应——这是因为它默认不保证多次遍历，也不承诺线程安全。
-
Spliterator是“一次性”资源，多数实现不支持重复使用 - 它不提供
hasNext()/next()这类状态检查+取值分离的接口，tryAdvance()是原子性消费动作 - 分割（
trySplit()）结果不可预测：可能返回null（无法再分），也可能只切出极小片段，取决于底层数据结构和characteristics()
trySplit() 返回 null 到底意味着什么
不是“出错了”，而是当前 Spliterator 主动放弃分割权——常见于小数据集、链表结构、或已处于最细粒度（如单个数组元素）。JVM 并行流正是靠这个信号决定是否继续 fork 子任务。
使用场景：自己实现并行处理逻辑时，必须检查 trySplit() 返回值；若为 null，就该直接用 forEachRemaining() 处理剩余元素，而不是重试或报错。
立即学习“Java免费学习笔记（深入）”；
- 数组-backed 的
Spliterator（如ArrayList）通常能稳定分裂，但最后一次分裂常返回null -
LinkedList的Spliterator几乎总是返回null，因为无索引跳转能力，强行分片代价高 - 调用
trySplit()后，原Spliterator的遍历范围自动收缩，未处理部分交给子对象——这点容易被忽略，导致漏数据
如何判断一个 Spliterator 是否适合并行
看它的 characteristics() 返回值，而不是大小或类型。并行效率高低，取决于是否具备 SIZED、SUBSIZED 和 ORDERED 等特性。
性能影响：缺少 SIZED（即无法预知剩余元素数）会导致并行流无法均分任务，可能产生严重负载倾斜；没有 CONCURRENT 却在多线程中修改源集合，会触发 ConcurrentModificationException。
-
HashSet的Spliterator有CONCURRENT但无ORDERED，适合并行处理，但不保证输出顺序 -
TreeSet有ORDERED和SIZED，并行流能兼顾效率与顺序，但trySplit()开销略大 - 自己封装的
Spliterator若忘记在characteristics()中声明SUBSIZED，即使有SIZED，父/子分片大小计算也会失准
手写 Spliterator 时最容易漏掉的三件事
不是实现 tryAdvance() 就完事了。JVM 并行流依赖完整契约，漏一项就可能导致任务卡死、数据丢失或吞吐暴跌。
- 忘记在
trySplit()中更新原对象的index或size，导致父Spliterator后续仍尝试遍历已被子对象拿走的部分 -
estimateSize()返回负数或不随trySplit()动态变化，会让并行调度器误判工作量，分配过重或过轻的任务 - 没正确传播
characteristics()：比如源数据是排序数组，但你的Spliterator没声明ORDERED，下游findFirst()在并行流里就可能返回任意匹配项
复杂点在于：这些逻辑必须彼此对齐。比如 trySplit() 切出前半段，estimateSize() 就得立刻反映剩余后半段的大小，而 characteristics() 得确保子对象继承父对象所有适用特性——少一个位掩码，整个并行行为就可能偏离预期。
