BigDecimal除法：缩放与舍入全解析

Java中BigDecimal除法必须显式指定小数位数（scale）和舍入模式（RoundingMode），否则会直接抛出ArithmeticException——这是开发者最容易忽视却后果严重的陷阱；文章深入剖析了常见误用（如未指定参数导致崩溃）、HALF_UP在负数下的非直觉行为、不同舍入模式的业务适用场景（如会计偏爱HALF_UP，统计推荐HALF_EVEN）、scale设置的精度与性能权衡，以及更安全的整除替代方案divideToIntegralValue()，强调每一次除法调用都需经得起财务合规与系统契约的双重检验。

BigDecimal除法必须指定scale和RoundingMode

不指定就抛ArithmeticException——这是最常踩的坑。Java设计上认为除不尽是严重问题，不会默认帮你截断或四舍五入。divide()有两个重载必须用：一个带scale，一个带RoundingMode；只传BigDecimal被除数的版本，仅适用于能整除的场景。

• 常见错误：bigDec1.divide(bigDec2) → 一除就崩，哪怕数值上看起来“应该能除尽”（比如1.0 / 0.1在二进制浮点里本就不精确，BigDecimal里也未必整除）
• 正确写法：bigDec1.divide(bigDec2, 2, RoundingMode.HALF_UP)，其中2是小数位数，RoundingMode.HALF_UP是经典四舍五入
• scale为0时，结果是整数部分，如new BigDecimal("7").divide(new BigDecimal("3"), 0, RoundingMode.HALF_UP) → 2

RoundingMode.HALF_UP ≠ 数学四舍五入？注意负数行为

RoundingMode.HALF_UP对正数确实是四舍五入，但对负数是“向正无穷方向舍入一半”，不是“绝对值四舍五入”。比如-1.5按HALF_UP会变成-1，而很多人直觉里希望是-2。

• 如果业务要求“绝对值四舍五入”（即-1.5→-2），得用RoundingMode.HALF_DOWN配合符号处理，或先取abs再还原符号
• RoundingMode.HALF_EVEN（银行家舍入）适合统计场景，避免系统性偏差，但会计系统通常明确要求HALF_UP
• 别用RoundingMode.UNNECESSARY，除非你100%确定能整除，否则运行时直接炸

scale设太小会丢精度，设太大可能引发性能或溢出问题

scale不是越大越好。它决定结果保留几位小数，但中间计算仍按原始精度进行。设成1000未必有意义，反而让toString()变慢、序列化体积变大，极端情况下触发OutOfMemoryError（尤其在循环中反复创建高scale值）。

• 金融场景常见scale：人民币用2，利息计算可能用4或6，需与业务协议一致
• 不要动态算scale，比如a.scale() + b.scale()——除法scale跟操作数scale无直接数学关系
• 若不确定该设多少，先看下游系统要求：数据库字段精度、API文档约定、报表展示位数

替代方案：用divideToIntegralValue()做整除

当真只需要商的整数部分（不要小数），divideToIntegralValue()比手动设scale=0更安全、语义更清晰。它不关心能否除尽，直接向下取整（朝零方向），且不抛异常。

• 例如：new BigDecimal("10").divideToIntegralValue(new BigDecimal("3")) → 3
• 注意它返回的是BigDecimal，不是int，想转long得调longValueExact()（否则可能丢失精度）
• 和divide(x, 0, RoundingMode.DOWN)效果一样，但意图明确，不易误用其他舍入模式

实际用的时候，scale和RoundingMode从来不是孤立选的——它们得跟业务规则、上下游契约、甚至审计要求对齐。写完一行divide()，最好反问一句：这个舍入方式，财务同事敢签字吗？

好了，本文到此结束，带大家了解了《BigDecimal除法：缩放与舍入全解析》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！