java浮点数误差源于二进制无法精确表示十进制小数，如0.1在二进制中为无限循环小数；bigdecimal须用字符串或valueof构造，除法需指定精度与舍入模式，比较应使用compareto而非==。
Java 中浮点数计算出错，不是代码写错了，而是 float 和 double 本身就不能精确表示很多十进制小数。0.1 + 0.2 得到 0.30000000000000004，根本原因在于二进制无法终结地表达 0.1 —— 它在二进制里是无限循环小数（0.0001100110011…），而 float（23位尾数）和 double（52位尾数）必须截断，误差就此产生。
BigDecimal 构造必须用字符串或 valueOf
很多人以为“用了 BigDecimal 就万事大吉”，结果还是输出 0.300000000000000016，问题就出在构造方式：
- ❌ 错误写法：new BigDecimal(0.1) —— 先让 double 存了 0.1 的近似值，再转成 BigDecimal，误差已固化
- ✅ 正确写法：new BigDecimal("0.1") 或 BigDecimal.valueOf(0.1) —— 前者直接解析字符串，后者内部做了 safe 转换
- 所有参与运算的数字，包括常量、用户输入、数据库读取的数值，只要涉及精度要求，都应走字符串路径构造
除法必须指定精度与舍入模式
BigDecimal 的 divide() 方法不带参数会抛 ArithmeticException（除不尽时）。真实业务中几乎从不用“无限精度”：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 财务系统常用 setScale(2, RoundingMode.HALF_EVEN)，即银行家舍入（四舍六入五看奇偶）
- 电商价格展示可用 setScale(2, RoundingMode.HALF_UP)，更符合大众认知
- 避免使用 RoundingMode.UNNECESSARY，除非你 100% 确认能整除
比较浮点逻辑要用 compareTo，别用 ==
double 类型的 == 比较只比内存位，哪怕数学上相等，也可能因计算路径不同导致二进制表示微异：
- 错误：
0.1 + 0.2 == 0.3→ false - 正确：
new BigDecimal("0.1").add(new BigDecimal("0.2")).compareTo(new BigDecimal("0.3")) == 0→ true - 若需容忍微小误差（如科学计算），可用 Math.abs(a - b)
高性能场景可考虑整数放大法
当对吞吐量极度敏感（如高频交易中间件、实时风控引擎），BigDecimal 对象创建开销可能成为瓶颈：
- 把金额单位统一为“分”，重量单位转为“克”，全部用 long 计算
- 放大倍数要合理：100（两位小数）、1000（三位）、1000000（六位），避免 long 溢出（最大约 9×10¹⁸）
- 转换时务必用 Math.round(value * scale)，而非强制类型转换，防止截断误差
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
