Java浮点数精度问题怎么解决

Java中double和float因遵循IEEE 754二进制浮点标准，无法精确表示0.1、0.2等常见十进制小数，导致0.1+0.2≠0.3等反直觉结果，在金融计费、金额统计等精度敏感场景中极易引发尾差甚至业务风险；本文深入剖析问题根源，强调避免使用==比较、禁用double构造BigDecimal、统一setScale与RoundingMode（如金融常用HALF_UP）、慎用equals()而改用compareTo()等关键实践，并清晰划出BigDecimal的适用边界——必须用于钱、利率、合同明确精度的场景，而非科学计算或图形渲染等可容忍误差的领域，真正帮你避开那些线上难复现、排查耗时长、同事还坚持“double够用”的致命陷阱。

Java中double加减乘除为什么算不准

因为double和float底层用二进制存储十进制小数，很多常见小数（比如0.1、0.2）根本无法精确表示。这不是Java的bug，是IEEE 754浮点标准的固有限制。

典型现象：0.1 + 0.2 == 0.3返回false，实际结果是0.30000000000000004；银行金额累加后出现0.000000000001这种尾差。

• 别用==直接比较double值，改用Math.abs(a - b)
• 涉及金额、计费、统计等对精度敏感的场景，一律避开double/float
• 临时调试时可用String.format("%.2f", x)格式化输出，但这不解决计算过程中的误差

什么时候必须用BigDecimal，什么时候可以不用

BigDecimal是唯一能真正控制十进制精度的方案，但它不是万能解药——用错场景反而引入新问题。

必须用：money字段运算、会计分录、利率计算、任何合同/协议里明确定义了“保留两位小数”的业务逻辑。

可以不用：科学计算（如物理模拟）、图形坐标、机器学习参数更新，这些本就接受浮点误差，且BigDecimal性能差、API重。

• 构造BigDecimal时，永远用String入参，比如new BigDecimal("0.1")；绝不用new BigDecimal(0.1)——后者传进去的已经是失真的double
• 所有运算必须调用.add()、.multiply()等方法，不能用+或*
• 除法.divide()必须指定scale和RoundingMode，否则遇到无限循环小数（如1/3）直接抛ArithmeticException

BigDecimal的scale和roundingMode怎么选

scale是小数位数，roundingMode决定超位时怎么舍入。选错会导致业务逻辑错误，比如该四舍五入却用了HALF_DOWN，或者该截断却用了UP。

金融系统最常用：setScale(2, RoundingMode.HALF_UP)——这就是小学数学里的“四舍五入”，也是人民币计价的标准规则。

• 不要默认用RoundingMode.HALF_EVEN（银行家舍入），它在0.5时向偶数靠，虽然统计上更公平，但和财务习惯不符
• 如果要求“直接截断”，用RoundingMode.DOWN；如果要求“只要超就进一”，用RoundingMode.UP
• 初始化后立刻setScale，别等到最后一步才处理精度，中间运算可能已累积误差

为什么BigDecimal的equals()和compareTo()行为不一样

这是最容易踩的坑：new BigDecimal("1.0").equals(new BigDecimal("1"))返回false，但.compareTo()返回0。

原因：equals()同时比较数值和scale（即"1.0"和"1"被视为不同对象），而compareTo()只比数值大小。几乎所有业务判断都应该用compareTo() == 0代替equals()。

• 集合去重（如HashSet）时，BigDecimal的equals()和hashCode()联动，可能导致你以为相同的数没被去重
• 数据库ORM映射时，某些框架（如MyBatis）用equals()做脏检查，结果数值相同但scale不同就被误判为修改
• 安全起见，比较前先统一setScale，比如都转成setScale(2, RoundingMode.HALF_UP)再比

事情说清了就结束。最麻烦的从来不是写BigDecimal，而是说服同事别在金额字段里用double，以及守住“构造必须用字符串”这条线。

今天关于《Java浮点数精度问题怎么解决》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！