别再让0.1+0.2不等于0.3了！Java中BigDecimal的正确使用姿势与避坑指南
金融系统凌晨告警：用户余额凭空消失0.01元。排查发现，某笔利息计算采用double类型累加，本应输出100.35元的结果却显示为100.34999999999999。这个看似微小的误差，最终导致公司单日损失超2万元——这正是不当使用浮点数引发的经典事故现场。
1. 为什么0.1+0.2≠0.3？浮点数的精度陷阱
计算机用二进制浮点数表示小数时，类似用1/2、1/4、1/8等分数组合来逼近十进制小数。就像用乐高积木拼出圆形，无论如何组合都存在缝隙：
System.out.println(0.1 + 0.2); // 输出0.30000000000000004 System.out.println(1.03 - 0.42); // 输出0.6100000000000001根本原因在于：
- 浮点数遵循IEEE 754标准，由符号位、指数位和尾数位组成
- 像0.1这样的十进制数，在二进制中是无限循环小数（类似1/3=0.333...）
- 存储时必然发生截断，导致精度丢失
金融、电商等涉及资金的系统必须禁用
double/float，误差累积可能引发法律纠纷
2. BigDecimal的生死局：初始化就是分水岭
同样的数字，不同的构造方式会导致完全不同的结果：
// 错误示范：直接传入double BigDecimal d1 = new BigDecimal(0.1); System.out.println(d1); // 0.100000000000000005551115123125... // 正确姿势：字符串构造 BigDecimal d2 = new BigDecimal("0.1"); System.out.println(d2); // 精确输出0.1初始化方案对比：
| 构造方式 | 精度保证 | 推荐指数 | 典型场景 |
|---|---|---|---|
| new BigDecimal(double) | ❌ | ⭐ | 绝对避免使用 |
| new BigDecimal(String) | ✅ | ⭐⭐⭐⭐⭐ | 金额、利率等计算 |
| BigDecimal.valueOf(double) | ✅ | ⭐⭐⭐⭐ | 临时转换已有变量 |
特殊技巧：若必须处理double类型输入，先用Double.toString()转换：
BigDecimal safe = new BigDecimal(Double.toString(0.1));3. 运算中的暗礁：除法的九死一生
当两个BigDecimal相除可能产生无限小数时，必须明确指定舍入模式，否则抛出ArithmeticException：
BigDecimal a = new BigDecimal("10"); BigDecimal b = new BigDecimal("3"); // 危险操作：未指定舍入模式 // a.divide(b); // 抛出异常 // 安全做法：指定精度和舍入规则 BigDecimal result = a.divide(b, 4, RoundingMode.HALF_UP); System.out.println(result); // 输出3.3333八大舍入模式实战指南：
RoundingMode.UP：零方向舍入1.111→1.12（总是进位）RoundingMode.DOWN：零方向截断1.119→1.11（直接舍弃）RoundingMode.HALF_UP：四舍五入1.115→1.12，1.114→1.11RoundingMode.HALF_EVEN：银行家舍入1.125→1.12（偶舍奇入）
税务计算通常要求
HALF_UP，而科学计算推荐HALF_EVEN减少累计误差
4. 性能与线程安全的双刃剑
虽然BigDecimal是线程安全的，但不当使用仍会导致性能问题：
典型陷阱：
// 错误：循环内重复创建对象 for (int i = 0; i < 10000; i++) { BigDecimal temp = new BigDecimal(i).multiply(rate); // ... } // 优化：复用不可变对象 BigDecimal rate = new BigDecimal("0.05"); BigDecimal sum = BigDecimal.ZERO; for (int i = 0; i < 10000; i++) { sum = sum.add(new BigDecimal(i).multiply(rate)); }性能优化技巧：
- 预定义常用常量：
BigDecimal.ZERO/ONE/TEN - 复杂运算使用
MathContext指定精度上下文 - 批量运算时考虑使用
stripTrailingZeros()去除多余零
5. 实战避坑清单：从血泪史中总结的黄金法则
构造禁区
- 永远不要用
new BigDecimal(0.1) - 金额字段在DTO中直接定义为
String类型
- 永远不要用
等值比较的玄机
// 错误：使用equals比较会同时校验值和scale new BigDecimal("2.0").equals(new BigDecimal("2")); // false // 正确：使用compareTo new BigDecimal("2.0").compareTo(new BigDecimal("2")) == 0; // true序列化陷阱
- JSON序列化时，Fastjson默认将
BigDecimal转为String避免精度丢失 - 使用
@JsonFormat(shape=STRING)注解强制输出字符串格式
- JSON序列化时，Fastjson默认将
数据库映射规范
-- 推荐使用DECIMAL(19,4)对应金额字段 CREATE TABLE account ( balance DECIMAL(19,4) NOT NULL COMMENT '金额' );科学计数法应对
// 避免输出1E+7这样的格式 bigDecimal.setScale(2).toPlainString();
某电商平台在促销活动期间，因未设置BigDecimal的scale导致折扣计算出现1.0000000001折的显示问题，引发大量客诉。后来团队在代码审查清单中加入以下条款：
- 所有金额计算必须显式设置
scale - 除法运算必须捕获
ArithmeticException - 所有
BigDecimal字段必须添加@Digits注解校验位数
