BigDecimal累加需兼顾精度与性能：不可变性导致频繁创建对象，应通过复用引用、预设MathContext、分批合并等方式优化，避免字符串拼接或double转换等伪优化。
在 java 中用 bigdecimal.add() 做高精度累加时，核心矛盾是：既要保证数值精度不丢失，又要避免频繁创建临时 bigdecimal 对象带来的内存与 gc 开销。关键不在“能不能加”，而在“怎么加得既准又轻”。
明确不可变性带来的开销本质
BigDecimal 是不可变对象，每次 add() 都返回一个新实例，原对象不受影响。这意味着：
- 连续调用
a.add(b).add(c).add(d)会生成 3 个中间对象（a+b、(a+b)+c、((a+b)+c)+d） - 若在循环中反复
sum = sum.add(item)，每次迭代都新建一个sum，旧的sum等待 GC - 开销大小取决于数据量级和 JVM 堆配置，但万级以上的累加已可能触发明显 GC 暂停
减少临时对象的实用策略
不依赖第三方库的前提下，有几种低侵入、易落地的方式：
-
复用引用 + 显式赋值：虽然不能修改对象本身，但可让变量始终指向最新结果，避免链式调用。这是最直接且零成本的做法：
BigDecimal sum = BigDecimal.ZERO;<br> for (BigDecimal x : values) {<br> sum = sum.add(x); // 每次覆盖引用，旧对象由 GC 回收<br> } -
预分配并复用 MathContext（如需统一精度控制）：若所有加法需相同舍入模式和精度（例如财务场景常用
MathContext.DECIMAL128），提前定义一个常量，避免每次add()都隐式构造默认上下文：private static final MathContext MC = new MathContext(34, RoundingMode.HALF_UP);<br> ...<br> sum = sum.add(x, MC);
-
批量合并再累加（适合流式或分片场景）：将大数据集切分为小批次（如每 100 个一组），组内用局部变量累加，再把各组结果合并。这能显著降低 GC 频率：
List<BigDecimal> batchSums = new ArrayList<>();<br> for (List<BigDecimal> batch : partition(values, 100)) {<br> BigDecimal batchSum = BigDecimal.ZERO;<br> for (BigDecimal x : batch) batchSum = batchSum.add(x);<br> batchSums.add(batchSum);<br> }<br> BigDecimal total = batchSums.stream().reduce(BigDecimal.ZERO, BigDecimal::add);
真正需要警惕的“伪优化”陷阱
有些做法看似节省对象，实则引入风险或无效：
-
试图缓存
BigDecimal.ZERO或小整数（如 1、10）以外的实例：除非业务中存在大量重复值（如固定费率、常量税点），否则缓存意义有限，还增加维护复杂度 -
用字符串拼接再 parse 替代 add：例如
new BigDecimal(sum.toString() + "+" + x.toString())—— 字符串操作更慢，且toString()可能产生科学计数法，parse 易出错 -
为省一次对象而改用 double 累加再转回 BigDecimal：彻底放弃精度保障，违背使用
BigDecimal的初衷
性能敏感场景的进阶建议
当单次累加达数十万以上、且对吞吐/延迟有硬性要求时：
立即学习“Java免费学习笔记（深入）”；
- 考虑用
BigInteger+ 手动小数点对齐（仅适用于所有操作数小数位数一致，如金额统一为 2 位）—— 避免BigDecimal内部的scale计算与校验开销 - 引入 big-math 库，它提供
MutableBigDecimal类型，支持 in-place 加法，但需接受 API 差异与额外依赖 - JVM 层面开启
-XX:+UseG1GC并合理设置-XX:G1NewSizePercent，帮助快速回收短命的BigDecimal实例
