Java Spliterator characteristics 设置错误会影响并行流吗

会，而且影响的不只是速度。parallel=true 只是要求 StreamSupport 创建并行流，真正决定任务能否均衡拆开、结果是否允许按遭遇顺序处理、尺寸估计能否用于优化的，是 Spliterator 自己的 trySplit()、estimateSize() 和 characteristics()。特征写错时，轻则并行流没有收益，重则进入规范未保证的行为。

先看清：并行开关不等于并行收益

Spliterator 的任务是遍历并分区。框架会反复尝试拆分，直到分片足够小，再把不同分片交给并行计算。若 trySplit() 总是返回 null，流仍可能是并行流，但实际工作几乎只能串行完成；如果拆分极不均衡，线程也会出现一边忙、一边等待。

因此第一项“资产”是元素集合本身：每个元素只能被覆盖一次，不能在父分片和子分片中重复出现。第二项是顺序和尺寸等元数据，它们服务于框架优化，也会影响某些终端操作的语义。下面两张图是静态关系示意，不是实际运行截图。

特征位要按事实填写，不要按愿望填写

常用特征可以这样判断：ORDERED 表示有稳定的遭遇顺序；SIZED 表示遍历前的 estimateSize() 是准确数量；SUBSIZED 更严格，要求 trySplit() 产生的子 Spliterator 也都满足 SIZED 和 SUBSIZED。数据源不会返回空值时才声明 NONNULL，源不可结构性修改时才声明 IMMUTABLE。

CONCURRENT 不是“我会加锁”的同义词，它表示源可以被多个线程安全地并发修改，并且要有明确的一致性策略。顶层 Spliterator 通常不应同时报告 CONCURRENT 和 SIZED，因为并发增删会让固定总数失去意义。声明 SORTED 还必须能通过 getComparator() 表达排序规则；声明 DISTINCT 则要求遇到的元素彼此不相等。

自定义 Spliterator 时，先守住拆分和尺寸边界

一个只读数组源可以从较保守的特征开始。代码中的注释解释关键约束，示例仅用于说明实现形状，不把未执行的输出当作证据：

final class RecordSpliterator implements Spliterator {
    private final String[] data;
    private int start;
    private final int end;

    RecordSpliterator(String[] data, int start, int end) {
        this.data = data;
        this.start = start;
        this.end = end;
    }

    @Override
    public boolean tryAdvance(Consumer super String> action) {
        if (start >= end) return false; // 没有剩余元素时必须停止
        action.accept(data[start++]); // 每次只消费当前分片的一个元素
        return true;
    }

    @Override
    public Spliterator trySplit() {
        int mid = (start + end) >>> 1; // 用中点减少分片倾斜
        if (mid 

这里最容易漏掉的是“拆分后仍然成立”。父分片和子分片不能重叠，也不能漏掉元素；如果报告 SUBSIZED，拆分前的尺寸还应等于拆分后父子尺寸之和。若数据来自动态队列、网络流或懒加载迭代器，就不要照抄这组 SIZED、IMMUTABLE。

把错误特征当成风险来分级

可以用下面的清单做发布前审计。这里的“攻击路径”指错误元数据如何传到并行计算，不是网络攻击。

实际检查时，先用串行流确认遍历集合，再检查每次拆分后的范围总和；最后才比较串行和并行的耗时。并行流适合可独立处理、分片成本低且任务足够大的工作，不适合带共享可变状态的副作用代码。若只是想“让它更快”，优先优化 trySplit() 的均衡性和任务粒度，而不是盲目增加特征位。

常见问题

只写 parallel=true，能自动修复 trySplit 吗？

不能。并行框架可以反复调用 trySplit()，但不能替自定义实现推断正确的元素边界；无法拆分或拆分失衡时，通常只有并行开销而没有收益。

SIZED 写错一定会得到错误结果吗？

不一定每次都直接错，但尺寸会参与分片和优化；规范对不一致的 Spliterator 不作保证。生产代码应把它当成契约错误处理，而不是依赖某次数据规模下“看起来正常”。

动态数据源应该选 CONCURRENT 还是删掉 SIZED？

先看数据源是否真的允许并发修改以及修改期间的可见性策略。不能仅因代码使用了并发集合就添加 CONCURRENT；如果总数会变化，也不能继续承诺固定尺寸。