spliterator() 方法为并行处理提供可拆分、可估算、可描述的迭代能力，其核心是按需递归分裂、依特性调度、原子遍历。
Collection 接口的 spliterator() 方法不是简单地“把集合切成几份”，而是为并行处理提供可拆分、可估算、可描述的迭代能力。它的核心作用是让框架知道：数据能不能分、怎么分、分完还剩多少、分出来的部分是否安全并发处理。
拆分不是硬切，而是按需递归分裂
调用 trySplit() 并不保证一定返回新 Spliterator。它根据当前状态（如剩余元素数、底层结构特性）决定是否拆——比如 ArrayListSpliterator 在 size ≥ 1024 时才均分；小于阈值就返回 null，表示“别再分了，我来串行跑完”。这种策略避免小任务带来调度开销。分裂过程由 ForkJoinPool 自动触发：一个 Spliterator 被提交后，框架会反复调用其 trySplit()，直到返回 null 或达到并行阈值，形成树状任务结构。
拆分能力取决于底层实现
不同集合的 spliterator() 行为差异极大：
-
ArrayList：返回
ArrayListSpliterator，支持 O(1) 索引定位，trySplit()按中点切，左右两半大小接近，适合负载均衡 -
LinkedList：实际是顺序遍历+计数器，
trySplit()成本高，多数情况直接返回 null，强行并行反而更慢 - HashSet / HashMap：基于哈希桶，Spliterator 按桶区间拆分，但因桶分布不均，可能造成任务倾斜
-
自定义集合未重写 spliterator()：默认走
Collection.spliterator()的通用包装，本质是 Iterator 封装，trySplit()返回 null，退化为顺序执行
characteristics() 决定并行行为，不只是“说明”
这个方法返回的位掩码（如 SIZED | ORDERED | SUBSIZED）直接影响 ForkJoin 调度逻辑：
- 有
SIZED：框架能准确预估总元素数，合理设定分割粒度；缺它可能导致过度拆分或线程空转 - 有
ORDERED：findFirst()、limit()等操作保持顺序语义，但会抑制乱序优化；若不需要顺序，可用findAny()提升并行效率 - 有
CONCURRENT：框架信任源线程安全，跳过同步保护；但普通 ArrayList 即使加了 synchronized 包装，其 Spliterator 也不带该标志——特性由类硬编码，非运行时推断
tryAdvance() 是原子遍历单元
它替代了 Iterator 的 hasNext() + next() 两步调用，一次完成判断和消费，天然规避多线程下的竞态条件。forEachRemaining() 是它的批量封装，默认循环调用 tryAdvance()，也可被子类重写以做批量优化（如数组 memcpy）。这种设计让每个线程在自己的 Spliterator 上独立推进，无需锁或 volatile 协调。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
