咱们搞Java的十有八九都跟小数金额打过交道。double算个0.1加0.2结果冒出个0.30000000000000004这种事儿碰上一次就刻骨铭心。所以在涉及金额、税、汇率这些场景里浮点数基本是禁忌首选方案就是BigDecimal——它靠着十进制字符串和定点精度把“算错钱”这个最恶劣的bug从源头掐死。这篇东西我不打算给你念API文档而是把这东西掰开揉碎从为什么非得用它、构造和运算有哪些深坑、比较和显示怎么不出错到面试最爱问的那几个点以及我在实际项目里怎么用它做金额计算的。适合刚学Java基础的朋友啃也适合准备跳槽面试的兄弟过一遍顺手还能当一份写业务代码时的避坑备忘录。1. 为什么double算钱会出事先搞懂浮点数是咋存钱的很多新手其实不是没用过BigDecimal而是没搞明白看不上的double到底错在哪。这一节咱们先把根因聊透。1.1 二进制世界的“十进制近似”计算机存储double用的是IEEE 754标准本质上是二进制科学计数法——尾数加指数能表示的范围很大但精度是有限的大概能精确到15~17位十进制有效数字。关键问题来了十进制里觉得挺“干净”的小数比如0.1、0.2写成二进制却是无限循环小数。你手写十进制除法1除以3等于0.3333……你只能写个有限位数的近似。计算机也一样0.1这个二进制表示没法除尽只能取一个最靠近的数存下来。于是double的0.1其实是一个“非常接近0.1但不完全等于0.1”的数值。单个用它展示JDK会帮你四舍五入成0.1看着没问题可一旦参与运算误差就会积累、暴露出来double d1 0.1; double d2 0.2; System.out.println(d1 d2); // 0.30000000000000004你说巧不巧0.10.2这个经典例子刚好能精准刺痛每个程序员。这种误差放在普通统计里可以忽略不计可放在金额上一厘钱的对不上账都会让你排查到怀疑人生。1.2 不是BigDecimal故意复杂是金钱天然需要确定性BigDecimal的设计思路和double完全不同。它把小数拆成“一个无标度整数unscaled value”加上“一个小数位数scale”。比如101.23内部就存成整数10123和一个scale2表示10123除以10的2次方等于101.23。这意味着什么它根本不需要把0.1转成二进制近似而是直接靠整数和十进制位权来精确表达这个数。整数在Java里表示是精确的所以只要你不乱调用那些从double直接构造的入口BigDecimal的加减乘除结果就是精确可预期的。本质上就是用“更贵的存储和更慢的运算”换取“业务上必须的确定性”。注意我这里说的是“不乱调用某些入口”。为什么因为BigDecimal给开发者留了一堆构造方法其中就有一个能从double直接构造的——那恰恰是精度陷阱的入口。下一节细说。2. 构造BigDecimal的正确姿势三个入口两种是坑用BigDecimal第一步就容易踩雷。很多人图省事new BigDecimal(0.1)一写整个世界都错位了。2.1 new BigDecimal(double) 是重灾区直接看代码BigDecimal bd1 new BigDecimal(0.1); System.out.println(bd1); // 0.1000000000000000055511151231257827021181583404541015625 BigDecimal bd2 BigDecimal.valueOf(0.1); System.out.println(bd2); // 0.1问题根源很简单new BigDecimal(double)拿到的是double那个“二进制近似值”的原样十进制展开。0.1实际存储的值是0.1000000000000000055511151231257827021181583404541015625于是BigDecimal就这么一字不差地给你存下来了。你以为自己在做精确计算结果初始数据就已经脏了后面全白忙活。如果你非要用double构造正确做法是用BigDecimal.valueOf(double)。这个方法内部先调用Double.toString转成十进制字符串再走字符串构造所以能还原成你“眼睛看到”的那个精度。实际业务里更推荐直接在源头就把数据当成String传进来。2.2 推荐方案直接用String构造BigDecimal price new BigDecimal(19.99);把数值写成字符串BigDecimal解析字符串得到的精度就是你写出来的精度干净利索。从我这些年写业务代码的经验看接口传金额只要约定好“字符串传输”后端的坑立减一半。尤其对接第三方支付、财务对账系统时报文里金额必须是字符串不然你都不知道double类型在那个系统里被转了几手。另外工程上更建议用BigDecimal.valueOf而不是new BigDecimal(String)去包装一个double型变量。比如前端传了0.1后端已经收到的是double类型你硬new BigDecimal(0.1)必然爆炸。此时一条铁律double转BigDecimal只准用valueOf不准直接new。double input 0.1; // 假设这是前端传来的 BigDecimal safe BigDecimal.valueOf(input); // 安全 // BigDecimal danger new BigDecimal(input); // 禁止提示Integer、Long、int、long这些整数类型走new BigDecimal(int/long)或者BigDecimal.valueOf(long)其实都可以整数没有二进制近似问题放心用。3. 加减乘除实操方法名都很熟但细节经常错3.1 为什么每次运算都要重新赋值BigDecimal是不可变对象immutable这点和String类似。你调用add方法并不会改掉原对象本身而是返回一个新对象。所以新手最常见的bug就是写完了不接返回值BigDecimal a new BigDecimal(10); BigDecimal b new BigDecimal(3); a.add(b); // 结果被丢弃了a还是10 System.out.println(a); // 10你以为结果会是13 BigDecimal result a.add(b); // 必须接收返回值为什么设计成不可变一方面方便线程安全同一个BigDecimal实例可以被多个线程共享读另一方面哈希缓存更稳定作为集合元素也更安全。代价就是你必须习惯每一笔运算都重新接收结果。我个人写业务代码时喜欢把中间量直接命名成result或者newValue减少“接错变量”的可能。3.2 add、subtract、multiply的常规用法代码层面并不复杂BigDecimal price new BigDecimal(19.90); BigDecimal quantity new BigDecimal(3); BigDecimal total price.multiply(quantity); // 59.70 BigDecimal shipping new BigDecimal(10.00); BigDecimal finalAmount total.add(shipping); // 69.70减法和加法一个路数。这几个运算在scale处理上遵循一些默认规则加法、减法取操作数中较大的scale作为结果的scale乘法结果的scale是两者scale之和。比如19.90scale2乘3scale0结果是59.70scale2符合直觉。3.3 divide是真正的分水岭舍入模式不定就异常加减乘都还好除法才是BigDecimal最容易翻车的地方。你试试BigDecimal a new BigDecimal(10); BigDecimal b new BigDecimal(3); System.out.println(a.divide(b)); // 报错Non-terminating decimal expansion为什么报错10除以3等于3.3333……无限循环结果是个无法精确表示的十进制数。BigDecimal的哲学是不允许“瞎算”算不出来精确结果就抛异常逼着你做决定——保留多少位小数四舍五入还是直接截断。正确写法是给足两个参数BigDecimal result a.divide(b, 2, RoundingMode.HALF_UP); System.out.println(result); // 3.33这里的2是结果保留两位小数scale2HALF_UP是四舍五入。这条API签名从JDK老版本一直流传下来凡是做报表、做分摊、做费率的几乎天天跟它打交道。有个细节如果你要的结果scale已经在上下文里定了可以用MathContextBigDecimal result a.divide(b, new MathContext(4, RoundingMode.HALF_DOWN));不过日常业务里我更喜欢明文指定scale因为代码可读性更强、同事看了也明白意图。3.4 舍入模式怎么选别一看到HALF_UP就觉得够了RoundingMode在Java里提供了8种模式真正业务开发中经常被讨论的是以下几种HALF_UP四舍五入。咱们从小数学课学的也是价格计算里最常见的选择。HALF_DOWN五舍六入。2.5舍成23.5入成3金融场景里有时用。HALF_EVEN银行家舍入。如果边界值是5则向“最近的偶数”靠近。2.5舍成23.5入成4。一些统计聚合场景会用它减少累计偏差。CEILING/ FLOOR向上取整/向下取整。在扣费、退款、券分摊时经常用到。DOWN直接截断不关心入还是舍。效率高适合不需要严格对称的场景。给你一个特别常见的实战例子两笔订单优惠券金额分摊前n-1单四舍五入最后一单用总额减已分摊金额兜底避免分分钱凑不平。这就是业务经验和舍入模式结合使用。重要一旦涉及金额运算RMB最小单位是分scale2。如果你做的是汇率换算可能scale4或者更高但要保证最后展示或入账时有一套统一的舍入策略不然对不上账。3.5 幂运算、取余等边角方法求幂用pow(int n)返回的是this的n次幂。取余用remainder和modulo区别在于余数符号的处理逻辑。还有max/min方法可以在两个BigDecimal之间取较大较小值适合做金额上限校验。这些方法平时用得不猛但面试里会经常被拎出来问“BigDecimal支持哪些运算”所以至少知道存在即可。4. 比较、格式化与转换精确计算的最后一公里算对了不等于用对了。BigDecimal的比较、显示、转换几个环节同样遍布深浅坑。4.1 equals和compareTo这是面试送命题BigDecimal有两个比较相关的方法行为却完全不同。equals不仅比较数值大小还比较scale小数位数。所以new BigDecimal(1.0)和new BigDecimal(1.00)用equals比较是false。听起来反直觉但这就是它的设计。compareTo只比较数值大小忽略精度。1.0和1.00用compareTo比较是0相等。看代码BigDecimal a new BigDecimal(1.0); BigDecimal b new BigDecimal(1.00); System.out.println(a.equals(b)); // false一个scale是1一个是2 System.out.println(a.compareTo(b)); // 0数值相等这个差异的杀伤力巨高。比如你把BigDecimal放进HashSet或者作为HashMap的key那么new BigDecimal(1.0)和new BigDecimal(1.00)会被当成两个不同的key因为hashCode是基于equals的equals的坑直接传导到了哈希容器。业务上但凡涉及金额做key或去重大概率会出诡异bug。正确逻辑判断数值大小一律用compareTo判断是否精确一致才用equals。前后端金额比较、条件判断、分页过滤我都是compareTo和0比if (amount.compareTo(BigDecimal.ZERO) 0) { // 金额大于0 }提示千万别用if (amount.equals(BigDecimal.ZERO))来判断“金额为0”。金额明明算出来是0.00scale不为0equals直接判false。用compareTo(BigDecimal.ZERO) 0最稳。4.2 scale、精度与stripTrailingZerosscale代表小数点后的位数。new BigDecimal(100.00)的scale是2new BigDecimal(100)的scale是0。有时候你发现计算结果出现了莫名其妙的“尾巴”比如0.10.2用BigDecimal算完是0.3看着正常但0.1乘0.1是0.01也正常可乘0.15结果可能是0.0150之类带着多余0的形态。处理这种事有两种路径用setScale(2, RoundingMode.HALF_UP)主动控制结果精度这是业务标准做法。如果你想“去掉多余尾部0”但保持数值不变用stripTrailingZerosBigDecimal a new BigDecimal(1.5000); System.out.println(a.stripTrailingZeros()); // 1.5注意stripTrailingZeros有个反直觉结果new BigDecimal(100).stripTrailingZeros()会变成1E2即科学计数法。要是用toString打印出来那就是“1E2”很多新手会懵。所以展示逻辑里光strip不够往往还需要toPlainString配合。4.3 科学计数法显示问题与toPlainStringBigDecimal的toString在某些情况下会输出科学计数法。比如BigDecimal big new BigDecimal(100000000000000000000); System.out.println(big.toString()); // 1.00000000000000000000E20 System.out.println(big.toPlainString()); // 100000000000000000000做报表导出、页面展示、接口返回值时都建议用toPlainString否则前端或者Excel里出现E20的数值又是一轮无效沟通。我印象里最深刻的一次就是报表接口直接返回了toString结果前端alert弹出一串科学计数法当场被产品骂了一顿。从那以后凡是金额字段展示一律toPlainString。再看转换相关的几个方法doubleValue()转成double返回。注意这可能丢失精度只有确认目标场景能容忍误差时才用。floatValue()同理更丢精度。longValue() / intValue()直接截断小数部分有损转换注意溢出风险。longValueExact() / intValueExact()如果小数部分不为0或超出范围抛ArithmeticException。精确场景校验时好用。你问那到底怎么把BigDecimal传给前端现在主流方案有两种——后端序列化的时候直接输出字符串或者保留数值类型但前端用字符串显示。二选一必须统一口径不然JSON序列化库默认转成number精度照样丢。实际项目里我在DTO上加了自定义序列化注解把金额字段全部输出为字符串这是经过血泪验证的稳。5. BigDecimal在真实业务里的落地套路熟悉了API只是第一层。真正让BigDecimal好用的还有一套业务层面的经验。5.1 金额字段的存取规范数据库层面金额字段要用DECIMAL而不是FLOAT/DOUBLEJava实体里用BigDecimal来接。这是行业通用约定没什么好争论的。ORM框架MyBatis、JPA对DECIMAL和BigDecimal的映射做得也很好几乎不需要额外配置。麻烦的是前后端交互。前端表单输入的金额传到后端可能是String、可能是Double、有可能是BigDecimal最终建议统一规范成String。别人可能觉得啰嗦但只有这么做才能保证“金额字段从入库到出参都不经过double”。我习惯在Controller入口做一层字符串校验用正则或者BigDecimal的构造器捕获异常任何非数字输入都直接拦截抛业务异常。5.2 一个电商下单算价的完整示例拿一个简化的例子串一遍// 商品单价元来自数据库或接口确保是字符串构造 BigDecimal unitPrice new BigDecimal(39.90); // 购买数量恒为整数 BigDecimal quantity new BigDecimal(2); // 优惠券抵扣元 BigDecimal coupon new BigDecimal(5.00); // 商品小计 单价 * 数量 BigDecimal subtotal unitPrice.multiply(quantity); // 79.80 // 实付金额 小计 - 优惠券抵扣 BigDecimal payable subtotal.subtract(coupon); // 74.80 // 如果涉及按比例分摊、退款、打折统一在最后setScale BigDecimal finalPayable payable.setScale(2, RoundingMode.HALF_UP); System.out.println(finalPayable.toPlainString()); // 74.80这个例子看着简单但当你把上百个优惠项叠起来、引入积分抵现、税费计算、多商品分摊折扣时核心原则永远是每一步都用BigDecimal每一步都明确scale和舍入模式所有汇总在最后做一次setScale。中途不要反复转double那等于自毁长城。5.3 金融场景的额外规矩做支付、财务、账务系统时还有几条独家规矩金额字段一律不允许为null。实体初始化时给BigDecimal.ZERO数据库默认0.00代码里判空兜底。读出来用于计算的金额必须先setScale统一精度不能一个大数一个小数直接算否则结果的scale会很随机。别用判断BigDecimal是否相等哪怕是同一个值必须用compareTo。金额的负数表示扣款、退款要约定清楚正负号BigDecimal本身没这个语义。序列化后不允许出现科学计数法前端和大数据系统解析都会出鬼。这几条看着老生常谈但真正在代码评审里几乎条条都能抓到问题。6. 常见问题排查与面试高频点6.1 面试中的BigDecimal经典题我把这几年整理过的题单挑几个放这儿供你自查double可以精确表示金额吗为什么不行——考IEEE 754浮点表示原理、二进制近似思想。new BigDecimal(0.1)和BigDecimal.valueOf(0.1)有什么区别——考构造器陷阱valueOf内部转String。BigDecimal的equals和compareTo有什么区别什么时候用哪个——考缩放精度与数值比较上面讲过。用BigDecimal做除法报Non-terminating decimal expansion异常怎么解决——考divide的scale和RoundingMode参数。BigDecimal是线程安全的吗为什么——考不可变对象设计以及为什么不可变对象天然线程安全。为什么HashMap的key不建议用BigDecimal——因为equals对scale敏感1.0和1.00会被当成两个键容易取不到值。金额到底用什么类型存储数据库DECIMAL、Java BigDecimal、JSON字符串——这一套组合拳送分题。面试时回答要点不要只背答案最好补充一两个自己踩坑的例子比如“用过equals判断金额为0导致分页过滤失效”“new BigDecimal(0.1)精度不对导致对账不平”。有真实案例说服力完全不一样。6.2 实际项目里最容易踩的5个坑坑一用double存金额、用double做计算最后才new BigDecimal。治标不治本等于从源头就脏了。坑二比较金额用equals判断相等。1.00和1.0硬生生不等最终触发的bug极其隐蔽。坑三除法不指定scale。一个ArithmeticException让你的定时任务半夜挂掉日志全是堆栈。坑四展示时直接toString。数值一大变科学计数法前端渲染直接乱套。坑五反复用doubleValue转来转去。某些场景你觉得自己“转出去再转回来没问题”实际上99%的情况会在换算过程中引入误差精度回到解放前。6.3 排查思路速查表症状可能原因排查/解决方向金额差0.01或0.02double参与过计算或构造全局搜索new BigDecimal(double)改valueOf或字符串构造除法运算抛ArithmeticExceptiondivide未指定舍入参数补scale和RoundingMode必要时用MathContextequals判断金额相等失败scale不一致改用compareTo比较数值金额显示科学计数法toString默认行为使用toPlainStringHashMap取key取不到BigDecimal作为key且scale不一致用String或stripTrailingZeros后再做key大量金额运算性能变慢每次都创建新对象缓存常量、减少无用运算或用long加分来替代6.4 最后的操作小技巧我自己日常写代码还有个习惯定义一个金额工具类把“字符串转BigDecimal”“null转ZERO”“金额格式化输出”“比较大小”封装成静态方法统一走一套精度策略。这样业务代码干净全项目舍入模式也统一。在微服务项目里这个类往往会被抽到公共模块谁也不能乱改。再分享一个性能细节BigDecimal对象创建代价相对高能用BigDecimal.ZERO、BigDecimal.ONE就别自己new。高频循环里还可以用预先定义好的常量值代替反复构造对接口性能有一定帮助。当然BigDecimal本来就不是为每秒百万次计算设计的真到那种规模你该考虑用long存“分”并且自己控制四舍五入逻辑但那是另一个话题了。结尾就写到这BigDecimal这玩意儿文档翻来覆去就那么点东西但落到真实项目里每一处“没想到”背后都是血和泪。我个人最大的体会是别迷信double也别迷信BigDecimal本身真正可靠的是你对精度运算的敬畏和一套贯穿始终的规范。把字符串构造、compareTo比较、toPlainString展示这几条铁律钉进团队代码规范里金额计算这关就稳住了。希望这篇能把你在BigDecimal上踩过的坑、还没踩的坑都串起来以后再碰金额心里有底。
Java金额计算避坑指南：BigDecimal精度原理与工程实践
咱们搞Java的十有八九都跟小数金额打过交道。double算个0.1加0.2结果冒出个0.30000000000000004这种事儿碰上一次就刻骨铭心。所以在涉及金额、税、汇率这些场景里浮点数基本是禁忌首选方案就是BigDecimal——它靠着十进制字符串和定点精度把“算错钱”这个最恶劣的bug从源头掐死。这篇东西我不打算给你念API文档而是把这东西掰开揉碎从为什么非得用它、构造和运算有哪些深坑、比较和显示怎么不出错到面试最爱问的那几个点以及我在实际项目里怎么用它做金额计算的。适合刚学Java基础的朋友啃也适合准备跳槽面试的兄弟过一遍顺手还能当一份写业务代码时的避坑备忘录。1. 为什么double算钱会出事先搞懂浮点数是咋存钱的很多新手其实不是没用过BigDecimal而是没搞明白看不上的double到底错在哪。这一节咱们先把根因聊透。1.1 二进制世界的“十进制近似”计算机存储double用的是IEEE 754标准本质上是二进制科学计数法——尾数加指数能表示的范围很大但精度是有限的大概能精确到15~17位十进制有效数字。关键问题来了十进制里觉得挺“干净”的小数比如0.1、0.2写成二进制却是无限循环小数。你手写十进制除法1除以3等于0.3333……你只能写个有限位数的近似。计算机也一样0.1这个二进制表示没法除尽只能取一个最靠近的数存下来。于是double的0.1其实是一个“非常接近0.1但不完全等于0.1”的数值。单个用它展示JDK会帮你四舍五入成0.1看着没问题可一旦参与运算误差就会积累、暴露出来double d1 0.1; double d2 0.2; System.out.println(d1 d2); // 0.30000000000000004你说巧不巧0.10.2这个经典例子刚好能精准刺痛每个程序员。这种误差放在普通统计里可以忽略不计可放在金额上一厘钱的对不上账都会让你排查到怀疑人生。1.2 不是BigDecimal故意复杂是金钱天然需要确定性BigDecimal的设计思路和double完全不同。它把小数拆成“一个无标度整数unscaled value”加上“一个小数位数scale”。比如101.23内部就存成整数10123和一个scale2表示10123除以10的2次方等于101.23。这意味着什么它根本不需要把0.1转成二进制近似而是直接靠整数和十进制位权来精确表达这个数。整数在Java里表示是精确的所以只要你不乱调用那些从double直接构造的入口BigDecimal的加减乘除结果就是精确可预期的。本质上就是用“更贵的存储和更慢的运算”换取“业务上必须的确定性”。注意我这里说的是“不乱调用某些入口”。为什么因为BigDecimal给开发者留了一堆构造方法其中就有一个能从double直接构造的——那恰恰是精度陷阱的入口。下一节细说。2. 构造BigDecimal的正确姿势三个入口两种是坑用BigDecimal第一步就容易踩雷。很多人图省事new BigDecimal(0.1)一写整个世界都错位了。2.1 new BigDecimal(double) 是重灾区直接看代码BigDecimal bd1 new BigDecimal(0.1); System.out.println(bd1); // 0.1000000000000000055511151231257827021181583404541015625 BigDecimal bd2 BigDecimal.valueOf(0.1); System.out.println(bd2); // 0.1问题根源很简单new BigDecimal(double)拿到的是double那个“二进制近似值”的原样十进制展开。0.1实际存储的值是0.1000000000000000055511151231257827021181583404541015625于是BigDecimal就这么一字不差地给你存下来了。你以为自己在做精确计算结果初始数据就已经脏了后面全白忙活。如果你非要用double构造正确做法是用BigDecimal.valueOf(double)。这个方法内部先调用Double.toString转成十进制字符串再走字符串构造所以能还原成你“眼睛看到”的那个精度。实际业务里更推荐直接在源头就把数据当成String传进来。2.2 推荐方案直接用String构造BigDecimal price new BigDecimal(19.99);把数值写成字符串BigDecimal解析字符串得到的精度就是你写出来的精度干净利索。从我这些年写业务代码的经验看接口传金额只要约定好“字符串传输”后端的坑立减一半。尤其对接第三方支付、财务对账系统时报文里金额必须是字符串不然你都不知道double类型在那个系统里被转了几手。另外工程上更建议用BigDecimal.valueOf而不是new BigDecimal(String)去包装一个double型变量。比如前端传了0.1后端已经收到的是double类型你硬new BigDecimal(0.1)必然爆炸。此时一条铁律double转BigDecimal只准用valueOf不准直接new。double input 0.1; // 假设这是前端传来的 BigDecimal safe BigDecimal.valueOf(input); // 安全 // BigDecimal danger new BigDecimal(input); // 禁止提示Integer、Long、int、long这些整数类型走new BigDecimal(int/long)或者BigDecimal.valueOf(long)其实都可以整数没有二进制近似问题放心用。3. 加减乘除实操方法名都很熟但细节经常错3.1 为什么每次运算都要重新赋值BigDecimal是不可变对象immutable这点和String类似。你调用add方法并不会改掉原对象本身而是返回一个新对象。所以新手最常见的bug就是写完了不接返回值BigDecimal a new BigDecimal(10); BigDecimal b new BigDecimal(3); a.add(b); // 结果被丢弃了a还是10 System.out.println(a); // 10你以为结果会是13 BigDecimal result a.add(b); // 必须接收返回值为什么设计成不可变一方面方便线程安全同一个BigDecimal实例可以被多个线程共享读另一方面哈希缓存更稳定作为集合元素也更安全。代价就是你必须习惯每一笔运算都重新接收结果。我个人写业务代码时喜欢把中间量直接命名成result或者newValue减少“接错变量”的可能。3.2 add、subtract、multiply的常规用法代码层面并不复杂BigDecimal price new BigDecimal(19.90); BigDecimal quantity new BigDecimal(3); BigDecimal total price.multiply(quantity); // 59.70 BigDecimal shipping new BigDecimal(10.00); BigDecimal finalAmount total.add(shipping); // 69.70减法和加法一个路数。这几个运算在scale处理上遵循一些默认规则加法、减法取操作数中较大的scale作为结果的scale乘法结果的scale是两者scale之和。比如19.90scale2乘3scale0结果是59.70scale2符合直觉。3.3 divide是真正的分水岭舍入模式不定就异常加减乘都还好除法才是BigDecimal最容易翻车的地方。你试试BigDecimal a new BigDecimal(10); BigDecimal b new BigDecimal(3); System.out.println(a.divide(b)); // 报错Non-terminating decimal expansion为什么报错10除以3等于3.3333……无限循环结果是个无法精确表示的十进制数。BigDecimal的哲学是不允许“瞎算”算不出来精确结果就抛异常逼着你做决定——保留多少位小数四舍五入还是直接截断。正确写法是给足两个参数BigDecimal result a.divide(b, 2, RoundingMode.HALF_UP); System.out.println(result); // 3.33这里的2是结果保留两位小数scale2HALF_UP是四舍五入。这条API签名从JDK老版本一直流传下来凡是做报表、做分摊、做费率的几乎天天跟它打交道。有个细节如果你要的结果scale已经在上下文里定了可以用MathContextBigDecimal result a.divide(b, new MathContext(4, RoundingMode.HALF_DOWN));不过日常业务里我更喜欢明文指定scale因为代码可读性更强、同事看了也明白意图。3.4 舍入模式怎么选别一看到HALF_UP就觉得够了RoundingMode在Java里提供了8种模式真正业务开发中经常被讨论的是以下几种HALF_UP四舍五入。咱们从小数学课学的也是价格计算里最常见的选择。HALF_DOWN五舍六入。2.5舍成23.5入成3金融场景里有时用。HALF_EVEN银行家舍入。如果边界值是5则向“最近的偶数”靠近。2.5舍成23.5入成4。一些统计聚合场景会用它减少累计偏差。CEILING/ FLOOR向上取整/向下取整。在扣费、退款、券分摊时经常用到。DOWN直接截断不关心入还是舍。效率高适合不需要严格对称的场景。给你一个特别常见的实战例子两笔订单优惠券金额分摊前n-1单四舍五入最后一单用总额减已分摊金额兜底避免分分钱凑不平。这就是业务经验和舍入模式结合使用。重要一旦涉及金额运算RMB最小单位是分scale2。如果你做的是汇率换算可能scale4或者更高但要保证最后展示或入账时有一套统一的舍入策略不然对不上账。3.5 幂运算、取余等边角方法求幂用pow(int n)返回的是this的n次幂。取余用remainder和modulo区别在于余数符号的处理逻辑。还有max/min方法可以在两个BigDecimal之间取较大较小值适合做金额上限校验。这些方法平时用得不猛但面试里会经常被拎出来问“BigDecimal支持哪些运算”所以至少知道存在即可。4. 比较、格式化与转换精确计算的最后一公里算对了不等于用对了。BigDecimal的比较、显示、转换几个环节同样遍布深浅坑。4.1 equals和compareTo这是面试送命题BigDecimal有两个比较相关的方法行为却完全不同。equals不仅比较数值大小还比较scale小数位数。所以new BigDecimal(1.0)和new BigDecimal(1.00)用equals比较是false。听起来反直觉但这就是它的设计。compareTo只比较数值大小忽略精度。1.0和1.00用compareTo比较是0相等。看代码BigDecimal a new BigDecimal(1.0); BigDecimal b new BigDecimal(1.00); System.out.println(a.equals(b)); // false一个scale是1一个是2 System.out.println(a.compareTo(b)); // 0数值相等这个差异的杀伤力巨高。比如你把BigDecimal放进HashSet或者作为HashMap的key那么new BigDecimal(1.0)和new BigDecimal(1.00)会被当成两个不同的key因为hashCode是基于equals的equals的坑直接传导到了哈希容器。业务上但凡涉及金额做key或去重大概率会出诡异bug。正确逻辑判断数值大小一律用compareTo判断是否精确一致才用equals。前后端金额比较、条件判断、分页过滤我都是compareTo和0比if (amount.compareTo(BigDecimal.ZERO) 0) { // 金额大于0 }提示千万别用if (amount.equals(BigDecimal.ZERO))来判断“金额为0”。金额明明算出来是0.00scale不为0equals直接判false。用compareTo(BigDecimal.ZERO) 0最稳。4.2 scale、精度与stripTrailingZerosscale代表小数点后的位数。new BigDecimal(100.00)的scale是2new BigDecimal(100)的scale是0。有时候你发现计算结果出现了莫名其妙的“尾巴”比如0.10.2用BigDecimal算完是0.3看着正常但0.1乘0.1是0.01也正常可乘0.15结果可能是0.0150之类带着多余0的形态。处理这种事有两种路径用setScale(2, RoundingMode.HALF_UP)主动控制结果精度这是业务标准做法。如果你想“去掉多余尾部0”但保持数值不变用stripTrailingZerosBigDecimal a new BigDecimal(1.5000); System.out.println(a.stripTrailingZeros()); // 1.5注意stripTrailingZeros有个反直觉结果new BigDecimal(100).stripTrailingZeros()会变成1E2即科学计数法。要是用toString打印出来那就是“1E2”很多新手会懵。所以展示逻辑里光strip不够往往还需要toPlainString配合。4.3 科学计数法显示问题与toPlainStringBigDecimal的toString在某些情况下会输出科学计数法。比如BigDecimal big new BigDecimal(100000000000000000000); System.out.println(big.toString()); // 1.00000000000000000000E20 System.out.println(big.toPlainString()); // 100000000000000000000做报表导出、页面展示、接口返回值时都建议用toPlainString否则前端或者Excel里出现E20的数值又是一轮无效沟通。我印象里最深刻的一次就是报表接口直接返回了toString结果前端alert弹出一串科学计数法当场被产品骂了一顿。从那以后凡是金额字段展示一律toPlainString。再看转换相关的几个方法doubleValue()转成double返回。注意这可能丢失精度只有确认目标场景能容忍误差时才用。floatValue()同理更丢精度。longValue() / intValue()直接截断小数部分有损转换注意溢出风险。longValueExact() / intValueExact()如果小数部分不为0或超出范围抛ArithmeticException。精确场景校验时好用。你问那到底怎么把BigDecimal传给前端现在主流方案有两种——后端序列化的时候直接输出字符串或者保留数值类型但前端用字符串显示。二选一必须统一口径不然JSON序列化库默认转成number精度照样丢。实际项目里我在DTO上加了自定义序列化注解把金额字段全部输出为字符串这是经过血泪验证的稳。5. BigDecimal在真实业务里的落地套路熟悉了API只是第一层。真正让BigDecimal好用的还有一套业务层面的经验。5.1 金额字段的存取规范数据库层面金额字段要用DECIMAL而不是FLOAT/DOUBLEJava实体里用BigDecimal来接。这是行业通用约定没什么好争论的。ORM框架MyBatis、JPA对DECIMAL和BigDecimal的映射做得也很好几乎不需要额外配置。麻烦的是前后端交互。前端表单输入的金额传到后端可能是String、可能是Double、有可能是BigDecimal最终建议统一规范成String。别人可能觉得啰嗦但只有这么做才能保证“金额字段从入库到出参都不经过double”。我习惯在Controller入口做一层字符串校验用正则或者BigDecimal的构造器捕获异常任何非数字输入都直接拦截抛业务异常。5.2 一个电商下单算价的完整示例拿一个简化的例子串一遍// 商品单价元来自数据库或接口确保是字符串构造 BigDecimal unitPrice new BigDecimal(39.90); // 购买数量恒为整数 BigDecimal quantity new BigDecimal(2); // 优惠券抵扣元 BigDecimal coupon new BigDecimal(5.00); // 商品小计 单价 * 数量 BigDecimal subtotal unitPrice.multiply(quantity); // 79.80 // 实付金额 小计 - 优惠券抵扣 BigDecimal payable subtotal.subtract(coupon); // 74.80 // 如果涉及按比例分摊、退款、打折统一在最后setScale BigDecimal finalPayable payable.setScale(2, RoundingMode.HALF_UP); System.out.println(finalPayable.toPlainString()); // 74.80这个例子看着简单但当你把上百个优惠项叠起来、引入积分抵现、税费计算、多商品分摊折扣时核心原则永远是每一步都用BigDecimal每一步都明确scale和舍入模式所有汇总在最后做一次setScale。中途不要反复转double那等于自毁长城。5.3 金融场景的额外规矩做支付、财务、账务系统时还有几条独家规矩金额字段一律不允许为null。实体初始化时给BigDecimal.ZERO数据库默认0.00代码里判空兜底。读出来用于计算的金额必须先setScale统一精度不能一个大数一个小数直接算否则结果的scale会很随机。别用判断BigDecimal是否相等哪怕是同一个值必须用compareTo。金额的负数表示扣款、退款要约定清楚正负号BigDecimal本身没这个语义。序列化后不允许出现科学计数法前端和大数据系统解析都会出鬼。这几条看着老生常谈但真正在代码评审里几乎条条都能抓到问题。6. 常见问题排查与面试高频点6.1 面试中的BigDecimal经典题我把这几年整理过的题单挑几个放这儿供你自查double可以精确表示金额吗为什么不行——考IEEE 754浮点表示原理、二进制近似思想。new BigDecimal(0.1)和BigDecimal.valueOf(0.1)有什么区别——考构造器陷阱valueOf内部转String。BigDecimal的equals和compareTo有什么区别什么时候用哪个——考缩放精度与数值比较上面讲过。用BigDecimal做除法报Non-terminating decimal expansion异常怎么解决——考divide的scale和RoundingMode参数。BigDecimal是线程安全的吗为什么——考不可变对象设计以及为什么不可变对象天然线程安全。为什么HashMap的key不建议用BigDecimal——因为equals对scale敏感1.0和1.00会被当成两个键容易取不到值。金额到底用什么类型存储数据库DECIMAL、Java BigDecimal、JSON字符串——这一套组合拳送分题。面试时回答要点不要只背答案最好补充一两个自己踩坑的例子比如“用过equals判断金额为0导致分页过滤失效”“new BigDecimal(0.1)精度不对导致对账不平”。有真实案例说服力完全不一样。6.2 实际项目里最容易踩的5个坑坑一用double存金额、用double做计算最后才new BigDecimal。治标不治本等于从源头就脏了。坑二比较金额用equals判断相等。1.00和1.0硬生生不等最终触发的bug极其隐蔽。坑三除法不指定scale。一个ArithmeticException让你的定时任务半夜挂掉日志全是堆栈。坑四展示时直接toString。数值一大变科学计数法前端渲染直接乱套。坑五反复用doubleValue转来转去。某些场景你觉得自己“转出去再转回来没问题”实际上99%的情况会在换算过程中引入误差精度回到解放前。6.3 排查思路速查表症状可能原因排查/解决方向金额差0.01或0.02double参与过计算或构造全局搜索new BigDecimal(double)改valueOf或字符串构造除法运算抛ArithmeticExceptiondivide未指定舍入参数补scale和RoundingMode必要时用MathContextequals判断金额相等失败scale不一致改用compareTo比较数值金额显示科学计数法toString默认行为使用toPlainStringHashMap取key取不到BigDecimal作为key且scale不一致用String或stripTrailingZeros后再做key大量金额运算性能变慢每次都创建新对象缓存常量、减少无用运算或用long加分来替代6.4 最后的操作小技巧我自己日常写代码还有个习惯定义一个金额工具类把“字符串转BigDecimal”“null转ZERO”“金额格式化输出”“比较大小”封装成静态方法统一走一套精度策略。这样业务代码干净全项目舍入模式也统一。在微服务项目里这个类往往会被抽到公共模块谁也不能乱改。再分享一个性能细节BigDecimal对象创建代价相对高能用BigDecimal.ZERO、BigDecimal.ONE就别自己new。高频循环里还可以用预先定义好的常量值代替反复构造对接口性能有一定帮助。当然BigDecimal本来就不是为每秒百万次计算设计的真到那种规模你该考虑用long存“分”并且自己控制四舍五入逻辑但那是另一个话题了。结尾就写到这BigDecimal这玩意儿文档翻来覆去就那么点东西但落到真实项目里每一处“没想到”背后都是血和泪。我个人最大的体会是别迷信double也别迷信BigDecimal本身真正可靠的是你对精度运算的敬畏和一套贯穿始终的规范。把字符串构造、compareTo比较、toPlainString展示这几条铁律钉进团队代码规范里金额计算这关就稳住了。希望这篇能把你在BigDecimal上踩过的坑、还没踩的坑都串起来以后再碰金额心里有底。