并行流没变快，主因是Spliterator的trySplit()未有效拆分任务——返回null或严重不均衡，导致实际单线程执行；关键看底层是否支持高效分割（如ArrayList可均分，LinkedList常返回null），且characteristics()特性直接影响ForkJoin调度与优化行为。
为什么并行流没变快？先看 trySplit() 是否真在拆
并行流性能差，八成是因为 Spliterator 没拆出有效子任务——它返回 null 或拆得极不均衡，结果还是单线程跑完。不是调了 parallelStream() 就自动并行，关键看底层 trySplit() 能不能反复切分。
-
ArrayList的spliterator()返回ArrayListSpliterator，支持 O(1) 随机分割，能平均切成两半 -
LinkedList的spliterator()实际是顺序遍历+计数，trySplit()成本高、常返回null，强行并行反而更慢 - 自定义集合若没重写
spliterator()，默认走Iterator包装，不支持拆分，trySplit()直接返回null
验证方法：打断点进 trySplit()，或在 estimateSize() 处观察调用栈——如果只进一次就结束，说明根本没触发分裂逻辑。
characteristics() 不只是“描述”，它直接控制并行行为
这个方法返回的位掩码（如 ORDERED | SIZED）不是装饰用的，ForkJoin 框架会据此决定是否启用某些优化、是否允许乱序合并、甚至跳过某些同步步骤。
- 缺
SIZED：框架无法预估数据量，可能低估任务粒度，导致线程空转或过度拆分 - 缺
ORDERED但你用了findFirst()：并行流会强制串行化该操作，失去并行意义 - 有
CONCURRENT但源不是线程安全集合（如普通ArrayList）：运行时可能抛ConcurrentModificationException，因为框架默认信任这个声明
示例：Collections.synchronizedList(new ArrayList()).spliterator() 仍不带 CONCURRENT 特性——特性由实现类硬编码，不是运行时推断出来的。
立即学习“Java免费学习笔记（深入）”；
手动用 Spliterator 写并行处理，比瞎套 parallelStream() 更可控
当标准并行流行为不符合预期（比如要控制拆分阈值、避免中间收集、或绕过 Stream 的状态缓存开销），直接操作 Spliterator 是更底层也更干净的选择。
- 用
tryAdvance()+ 循环做确定性单线程遍历（比forEachRemaining()更易中断或加条件） - 递归调用
trySplit()构建任务树，配合ForkJoinTask自定义拆分策略（例如按业务维度切，而非简单二分） - 把
estimateSize()当作启发式依据：小于 1000 就不拆，直接forEachRemaining()执行，避免小数据的调度开销
简例：
Spliterator<String> spl = list.spliterator();
if (spl.estimateSize() > 5000) {
Spliterator<String> right = spl.trySplit();
if (right != null) {
new MyParallelTask(spl).fork(); // 左半
new MyParallelTask(right).compute(); // 右半，当前线程执行
}
}
常见误用：以为 forEachRemaining() 是“优化版循环”，其实它可能掩盖并发问题
forEachRemaining() 底层就是循环调用 tryAdvance()，但它**不检查结构修改**——如果源集合在遍历中被其他线程修改，它不会像 Iterator 那样抛 ConcurrentModificationException，而是静默出错或漏元素。
- 仅适用于不可变集合、或明确受控的并发场景（如
CopyOnWriteArrayList） - 在调试时，若发现并行流结果偶尔缺失/重复，优先怀疑是否误用了
forEachRemaining()替代了带状态检查的遍历 - 它和
tryAdvance()不是互斥替代关系：前者适合“全量一次性处理”，后者适合“逐个判断后处理”
真正难的从来不是怎么拆，而是怎么让拆出来的每一块，都清楚自己该守什么契约、不该碰什么变量、以及什么时候该放弃并行退回到顺序执行。
