BigDecimal防精度丢失技巧解析

偷偷努力，悄无声息地变强，然后惊艳所有人！哈哈，小伙伴们又来学习啦~今天我将给大家介绍《BigDecimal如何避免精度丢失？Java数值计算规范解析》，这篇文章主要会讲到等等知识点，不知道大家对其都有多少了解，下面我们就一起来看一吧！当然，非常希望大家能多多评论，给出合理的建议，我们一起学习，一起进步！

new BigDecimal(double)会精度丢失，因double是二进制浮点数，0.1在二进制中无限循环，JVM先按IEEE 754近似表示再传入BigDecimal；正确做法是用字符串构造（如new BigDecimal("0.1")）或BigDecimal.valueOf(0.1)。

为什么 new BigDecimal(double) 会精度丢失

直接用 new BigDecimal(0.1) 得到的不是精确的 0.1，而是 0.1000000000000000055511151231257827021181583404541015625。这是因为 double 本身是二进制浮点数，0.1 在二进制中是无限循环小数，JVM 先按 IEEE 754 表示它，再把这个“已经失真”的值传给 BigDecimal 构造器——相当于把错误原样封装了。

正确做法只有一条：从字符串构造。

• new BigDecimal("0.1") ✅ 精确
• BigDecimal.valueOf(0.1) ✅ 内部调用 Double.toString() 转成字符串再构造，比 new BigDecimal(double) 安全得多
• new BigDecimal(0.1) ❌ 避免使用

加减乘除必须用方法，不能用运算符

Java 不支持 BigDecimal 的算术运算符重载，写 a + b 会编译报错或自动拆箱成 double 导致精度崩坏。所有计算必须显式调用方法：

BigDecimal a = new BigDecimal("1.23");
BigDecimal b = new BigDecimal("0.45");
BigDecimal sum = a.add(b);        // ✅
BigDecimal diff = a.subtract(b); // ✅
BigDecimal prod = a.multiply(b); // ✅
BigDecimal quot = a.divide(b, 2, RoundingMode.HALF_UP); // ✅ 必须指定 scale 和 rounding mode

特别注意 divide()：不带 scale 和 RoundingMode 参数的重载在除不尽时直接抛 ArithmeticException，生产环境几乎不可用。

setScale() 和 divide() 的 roundingMode 别乱选

四舍五入不是只有 RoundingMode.HALF_UP 一种。银行、财务、科学计算对舍入规则要求不同，选错会导致业务逻辑偏差：

• RoundingMode.HALF_UP：传统“四舍五入”，如 1.5 → 2，-1.5 → -2
• RoundingMode.HALF_EVEN（银行家舍入）：1.5 → 2，2.5 → 2，-1.5 → -2，-2.5 → -2；能减少统计偏差，金融系统常用
• RoundingMode.CEILING：朝正无穷取整，负数慎用（-1.1 → -1）
• RoundingMode.FLOOR：朝负无穷取整，-1.1 → -2

一旦设定了 scale，就等于承诺“这个数最多保留几位小数”，后续参与计算时若未重新 setScale()，可能因隐式精度截断引发误差累积。

compareTo() 才是安全的相等判断

别用 equals() 判断两个 BigDecimal 是否数值相等。因为 new BigDecimal("1.0").equals(new BigDecimal("1")) 返回 false——它们的 scale 不同（1.0 是 1，1 是 0），而 equals() 同时比较数值和 scale。

正确方式永远是：

if (a.compareTo(b) == 0) {
    // 数值相等
}

另外，compareTo() 可用于排序、TreeSet/TreeMap 键比较，天然支持任意精度下的大小判定。

最常被忽略的是：哪怕你全程用字符串构造、用方法计算、设好 roundingMode，只要在某个环节用了 equals() 或漏了 setScale()，前面所有努力都可能白费。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~