LongAccumulator的自定义函数必须是纯函数且满足结合律，identity值须为对应二元操作的单位元，如取最大值时为Long.MIN_VALUE；非纯函数或错误identity会导致结果错误或不可重现。
LongAccumulator 的自定义函数必须是纯函数且满足结合律
它不是用来随便塞个 lambda 的。比如你想做“跨线程最小值汇聚”，写成 (a, b) -> Math.min(a, b) 是对的；但若写成 (a, b) -> a + b * ThreadLocalRandom.current().nextInt() 就彻底失效——非确定性导致结果不可重现，且违反结合律（op(op(a,b),c) != op(a,op(b,c))）会破坏并发聚合逻辑。
常见踩坑点：
- 误把带副作用的逻辑（如日志、IO、修改外部变量）塞进累加器函数
- 用
Math.max却初始化为0，而实际数据全为负数 → 结果永远是0（应初始化为Long.MIN_VALUE） - 混淆
LongAccumulator和LongAdder：后者只支持固定加法，前者才支持任意二元操作
初始化时必须提供 identity 值且与函数语义一致
identity 不是“默认值”，而是该二元操作的单位元（identity element）。比如加法对应 0，乘法对应 1，取最小值对应 Long.MAX_VALUE，取最大值对应 Long.MIN_VALUE。传错会导致首次 accumulate() 就得到错误中间态。
实操建议：
- 用静态工厂方法显式构造，避免手写匿名类：
new LongAccumulator(Math::max, Long.MIN_VALUE) - 如果业务逻辑需要“非数字”语义（如统计最长字符串长度），别硬套
LongAccumulator，改用DoubleAccumulator或自定义Striped64子类更稳妥 - 注意
identity会被多线程同时读取，必须是常量或线程安全的不可变值
accumulate() 调用时机决定统计粒度，别在循环内高频误用
每次 accumulate() 都触发 CAS 尝试，虽然比锁轻量，但频繁调用（如每毫秒更新一次计数器）仍可能引发缓存行争用（false sharing）。尤其当多个 LongAccumulator 实例相邻分配时，JVM 可能将它们放在同一缓存行里。
优化方式：
- 在批处理场景中，先本地累积再单次
accumulate()：比如线程内算完一批数据的 sum，再把 batchSum 传给acc.accumulate(batchSum) - 避免在热点路径中直接传原始业务对象字段，先提取数值再调用：
acc.accumulate(order.getAmount())比acc.accumulate(order)（再在 lambda 里 getAmount）更干净 - 监控
acc.sum()调用频率——它内部要合并所有 cell，高并发下开销不小，别在响应时间敏感路径里反复调用
sumThenReset() 是唯一原子性“读-清零”操作，但有陷阱
它返回当前总和并重置为 identity，看似适合周期性指标采集（如每秒请求数）。但要注意：这个操作不阻塞其他线程的 accumulate()，所以可能出现“部分新值被计入下一轮”的情况——即不是严格意义上的“窗口切片”。
真实约束：
- 不能用于需要强一致性快照的场景（如财务对账），此时应改用
AtomicLong+ 读写锁 - 如果重置后立即又调用
sum()，可能得到identity，不代表没数据，只是刚被清掉 - 多线程并发调用
sumThenReset()时，只有第一个成功者拿到完整和，其余返回的是后续增量，这点文档极少强调
真正难的是让自定义函数既满足数学性质，又贴合业务语义。比如“去重计数”无法用 LongAccumulator 直接实现，因为集合合并不满足结合律——这时候就得退回到 ConcurrentHashMap + 分段锁，或者接受近似解（HyperLogLog）。工具再好，也得先看清问题能不能被它的代数模型覆盖。
