collection转stream的本质是通过spliterator()获取spliterator再由streamsupport封装，其拆分策略直接影响并行流性能；arraylist、linkedlist、hashset等各有优化实现，自定义spliterator需正确实现trysplit()、tryadvance()和characteristics()。
Collection 转 Stream 的本质，是通过 spliterator() 方法获取一个可拆分的迭代器，再由 StreamSupport 封装成流。这个过程不涉及手动创建或干预，但拆分策略直接影响并行流的性能和行为。
Collection 默认 spliterator 的实现逻辑
所有标准集合（如 ArrayList、HashSet、LinkedList）都重写了 spliterator() 方法，返回各自优化过的 Spliterator 实现：
-
ArrayList返回基于数组索引范围的ArrayListSpliterator，支持 O(1) 拆分，每次按大致中点二分，具备SIZED和SUBSIZED特性； -
LinkedList返回基于节点遍历的LinkedSpliterator，无法随机访问，拆分需遍历一半节点，效率低，通常不建议用于并行流； -
HashSet/HashMap使用桶数组 + 链表/红黑树结构，其Spliterator按桶区间拆分，但因哈希分布不均，可能导致负载不均衡； - 不可变集合（如
ImmutableList）往往标记IMMUTABLE和CONCURRENT，允许更激进的并行策略。
spliterator 如何驱动并行流的拆分过程
调用 parallelStream() 时，框架会反复调用 trySplit() 构建任务树，直到子 Spliterator 不再可拆（返回 null）：
- 拆分不是固定次数，而是递归进行，直到每个子任务元素数低于阈值（JDK 默认以
estimateSize()为启发，通常当剩余元素 ≤ 10–100 时停止拆分）； -
estimateSize()不必精确，但越准越利于负载均衡；例如ArrayList返回准确 size，而ConcurrentHashMap返回估算值； -
characteristics()决定能否启用某些优化：比如有ORDERED才保证forEachOrdered()正确性，有SORTED可跳过中间排序步骤。
自定义拆分策略的适用场景与关键点
当默认拆分不符合业务需求时（如按时间窗口、租户 ID 或业务分区），可实现自己的 Spliterator：
- 重写
trySplit()时不一定要二分，可以按业务维度切分（例如将日志按小时段分离、订单按用户哈希槽位划分）； -
tryAdvance()必须保证线程安全，尤其在并发修改源数据时；若源不可变，可省略同步； - 务必正确声明
characteristics()：错误标注IMMUTABLE或遗漏NONNULL可能导致流操作异常或结果不一致； - 避免在
tryAdvance()中做耗时 I/O 或锁等待——这会拖慢整个 ForkJoinPool 线程池。
何时该关注 spliterator 行为
多数情况下无需干预，但在以下情形值得检查或定制：
- 并行流性能未达预期，且数据量足够大（>10⁴ 元素），可检查是否用了
LinkedList或自定义集合； - 需要控制并行粒度（如防止过度拆分造成小任务过多），可通过包装已有 Spliterator 并重写
trySplit()加入最小尺寸限制； - 处理外部数据源（如数据库游标、文件分块读取），默认
Spliterator不适用，必须手写支持分片的实现； - 要求严格有序归约（如
reduce()的组合函数需满足结合律），应确认 Spliterator 具备ORDERED特性。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
