BigDecimal除法报错常见原因分析

BigDecimal除法看似简单，却暗藏四大“静默炸弹”：除零只是表象，更易被忽视的是未指定精度与舍入模式导致无限小数报错、误用UNNECESSARY舍入模式强行要求精确表达、以及divideToIntegralValue在非整除时的版本兼容性异常——这些场景不涉及零，却同样触发ArithmeticException，轻则线上报错，重则业务中断；掌握精准的调用姿势和前置校验逻辑，才是保障金融级计算稳定性的关键。

BigDecimal.divide 抛出 ArithmeticException，最常见原因是除零，但实际还有几个容易被忽略的变量场景——它们不涉及零，却同样触发异常。

未指定精度和舍入模式的除法（scale 未设 + 无限小数）

当两个 BigDecimal 相除结果是无限循环小数（如 1 ÷ 3），且调用的是无参 divide(BigDecimal) 或只传一个参数的重载方法时，JDK 要求结果必须能精确表示。无法终止的商直接抛出 ArithmeticException: Non-terminating decimal expansion。

• 错误写法：new BigDecimal("1").divide(new BigDecimal("3"))
• 正确做法：显式指定保留位数和舍入方式，例如 divide(divisor, 2, RoundingMode.HALF_UP)

指定了 scale 但舍入模式为 UNNECESSARY 且结果不整除

RoundingMode.UNNECESSARY 表示“绝不允许舍入”，仅当除法结果恰好为有限小数且位数 ≤ 指定 scale 时才成功。哪怕只多一位、或结果本就是无限小数，都会失败。

• 错误示例：new BigDecimal("5").divide(new BigDecimal("3"), 2, RoundingMode.UNNECESSARY) → 5/3 = 1.666…，无法在 2 位内无舍入表达
• 适用场景：仅用于校验型计算，比如确认某金额是否能被固定单位（如分）整除

除数为零（最直观但易被动态值掩盖）

除数是逻辑上为 0 的 BigDecimal，包括 BigDecimal.ZERO、new BigDecimal("0")、new BigDecimal("0.00") 等。注意：BigDecimal.valueOf(0) 同样是零。

• 陷阱：从数据库、HTTP 参数或配置中读取的数值可能表面非空，但值为 0，未校验就参与除法
• 建议：除法前加判断 if (divisor.signum() == 0) { throw … }，比 try-catch 更主动

使用 divideToIntegralValue 但余数非零

divideToIntegralValue 本意是做整除（返回商的整数部分），但它不接受舍入参数。若被除数不能被除数整除，它仍会尝试返回精确整商 —— 当无法整除时，某些版本 JDK 会抛 ArithmeticException（行为与文档略有出入，尤其在老版本中较常见）。

• 风险操作：new BigDecimal("7").divideToIntegralValue(new BigDecimal("2")) 在部分环境下失败
• 稳妥替代：divide(divisor, 0, RoundingMode.DOWN) 显式向下取整，更可控

理论要掌握，实操不能落！以上关于《BigDecimal除法报错常见原因分析》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！