java浮点数按ieee 754标准用二进制近似表示十进制小数，float有24位精度（约6–7位十进制），double有53位精度（约15–16位），0.1等十进制小数在二进制中无限循环导致可预期精度偏差。
Java 中的浮点数不是“不精确”，而是按 IEEE 754 标准用二进制近似表示十进制小数——这种设计在性能和通用性上做了权衡，但会带来可预期的精度偏差。关键不在于避免使用 float/double，而在于理解它们何时可靠、何时必须绕开。
float 和 double 的底层存储结构
两者都严格遵循 IEEE 754 标准，本质是三个字段拼成的二进制编码：
- 符号位（1 位）：0 表示正，1 表示负
- 指数位：float 用 8 位（偏移量 127），double 用 11 位（偏移量 1023）。它决定数量级，不是真实指数，需减去偏移量还原
- 尾数位（有效数字）：float 实际有 24 位精度（23 位显式 + 1 位隐藏位），对应约 6–7 位十进制有效数字；double 有 53 位精度（52+1），对应约 15–16 位十进制有效数字
例如 0.1 在二进制中是无限循环小数 0.0001100110011…，float 只能截取前 23 位尾数，double 截取前 52 位——两者都只是近似值，只是 double 更接近而已。
精度问题的典型表现
这些现象不是 Bug，而是 IEEE 754 的自然结果：
- 简单加法不等于预期：0.1 + 0.2 == 0.3 返回 false（double 场景），因为三者各自二进制近似值相加后仍≠0.3 的二进制近似值
- 大数下整数丢失：float f = 16777217f; System.out.println(f == 16777216f); 输出 true —— 因为 float 在该量级已无法区分相邻整数
- 比较失效：不同构造方式的相同十进制数可能不等，如 0.1f == 0.1（后者是 double）为 false，因 float 和 double 对 0.1 的截断位置不同
安全处理浮点数据的实用策略
没有银弹，但有匹配场景的正确工具：
-
金融/计费/高保真计算 → 用 BigDecimal：必须用字符串构造，如
new BigDecimal("0.1")；避免new BigDecimal(0.1)（会把 double 的误差带进来）；除法必须指定 scale 和 RoundingMode -
科学计算/图形渲染/传感器数据 → 用 double + 误差容限比较：不用
==，改用Math.abs(a - b) ；累加时考虑 Kahan 求和算法抑制误差累积 - 内存敏感或 GPU 协同场景 → float 可用，但需主动降维：比如坐标归一化到 [0,1] 区间再存 float，比直接存百万级坐标更稳妥
- 整数语义优先 → 转为 long/int 处理：金额用“分”为单位，比例用“万分比”整数存储，彻底规避小数
常见误区与避坑提醒
很多问题源于习惯性写法，而非技术限制：
- 声明 float 字面量必须加
f或F，否则编译器按 double 处理，可能导致隐式转换和意外精度提升/丢失 - 不要在循环中反复对 float/double 做 += 运算，尤其步长是 0.1、0.01 这类十进制小数——误差会线性甚至指数级放大
- JSON 库、数据库 JDBC 驱动默认将小数转为 double，若原始数据来自 BigDecimal，需显式配置精度传递行为
- 日志打印 float/double 时，
System.out.println(x)默认保留有限小数位，掩盖了实际存储值；调试时建议用String.format("%.17g", x)查看完整精度
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
