开头要写得像有经验的Java开发者在分享经验。
我做过多个金融相关的项目，每次接手和金额有关的模块，都要先看一眼代码里用的是 double 还是 BigDecimal。这个习惯的由来，是一次线上事故——一个账务系统用 double 算利息，季度结算时对不上账，差了几分钱，排查了一整天，最后定位到是浮点数精度导致的问题。也正是从那次之后，我对 BigDecimal 的态度从"会用"变成了"研究透"。作为 Java 基础篇里几乎必考、也几乎必用的一块内容，BigDecimal 是真正考验基本功的知识点，它不复杂，但坑很多。这篇内容我从原理讲到实战，把用到过的细节、踩过的坑、面试里常被问到的点一次性梳理清楚。
1. 为什么非用 BigDecimal 不可：从 0.1+0.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 是整数12345，scale 是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→2，3.5→4 | 同左 | 统计、金融算法中有时会用到 |
业务系统里最常用的是HALF_UP，理解起来就是小学学的四舍五入。HALF_EVEN（银行家舍入）在金融统计中会用到，它的原则是"五入成双"，当数字正好处于中间值（比如 2.5）时，舍入到相邻的偶数，目的是让多次舍入产生的统计偏差趋于平衡。但普通计费场景不需要这种高级策略，HALF_UP是最稳的选择。
注意setScale不止能缩小小数位数，还能扩大。比如new BigDecimal("3.1").setScale(3, RoundingMode.HALF_UP)的结果是3.100，这个特性在需要对齐小数位做比较时很实用。
4. 比较大小用 compareTo，别用 equals
4.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 是 1，1.00的 scale 是 2，内部结构不同，结果就是 false。这是 BigDecimal 里最经典的隐形坑之一。
如果代码里用equals判断金额或者价格相等，一旦两个值的精度位数不一致，即使数值相同也会被判为不同。我见过有人用数据库查出一个1.00，代码里写死1.0，equals永远返回 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 天然支持排序。实际工作中常见的场景是列表按金额排序：
List<BigDecimal> 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("1E+10"); System.out.println(number.toString()); // 输出：1E+10如果直接把这个结果拼进短信、邮件、报表或者传给前端展示，会出现1E+10这种让人摸不着头脑的显示。正确做法是使用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); // 10，a 没有变 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 为 1，1.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 基础的东西就是这样——越基础越重要，越重要越值得提前研究透。
