1. 项目概述1.1 为什么说 BigDecimal 是精确计算的基石做 Java 开发的人迟早会撞上浮点数精度这道墙。我刚工作那年写过一段计算订单优惠金额的代码用的就是 double。那会儿觉得能跑就行直到某天财务跑过来说对不上账客户单价 0.1 元的东西买了三件合计金额显示成了 0.30000000000000004。那一刻我才意识到double 这种二进制浮点数天生就没法精确表达 0.1 这样的十进制小数。它的底层是 IEEE 754 标准用有限的二进制位去逼近一个十进制小数一旦涉及货币、利息、百分比、库存数量这类对精度要求极高的场景误差就会从毫厘之间滚成不容忽视的差池。Java 的 BigDecimal 就是为解决这个问题而生的。它是 java.math 包下的一个不可变类能够以任意精度表示十进制数并且对加减乘除、取余、比较、舍入都有明确的语义定义。实体行业的计价系统、金融系统的账务计算、电商平台的优惠分摊凡是涉及钱的运算基本都绕不开它。更关键的是即便你不做金融业务只要你的程序里出现过 0.1 0.2 不等于 0.3 这种诡异现象你就需要认真审视一下自己是不是该引入 BigDecimal 了。这篇文章适合刚接触 BigDecimal 的新手也适合已经用了几年但偶尔还会踩坑的开发者。我会从浮点数为什么不可靠讲起然后逐步展开 BigDecimal 的核心用法、精度模型、舍入策略再把那些真实项目里踩过的坑挨个翻出来最后附上一些高频问题的排查速查。读完这篇基本的精确计算场景你都能应对别人代码里那些隐蔽的金额 bug你也能一眼看穿。1.2 BigDecimal 到底解决了什么问题先做个简单的实验对比double a 0.1; double b 0.2; System.out.println(a b); // 输出 0.30000000000000004 BigDecimal c new BigDecimal(0.1); BigDecimal d new BigDecimal(0.2); System.out.println(c.add(d)); // 输出 0.3同样的两个数相加double 得到了一个看起来像0.30000000000000004的怪物而 BigDecimal 老老实实地给出了 0.3。差别本质在于double 用二进制近似十进制BigDecimal 则直接把十进制数值以未缩放值加小数位数的形式存下来。BigDecimal 的内部结构其实不复杂它由两部分组成一个任意精度的整数BigInteger作为未缩放值以及一个 32 位整数表示的小数位数 scale。比如new BigDecimal(123.45)未缩放值就是 12345scale 是 2含义是 12345 × 10⁻²。这种存法保证了人写的十进制小数是什么样它在内存里就是什么样不存在二进制转换的近似过程。这才是 BigDecimal 能作为精确计算基石的根本原因。在展开用法之前我还得强调一个原则如果你需要的是精确的十进制算术就不要用 double 来参与中间运算哪怕只在最后做一次转换也不行。正确的姿势是从源头就用字符串构造 BigDecimal或者用 BigDecimal.valueOf 从已有数值转换。后文会专门讲这个点因为它是新手最容易踩的第一道坑。2. BigDecimal 的核心概念与精度模型2.1 从构造说起三种创建方式差别能要命BigDecimal 的构造函数有很多但日常开发中真正用得上的就三类。我先说最推荐的直接用字符串构造。BigDecimal fromString new BigDecimal(19.99);之所以推荐字符串是因为它忠实保留了原始数字的每一位。你用new BigDecimal(0.10)它的 scale 是 2值就是 0.10带一个明确的精度语义你用new BigDecimal(0.1)scale 是 1。这两个数在数值上相等但在精度语境下并不完全一样在后续的除法、格式化输出、比较时会有微妙差异。第二类是BigDecimal.valueOf它适合从已有的 double 或 long 转换。看下面这段代码double price 0.1; BigDecimal fromValueOf BigDecimal.valueOf(price); // 结果是 0.1 BigDecimal fromDouble new BigDecimal(price); // 结果是 0.1000000000000000055511151231257827021181583404541015625同一个 double 0.1两种方式转出来的结果天差地别。原因是new BigDecimal(double)会把这个 double 的二进制精确值完完整整地转换出来而这个精确值本身就是一个长得离谱的十进制小数BigDecimal.valueOf内部则调用了Double.toString先把 double 转成人能看懂的字符串形式再基于字符串构造所以结果看起来干净利落。凡是需要把 double 转 BigDecimal 的场景一律用valueOf不要直接 new。第三类是new BigDecimal(int)和new BigDecimal(long)这两个没什么坑直接用即可。整数不存在精度问题放心使用。还有一个小众场景从数据库的 DECIMAL 列取值时JDBC 驱动返回的通常是 BigDecimal 对象直接使用即可不需要额外转换。2.2 精度模型scale、precision 和科学计数法BigDecimal 有两个容易混淆的属性scale小数位数和 precision有效数字位数。打个比方如果说 BigDecimal 是一把尺子scale 就是这把尺子上刻了多少位小数precision 则是这把尺子上总共显示了多少位有效数字。BigDecimal a new BigDecimal(123.4500); System.out.println(a.scale()); // 4 System.out.println(a.precision()); // 7123.4500的 scale 是 4因为小数点后有四位precision 是 7因为全部有效数字是 1、2、3、4、5、0、0 七个。注意末尾的 0 也是有效精度的一部分这对保留金额两位小数的场景很关键后面讲格式化时会用到。还有一个容易撞上的坑极小的数会被表示成科学计数法。比如BigDecimal b new BigDecimal(0.000001); System.out.println(b); // 0.000001 System.out.println(b.scale()); // 6 BigDecimal c new BigDecimal(1E-7); System.out.println(c.scale()); // 7但打印时可能显示 1E-7当 scale 小于 0 或数值过小/过大时toString 可能输出科学计数法形式比如1E3或1E-7。在对接前端接口时这种输出会让 JSON 序列化出现金额显示成了科学计数法的诡异 bug。后面实操篇会给出格式化输出方案这里先记住一个结论BigDecimal 转 String 给前端时不要直接调用 toString要指定格式或调用 toPlainString这个方法总能输出普通十进制表示不会用科学计数法。2.3 不可变性BigDecimal 每个操作都返回新对象BigDecimal 和 String 一样是不可变类。add、subtract、multiply、divide这些方法都不会修改调用者自身而是返回一个新的 BigDecimal。这一点看着简单却是我见过最多 bug 的源头。BigDecimal total new BigDecimal(100); total.add(new BigDecimal(50)); System.out.println(total); // 输出 100不是你期望的 150上面的代码不会报错结果却完全不对因为add的返回值被丢弃了。正确写法是BigDecimal total new BigDecimal(100); total total.add(new BigDecimal(50));类似这种结果没接住的问题代码评审的时候肉眼很难发现因為编译期既不警告也不报错。我的习惯是在项目里加一个约定凡是用 BigDecimal 做累加累减操作必须显式赋值给一个新的变量或者覆盖原变量并通过代码评审重点检查这一类语句。另外在循环中累加金额时可以在循环外声明变量循环内用total total.add(item)的方式更新避免创建过多中间引用。还有一点不得不提既然是不可变的那就意味着每次运算都会产生新的对象。极端性能场景下这确实会有额外开销但是在一个日均订单量在百万级别的系统里这点开销跟保证金额不差错比起来根本不值一提。如果真遇到性能瓶颈再考虑用MutableBigDecimal之类的替代方案不要一开始就过度优化。3. 核心运算实战加减乘除与舍入策略3.1 add、subtract、multiply这几个相对省心加减乘三种运算只要没有除法的参与通常不涉及舍入BigDecimal 会让结果自动携带足够的精度。看几个例子BigDecimal price new BigDecimal(10.50); BigDecimal quantity new BigDecimal(3); // 乘法单价 × 数量 BigDecimal total price.multiply(quantity); System.out.println(total); // 31.50注意到10.50 × 3的结果是 31.50末尾的 0 被保留了scale 是 2。这个特性在金额计算中非常友好因为金额往往需要固定两位小数乘法在多数情况下能自动维持两位精度。加法和减法就更容易理解了BigDecimal a new BigDecimal(10.20); BigDecimal b new BigDecimal(5.30); System.out.println(a.add(b)); // 15.50 System.out.println(a.subtract(b)); // 4.90我需要提醒一个细节结果的小数位数会取两个操作数中较大的 scale。10.20加5.3的结果是15.50还是15.5答案是15.50因为10.20的 scale 是 2比5.3的 scale 大结果沿用 2 位小数。这个规则大多数时候符合直觉但你需要知道它的存在否则在断言测试结果的时候可能会因为末尾多一个 0 而失败。如果两个数的小数位数不一样而你又想要固定的小数位数最简单的办法是在运算前统一用setScale把两个数都调整到目标精度。下面这段代码演示了这个过程BigDecimal a new BigDecimal(10.1); BigDecimal b new BigDecimal(5.234); BigDecimal aAdjusted a.setScale(2, RoundingMode.HALF_UP); BigDecimal bAdjusted b.setScale(2, RoundingMode.HALF_UP); BigDecimal sum aAdjusted.add(bAdjusted); // 15.33金额计算里先统一精度再运算的写法能显著减少意外结果。3.2 divide五百年来最难缠的方法BigDecimal 的divide方法是无数人初次接触时最容易翻车的地方。它不像add那样直接返回结果因为有些除法是无限循环小数比如 1 除以 3。如果你不指定结果的小数位数和舍入策略它就会抛出一个ArithmeticException提示 Non-terminating decimal expansion。看个典型的报错代码BigDecimal one new BigDecimal(1); BigDecimal three new BigDecimal(3); System.out.println(one.divide(three)); // 运行时抛出 ArithmeticException: Non-terminating decimal expansion这个异常着实吓到过不少新手。实际上它保护了你——如果你不知道要保留几位小数程序就不该随便替你做主。正确的用法是指定小数位数和舍入方式BigDecimal result one.divide(three, 4, RoundingMode.HALF_UP); System.out.println(result); // 0.3333参数含义很直白保留 4 位小数用四舍五入。在日常业务里scale定多少取决于需求。价格分摊场景常见的是 2 位小数给前端展示但内部算明细时最好保留 4 位甚至更多最后汇总时再处理尾差这个中间多留几位最终结果再舍入的原则非常实用。RoundingMode有八个枚举值真正常用到的也就以下几个HALF_UP四舍五入最符合人直觉的规则。HALF_DOWN五舍六入即 2.5 舍为 23.5 入为 4。HALF_EVEN银行家舍入五之后看前一位奇偶奇数进位、偶数舍去。适合统计分析但注意它不符合一般财务直觉。CEILING/FLOOR朝正无穷/负无穷方向舍入适合需要明确上下界的方向性计算。UP/DOWN远离零/靠近零应用较少。我在团队里定的规矩是非特殊情况一律用HALF_UP遇到监管或统计口径需要特殊处理时再另行指定并在代码注释里写清楚为什么。3.3 setScale手动控制小数位数setScale是精确控制结果精度的最直接手段。它的第一个参数是目标小数位数第二个参数是舍入策略。BigDecimal value new BigDecimal(123.456); BigDecimal twoScale value.setScale(2, RoundingMode.HALF_UP); System.out.println(twoScale); // 123.46如果把一个精度高的数往精度低的方向舍入策略参数是必须的否则同样会抛ArithmeticExceptionBigDecimal value new BigDecimal(123.456); value.setScale(2); // 异常因为舍入策略未指定时如果原值有多余的小数位它不知道该怎么做从低精度向高精度调整时第二个参数可以省略BigDecimal value new BigDecimal(123.4); System.out.println(value.setScale(4)); // 123.4000这种补零行为非常有用尤其在需要对齐金额小数位的场景。订单金额 123.4 元要展示成 123.40 元直接 setScale(2) 即可。还有一个骚操作值得提一下setScale(0)配合不同的RoundingMode可以做取整运算。比如new BigDecimal(5.6).setScale(0, RoundingMode.DOWN)结果是 5new BigDecimal(5.6).setScale(0, RoundingMode.CEILING)结果是 6。3.4 运算链的连式写法与可读性建议BigDecimal 的方法都是返回新对象天然适合链式调用。不过链越长可读性越差一旦中间某一步精度设定错了排查难度也成倍上升。我比较推荐的写法是分步赋值每一步变量名都能表达业务含义BigDecimal unitPrice new BigDecimal(49.90); BigDecimal quantity new BigDecimal(3); BigDecimal discount new BigDecimal(0.85); BigDecimal subtotal unitPrice.multiply(quantity); // 149.70 BigDecimal payAmount subtotal.multiply(discount).setScale(2, RoundingMode.HALF_UP); // 127.245 - 127.25别看最后一行写了两步它实际上等价于先乘再舍入。如果项目里有人追求漂亮的链式调用我建议仅在每一步意图清晰时使用不然 debug 时你会非常想念那些有名字的中间变量。4. 必须知道的避坑清单4.1 坑一用 double 构造 BigDecimal这是最高频的坑没有之一。我在 2.1 节其实已经展示过这里再强调一次它的严重性。new BigDecimal(0.1)产生的那个超长小数当你把它传给数据库、展示给用户时都会造成巨大的困惑。BigDecimal amount new BigDecimal(0.1); System.out.println(amount); // 0.1000000000000000055511151231257827021181583404541015625如果这段代码出现在金融系统里后果就是账面金额跟实际金额对不上。记住两条铁律从字符串构造new BigDecimal(0.1)从 double 构造BigDecimal.valueOf(0.1)或BigDecimal.valueOf(doubleVar)内部会走Double.toString的双保险逻辑。还有一个相近的坑从 JSON 反序列化 BigDecimal 字段时如果 JSON 里的金额是数字类型如 19.99某些反序列化框架会先解析成 double 再转 BigDecimal从而引入同样的精度问题。稳妥做法是让前端把金额字段作为 string 传或者在反序列化配置里指定用字符串方式读取。这个坑在对接第三方支付回调时偶有发生值得警惕。4.2 坑二equals 和 compareTo 不是一回事BigDecimal 的equals方法同时比较数值和 scale也就是说1.0和1.00在 equals 看来是不相等的。而compareTo只比较数值1.0和1.00是相等的。BigDecimal a new BigDecimal(1.0); BigDecimal b new BigDecimal(1.00); System.out.println(a.equals(b)); // false因为 scale 不同 System.out.println(a.compareTo(b)); // 0因为数值相等这个区别如果没搞清楚业务里会出现很多匪夷所思的 bug。比如你查数据库拿到一个1.00scale2跟代码里 new 出来的1.0scale1做 equals 判断结果 false于是你的逻辑绕了远路甚至直接走进错误分支。判断 BigDecimal 大小或相等时一律用compareTo。它返回 -1、0、1 分别表示小于、等于、大于使用起来就像Integer.compareTo。利用compareTo我们还能做范围校验if (amount.compareTo(BigDecimal.ZERO) 0) { // amount 大于 0 } if (amount.compareTo(minValue) 0 amount.compareTo(maxValue) 0) { // amount 在区间内 }这个写法的好处是BigDecimal 的原生比较语义是纯数值的不会因为精度不同产生干扰。4.3 坑三浮点数判断 0 和用 比较不要用equals去判断一个 BigDecimal 是否为 0因为0.00的 equals 跟0是不相等的。判断 0 应该用compareToBigDecimal zero new BigDecimal(0.00); System.out.println(zero.compareTo(BigDecimal.ZERO) 0); // true顺便提一句常量BigDecimal.ZERO的 scale 是 0它是一个整数 0。金融系统里有个常见需求是金额不能为负正确的写法是if (amount.compareTo(BigDecimal.ZERO) 0) { throw new IllegalArgumentException(金额不能为负); }不要写成amount.signum() -1之外的判断——虽然 signum() 也行但比较语义不如 compareTo 直观。另外注意BigDecimal.ZERO与new BigDecimal(0.00)的 scale 不一致用 equals 判断必然失败这是同一个问题的变体。4.4 坑四格式化输出与科学计数法当数值很小时BigDecimal 的toString()会输出科学计数法这会让前端展示出现1E-7这种令人生畏的字符串。解决方式是用toPlainString()BigDecimal tiny new BigDecimal(0.0000001); System.out.println(tiny.toString()); // 1E-7 System.out.println(tiny.toPlainString()); // 0.0000001如果要格式化带千分位的金额展示用DecimalFormat配合BigDecimal时也要小心。DecimalFormat默认会把输入对象转换成 double 再格式化这又会引入精度损失。推荐的做法是用BigDecimal的setScale先定好要展示的位数然后用DecimalFormat的setParseBigDecimal(true)让它按字符串解析DecimalFormat df new DecimalFormat(#,##0.00); df.setParseBigDecimal(true); BigDecimal amount new BigDecimal(1234567.895); String formatted df.format(amount.setScale(2, RoundingMode.HALF_UP)); System.out.println(formatted); // 1,234,567.90顺带说一句不要用String.format(%.2f, bigDecimal)因为%f格式符的底层是浮点格式化同样会将 BigDecimal 转成 double舍入和精度都会失真。4.5 坑五运算时不指定 MathContext / 舍入模式引发异常除了 divide 之外pow、sqrt等方法在运算结果无法精确表达时同样会抛出ArithmeticException。以divide为最常见场景但divideToIntegralValue和remainder的组合运算也容易踩坑。BigDecimal numerator new BigDecimal(10); BigDecimal denominator new BigDecimal(3); BigDecimal quotient numerator.divideToIntegralValue(denominator); // 3 BigDecimal remainder numerator.remainder(denominator); // 1divideToIntegralValue返回整数部分remainder返回余数这两个组合起来可以避免除法无限循环的问题。如果业务上需要商和余数比单独调用 divide 再处理尾差要清晰得多。此外当你在一个方法里多次调用divide时建议抽一个公共工具方法把 scale 和 roundingMode 收口到一处避免每个调用方各写各的导致精度语义混乱。我们项目里就有一个MoneyArith工具类统一封装了加减乘除和舍入规则这个做法值得推广。5. 综合实操从需求到落地的完整示例5.1 场景还原电商订单金额分摊假设这样一个需求用户买了几件商品订单总额是 100 元要按比例分摊到三个商品明细上分摊金额之和必须等于订单总额不能多一分也不能少一分。这是一个非常经典的 BigDecimal 应用场景。很多人拿到需求后直接做除法然后每个明细单独四舍五入最后发现明细合计跟总额差了 0.01 元。正确的做法是先按最大精度分配再把尾差差额加到最后一个明细上。public class OrderAmountAllocator { // 分摊总金额 100 元到三件商品权重分别为 3、3、4 public static void main(String[] args) { BigDecimal total new BigDecimal(100.00); // 模拟三个商品按权重分摊权重之和为 10 BigDecimal[] weights { new BigDecimal(3), new BigDecimal(3), new BigDecimal(4) }; BigDecimal weightSum new BigDecimal(10); BigDecimal[] results new BigDecimal[weights.length]; BigDecimal allocatedSum BigDecimal.ZERO; for (int i 0; i weights.length; i) { // 先按权重比例计算保留 4 位小数避免过早舍入 BigDecimal ratio weights[i].divide(weightSum, 10, RoundingMode.HALF_UP); BigDecimal share total.multiply(ratio).setScale(2, RoundingMode.HALF_UP); results[i] share; allocatedSum allocatedSum.add(share); } // 计算尾差 BigDecimal diff total.subtract(allocatedSum); // 将尾差加到第一个明细上 if (diff.compareTo(BigDecimal.ZERO) ! 0) { results[0] results[0].add(diff); } BigDecimal check BigDecimal.ZERO; for (BigDecimal result : results) { check check.add(result); } System.out.println(分摊结果: Arrays.toString(results)); System.out.println(校验合计: check); // 100.00 } }这里面的关键点有三个第一权重比例不要直接舍入到 2 位先用 10 位精度做中间计算保证比例值的精度足够第二真实分摊金额保留 2 位小数展示第三尾差修正放在最后一步修正量通常就是 ±0.01 以内。实际项目里尾差修正的策略有多种加到最后一个明细、加到金额最大的明细、或按顺序加到第一个。具体用哪种要看产品需求但核心原则不变先算完所有明细最后统一做差额修正不能边算边修正。5.2 金额运算的工具类封装我始终建议把金额运算收拢到一个工具类而不是散布在各个业务代码里。下面是一个简化版的设计public final class MoneyArith { private static final int DEFAULT_SCALE 2; private static final RoundingMode DEFAULT_ROUNDING RoundingMode.HALF_UP; private MoneyArith() { } public static BigDecimal add(BigDecimal a, BigDecimal b) { return nullSafe(a).add(nullSafe(b)); } public static BigDecimal subtract(BigDecimal a, BigDecimal b) { return nullSafe(a).subtract(nullSafe(b)); } public static BigDecimal multiply(BigDecimal a, BigDecimal b) { return nullSafe(a).multiply(nullSafe(b)).setScale(DEFAULT_SCALE, DEFAULT_ROUNDING); } public static BigDecimal divide(BigDecimal a, BigDecimal b) { return nullSafe(a).divide(nullSafe(b), DEFAULT_SCALE, DEFAULT_ROUNDING); } private static BigDecimal nullSafe(BigDecimal value) { return value null ? BigDecimal.ZERO : value; } public static BigDecimal toDisplay(BigDecimal value) { return nullSafe(value).setScale(DEFAULT_SCALE, DEFAULT_ROUNDING); } }这里有个值得讨论的点multiply我强行做了setScale(2)。单价乘数量之后正常结果的小数位数是两个操作数 scale 之和常常会超过 2 位比如19.90 × 3结果是59.702 位但19.90 × 0.85结果是16.9154 位。如果业务要求展示金额必须两位小数乘完直接舍入到 2 位是最干净的方式。但要注意如果中间计算还需要更高精度就不要调用工具类的multiply而是直接裸调 Math API见仁见智。这类工具类的意义在于把 null 防护、默认精度、默认舍入规则统一收口。项目里如果每个业务对象都用裸的add、multiply总有一天会有人在某处用错舍入模式然后线上金额多一分钱少一分钱排查成本极高。5.3 前端展示与数据库存储的精度转换数据库 DECIMAL 类型和 Java BigDecimal 是天生的好搭档。你在实体类里定义BigDecimal priceJDBC 会直接映射不会经过 double 中转。需要注意的反而是一些中间 DTO 和前端交互。我个人遇到过的一个真实问题接口返回给前端一个 BigDecimal 字段前端 JavaScript 默认把它当 number 处理。JavaScript 的 number 本身也是 IEEE 754 浮点数同样有精度限制超过 2^53 的整数或者某些小数就会失真。如果一个金额是 9007199254740993 这样的超大数传给前端再原样传回来它可能已经变成了 9007199254740992。这是一个跨语言的精度陷阱。解决办法通常有两种一是把金额字段在 JSON 序列化时转成字符串前端拿字符串做展示不做运算二是如果前端必须要参与金额计算比如购物车试用那就只能约定所有计算在后端完成前端只负责展示。从工程实践来看方案一更省心你只需要在 DTO 的金额字段上加一个序列化为字符串的注解或自定义序列化器问题就解决了。后端还有一个常见需求把 BigDecimal 传给报表工具或导出 Excel。POI 的setCellValue如果传 BigDecimal 会默认转成 double 写入单元格大整数场景同样会失真。稳妥做法是先把bigDecimal.toPlainString()写入单元格并设置单元格格式为文本或保留足够小数位的数字格式。这个细节看似不起眼但在金额核对报表这种场景里差异一望即知能避免不少纠纷。5.4 MathContext 与精度控制的进阶用法除了直接指定 scale 和 roundingModeBigDecimal 还提供了MathContext来统一控制精度。MathContext 由 precision有效数字位数和 RoundingMode 组成。看个例子MathContext mc new MathContext(5, RoundingMode.HALF_UP); BigDecimal a new BigDecimal(1.23456); BigDecimal b new BigDecimal(2.34567); BigDecimal sum a.add(b, mc); System.out.println(sum); // 3.5802总共保留了 5 位有效数字MathContext控制的是有效数字位数而不是小数点后的位数所以它能限制整体数字的长度适合一些科学计算场景。但在金额计算里我更推荐直接控制 scale因为金额的业务语义是保留几位小数而不是保留几位有效数字。这两者的差异在数值很小的时候尤其明显——0.00012345保留 5 位有效数字会变成0.00012345本身但保留 5 位小数就变成0.00012。顺便说一个实际高频需求开根号和幂运算。BigDecimal.pow(int)直接可用但结果可能超长如果要限制结果精度需要配合 MathContextBigDecimal base new BigDecimal(1.05); BigDecimal result base.pow(12, new MathContext(10, RoundingMode.HALF_UP)); System.out.println(result); // 1.795856326至于平方根Java 9 之后提供sqrt(MathContext)方法Java 8 或更早版本没有内置 sqrt需要自己用牛顿迭代法实现或者用第三方库。这部分在实际业务里用得不算多但如果处理年化利率这类场景你会需要它。6. 常见问题与面试高频点6.1 经典问题速查表问题场景错误示例正确方案原因double 转 BigDecimalnew BigDecimal(0.1)BigDecimal.valueOf(0.1)直接构造会保留 double 的二进制近似值判断数值相等a.equals(b)a.compareTo(b) 0equals 同时比较 scale1.0 不等于 1.00除法不指定精度a.divide(b)a.divide(b, 4, RoundingMode.HALF_UP)无限循环小数会抛异常setScale 不指定舍入a.setScale(2)a.setScale(2, RoundingMode.HALF_UP)原值有额外小数位时抛异常toString 直接给前端amount.toString()在极小值输出1E-7amount.toPlainString()避免科学计数法输出金额序列化给 JSBigDecimal 直传成 JSON number序列化为字符串JS number 是 IEEE 754有精度上限累加不接收返回值total.add(item)total total.add(item)BigDecimal 不可变原对象不改变这张表几乎覆盖了我日常 Code Review 里遇到的所有 BigDecimal 相关问题。每一行背后都有真实的事故案例不是纸上谈兵。6.2 排查思路金额对不上账从哪里入手线上出了金额计算不一致的问题先别急着翻业务代码。我建议按下面的顺序排查第一找源头数据。把钱的最初来源找出来看它是字符串、double、数据库 DECIMAL、还是前端传过来的 JSON number。如果源头就是 double那大概率问题在数据的产生阶段就已经埋下了后面用 BigDecimal 也救不回来。源头是数据库 DECIMAL 且 JDBC 映射正常通常没问题。第二看舍入场景。找出所有调用 divide 和 setScale 的地方检查是否每一个都明确指定了舍入策略以及策略是否符合业务口径。尤其注意同一个系统中的不同模块可能用了不同的舍入规则例如订单模块用 HALF_UP营销模块用 HALF_EVEN两边一汇总就出现分差。第三检查尾差处理。在分摊、折扣、优惠券抵扣这类涉及多个金额加总必须等于总额的逻辑里优先看尾差修正是否做了以及修正策略是否统一。第四检查格式化输出。如果金额在存入数据库之前经过了 DecimalFormat 或 String.format 的格式化再解析回 BigDecimal就可能在格式化过程中被舍入。这类 bug 隐蔽的地方在于代码能跑通数据也是合法的只是差了一分钱。按这个顺序排查绝大多数金额问题都能在半小时内定位到根因。相比直接就满屏打印日志慢慢翻这个方法高效得多。6.3 面试中经常问到的 BigDecimal 知识点BigDecimal 在面试里几乎是必考题。面试官问的点主要集中在浮点数精度问题成因、BigDecimal 的构造差异、equals 与 compareTo 的区别、除法为什么要指定舍入、以及如何做金额分摊。这些点在本文前几节都已经覆盖。有一个容易被小看的点是为什么 BigDecimal 是不可变的答案是 BigDecimal 内部持有 BigInteger 和 scale这些值一旦创建后不会更改所有算术方法返回新对象。这个设计能保证 BigDecimal 可以在多线程环境下安全共享不需要加锁。面试中如果再深入一点面试官可能会问 BigInteger 的底层实现即内部是 int[] 数组存储二进制补码表示的整数这个话题可以单独写一篇本文不展开。再有个面试官爱问的思维题给你一个 double 0.1你怎么证明它不等于十进制的 0.1答案是把它打印到足够多的小数位或者用new BigDecimal(double)展示出它的精确值。0.1在二进制中是无限循环小数 0.00011001100110011...浮点数只能截断存储所以它永远不可能是精确的 0.1。能把这个逻辑理清楚的候选人通常对计算机组成原理和数值分析都有扎实的基础。7. 性能与替代方案7.1 BigDecimal 的性能到底差到什么程度BigDecimal 确实比 double 慢但慢多少取决于运算类型。加法减法大约慢几十倍到一百倍不等乘法和除法更重因为内部走的是 BigInteger 的大整数运算路径。如果在海量数据场景里用 BigDecimal 做百万次乘法单次耗时上升到微秒级别累积起来会比较可观。但我要给一个更务实的判断绝大多数业务系统性能瓶颈根本不在 BigDecimal 上而在数据库查询、网络 IO、外部接口调用这些环节。一次数据库查询耗时动辄几毫秒而 BigDecimal 哪怕做一万次加法也就是一两个毫秒的量级。真要优化优先优化 IO而不是把金额计算换成 double。如果确实有极端性能要求比如高频交易场景里的风控计算每一次运算都至关重要可以考虑用long表示以分为单位的金额做纯整数运算最后再转 BigDecimal 或字符串展示。这种方案本质上是自己维护 decimal 语义可以规避 BigDecimal 的对象开销但代价是失去了 BigDecimal 内置的精度控制和舍入策略业务方必须自己处理所有边界情况开发成本直线上升。我个人的观点是不到万不得已不要这么做除非你确定团队里有能力兜底这些坑的人。7.2 不可变对象的防御性拷贝问题BigDecimal 不可变意味着没有 setter 修改风险但还有一个细节需要留意如果你从外部 API 拿到了一个 BigDecimal 对象而这个对象可能不是你信任的代码创建的比如某框架通过反射修改过内部字段理论上是可以被攻破的。不过在普通业务系统里这个场景几乎没有我不建议为了防御这种极端威胁在每次传递时都做new BigDecimal(original.toPlainString())这样的防御性拷贝过度设计反而影响性能和可读性。真正值得关注的防御性场景是从数据库读出的 DECIMAL 字段在某些老版本 JDBC 驱动里可能返回的是 java.math.BigDecimal 的兼容类或者由其他序列化框架反序列化出来的异常 BigDecimal。这种情况用compareTo做校验通常就够用了。BigDecimal 即使内部被篡改它的数值语义依然由 BigInteger 保证只有当 BigInteger 本身也是非正规对象时才需要警惕而这在标准 JDK 中几乎不可能发生。7.3 其他精确数值方案对比用表格对比一下当前主流的方案方案精度性能使用场景double/float二进制近似有精度误差极高科学计算、图形学、一般工程近似BigDecimal任意精度十进制精确较低金额、税率、需要人类可读精度的所有场景long以分为单位精确到分整数运算极高极高性能要求的内部金额计算第三方库如 Joda-Money基于 BigDecimal 或 long 封装视实现而定偏好领域建模、需要货币单位语义的场景Joda-Money 在货币建模上有优势它封装了货币单位如 CNY、USD和金额避免你忘记货币单位导致跨币种计算错误。不过它的底层很多操作还是委托给 BigDecimal所以性能没有数量级的差别。如果你的项目依赖管理方便引入 Joda-Money 也可以但如果只是单纯算钱标准 BigDecimal 项目内工具类就完全够用不必额外引依赖。8. 个人实践的补充建议8.1 代码规范与团队约定在我自己带过的项目里BigDecimal 的用法一定要写进团队的代码规范。光靠口头传递经验总有人会漏掉关键细节。我在规范里固定了几条硬性条款这里分享给你参考所有金额字段的类型必须是 BigDecimal禁止用 double 或 float 定义金额。金额的默认精度为 2 位小数默认舍入策略为 HALF_UP。从外部接口获取金额时优先按字符串解析。所有涉及金额的除法运算必须显式指定 scale 和 RoundingMode。BigDecimal 比较一律用 compareTo禁止用 equals。金额字段在 DTO 层输出时序列化为字符串。禁止直接使用new BigDecimal(double)统一使用new BigDecimal(String)或BigDecimal.valueOf。这些条款每一条都有真实事故案例支撑。比如禁止 equals 比较金额这一条就是来自一次线上优惠券叠加失败的事故。当时运营配置的优惠券面额是 5.00系统内的抵扣金额变量算出来是 5.0一个 equals 判断直接判为不相等导致一批订单没有享受优惠事后赔付用户权益的成本远高于写对这行代码的成本。8.2 一个亲历的线上事故复盘有一回线上系统出现了一个诡异问题用户下单后订单金额偶尔会跟后台订单明细的汇总金额差一分钱。一开始大家都以为是分摊算法的问题把分摊逻辑翻来覆去查了好几遍没发现异常。后来注意到差一分钱的情况只在某几条特定明细组合下出现而且规律是个别明细多一分另一条明细少一分。最终定位到根因某个老模块在计算折扣时先调用了divideToIntegralValue取整再用原始金额减去取整后的单价乘以数量来算折扣这一步本身没问题但另一个新模块在同样的计算路径上直接调用了divide(..., 2, HALF_UP)导致两条计算路径的中间结果精度不一致汇总时对不上。修复方案也很简单把新模块的除法精度从 2 位改为 4 位做中间计算最后展示时再舍入到 2 位两边结果就完全一致了。这个事故给我的教训非常深刻BigDecimal 的精度问题往往不是某个单点写错了而是多个模块各自看起来正确的精度处理方式在衔接处产生了冲撞。尤其是同一个数值经由不同模块处理后再汇总时中间精度不一致是最大的隐患源。所以我在每个涉及金额的项目里都会推行中间计算统一多保留几位、最终展示统一舍入的策略让精度变化的边界足够清晰。8.3 后续扩展方向BigDecimal 这篇内容其实还有不少可以深入的方向。比如 BigInteger 本身的底层算法、MathContext 在大数运算中的行为、Java 8 以下版本的 BigDecimal 限制、以及各类 JSON 库如 Jackson、Gson对 BigDecimal 序列化的不同默认行为。如果你在实际项目中遇到了 BigDecimal 相关的疑难问题一个建议是先把异常堆栈里的关键信息读全再对照本文的避坑清单逐一排查多数情况下都能找到答案。数值计算这门功夫说到底是精确谨慎四个字。写代码的时候多想一层这个金额从哪来经过哪些中间运算最终要到哪去精度在每一段是否保得住。想清楚了BigDecimal 就是你手里一把十分趁手的工具。
1. 项目概述1.1 为什么说 BigDecimal 是精确计算的基石做 Java 开发的人迟早会撞上浮点数精度这道墙。我刚工作那年写过一段计算订单优惠金额的代码用的就是 double。那会儿觉得能跑就行直到某天财务跑过来说对不上账客户单价 0.1 元的东西买了三件合计金额显示成了 0.30000000000000004。那一刻我才意识到double 这种二进制浮点数天生就没法精确表达 0.1 这样的十进制小数。它的底层是 IEEE 754 标准用有限的二进制位去逼近一个十进制小数一旦涉及货币、利息、百分比、库存数量这类对精度要求极高的场景误差就会从毫厘之间滚成不容忽视的差池。Java 的 BigDecimal 就是为解决这个问题而生的。它是 java.math 包下的一个不可变类能够以任意精度表示十进制数并且对加减乘除、取余、比较、舍入都有明确的语义定义。实体行业的计价系统、金融系统的账务计算、电商平台的优惠分摊凡是涉及钱的运算基本都绕不开它。更关键的是即便你不做金融业务只要你的程序里出现过 0.1 0.2 不等于 0.3 这种诡异现象你就需要认真审视一下自己是不是该引入 BigDecimal 了。这篇文章适合刚接触 BigDecimal 的新手也适合已经用了几年但偶尔还会踩坑的开发者。我会从浮点数为什么不可靠讲起然后逐步展开 BigDecimal 的核心用法、精度模型、舍入策略再把那些真实项目里踩过的坑挨个翻出来最后附上一些高频问题的排查速查。读完这篇基本的精确计算场景你都能应对别人代码里那些隐蔽的金额 bug你也能一眼看穿。1.2 BigDecimal 到底解决了什么问题先做个简单的实验对比double a 0.1; double b 0.2; System.out.println(a b); // 输出 0.30000000000000004 BigDecimal c new BigDecimal(0.1); BigDecimal d new BigDecimal(0.2); System.out.println(c.add(d)); // 输出 0.3同样的两个数相加double 得到了一个看起来像0.30000000000000004的怪物而 BigDecimal 老老实实地给出了 0.3。差别本质在于double 用二进制近似十进制BigDecimal 则直接把十进制数值以未缩放值加小数位数的形式存下来。BigDecimal 的内部结构其实不复杂它由两部分组成一个任意精度的整数BigInteger作为未缩放值以及一个 32 位整数表示的小数位数 scale。比如new BigDecimal(123.45)未缩放值就是 12345scale 是 2含义是 12345 × 10⁻²。这种存法保证了人写的十进制小数是什么样它在内存里就是什么样不存在二进制转换的近似过程。这才是 BigDecimal 能作为精确计算基石的根本原因。在展开用法之前我还得强调一个原则如果你需要的是精确的十进制算术就不要用 double 来参与中间运算哪怕只在最后做一次转换也不行。正确的姿势是从源头就用字符串构造 BigDecimal或者用 BigDecimal.valueOf 从已有数值转换。后文会专门讲这个点因为它是新手最容易踩的第一道坑。2. BigDecimal 的核心概念与精度模型2.1 从构造说起三种创建方式差别能要命BigDecimal 的构造函数有很多但日常开发中真正用得上的就三类。我先说最推荐的直接用字符串构造。BigDecimal fromString new BigDecimal(19.99);之所以推荐字符串是因为它忠实保留了原始数字的每一位。你用new BigDecimal(0.10)它的 scale 是 2值就是 0.10带一个明确的精度语义你用new BigDecimal(0.1)scale 是 1。这两个数在数值上相等但在精度语境下并不完全一样在后续的除法、格式化输出、比较时会有微妙差异。第二类是BigDecimal.valueOf它适合从已有的 double 或 long 转换。看下面这段代码double price 0.1; BigDecimal fromValueOf BigDecimal.valueOf(price); // 结果是 0.1 BigDecimal fromDouble new BigDecimal(price); // 结果是 0.1000000000000000055511151231257827021181583404541015625同一个 double 0.1两种方式转出来的结果天差地别。原因是new BigDecimal(double)会把这个 double 的二进制精确值完完整整地转换出来而这个精确值本身就是一个长得离谱的十进制小数BigDecimal.valueOf内部则调用了Double.toString先把 double 转成人能看懂的字符串形式再基于字符串构造所以结果看起来干净利落。凡是需要把 double 转 BigDecimal 的场景一律用valueOf不要直接 new。第三类是new BigDecimal(int)和new BigDecimal(long)这两个没什么坑直接用即可。整数不存在精度问题放心使用。还有一个小众场景从数据库的 DECIMAL 列取值时JDBC 驱动返回的通常是 BigDecimal 对象直接使用即可不需要额外转换。2.2 精度模型scale、precision 和科学计数法BigDecimal 有两个容易混淆的属性scale小数位数和 precision有效数字位数。打个比方如果说 BigDecimal 是一把尺子scale 就是这把尺子上刻了多少位小数precision 则是这把尺子上总共显示了多少位有效数字。BigDecimal a new BigDecimal(123.4500); System.out.println(a.scale()); // 4 System.out.println(a.precision()); // 7123.4500的 scale 是 4因为小数点后有四位precision 是 7因为全部有效数字是 1、2、3、4、5、0、0 七个。注意末尾的 0 也是有效精度的一部分这对保留金额两位小数的场景很关键后面讲格式化时会用到。还有一个容易撞上的坑极小的数会被表示成科学计数法。比如BigDecimal b new BigDecimal(0.000001); System.out.println(b); // 0.000001 System.out.println(b.scale()); // 6 BigDecimal c new BigDecimal(1E-7); System.out.println(c.scale()); // 7但打印时可能显示 1E-7当 scale 小于 0 或数值过小/过大时toString 可能输出科学计数法形式比如1E3或1E-7。在对接前端接口时这种输出会让 JSON 序列化出现金额显示成了科学计数法的诡异 bug。后面实操篇会给出格式化输出方案这里先记住一个结论BigDecimal 转 String 给前端时不要直接调用 toString要指定格式或调用 toPlainString这个方法总能输出普通十进制表示不会用科学计数法。2.3 不可变性BigDecimal 每个操作都返回新对象BigDecimal 和 String 一样是不可变类。add、subtract、multiply、divide这些方法都不会修改调用者自身而是返回一个新的 BigDecimal。这一点看着简单却是我见过最多 bug 的源头。BigDecimal total new BigDecimal(100); total.add(new BigDecimal(50)); System.out.println(total); // 输出 100不是你期望的 150上面的代码不会报错结果却完全不对因为add的返回值被丢弃了。正确写法是BigDecimal total new BigDecimal(100); total total.add(new BigDecimal(50));类似这种结果没接住的问题代码评审的时候肉眼很难发现因為编译期既不警告也不报错。我的习惯是在项目里加一个约定凡是用 BigDecimal 做累加累减操作必须显式赋值给一个新的变量或者覆盖原变量并通过代码评审重点检查这一类语句。另外在循环中累加金额时可以在循环外声明变量循环内用total total.add(item)的方式更新避免创建过多中间引用。还有一点不得不提既然是不可变的那就意味着每次运算都会产生新的对象。极端性能场景下这确实会有额外开销但是在一个日均订单量在百万级别的系统里这点开销跟保证金额不差错比起来根本不值一提。如果真遇到性能瓶颈再考虑用MutableBigDecimal之类的替代方案不要一开始就过度优化。3. 核心运算实战加减乘除与舍入策略3.1 add、subtract、multiply这几个相对省心加减乘三种运算只要没有除法的参与通常不涉及舍入BigDecimal 会让结果自动携带足够的精度。看几个例子BigDecimal price new BigDecimal(10.50); BigDecimal quantity new BigDecimal(3); // 乘法单价 × 数量 BigDecimal total price.multiply(quantity); System.out.println(total); // 31.50注意到10.50 × 3的结果是 31.50末尾的 0 被保留了scale 是 2。这个特性在金额计算中非常友好因为金额往往需要固定两位小数乘法在多数情况下能自动维持两位精度。加法和减法就更容易理解了BigDecimal a new BigDecimal(10.20); BigDecimal b new BigDecimal(5.30); System.out.println(a.add(b)); // 15.50 System.out.println(a.subtract(b)); // 4.90我需要提醒一个细节结果的小数位数会取两个操作数中较大的 scale。10.20加5.3的结果是15.50还是15.5答案是15.50因为10.20的 scale 是 2比5.3的 scale 大结果沿用 2 位小数。这个规则大多数时候符合直觉但你需要知道它的存在否则在断言测试结果的时候可能会因为末尾多一个 0 而失败。如果两个数的小数位数不一样而你又想要固定的小数位数最简单的办法是在运算前统一用setScale把两个数都调整到目标精度。下面这段代码演示了这个过程BigDecimal a new BigDecimal(10.1); BigDecimal b new BigDecimal(5.234); BigDecimal aAdjusted a.setScale(2, RoundingMode.HALF_UP); BigDecimal bAdjusted b.setScale(2, RoundingMode.HALF_UP); BigDecimal sum aAdjusted.add(bAdjusted); // 15.33金额计算里先统一精度再运算的写法能显著减少意外结果。3.2 divide五百年来最难缠的方法BigDecimal 的divide方法是无数人初次接触时最容易翻车的地方。它不像add那样直接返回结果因为有些除法是无限循环小数比如 1 除以 3。如果你不指定结果的小数位数和舍入策略它就会抛出一个ArithmeticException提示 Non-terminating decimal expansion。看个典型的报错代码BigDecimal one new BigDecimal(1); BigDecimal three new BigDecimal(3); System.out.println(one.divide(three)); // 运行时抛出 ArithmeticException: Non-terminating decimal expansion这个异常着实吓到过不少新手。实际上它保护了你——如果你不知道要保留几位小数程序就不该随便替你做主。正确的用法是指定小数位数和舍入方式BigDecimal result one.divide(three, 4, RoundingMode.HALF_UP); System.out.println(result); // 0.3333参数含义很直白保留 4 位小数用四舍五入。在日常业务里scale定多少取决于需求。价格分摊场景常见的是 2 位小数给前端展示但内部算明细时最好保留 4 位甚至更多最后汇总时再处理尾差这个中间多留几位最终结果再舍入的原则非常实用。RoundingMode有八个枚举值真正常用到的也就以下几个HALF_UP四舍五入最符合人直觉的规则。HALF_DOWN五舍六入即 2.5 舍为 23.5 入为 4。HALF_EVEN银行家舍入五之后看前一位奇偶奇数进位、偶数舍去。适合统计分析但注意它不符合一般财务直觉。CEILING/FLOOR朝正无穷/负无穷方向舍入适合需要明确上下界的方向性计算。UP/DOWN远离零/靠近零应用较少。我在团队里定的规矩是非特殊情况一律用HALF_UP遇到监管或统计口径需要特殊处理时再另行指定并在代码注释里写清楚为什么。3.3 setScale手动控制小数位数setScale是精确控制结果精度的最直接手段。它的第一个参数是目标小数位数第二个参数是舍入策略。BigDecimal value new BigDecimal(123.456); BigDecimal twoScale value.setScale(2, RoundingMode.HALF_UP); System.out.println(twoScale); // 123.46如果把一个精度高的数往精度低的方向舍入策略参数是必须的否则同样会抛ArithmeticExceptionBigDecimal value new BigDecimal(123.456); value.setScale(2); // 异常因为舍入策略未指定时如果原值有多余的小数位它不知道该怎么做从低精度向高精度调整时第二个参数可以省略BigDecimal value new BigDecimal(123.4); System.out.println(value.setScale(4)); // 123.4000这种补零行为非常有用尤其在需要对齐金额小数位的场景。订单金额 123.4 元要展示成 123.40 元直接 setScale(2) 即可。还有一个骚操作值得提一下setScale(0)配合不同的RoundingMode可以做取整运算。比如new BigDecimal(5.6).setScale(0, RoundingMode.DOWN)结果是 5new BigDecimal(5.6).setScale(0, RoundingMode.CEILING)结果是 6。3.4 运算链的连式写法与可读性建议BigDecimal 的方法都是返回新对象天然适合链式调用。不过链越长可读性越差一旦中间某一步精度设定错了排查难度也成倍上升。我比较推荐的写法是分步赋值每一步变量名都能表达业务含义BigDecimal unitPrice new BigDecimal(49.90); BigDecimal quantity new BigDecimal(3); BigDecimal discount new BigDecimal(0.85); BigDecimal subtotal unitPrice.multiply(quantity); // 149.70 BigDecimal payAmount subtotal.multiply(discount).setScale(2, RoundingMode.HALF_UP); // 127.245 - 127.25别看最后一行写了两步它实际上等价于先乘再舍入。如果项目里有人追求漂亮的链式调用我建议仅在每一步意图清晰时使用不然 debug 时你会非常想念那些有名字的中间变量。4. 必须知道的避坑清单4.1 坑一用 double 构造 BigDecimal这是最高频的坑没有之一。我在 2.1 节其实已经展示过这里再强调一次它的严重性。new BigDecimal(0.1)产生的那个超长小数当你把它传给数据库、展示给用户时都会造成巨大的困惑。BigDecimal amount new BigDecimal(0.1); System.out.println(amount); // 0.1000000000000000055511151231257827021181583404541015625如果这段代码出现在金融系统里后果就是账面金额跟实际金额对不上。记住两条铁律从字符串构造new BigDecimal(0.1)从 double 构造BigDecimal.valueOf(0.1)或BigDecimal.valueOf(doubleVar)内部会走Double.toString的双保险逻辑。还有一个相近的坑从 JSON 反序列化 BigDecimal 字段时如果 JSON 里的金额是数字类型如 19.99某些反序列化框架会先解析成 double 再转 BigDecimal从而引入同样的精度问题。稳妥做法是让前端把金额字段作为 string 传或者在反序列化配置里指定用字符串方式读取。这个坑在对接第三方支付回调时偶有发生值得警惕。4.2 坑二equals 和 compareTo 不是一回事BigDecimal 的equals方法同时比较数值和 scale也就是说1.0和1.00在 equals 看来是不相等的。而compareTo只比较数值1.0和1.00是相等的。BigDecimal a new BigDecimal(1.0); BigDecimal b new BigDecimal(1.00); System.out.println(a.equals(b)); // false因为 scale 不同 System.out.println(a.compareTo(b)); // 0因为数值相等这个区别如果没搞清楚业务里会出现很多匪夷所思的 bug。比如你查数据库拿到一个1.00scale2跟代码里 new 出来的1.0scale1做 equals 判断结果 false于是你的逻辑绕了远路甚至直接走进错误分支。判断 BigDecimal 大小或相等时一律用compareTo。它返回 -1、0、1 分别表示小于、等于、大于使用起来就像Integer.compareTo。利用compareTo我们还能做范围校验if (amount.compareTo(BigDecimal.ZERO) 0) { // amount 大于 0 } if (amount.compareTo(minValue) 0 amount.compareTo(maxValue) 0) { // amount 在区间内 }这个写法的好处是BigDecimal 的原生比较语义是纯数值的不会因为精度不同产生干扰。4.3 坑三浮点数判断 0 和用 比较不要用equals去判断一个 BigDecimal 是否为 0因为0.00的 equals 跟0是不相等的。判断 0 应该用compareToBigDecimal zero new BigDecimal(0.00); System.out.println(zero.compareTo(BigDecimal.ZERO) 0); // true顺便提一句常量BigDecimal.ZERO的 scale 是 0它是一个整数 0。金融系统里有个常见需求是金额不能为负正确的写法是if (amount.compareTo(BigDecimal.ZERO) 0) { throw new IllegalArgumentException(金额不能为负); }不要写成amount.signum() -1之外的判断——虽然 signum() 也行但比较语义不如 compareTo 直观。另外注意BigDecimal.ZERO与new BigDecimal(0.00)的 scale 不一致用 equals 判断必然失败这是同一个问题的变体。4.4 坑四格式化输出与科学计数法当数值很小时BigDecimal 的toString()会输出科学计数法这会让前端展示出现1E-7这种令人生畏的字符串。解决方式是用toPlainString()BigDecimal tiny new BigDecimal(0.0000001); System.out.println(tiny.toString()); // 1E-7 System.out.println(tiny.toPlainString()); // 0.0000001如果要格式化带千分位的金额展示用DecimalFormat配合BigDecimal时也要小心。DecimalFormat默认会把输入对象转换成 double 再格式化这又会引入精度损失。推荐的做法是用BigDecimal的setScale先定好要展示的位数然后用DecimalFormat的setParseBigDecimal(true)让它按字符串解析DecimalFormat df new DecimalFormat(#,##0.00); df.setParseBigDecimal(true); BigDecimal amount new BigDecimal(1234567.895); String formatted df.format(amount.setScale(2, RoundingMode.HALF_UP)); System.out.println(formatted); // 1,234,567.90顺带说一句不要用String.format(%.2f, bigDecimal)因为%f格式符的底层是浮点格式化同样会将 BigDecimal 转成 double舍入和精度都会失真。4.5 坑五运算时不指定 MathContext / 舍入模式引发异常除了 divide 之外pow、sqrt等方法在运算结果无法精确表达时同样会抛出ArithmeticException。以divide为最常见场景但divideToIntegralValue和remainder的组合运算也容易踩坑。BigDecimal numerator new BigDecimal(10); BigDecimal denominator new BigDecimal(3); BigDecimal quotient numerator.divideToIntegralValue(denominator); // 3 BigDecimal remainder numerator.remainder(denominator); // 1divideToIntegralValue返回整数部分remainder返回余数这两个组合起来可以避免除法无限循环的问题。如果业务上需要商和余数比单独调用 divide 再处理尾差要清晰得多。此外当你在一个方法里多次调用divide时建议抽一个公共工具方法把 scale 和 roundingMode 收口到一处避免每个调用方各写各的导致精度语义混乱。我们项目里就有一个MoneyArith工具类统一封装了加减乘除和舍入规则这个做法值得推广。5. 综合实操从需求到落地的完整示例5.1 场景还原电商订单金额分摊假设这样一个需求用户买了几件商品订单总额是 100 元要按比例分摊到三个商品明细上分摊金额之和必须等于订单总额不能多一分也不能少一分。这是一个非常经典的 BigDecimal 应用场景。很多人拿到需求后直接做除法然后每个明细单独四舍五入最后发现明细合计跟总额差了 0.01 元。正确的做法是先按最大精度分配再把尾差差额加到最后一个明细上。public class OrderAmountAllocator { // 分摊总金额 100 元到三件商品权重分别为 3、3、4 public static void main(String[] args) { BigDecimal total new BigDecimal(100.00); // 模拟三个商品按权重分摊权重之和为 10 BigDecimal[] weights { new BigDecimal(3), new BigDecimal(3), new BigDecimal(4) }; BigDecimal weightSum new BigDecimal(10); BigDecimal[] results new BigDecimal[weights.length]; BigDecimal allocatedSum BigDecimal.ZERO; for (int i 0; i weights.length; i) { // 先按权重比例计算保留 4 位小数避免过早舍入 BigDecimal ratio weights[i].divide(weightSum, 10, RoundingMode.HALF_UP); BigDecimal share total.multiply(ratio).setScale(2, RoundingMode.HALF_UP); results[i] share; allocatedSum allocatedSum.add(share); } // 计算尾差 BigDecimal diff total.subtract(allocatedSum); // 将尾差加到第一个明细上 if (diff.compareTo(BigDecimal.ZERO) ! 0) { results[0] results[0].add(diff); } BigDecimal check BigDecimal.ZERO; for (BigDecimal result : results) { check check.add(result); } System.out.println(分摊结果: Arrays.toString(results)); System.out.println(校验合计: check); // 100.00 } }这里面的关键点有三个第一权重比例不要直接舍入到 2 位先用 10 位精度做中间计算保证比例值的精度足够第二真实分摊金额保留 2 位小数展示第三尾差修正放在最后一步修正量通常就是 ±0.01 以内。实际项目里尾差修正的策略有多种加到最后一个明细、加到金额最大的明细、或按顺序加到第一个。具体用哪种要看产品需求但核心原则不变先算完所有明细最后统一做差额修正不能边算边修正。5.2 金额运算的工具类封装我始终建议把金额运算收拢到一个工具类而不是散布在各个业务代码里。下面是一个简化版的设计public final class MoneyArith { private static final int DEFAULT_SCALE 2; private static final RoundingMode DEFAULT_ROUNDING RoundingMode.HALF_UP; private MoneyArith() { } public static BigDecimal add(BigDecimal a, BigDecimal b) { return nullSafe(a).add(nullSafe(b)); } public static BigDecimal subtract(BigDecimal a, BigDecimal b) { return nullSafe(a).subtract(nullSafe(b)); } public static BigDecimal multiply(BigDecimal a, BigDecimal b) { return nullSafe(a).multiply(nullSafe(b)).setScale(DEFAULT_SCALE, DEFAULT_ROUNDING); } public static BigDecimal divide(BigDecimal a, BigDecimal b) { return nullSafe(a).divide(nullSafe(b), DEFAULT_SCALE, DEFAULT_ROUNDING); } private static BigDecimal nullSafe(BigDecimal value) { return value null ? BigDecimal.ZERO : value; } public static BigDecimal toDisplay(BigDecimal value) { return nullSafe(value).setScale(DEFAULT_SCALE, DEFAULT_ROUNDING); } }这里有个值得讨论的点multiply我强行做了setScale(2)。单价乘数量之后正常结果的小数位数是两个操作数 scale 之和常常会超过 2 位比如19.90 × 3结果是59.702 位但19.90 × 0.85结果是16.9154 位。如果业务要求展示金额必须两位小数乘完直接舍入到 2 位是最干净的方式。但要注意如果中间计算还需要更高精度就不要调用工具类的multiply而是直接裸调 Math API见仁见智。这类工具类的意义在于把 null 防护、默认精度、默认舍入规则统一收口。项目里如果每个业务对象都用裸的add、multiply总有一天会有人在某处用错舍入模式然后线上金额多一分钱少一分钱排查成本极高。5.3 前端展示与数据库存储的精度转换数据库 DECIMAL 类型和 Java BigDecimal 是天生的好搭档。你在实体类里定义BigDecimal priceJDBC 会直接映射不会经过 double 中转。需要注意的反而是一些中间 DTO 和前端交互。我个人遇到过的一个真实问题接口返回给前端一个 BigDecimal 字段前端 JavaScript 默认把它当 number 处理。JavaScript 的 number 本身也是 IEEE 754 浮点数同样有精度限制超过 2^53 的整数或者某些小数就会失真。如果一个金额是 9007199254740993 这样的超大数传给前端再原样传回来它可能已经变成了 9007199254740992。这是一个跨语言的精度陷阱。解决办法通常有两种一是把金额字段在 JSON 序列化时转成字符串前端拿字符串做展示不做运算二是如果前端必须要参与金额计算比如购物车试用那就只能约定所有计算在后端完成前端只负责展示。从工程实践来看方案一更省心你只需要在 DTO 的金额字段上加一个序列化为字符串的注解或自定义序列化器问题就解决了。后端还有一个常见需求把 BigDecimal 传给报表工具或导出 Excel。POI 的setCellValue如果传 BigDecimal 会默认转成 double 写入单元格大整数场景同样会失真。稳妥做法是先把bigDecimal.toPlainString()写入单元格并设置单元格格式为文本或保留足够小数位的数字格式。这个细节看似不起眼但在金额核对报表这种场景里差异一望即知能避免不少纠纷。5.4 MathContext 与精度控制的进阶用法除了直接指定 scale 和 roundingModeBigDecimal 还提供了MathContext来统一控制精度。MathContext 由 precision有效数字位数和 RoundingMode 组成。看个例子MathContext mc new MathContext(5, RoundingMode.HALF_UP); BigDecimal a new BigDecimal(1.23456); BigDecimal b new BigDecimal(2.34567); BigDecimal sum a.add(b, mc); System.out.println(sum); // 3.5802总共保留了 5 位有效数字MathContext控制的是有效数字位数而不是小数点后的位数所以它能限制整体数字的长度适合一些科学计算场景。但在金额计算里我更推荐直接控制 scale因为金额的业务语义是保留几位小数而不是保留几位有效数字。这两者的差异在数值很小的时候尤其明显——0.00012345保留 5 位有效数字会变成0.00012345本身但保留 5 位小数就变成0.00012。顺便说一个实际高频需求开根号和幂运算。BigDecimal.pow(int)直接可用但结果可能超长如果要限制结果精度需要配合 MathContextBigDecimal base new BigDecimal(1.05); BigDecimal result base.pow(12, new MathContext(10, RoundingMode.HALF_UP)); System.out.println(result); // 1.795856326至于平方根Java 9 之后提供sqrt(MathContext)方法Java 8 或更早版本没有内置 sqrt需要自己用牛顿迭代法实现或者用第三方库。这部分在实际业务里用得不算多但如果处理年化利率这类场景你会需要它。6. 常见问题与面试高频点6.1 经典问题速查表问题场景错误示例正确方案原因double 转 BigDecimalnew BigDecimal(0.1)BigDecimal.valueOf(0.1)直接构造会保留 double 的二进制近似值判断数值相等a.equals(b)a.compareTo(b) 0equals 同时比较 scale1.0 不等于 1.00除法不指定精度a.divide(b)a.divide(b, 4, RoundingMode.HALF_UP)无限循环小数会抛异常setScale 不指定舍入a.setScale(2)a.setScale(2, RoundingMode.HALF_UP)原值有额外小数位时抛异常toString 直接给前端amount.toString()在极小值输出1E-7amount.toPlainString()避免科学计数法输出金额序列化给 JSBigDecimal 直传成 JSON number序列化为字符串JS number 是 IEEE 754有精度上限累加不接收返回值total.add(item)total total.add(item)BigDecimal 不可变原对象不改变这张表几乎覆盖了我日常 Code Review 里遇到的所有 BigDecimal 相关问题。每一行背后都有真实的事故案例不是纸上谈兵。6.2 排查思路金额对不上账从哪里入手线上出了金额计算不一致的问题先别急着翻业务代码。我建议按下面的顺序排查第一找源头数据。把钱的最初来源找出来看它是字符串、double、数据库 DECIMAL、还是前端传过来的 JSON number。如果源头就是 double那大概率问题在数据的产生阶段就已经埋下了后面用 BigDecimal 也救不回来。源头是数据库 DECIMAL 且 JDBC 映射正常通常没问题。第二看舍入场景。找出所有调用 divide 和 setScale 的地方检查是否每一个都明确指定了舍入策略以及策略是否符合业务口径。尤其注意同一个系统中的不同模块可能用了不同的舍入规则例如订单模块用 HALF_UP营销模块用 HALF_EVEN两边一汇总就出现分差。第三检查尾差处理。在分摊、折扣、优惠券抵扣这类涉及多个金额加总必须等于总额的逻辑里优先看尾差修正是否做了以及修正策略是否统一。第四检查格式化输出。如果金额在存入数据库之前经过了 DecimalFormat 或 String.format 的格式化再解析回 BigDecimal就可能在格式化过程中被舍入。这类 bug 隐蔽的地方在于代码能跑通数据也是合法的只是差了一分钱。按这个顺序排查绝大多数金额问题都能在半小时内定位到根因。相比直接就满屏打印日志慢慢翻这个方法高效得多。6.3 面试中经常问到的 BigDecimal 知识点BigDecimal 在面试里几乎是必考题。面试官问的点主要集中在浮点数精度问题成因、BigDecimal 的构造差异、equals 与 compareTo 的区别、除法为什么要指定舍入、以及如何做金额分摊。这些点在本文前几节都已经覆盖。有一个容易被小看的点是为什么 BigDecimal 是不可变的答案是 BigDecimal 内部持有 BigInteger 和 scale这些值一旦创建后不会更改所有算术方法返回新对象。这个设计能保证 BigDecimal 可以在多线程环境下安全共享不需要加锁。面试中如果再深入一点面试官可能会问 BigInteger 的底层实现即内部是 int[] 数组存储二进制补码表示的整数这个话题可以单独写一篇本文不展开。再有个面试官爱问的思维题给你一个 double 0.1你怎么证明它不等于十进制的 0.1答案是把它打印到足够多的小数位或者用new BigDecimal(double)展示出它的精确值。0.1在二进制中是无限循环小数 0.00011001100110011...浮点数只能截断存储所以它永远不可能是精确的 0.1。能把这个逻辑理清楚的候选人通常对计算机组成原理和数值分析都有扎实的基础。7. 性能与替代方案7.1 BigDecimal 的性能到底差到什么程度BigDecimal 确实比 double 慢但慢多少取决于运算类型。加法减法大约慢几十倍到一百倍不等乘法和除法更重因为内部走的是 BigInteger 的大整数运算路径。如果在海量数据场景里用 BigDecimal 做百万次乘法单次耗时上升到微秒级别累积起来会比较可观。但我要给一个更务实的判断绝大多数业务系统性能瓶颈根本不在 BigDecimal 上而在数据库查询、网络 IO、外部接口调用这些环节。一次数据库查询耗时动辄几毫秒而 BigDecimal 哪怕做一万次加法也就是一两个毫秒的量级。真要优化优先优化 IO而不是把金额计算换成 double。如果确实有极端性能要求比如高频交易场景里的风控计算每一次运算都至关重要可以考虑用long表示以分为单位的金额做纯整数运算最后再转 BigDecimal 或字符串展示。这种方案本质上是自己维护 decimal 语义可以规避 BigDecimal 的对象开销但代价是失去了 BigDecimal 内置的精度控制和舍入策略业务方必须自己处理所有边界情况开发成本直线上升。我个人的观点是不到万不得已不要这么做除非你确定团队里有能力兜底这些坑的人。7.2 不可变对象的防御性拷贝问题BigDecimal 不可变意味着没有 setter 修改风险但还有一个细节需要留意如果你从外部 API 拿到了一个 BigDecimal 对象而这个对象可能不是你信任的代码创建的比如某框架通过反射修改过内部字段理论上是可以被攻破的。不过在普通业务系统里这个场景几乎没有我不建议为了防御这种极端威胁在每次传递时都做new BigDecimal(original.toPlainString())这样的防御性拷贝过度设计反而影响性能和可读性。真正值得关注的防御性场景是从数据库读出的 DECIMAL 字段在某些老版本 JDBC 驱动里可能返回的是 java.math.BigDecimal 的兼容类或者由其他序列化框架反序列化出来的异常 BigDecimal。这种情况用compareTo做校验通常就够用了。BigDecimal 即使内部被篡改它的数值语义依然由 BigInteger 保证只有当 BigInteger 本身也是非正规对象时才需要警惕而这在标准 JDK 中几乎不可能发生。7.3 其他精确数值方案对比用表格对比一下当前主流的方案方案精度性能使用场景double/float二进制近似有精度误差极高科学计算、图形学、一般工程近似BigDecimal任意精度十进制精确较低金额、税率、需要人类可读精度的所有场景long以分为单位精确到分整数运算极高极高性能要求的内部金额计算第三方库如 Joda-Money基于 BigDecimal 或 long 封装视实现而定偏好领域建模、需要货币单位语义的场景Joda-Money 在货币建模上有优势它封装了货币单位如 CNY、USD和金额避免你忘记货币单位导致跨币种计算错误。不过它的底层很多操作还是委托给 BigDecimal所以性能没有数量级的差别。如果你的项目依赖管理方便引入 Joda-Money 也可以但如果只是单纯算钱标准 BigDecimal 项目内工具类就完全够用不必额外引依赖。8. 个人实践的补充建议8.1 代码规范与团队约定在我自己带过的项目里BigDecimal 的用法一定要写进团队的代码规范。光靠口头传递经验总有人会漏掉关键细节。我在规范里固定了几条硬性条款这里分享给你参考所有金额字段的类型必须是 BigDecimal禁止用 double 或 float 定义金额。金额的默认精度为 2 位小数默认舍入策略为 HALF_UP。从外部接口获取金额时优先按字符串解析。所有涉及金额的除法运算必须显式指定 scale 和 RoundingMode。BigDecimal 比较一律用 compareTo禁止用 equals。金额字段在 DTO 层输出时序列化为字符串。禁止直接使用new BigDecimal(double)统一使用new BigDecimal(String)或BigDecimal.valueOf。这些条款每一条都有真实事故案例支撑。比如禁止 equals 比较金额这一条就是来自一次线上优惠券叠加失败的事故。当时运营配置的优惠券面额是 5.00系统内的抵扣金额变量算出来是 5.0一个 equals 判断直接判为不相等导致一批订单没有享受优惠事后赔付用户权益的成本远高于写对这行代码的成本。8.2 一个亲历的线上事故复盘有一回线上系统出现了一个诡异问题用户下单后订单金额偶尔会跟后台订单明细的汇总金额差一分钱。一开始大家都以为是分摊算法的问题把分摊逻辑翻来覆去查了好几遍没发现异常。后来注意到差一分钱的情况只在某几条特定明细组合下出现而且规律是个别明细多一分另一条明细少一分。最终定位到根因某个老模块在计算折扣时先调用了divideToIntegralValue取整再用原始金额减去取整后的单价乘以数量来算折扣这一步本身没问题但另一个新模块在同样的计算路径上直接调用了divide(..., 2, HALF_UP)导致两条计算路径的中间结果精度不一致汇总时对不上。修复方案也很简单把新模块的除法精度从 2 位改为 4 位做中间计算最后展示时再舍入到 2 位两边结果就完全一致了。这个事故给我的教训非常深刻BigDecimal 的精度问题往往不是某个单点写错了而是多个模块各自看起来正确的精度处理方式在衔接处产生了冲撞。尤其是同一个数值经由不同模块处理后再汇总时中间精度不一致是最大的隐患源。所以我在每个涉及金额的项目里都会推行中间计算统一多保留几位、最终展示统一舍入的策略让精度变化的边界足够清晰。8.3 后续扩展方向BigDecimal 这篇内容其实还有不少可以深入的方向。比如 BigInteger 本身的底层算法、MathContext 在大数运算中的行为、Java 8 以下版本的 BigDecimal 限制、以及各类 JSON 库如 Jackson、Gson对 BigDecimal 序列化的不同默认行为。如果你在实际项目中遇到了 BigDecimal 相关的疑难问题一个建议是先把异常堆栈里的关键信息读全再对照本文的避坑清单逐一排查多数情况下都能找到答案。数值计算这门功夫说到底是精确谨慎四个字。写代码的时候多想一层这个金额从哪来经过哪些中间运算最终要到哪去精度在每一段是否保得住。想清楚了BigDecimal 就是你手里一把十分趁手的工具。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
