java浮点数计算误差非bug而是ieee 754二进制表示必然结果，应依场景选用bigdecimal（字符串构造）、整数缩放或误差阈值法规避。
Java 中浮点数计算出现 0.1 + 0.2 = 0.30000000000000004 这类结果，不是 bug，而是 IEEE 754 二进制浮点表示的必然现象。核心矛盾在于：很多十进制小数（如 0.1、0.3）在二进制中是无限循环小数，而 float（23 位尾数）和 double（52 位尾数）只能截断存储，导致舍入误差。这种误差会在加减乘除、尤其是连续运算中累积放大。
用 BigDecimal 做高精度十进制计算
这是金融、计费、订单金额等对精度零容忍场景的首选方案。
- 必须用字符串构造：
new BigDecimal("0.1")，而非new BigDecimal(0.1)—— 后者会把 double 已有的误差直接带进来 - 所有四则运算使用对应方法：
.add()、.subtract()、.multiply()、.divide(divisor, scale, roundingMode) - 除法必须指定精度和舍入模式，例如：
a.divide(b, 2, RoundingMode.HALF_UP)表示保留两位小数，四舍五入 - 比较相等性用
.compareTo() == 0，不要用.equals()（后者会比较 scale，"1.0" 和 "1.00" 不等）
用整数替代法规避浮点运算
适用于性能敏感且业务逻辑允许缩放的场景，比如金额单位统一为“分”，温度保留整数厘度。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 将原始值乘以固定倍数转为 long 或 BigInteger，全程整数运算
- 放大倍数要合理：常用 100（元→分）、1000（米→毫米）、1000000（秒→微秒）
- 转换时用
Math.round(value * scale)防止截断误差，避免直接强转(long)(value * scale) - 注意溢出风险：大数值 × 大 scale 可能超出 long 范围，必要时改用 BigInteger
用误差阈值代替直接相等判断
适合科学计算、物理模拟、图形渲染等允许微小偏差的场景。
- 永远不要写
if (a == b)判断两个 double 是否相等 - 改用
if (Math.abs(a - b) ，其中 epsilon 是可接受的误差上限 - 普通计算推荐
1e-10，物理引擎常用1e-8，图形渲染可放宽到1e-6 - 若涉及数量级差异大的数，建议用相对误差：
Math.abs(a - b) / Math.max(Math.abs(a), Math.abs(b))
理解并规避底层存储陷阱
不盲目优化，先看清问题根源才能选对策略。
- float 比 double 更容易丢精度：float 仅约 7 位十进制有效数字，double 约 15 位；除非内存极度受限，否则优先用 double
- 大数精度丢失不可避免：当数值超过
2^24（float）或2^53（double）时，相邻可表示浮点数的间隔大于 1，f + 1 == f就会发生 - 不要依赖编译器或 JVM 的“优化”：像
0.1f + 0.2f和0.1d + 0.2d结果不同，混用 float/double 比较极易出错 - 日志或展示用 DecimalFormat / String.format 控制显示位数，但不能修复计算过程中的误差
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
