Java中float和double因遵循IEEE 754标准,无法精确表示0.1等十进制小数,导致舍入误差;金融计算、循环累加小步长等场景必须避免使用,应选用BigDecimal等类型。

Java 中的 float 和 double 本身无法做到“精确计算”——这不是 Java 的缺陷,而是它们遵循 IEEE 754 二进制浮点标准的必然结果。0.1、0.2、0.05 这类常见十进制小数,在二进制中是无限循环小数,必须截断存储,因此所有基于 float/double 的算术都自带舍入误差。所谓“精确”,只能靠选对类型和方法来逼近。
什么时候不能用 float/double 做“精确”计算
以下场景一旦用 float 或 double,结果注定不精确:
- 金融计算(如金额加减、利息结算):0.01 + 0.02 ≠ 0.03,可能变成 0.030000000000000002
- 循环累加小步长(如 for (double x = 0; x
- 判断相等(if (d == 0.1)):几乎总是 false,即使看起来“应该为 true”
- 需要固定小数位数输出(如显示“¥19.99”):直接 toString() 可能输出 “19.989999999999998”
替代方案:用 BigDecimal 做真正十进制精确运算
当业务要求“数学上可预期的十进制精度”时,唯一可靠的选择是 BigDecimal:
分析 Java Spring Boot 后端 Controller 代码,自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 构造时优先用 String 构造器:new BigDecimal("0.1"),避免 new BigDecimal(0.1) —— 后者仍会先用 double 表示再转,误差已埋下
- 运算全部调用方法:add()、subtract()、multiply()、divide()(注意指定 scale 和 RoundingMode)
- 除法必须指定精度和舍入模式:divide(new BigDecimal("3"), 2, RoundingMode.HALF_UP)
- 比较用 compareTo(),不用 equals()(equals 会比较 scale,0.1 和 0.10 不等)
如果必须用 float/double,怎么“相对安全”地用
不是所有场景都需要绝对精确。在科学计算、图形渲染、传感器数据处理等允许误差的领域,可以接受 float/double,但需遵守规范:
- 比较两个值是否“相等”:用 Math.abs(a - b)
- 避免链式小数累加:改用整数计数(如把元转为分,用 long 运算)再最后转回
- 格式化输出时用 DecimalFormat 或 String.format("%.2f", d),但注意这只是显示四舍五入,不改变原始值
- 不要混用字面量精度:0.1f + 0.2f == 0.3f 可能为 true,但 0.1 + 0.2 == 0.3 几乎必为 false —— 因类型不同、舍入路径不同
float 和 double 之间怎么选
多数情况下直接选 double:
- Java 默认浮点字面量就是 double,省去写 f/F 的麻烦
- double 提供约 15–17 位有效数字,float 仅 6–7 位,差一个数量级
- 现代 JVM 和硬件对 double 运算优化充分,性能差距微乎其微
- 只在极端内存受限场景(如千万级 float 数组且精度要求低)才考虑 float
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










