BinaryOperator 本身无状态、纯函数式，不自带死锁风险；真正引发死锁的是其在并行流中同步访问共享资源时锁获取顺序不一致，需强制统一加锁顺序、避免阻塞操作、优先使用无锁原子类型，并确保 combiner 满足结合律且线程安全。
BinaryOperator 本身是无状态、纯函数式的接口，不自带死锁风险；真正引发死锁的，是它在并行流中被用于需同步访问共享资源的操作（比如更新数据库、调用外部服务、或操作非线程安全对象），且这些操作内部涉及多把锁且获取顺序不一致。
避免锁顺序混乱导致循环等待
当 BinaryOperator 的实现体（如 reduce(identity, accumulator, combiner) 中的 accumulator 或 combiner）内部执行了加锁逻辑，就必须确保所有线程以**完全相同的顺序**获取锁。否则极易触发“线程A锁a再等b、线程B锁b再等a”的经典死锁闭环。
- 推荐做法：对参与运算的资源（如账户、配置项、缓存键）预先定义全局唯一排序规则，例如按 ID 字符串自然序、哈希值模 N、或枚举序号，强制先锁小后锁大
- 反例：直接对两个动态传入的对象分别
synchronized(obj1)和synchronized(obj2)，未校验大小关系
慎用阻塞型资源操作
BinaryOperator 应保持轻量、快速完成。若其中包含 JDBC 更新、HTTP 调用、文件写入等可能长时间阻塞的操作，在并行流高并发下极易因线程池耗尽或锁持有时间过长，间接放大死锁概率。
- 建议将耗时/阻塞逻辑移出 BinaryOperator，改在 reduce 完成后再批量处理
- 若必须内联，应设置超时（如
Lock.tryLock(1, TimeUnit.SECONDS)）并主动放弃，避免无限等待
优先使用无锁、不可变或原子化设计
BinaryOperator 最安全的用法，是仅操作不可变对象或原子类型（如 AtomicInteger::addAndGet、LongAdder::sumThenReset），完全规避显式锁。
立即学习“Java免费学习笔记（深入）”；
- 例如累加场景：用
Integer::sum作 combiner，配合AtomicInteger或LongAdder做 identity，无需 synchronized - 聚合复杂对象时，用
Collectors.toMap或Collectors.groupingByConcurrent替代手动加锁合并
验证 combiner 的可结合性与线程安全性
ParallelStream 的 reduce 要求 combiner 满足结合律（combiner(combiner(a,b),c) == combiner(a,combiner(b,c))），且必须线程安全——因为 combiner 可能在任意线程上调用多次，用于合并不同分段结果。
- 禁止在 combiner 中修改外部状态（如 static 变量、共享集合）
- 若需构造中间对象，确保其构建过程无副作用、不依赖外部锁
- 测试时开启 -Djava.util.concurrent.ForkJoinPool.common.parallelism=2 强制低并行度，更容易暴露竞态
