开头要写得像有经验的Java开发者在分享经验。我做过多个金融相关的项目每次接手和金额有关的模块都要先看一眼代码里用的是 double 还是 BigDecimal。这个习惯的由来是一次线上事故——一个账务系统用 double 算利息季度结算时对不上账差了几分钱排查了一整天最后定位到是浮点数精度导致的问题。也正是从那次之后我对 BigDecimal 的态度从会用变成了研究透。作为 Java 基础篇里几乎必考、也几乎必用的一块内容BigDecimal 是真正考验基本功的知识点它不复杂但坑很多。这篇内容我从原理讲到实战把用到过的细节、踩过的坑、面试里常被问到的点一次性梳理清楚。1. 为什么非用 BigDecimal 不可从 0.10.2 说起1.1 浮点数精度丢失的根源先做一个最简单、也最经典的实验在你的 IDE 里跑一下这段代码System.out.println(0.1 0.2); System.out.println(1.0 - 0.9); System.out.println(0.5 * 3);输出结果会让你怀疑人生0.30000000000000004 0.09999999999999998 1.5前两行都出现了诡异的尾巴第三行却正常。原因在于计算机底层用二进制存储数据而二进制并不能精确表示所有十进制小数。0.1 转换成二进制后是一个无限循环小数类似于十进制里 1/3 无法被有限表示double 只能取其近似值。0.1 0.2时两个近似值相加误差就叠加暴露出来了。1.5为什么没问题因为 0.5 正好等于 2 的负一次方二进制可以精确表示。这也是浮点数精度问题的核心规律只有能用 2 的幂次和表示的小数才是精确的其他都是近似值。1.2 float/double 在业务场景中为什么失控如果你只把 float/double 用在科学计算或者游戏物理引擎里误差通常是可接受的。但一旦进入业务系统情况完全不同金额计算单价×数量得到的价格用户会拿着计算器和你对账任何一分钱的偏差都会触发客诉。统计报表百分比、平均值、增长率连续运算后误差会不断累积放大最后报表数据和数据库明细对不上。计费系统按分钟计费、按流量计费每笔误差看起来微小乘以海量用户就是巨大的资金差异。数值比较if (balance targetBalance)这种直接等值判断在浮点数面前是不可靠的误差将导致正确业务被误判。在这些场景里需要的是一个能精确表示小数并且可控舍入的类型。Java 给出的标准答案就是 BigDecimal。它的思路很直接不采用二进制近似表示而是用一个大整数unscaled value加上一个小数位刻度scale完整还原出十进制数值。0.1在 BigDecimal 里被存成整数1和刻度1本质含义是1 × 10⁻¹这是精确的。一句话总结凡是和钱、比例、精确计算有关的场景放弃原生浮点类型统一上 BigDecimal。2. 构造 BigDecimal一半的坑集中在这里2.1 三种构造方式对比BigDecimal 提供了多种构造方式选择哪一种是最容易踩坑的地方。先看这段真实的坑BigDecimal a new BigDecimal(0.1); System.out.println(a); // 输出0.1000000000000000055511151231257827021181583404541015625有没有发现问题明明写的是0.1得到的却不是 0.1。原因在于new BigDecimal(double)接收的是 double 的二进制近似值然后把这个近似值如实转换为 BigDecimal。double 表示的 0.1 本身就是那个一长串尾巴的近似值于是结果就污染了。而换成字符串构造结果立刻清爽BigDecimal b new BigDecimal(0.1); System.out.println(b); // 输出0.1字符串构造会严格按照字符串的内容解析得到精确的十进制结果。所以业界有一条铁律不要用 new BigDecimal(double构造优先使用 new BigDecimal(String或 BigDecimal.valueOf()。那BigDecimal.valueOf(0.1)为什么也是安全的看一下源码就不难理解public static BigDecimal valueOf(double val) { return new BigDecimal(Double.toString(val)); }valueOf内部先把 double 转成字符串再走字符串构造路径所以绕开了二进制近似值的陷阱。这实际上就是官方帮你封了一层安全转换。我把三种方式整理成一个对比表方便记忆构造方式示例结果安全性new BigDecimal(double)new BigDecimal(0.1)0.1000000000000000055511151231257827021181583404541015625不安全new BigDecimal(String)new BigDecimal(0.1)0.1安全BigDecimal.valueOf(double)BigDecimal.valueOf(0.1)0.1安全2.2 从源码理解 BigDecimal 的内部结构理解 BigDecimal 的精度机制关键在于它内部的两个核心字段intVal或者 Java 高版本中直接使用BigInteger表示未缩放值和scale。用公式表示就是BigDecimal 数值 unscaledValue × 10^(-scale)举个例子new BigDecimal(123.45)中unscaledValue 是整数12345scale 是2也就是12345 × 10⁻²。new BigDecimal(0.1)则是1 × 10⁻¹。这套设计让任意十进制小数都能被精确表示不再依赖二进制近似。这也解释了为什么equals方法会比较 scale两个数值相同但 scale 不同的 BigDecimal在你眼里可能是同一个数在它自己看来身份不同。比如1.0是10 × 10⁻¹1.00是100 × 10⁻²数值相等但内部表示不同。这个细节极其重要后面我会单独展开讲。从 JDK 9 开始 BigDecimal 的内部实现做过升级核心存储换成了BigInteger但对外行为和概念模型不变。理解unscaledValue scale这套模型就理解了 BigDecimal 的一切行为。3. 加减乘除与舍入规则业务里 90% 的操作在这里3.1 add/subtract/multiply 基本用法与链式调用BigDecimal 的加减乘操作接口非常直观分别是add、subtract、multiply。关键要养成一个习惯每次运算都要接收返回值因为它是一个不可变对象运算结果不会修改调用者本身而是返回一个新对象。BigDecimal price new BigDecimal(19.9); BigDecimal count new BigDecimal(3); BigDecimal total price.multiply(count); System.out.println(total); // 输出59.7 BigDecimal taxRate new BigDecimal(0.06); BigDecimal tax total.multiply(taxRate).setScale(2, RoundingMode.HALF_UP); System.out.println(tax); // 输出3.58第二行里我用了链式调用multiply(taxRate)返回一个新 BigDecimal再继续调用setScale。这种写法在工作中很常见要注意顺序别乱。好多初学者写链式调用时会忘掉中间结果没有接收导致后面取到的还是旧对象排查半天才发现是这回事。对于加法减法用法完全对称。特别提醒一点如果要对金额做累加比如统计一批订单的总金额推荐先初始化一个BigDecimal.ZERO然后循环往里面加BigDecimal sum BigDecimal.ZERO; for (Order order : orderList) { sum sum.add(order.getAmount()); }注意每一轮都要重新赋值给sum这是不可变对象的使用常识。有人会写sum.add(order.getAmount())然后不接收循环结束后 sum 仍然是零这个 bug 非常隐蔽。3.2 divide 的两种形态与除不尽的异常除法是整个 BigDecimal 中最容易出问题的操作尤其是不指定精度时。看这个例子BigDecimal one new BigDecimal(1); BigDecimal three new BigDecimal(3); System.out.println(one.divide(three));运行后直接抛出ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result.因为 1 ÷ 3 的结果是无限循环小数BigDecimal 不知道你想保留多少位也不知道怎么舍入只能抛异常结束。解决方式是指定精度和舍入模式两个参数几乎是绑定出现的BigDecimal result one.divide(three, 4, RoundingMode.HALF_UP); System.out.println(result); // 输出0.3333这个例子中4表示保留 4 位小数RoundingMode.HALF_UP表示四舍五入。Java 里除法的一个常见报错就是除不尽抛异常凡是代码里出现divide的地方都应该习惯性带上 scale 和 RoundingMode。3.3 setScale 与七种舍入模式setScale是控制 BigDecimal 小数位数的核心方法。它有两种常见形态bigDecimal.setScale(2); // 不指定舍入模式遇到无法精确表示时可能抛异常 bigDecimal.setScale(2, RoundingMode.HALF_UP); // 推荐指定舍入模式Java 8 开始RoundingMode取代了老的常量提供了 7 种模式。我把每种模式结合实际数值说明白这样你以后选型心里有数。舍入模式对正数的行为对负数的行为典型使用场景UP远离零方向舍入1.1→2远离零-1.1→-2极少用向上取整的场景DOWN趋向零舍入1.9→1趋向零-1.9→-1直接截断小数位CEILING向正无穷大方向1.1→2向正无穷大-1.1→-1结果不允许小于真实值FLOOR向负无穷大方向1.9→1向负无穷大-1.1→-2结果不允许大于真实值HALF_UP四舍五入2.5→3四舍五入-2.5→-3业务中最常用HALF_DOWN五舍六入2.5→2五舍六入-2.5→-2少见HALF_EVEN银行家舍入2.5→23.5→4同左统计、金融算法中有时会用到业务系统里最常用的是HALF_UP理解起来就是小学学的四舍五入。HALF_EVEN银行家舍入在金融统计中会用到它的原则是五入成双当数字正好处于中间值比如 2.5时舍入到相邻的偶数目的是让多次舍入产生的统计偏差趋于平衡。但普通计费场景不需要这种高级策略HALF_UP是最稳的选择。注意setScale不止能缩小小数位数还能扩大。比如new BigDecimal(3.1).setScale(3, RoundingMode.HALF_UP)的结果是3.100这个特性在需要对齐小数位做比较时很实用。4. 比较大小用 compareTo别用 equals4.1 equals 的 scale 陷阱接前面提到的内部结构来看一个让人猝不及防的比较问题BigDecimal a new BigDecimal(1.0); BigDecimal b new BigDecimal(1.00); System.out.println(a.equals(b)); // false System.out.println(a.compareTo(b) 0); // true数学上完全相等的两个数equals却返回 false。因为equals不仅比较数值还比较 scale。1.0的 scale 是 11.00的 scale 是 2内部结构不同结果就是 false。这是 BigDecimal 里最经典的隐形坑之一。如果代码里用equals判断金额或者价格相等一旦两个值的精度位数不一致即使数值相同也会被判为不同。我见过有人用数据库查出一个1.00代码里写死1.0equals永远返回 false导致业务分支走错。排查了很久才发现问题出在 scale 上。4.2 正确比较姿势与排序应用正确判断数值大小的方式是compareTo它只比较数值本身忽略 scale 差异System.out.println(a.compareTo(b)); // 0表示相等 System.out.println(a.compareTo(new BigDecimal(2))); // -1表示小于 System.out.println(a.compareTo(new BigDecimal(0.5))); // 1表示大于compareTo的返回值语义和 Comparable 接口一致负数表示小于0 表示等于正数表示大于。这也让 BigDecimal 天然支持排序。实际工作中常见的场景是列表按金额排序ListBigDecimal amounts Arrays.asList( new BigDecimal(39.90), new BigDecimal(129.00), new BigDecimal(9.90) ); amounts.sort(BigDecimal::compareTo); System.out.println(amounts); // 输出[9.9, 39.90, 129.00]如果要在HashMap或HashSet里用 BigDecimal 当 key同样要注意equals和hashCode是配套的。既然equals会对1.0和1.00返回 false那么它们在 HashMap 中也会被当作两个 key。如果业务上希望数值相等就视为相同 key最好统一精度后再入 Map或者用TreeMap配合compareTo来规避。4.3 判断零值的正确姿势判断一个 BigDecimal 是否为零很多人顺手写bigDecimal.equals(BigDecimal.ZERO)这又会踩到 scale 的坑。0.00在 equals 眼里和0不是同一个对象但业务上它们就是零。推荐两种写法bigDecimal.compareTo(BigDecimal.ZERO) 0; // 或者 bigDecimal.signum() 0;signum()方法返回 -1、0、1 三种状态表示负数、零、正数效率高且没有 scale 问题。在判断大于 0 时signum() 0也是一个很清晰的写法。5. 格式化输出与类型转换toString 也可能出问题5.1 科学计数法带来的显示问题BigDecimal 在数值特别大或特别小时toString()会采用科学计数法展示。看这个例子BigDecimal number new BigDecimal(1E10); System.out.println(number.toString()); // 输出1E10如果直接把这个结果拼进短信、邮件、报表或者传给前端展示会出现1E10这种让人摸不着头脑的显示。正确做法是使用toPlainString()System.out.println(number.toPlainString()); // 输出10000000000toPlainString()返回的永远是不带科学计数法的普通十进制字符串。凡是要把 BigDecimal 展示给用户或写入业务单据我都统一走toPlainString()这是一个成本极低但收益很大的习惯。5.2 金额格式化与小数位对齐业务中最常见的格式化需求是保留两位小数并加千分位。通常会配合DecimalFormat完成需要注意先设置好 BigDecimal 的精度再做格式化避免格式化阶段引入意外BigDecimal amount new BigDecimal(12345678.9); DecimalFormat df new DecimalFormat(#,##0.00); System.out.println(df.format(amount)); // 输出12,345,678.90有一个细节容易被忽视DecimalFormat默认使用的舍入模式是HALF_EVEN不是HALF_UP。如果业务明确要求四舍五入必须手动指定df.setRoundingMode(RoundingMode.HALF_UP);不设置的话2.5会被格式化成2而不是3这种问题隐蔽性特别强通常要到最后的数据核对阶段才会暴露。另外一个处理方式是从 BigDecimal 层面先完成精度控制再用字符串拼接这样每一步都有明确边界BigDecimal rounded amount.setScale(2, RoundingMode.HALF_UP); String result String.format(%,.2f, rounded);开发时也要避免让 BigDecimal 绕道 double 去做格式化比如String.format(%.2f, bigDecimal.doubleValue())。这种写法把 BigDecimal 转换成了 double精度在转换过程中就已经丢失了格式化再好看都没有意义。6. 项目实战从工具类封装到踩坑记录6.1 我在项目中沉淀的 BigDecimal 工具类因为 BigDecimal 在代码里出镜率太高我习惯在项目里沉淀一个工具类把兜底逻辑集中管理。核心功能是安全转换和空值兜底。下面是一个很实用的模板你直接可以拿去改改用public final class BigDecimalUtils { private BigDecimalUtils() { } public static BigDecimal toBigDecimal(Object value) { return toBigDecimal(value, BigDecimal.ZERO); } public static BigDecimal toBigDecimal(Object value, BigDecimal defaultValue) { if (value null) { return defaultValue; } if (value instanceof BigDecimal) { return (BigDecimal) value; } if (value instanceof Number) { return BigDecimal.valueOf(((Number) value).doubleValue()); } try { return new BigDecimal(value.toString().trim()); } catch (NumberFormatException e) { return defaultValue; } } public static BigDecimal toBigDecimalQuietly(String text, BigDecimal defaultValue) { if (text null || text.trim().isEmpty()) { return defaultValue; } try { return new BigDecimal(text.trim()); } catch (NumberFormatException e) { return defaultValue; } } public static boolean isPositive(BigDecimal value) { return value ! null value.signum() 0; } public static boolean isZero(BigDecimal value) { return value null || value.signum() 0; } public static BigDecimal scaleTo2(BigDecimal value) { return value.setScale(2, RoundingMode.HALF_UP); } public static BigDecimal divide(BigDecimal dividend, BigDecimal divisor) { return dividend.divide(divisor, 2, RoundingMode.HALF_UP); } }这个工具类里有两个设计要点。第一toBigDecimal对参数是Number的情况使用BigDecimal.valueOf而不是直接强转确保精度安全。第二所有转换失败的情况都返回默认值避免调用方到处写判空逻辑。空指针是 BigDecimal 使用中最常见的运行时异常所以判空和兜底要前置到工具层。6.2 实际项目中踩过的三个典型坑我把自己在真实项目中遇到的三个问题记录在这里每一个都对应一段痛苦的排查经历。第一个坑是数据库字段类型与 BigDecimal 的映射问题。MySQL 的decimal类型映射到 Java 的 BigDecimal 后scale 取决于表结构的定义。如果数据库字段是decimal(10, 2)查出来就是两位小数如果字段是decimal(10, 4)查出来是四位小数。代码里如果假设查出来的一定是两位小数直接做展示会出现19.9000这种尾巴必须统一用工具类做setScale(2)。第二个坑是JSON 序列化与反序列化的精度丢失。早期项目用 Fastjson 或 Gson 时如果没有注册针对 BigDecimal 的序列化器反序列化过程可能先把 JSON 中的数值转成 double再转成 BigDecimal精度直接受损。一个保底方案是JSON 里金额字段统一用字符串类型传输Java 侧接收为 String 再做转换彻底绕开中间态。如果用 Jackson也可以配置把 BigDecimal 序列化为字符串保证传输过程中不被 JS 精度问题二次伤害。第三个坑是在循环里频繁创建 BigDecimal 对象导致性能问题。BigDecimal 是不可变对象每次运算都会产生新对象在循环里如果每次创建新对象而不复用GC 压力会明显上升。比如在百万级数据量下计算平均值先把所有值累加为 BigDecimal再做一次除法而不是每笔数据都做一次除法。对于性能敏感的场景要评估是否可以用 long 以分为单位存储金额让计算发生在整数域里最后除以 100 转 BigDecimal牺牲一点代码直观性换取极高效率。6.3 不可变性的正确理解BigDecimal 是不可变对象这一点在 Java 里和 String 完全一致。任何add、subtract、multiply、divide、setScale操作都不会修改原对象而是返回一个新对象。理解不可变性对编写正确代码非常重要BigDecimal a new BigDecimal(10); BigDecimal b a.add(new BigDecimal(5)); System.out.println(a); // 10a 没有变 System.out.println(b); // 15如果你需要的是修改后的结果必须接收返回值。这个特性也让 BigDecimal 天然线程安全因为它没有内部状态可以被修改。多个线程共享同一个 BigDecimal 实例时不需要额外的同步处理。这在并发编程里是一个加分项面试时经常被问到BigDecimal 是线程安全的吗答案就是它是不可变对象所以是线程安全的。7. 面试官视角的 BigDecimal 高频问题7.1 六个常考问题及回答要点我参与过不少技术面试也问过候选人 BigDecimal 相关的问题。整理几个高频问题列出我认为合理的回答要点。问题一为什么不能用 float 或 double 表示金额回答要点float/double 采用二进制近似表示十进制小数很多小数无法精确表达运算会产生误差在金额计算中可能导致对不上账。BigDecimal 采用unscaledValue × 10^(-scale)的方式精确表示十进制数值可以满足精度要求。问题二new BigDecimal(0.1)和new BigDecimal(0.1)有什么区别回答要点前者接收 double 的二进制近似值并如实转换结果是一长串精度污染后的数值后者按字符串内容精确解析得到0.1。线上代码必须用字符串构造或BigDecimal.valueOf。问题三两个 BigDecimal 比较相等用什么回答要点compareTo忽略 scale比较的是数值本身equals会同时比较 scale。业务上判断金额相等应该使用compareTo 0或者用signum() 0判断是否为零。问题四BigDecimal 除法抛 ArithmeticException 是什么原因如何处理回答要点不指定舍入模式时如果除不尽结果是一个无限循环小数BigDecimal 无法确定保留位数就抛异常。处理方式是指定带的scale和RoundingMode如divide(divisor, 2, RoundingMode.HALF_UP)。问题五BigDecimal 是线程安全的吗回答要点BigDecimal 是不可变对象所有运算都会返回新对象不会修改内部状态所以在多线程环境下可以安全共享。这与 String 的设计类似。问题六1.0和1.00用 equals 比较结果是什么为什么回答要点结果是 false。equals不仅比较数值还比较 scale。1.0的 scale 为 11.00的 scale 为 2内部表示的 unscaledValue 不同。这是 BigDecimal 最容易踩坑的细节之一。7.2 回答面试题的小技巧面试中回答 BigDecimal 问题时除了正确性展示你对原理的理解会加分。比如被问到为什么 0.1 0.2 不等于 0.3比起直接说 float 有精度问题更好的回答是先说明二进制表示十进制小数的局限性再讲 BigDecimal 的实现原理最后补一句实际开发中的最佳实践字符串构造、compareTo 比较、divide 带舍入模式。这样从原理到实践都覆盖了面试官能立刻感受到你的经验深度。如果被问到工具类设计这类开放性问题可以把前面那个BigDecimalUtils的思路讲出来判空兜底、统一精度、安全除法。这种问题没有标准答案考察的是编码习惯和工程意识能说出这几个维度就说明你在真实项目里是思考过的。写在最后的心得BigDecimal 用起来不难但做到零坑需要把原理和边界都摸透。我个人的习惯是金额字段一律 BigDecimal构造优先用字符串或valueOf比较统一用compareTo除法必须带精度和舍入模式对外展示用toPlainString。这些习惯看起来琐碎但就是它们拦住了一次又一次的线上事故。最后提醒一点不要在一个项目里混用 BigDecimal 的多种构造方式。定好规范、写在团队开发手册里、让每个新人都从规范开始写比等到线上出了精度预警再回头收拾要省太多力气。Java 基础的东西就是这样——越基础越重要越重要越值得提前研究透。
开头要写得像有经验的Java开发者在分享经验。我做过多个金融相关的项目每次接手和金额有关的模块都要先看一眼代码里用的是 double 还是 BigDecimal。这个习惯的由来是一次线上事故——一个账务系统用 double 算利息季度结算时对不上账差了几分钱排查了一整天最后定位到是浮点数精度导致的问题。也正是从那次之后我对 BigDecimal 的态度从会用变成了研究透。作为 Java 基础篇里几乎必考、也几乎必用的一块内容BigDecimal 是真正考验基本功的知识点它不复杂但坑很多。这篇内容我从原理讲到实战把用到过的细节、踩过的坑、面试里常被问到的点一次性梳理清楚。1. 为什么非用 BigDecimal 不可从 0.10.2 说起1.1 浮点数精度丢失的根源先做一个最简单、也最经典的实验在你的 IDE 里跑一下这段代码System.out.println(0.1 0.2); System.out.println(1.0 - 0.9); System.out.println(0.5 * 3);输出结果会让你怀疑人生0.30000000000000004 0.09999999999999998 1.5前两行都出现了诡异的尾巴第三行却正常。原因在于计算机底层用二进制存储数据而二进制并不能精确表示所有十进制小数。0.1 转换成二进制后是一个无限循环小数类似于十进制里 1/3 无法被有限表示double 只能取其近似值。0.1 0.2时两个近似值相加误差就叠加暴露出来了。1.5为什么没问题因为 0.5 正好等于 2 的负一次方二进制可以精确表示。这也是浮点数精度问题的核心规律只有能用 2 的幂次和表示的小数才是精确的其他都是近似值。1.2 float/double 在业务场景中为什么失控如果你只把 float/double 用在科学计算或者游戏物理引擎里误差通常是可接受的。但一旦进入业务系统情况完全不同金额计算单价×数量得到的价格用户会拿着计算器和你对账任何一分钱的偏差都会触发客诉。统计报表百分比、平均值、增长率连续运算后误差会不断累积放大最后报表数据和数据库明细对不上。计费系统按分钟计费、按流量计费每笔误差看起来微小乘以海量用户就是巨大的资金差异。数值比较if (balance targetBalance)这种直接等值判断在浮点数面前是不可靠的误差将导致正确业务被误判。在这些场景里需要的是一个能精确表示小数并且可控舍入的类型。Java 给出的标准答案就是 BigDecimal。它的思路很直接不采用二进制近似表示而是用一个大整数unscaled value加上一个小数位刻度scale完整还原出十进制数值。0.1在 BigDecimal 里被存成整数1和刻度1本质含义是1 × 10⁻¹这是精确的。一句话总结凡是和钱、比例、精确计算有关的场景放弃原生浮点类型统一上 BigDecimal。2. 构造 BigDecimal一半的坑集中在这里2.1 三种构造方式对比BigDecimal 提供了多种构造方式选择哪一种是最容易踩坑的地方。先看这段真实的坑BigDecimal a new BigDecimal(0.1); System.out.println(a); // 输出0.1000000000000000055511151231257827021181583404541015625有没有发现问题明明写的是0.1得到的却不是 0.1。原因在于new BigDecimal(double)接收的是 double 的二进制近似值然后把这个近似值如实转换为 BigDecimal。double 表示的 0.1 本身就是那个一长串尾巴的近似值于是结果就污染了。而换成字符串构造结果立刻清爽BigDecimal b new BigDecimal(0.1); System.out.println(b); // 输出0.1字符串构造会严格按照字符串的内容解析得到精确的十进制结果。所以业界有一条铁律不要用 new BigDecimal(double构造优先使用 new BigDecimal(String或 BigDecimal.valueOf()。那BigDecimal.valueOf(0.1)为什么也是安全的看一下源码就不难理解public static BigDecimal valueOf(double val) { return new BigDecimal(Double.toString(val)); }valueOf内部先把 double 转成字符串再走字符串构造路径所以绕开了二进制近似值的陷阱。这实际上就是官方帮你封了一层安全转换。我把三种方式整理成一个对比表方便记忆构造方式示例结果安全性new BigDecimal(double)new BigDecimal(0.1)0.1000000000000000055511151231257827021181583404541015625不安全new BigDecimal(String)new BigDecimal(0.1)0.1安全BigDecimal.valueOf(double)BigDecimal.valueOf(0.1)0.1安全2.2 从源码理解 BigDecimal 的内部结构理解 BigDecimal 的精度机制关键在于它内部的两个核心字段intVal或者 Java 高版本中直接使用BigInteger表示未缩放值和scale。用公式表示就是BigDecimal 数值 unscaledValue × 10^(-scale)举个例子new BigDecimal(123.45)中unscaledValue 是整数12345scale 是2也就是12345 × 10⁻²。new BigDecimal(0.1)则是1 × 10⁻¹。这套设计让任意十进制小数都能被精确表示不再依赖二进制近似。这也解释了为什么equals方法会比较 scale两个数值相同但 scale 不同的 BigDecimal在你眼里可能是同一个数在它自己看来身份不同。比如1.0是10 × 10⁻¹1.00是100 × 10⁻²数值相等但内部表示不同。这个细节极其重要后面我会单独展开讲。从 JDK 9 开始 BigDecimal 的内部实现做过升级核心存储换成了BigInteger但对外行为和概念模型不变。理解unscaledValue scale这套模型就理解了 BigDecimal 的一切行为。3. 加减乘除与舍入规则业务里 90% 的操作在这里3.1 add/subtract/multiply 基本用法与链式调用BigDecimal 的加减乘操作接口非常直观分别是add、subtract、multiply。关键要养成一个习惯每次运算都要接收返回值因为它是一个不可变对象运算结果不会修改调用者本身而是返回一个新对象。BigDecimal price new BigDecimal(19.9); BigDecimal count new BigDecimal(3); BigDecimal total price.multiply(count); System.out.println(total); // 输出59.7 BigDecimal taxRate new BigDecimal(0.06); BigDecimal tax total.multiply(taxRate).setScale(2, RoundingMode.HALF_UP); System.out.println(tax); // 输出3.58第二行里我用了链式调用multiply(taxRate)返回一个新 BigDecimal再继续调用setScale。这种写法在工作中很常见要注意顺序别乱。好多初学者写链式调用时会忘掉中间结果没有接收导致后面取到的还是旧对象排查半天才发现是这回事。对于加法减法用法完全对称。特别提醒一点如果要对金额做累加比如统计一批订单的总金额推荐先初始化一个BigDecimal.ZERO然后循环往里面加BigDecimal sum BigDecimal.ZERO; for (Order order : orderList) { sum sum.add(order.getAmount()); }注意每一轮都要重新赋值给sum这是不可变对象的使用常识。有人会写sum.add(order.getAmount())然后不接收循环结束后 sum 仍然是零这个 bug 非常隐蔽。3.2 divide 的两种形态与除不尽的异常除法是整个 BigDecimal 中最容易出问题的操作尤其是不指定精度时。看这个例子BigDecimal one new BigDecimal(1); BigDecimal three new BigDecimal(3); System.out.println(one.divide(three));运行后直接抛出ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result.因为 1 ÷ 3 的结果是无限循环小数BigDecimal 不知道你想保留多少位也不知道怎么舍入只能抛异常结束。解决方式是指定精度和舍入模式两个参数几乎是绑定出现的BigDecimal result one.divide(three, 4, RoundingMode.HALF_UP); System.out.println(result); // 输出0.3333这个例子中4表示保留 4 位小数RoundingMode.HALF_UP表示四舍五入。Java 里除法的一个常见报错就是除不尽抛异常凡是代码里出现divide的地方都应该习惯性带上 scale 和 RoundingMode。3.3 setScale 与七种舍入模式setScale是控制 BigDecimal 小数位数的核心方法。它有两种常见形态bigDecimal.setScale(2); // 不指定舍入模式遇到无法精确表示时可能抛异常 bigDecimal.setScale(2, RoundingMode.HALF_UP); // 推荐指定舍入模式Java 8 开始RoundingMode取代了老的常量提供了 7 种模式。我把每种模式结合实际数值说明白这样你以后选型心里有数。舍入模式对正数的行为对负数的行为典型使用场景UP远离零方向舍入1.1→2远离零-1.1→-2极少用向上取整的场景DOWN趋向零舍入1.9→1趋向零-1.9→-1直接截断小数位CEILING向正无穷大方向1.1→2向正无穷大-1.1→-1结果不允许小于真实值FLOOR向负无穷大方向1.9→1向负无穷大-1.1→-2结果不允许大于真实值HALF_UP四舍五入2.5→3四舍五入-2.5→-3业务中最常用HALF_DOWN五舍六入2.5→2五舍六入-2.5→-2少见HALF_EVEN银行家舍入2.5→23.5→4同左统计、金融算法中有时会用到业务系统里最常用的是HALF_UP理解起来就是小学学的四舍五入。HALF_EVEN银行家舍入在金融统计中会用到它的原则是五入成双当数字正好处于中间值比如 2.5时舍入到相邻的偶数目的是让多次舍入产生的统计偏差趋于平衡。但普通计费场景不需要这种高级策略HALF_UP是最稳的选择。注意setScale不止能缩小小数位数还能扩大。比如new BigDecimal(3.1).setScale(3, RoundingMode.HALF_UP)的结果是3.100这个特性在需要对齐小数位做比较时很实用。4. 比较大小用 compareTo别用 equals4.1 equals 的 scale 陷阱接前面提到的内部结构来看一个让人猝不及防的比较问题BigDecimal a new BigDecimal(1.0); BigDecimal b new BigDecimal(1.00); System.out.println(a.equals(b)); // false System.out.println(a.compareTo(b) 0); // true数学上完全相等的两个数equals却返回 false。因为equals不仅比较数值还比较 scale。1.0的 scale 是 11.00的 scale 是 2内部结构不同结果就是 false。这是 BigDecimal 里最经典的隐形坑之一。如果代码里用equals判断金额或者价格相等一旦两个值的精度位数不一致即使数值相同也会被判为不同。我见过有人用数据库查出一个1.00代码里写死1.0equals永远返回 false导致业务分支走错。排查了很久才发现问题出在 scale 上。4.2 正确比较姿势与排序应用正确判断数值大小的方式是compareTo它只比较数值本身忽略 scale 差异System.out.println(a.compareTo(b)); // 0表示相等 System.out.println(a.compareTo(new BigDecimal(2))); // -1表示小于 System.out.println(a.compareTo(new BigDecimal(0.5))); // 1表示大于compareTo的返回值语义和 Comparable 接口一致负数表示小于0 表示等于正数表示大于。这也让 BigDecimal 天然支持排序。实际工作中常见的场景是列表按金额排序ListBigDecimal amounts Arrays.asList( new BigDecimal(39.90), new BigDecimal(129.00), new BigDecimal(9.90) ); amounts.sort(BigDecimal::compareTo); System.out.println(amounts); // 输出[9.9, 39.90, 129.00]如果要在HashMap或HashSet里用 BigDecimal 当 key同样要注意equals和hashCode是配套的。既然equals会对1.0和1.00返回 false那么它们在 HashMap 中也会被当作两个 key。如果业务上希望数值相等就视为相同 key最好统一精度后再入 Map或者用TreeMap配合compareTo来规避。4.3 判断零值的正确姿势判断一个 BigDecimal 是否为零很多人顺手写bigDecimal.equals(BigDecimal.ZERO)这又会踩到 scale 的坑。0.00在 equals 眼里和0不是同一个对象但业务上它们就是零。推荐两种写法bigDecimal.compareTo(BigDecimal.ZERO) 0; // 或者 bigDecimal.signum() 0;signum()方法返回 -1、0、1 三种状态表示负数、零、正数效率高且没有 scale 问题。在判断大于 0 时signum() 0也是一个很清晰的写法。5. 格式化输出与类型转换toString 也可能出问题5.1 科学计数法带来的显示问题BigDecimal 在数值特别大或特别小时toString()会采用科学计数法展示。看这个例子BigDecimal number new BigDecimal(1E10); System.out.println(number.toString()); // 输出1E10如果直接把这个结果拼进短信、邮件、报表或者传给前端展示会出现1E10这种让人摸不着头脑的显示。正确做法是使用toPlainString()System.out.println(number.toPlainString()); // 输出10000000000toPlainString()返回的永远是不带科学计数法的普通十进制字符串。凡是要把 BigDecimal 展示给用户或写入业务单据我都统一走toPlainString()这是一个成本极低但收益很大的习惯。5.2 金额格式化与小数位对齐业务中最常见的格式化需求是保留两位小数并加千分位。通常会配合DecimalFormat完成需要注意先设置好 BigDecimal 的精度再做格式化避免格式化阶段引入意外BigDecimal amount new BigDecimal(12345678.9); DecimalFormat df new DecimalFormat(#,##0.00); System.out.println(df.format(amount)); // 输出12,345,678.90有一个细节容易被忽视DecimalFormat默认使用的舍入模式是HALF_EVEN不是HALF_UP。如果业务明确要求四舍五入必须手动指定df.setRoundingMode(RoundingMode.HALF_UP);不设置的话2.5会被格式化成2而不是3这种问题隐蔽性特别强通常要到最后的数据核对阶段才会暴露。另外一个处理方式是从 BigDecimal 层面先完成精度控制再用字符串拼接这样每一步都有明确边界BigDecimal rounded amount.setScale(2, RoundingMode.HALF_UP); String result String.format(%,.2f, rounded);开发时也要避免让 BigDecimal 绕道 double 去做格式化比如String.format(%.2f, bigDecimal.doubleValue())。这种写法把 BigDecimal 转换成了 double精度在转换过程中就已经丢失了格式化再好看都没有意义。6. 项目实战从工具类封装到踩坑记录6.1 我在项目中沉淀的 BigDecimal 工具类因为 BigDecimal 在代码里出镜率太高我习惯在项目里沉淀一个工具类把兜底逻辑集中管理。核心功能是安全转换和空值兜底。下面是一个很实用的模板你直接可以拿去改改用public final class BigDecimalUtils { private BigDecimalUtils() { } public static BigDecimal toBigDecimal(Object value) { return toBigDecimal(value, BigDecimal.ZERO); } public static BigDecimal toBigDecimal(Object value, BigDecimal defaultValue) { if (value null) { return defaultValue; } if (value instanceof BigDecimal) { return (BigDecimal) value; } if (value instanceof Number) { return BigDecimal.valueOf(((Number) value).doubleValue()); } try { return new BigDecimal(value.toString().trim()); } catch (NumberFormatException e) { return defaultValue; } } public static BigDecimal toBigDecimalQuietly(String text, BigDecimal defaultValue) { if (text null || text.trim().isEmpty()) { return defaultValue; } try { return new BigDecimal(text.trim()); } catch (NumberFormatException e) { return defaultValue; } } public static boolean isPositive(BigDecimal value) { return value ! null value.signum() 0; } public static boolean isZero(BigDecimal value) { return value null || value.signum() 0; } public static BigDecimal scaleTo2(BigDecimal value) { return value.setScale(2, RoundingMode.HALF_UP); } public static BigDecimal divide(BigDecimal dividend, BigDecimal divisor) { return dividend.divide(divisor, 2, RoundingMode.HALF_UP); } }这个工具类里有两个设计要点。第一toBigDecimal对参数是Number的情况使用BigDecimal.valueOf而不是直接强转确保精度安全。第二所有转换失败的情况都返回默认值避免调用方到处写判空逻辑。空指针是 BigDecimal 使用中最常见的运行时异常所以判空和兜底要前置到工具层。6.2 实际项目中踩过的三个典型坑我把自己在真实项目中遇到的三个问题记录在这里每一个都对应一段痛苦的排查经历。第一个坑是数据库字段类型与 BigDecimal 的映射问题。MySQL 的decimal类型映射到 Java 的 BigDecimal 后scale 取决于表结构的定义。如果数据库字段是decimal(10, 2)查出来就是两位小数如果字段是decimal(10, 4)查出来是四位小数。代码里如果假设查出来的一定是两位小数直接做展示会出现19.9000这种尾巴必须统一用工具类做setScale(2)。第二个坑是JSON 序列化与反序列化的精度丢失。早期项目用 Fastjson 或 Gson 时如果没有注册针对 BigDecimal 的序列化器反序列化过程可能先把 JSON 中的数值转成 double再转成 BigDecimal精度直接受损。一个保底方案是JSON 里金额字段统一用字符串类型传输Java 侧接收为 String 再做转换彻底绕开中间态。如果用 Jackson也可以配置把 BigDecimal 序列化为字符串保证传输过程中不被 JS 精度问题二次伤害。第三个坑是在循环里频繁创建 BigDecimal 对象导致性能问题。BigDecimal 是不可变对象每次运算都会产生新对象在循环里如果每次创建新对象而不复用GC 压力会明显上升。比如在百万级数据量下计算平均值先把所有值累加为 BigDecimal再做一次除法而不是每笔数据都做一次除法。对于性能敏感的场景要评估是否可以用 long 以分为单位存储金额让计算发生在整数域里最后除以 100 转 BigDecimal牺牲一点代码直观性换取极高效率。6.3 不可变性的正确理解BigDecimal 是不可变对象这一点在 Java 里和 String 完全一致。任何add、subtract、multiply、divide、setScale操作都不会修改原对象而是返回一个新对象。理解不可变性对编写正确代码非常重要BigDecimal a new BigDecimal(10); BigDecimal b a.add(new BigDecimal(5)); System.out.println(a); // 10a 没有变 System.out.println(b); // 15如果你需要的是修改后的结果必须接收返回值。这个特性也让 BigDecimal 天然线程安全因为它没有内部状态可以被修改。多个线程共享同一个 BigDecimal 实例时不需要额外的同步处理。这在并发编程里是一个加分项面试时经常被问到BigDecimal 是线程安全的吗答案就是它是不可变对象所以是线程安全的。7. 面试官视角的 BigDecimal 高频问题7.1 六个常考问题及回答要点我参与过不少技术面试也问过候选人 BigDecimal 相关的问题。整理几个高频问题列出我认为合理的回答要点。问题一为什么不能用 float 或 double 表示金额回答要点float/double 采用二进制近似表示十进制小数很多小数无法精确表达运算会产生误差在金额计算中可能导致对不上账。BigDecimal 采用unscaledValue × 10^(-scale)的方式精确表示十进制数值可以满足精度要求。问题二new BigDecimal(0.1)和new BigDecimal(0.1)有什么区别回答要点前者接收 double 的二进制近似值并如实转换结果是一长串精度污染后的数值后者按字符串内容精确解析得到0.1。线上代码必须用字符串构造或BigDecimal.valueOf。问题三两个 BigDecimal 比较相等用什么回答要点compareTo忽略 scale比较的是数值本身equals会同时比较 scale。业务上判断金额相等应该使用compareTo 0或者用signum() 0判断是否为零。问题四BigDecimal 除法抛 ArithmeticException 是什么原因如何处理回答要点不指定舍入模式时如果除不尽结果是一个无限循环小数BigDecimal 无法确定保留位数就抛异常。处理方式是指定带的scale和RoundingMode如divide(divisor, 2, RoundingMode.HALF_UP)。问题五BigDecimal 是线程安全的吗回答要点BigDecimal 是不可变对象所有运算都会返回新对象不会修改内部状态所以在多线程环境下可以安全共享。这与 String 的设计类似。问题六1.0和1.00用 equals 比较结果是什么为什么回答要点结果是 false。equals不仅比较数值还比较 scale。1.0的 scale 为 11.00的 scale 为 2内部表示的 unscaledValue 不同。这是 BigDecimal 最容易踩坑的细节之一。7.2 回答面试题的小技巧面试中回答 BigDecimal 问题时除了正确性展示你对原理的理解会加分。比如被问到为什么 0.1 0.2 不等于 0.3比起直接说 float 有精度问题更好的回答是先说明二进制表示十进制小数的局限性再讲 BigDecimal 的实现原理最后补一句实际开发中的最佳实践字符串构造、compareTo 比较、divide 带舍入模式。这样从原理到实践都覆盖了面试官能立刻感受到你的经验深度。如果被问到工具类设计这类开放性问题可以把前面那个BigDecimalUtils的思路讲出来判空兜底、统一精度、安全除法。这种问题没有标准答案考察的是编码习惯和工程意识能说出这几个维度就说明你在真实项目里是思考过的。写在最后的心得BigDecimal 用起来不难但做到零坑需要把原理和边界都摸透。我个人的习惯是金额字段一律 BigDecimal构造优先用字符串或valueOf比较统一用compareTo除法必须带精度和舍入模式对外展示用toPlainString。这些习惯看起来琐碎但就是它们拦住了一次又一次的线上事故。最后提醒一点不要在一个项目里混用 BigDecimal 的多种构造方式。定好规范、写在团队开发手册里、让每个新人都从规范开始写比等到线上出了精度预警再回头收拾要省太多力气。Java 基础的东西就是这样——越基础越重要越重要越值得提前研究透。
