从一次线上金额对账Bug说起：手把手教你用BigDecimal重构Java浮点数计算
从一次线上金额对账Bug说起：手把手教你用BigDecimal重构Java浮点数计算
凌晨三点，电商平台的财务对账系统突然告警——当日订单总金额与支付流水相差0.01元。这个看似微小的差异引发了长达6小时的排查，最终发现是优惠券计算中0.1 + 0.2的结果竟是0.30000000000000004。这个经典案例揭示了Java浮点数计算的陷阱：当金融、电商等系统涉及精确计算时，double和float类型就像走钢丝，而BigDecimal才是安全绳。
1. 浮点数的精度陷阱：为什么0.1+0.2≠0.3？
在计算机底层，浮点数采用IEEE 754标准用二进制表示十进制小数。就像1/3在十进制中无法精确表示（0.333...），0.1在二进制中也是无限循环数（0.0001100110011...）。这种存储方式必然导致精度丢失，尤其经过多次运算后误差会累积放大。
典型问题场景：
- 电商优惠券计算：
0.66 * 10 = 6.6000000000000005 - 财务系统汇总：
0.1 + 0.2 = 0.30000000000000004 - 税率计算：
9.99 * 0.08 = 0.7992000000000001
// 危险的浮点运算示例 System.out.println(1.03 - 0.42); // 输出0.6100000000000001 System.out.println(1.00 - 9 * 0.10); // 输出0.099999999999999982. BigDecimal的正确打开方式
2.1 初始化：字符串才是王道
BigDecimal的构造函数有双刃剑：
// 错误示范 - 仍可能丢失精度 BigDecimal d1 = new BigDecimal(0.1); // 正确姿势 - 始终使用String构造 BigDecimal d2 = new BigDecimal("0.1");为什么？直接传入double时，构造函数实际接收的是已经存在精度损失的二进制值。而字符串构造会直接解析十进制表示。
2.2 不可变性带来的性能考量
每个BigDecimal运算都产生新对象，高频计算时可能引发GC压力。解决方案：
// 反模式：链式调用创建多个中间对象 BigDecimal result = a.add(b).multiply(c).divide(d); // 优化方案：重用对象 BigDecimal temp = a.add(b); temp = temp.multiply(c); result = temp.divide(d);3. 全链路改造实战
3.1 数据库层映射
| 数据库类型 | Java类型 | 备注 |
|---|---|---|
| FLOAT | ❌ 禁止使用 | 精度不可控 |
| DOUBLE | ❌ 禁止使用 | 同FLOAT |
| DECIMAL | ✅ BigDecimal | 需指定精度(如DECIMAL(19,4)) |
MyBatis配置示例：
<resultMap type="Order"> <result column="amount" property="amount" jdbcType="DECIMAL" javaType="java.math.BigDecimal"/> </resultMap>3.2 DTO与序列化处理
JSON序列化时需要特殊处理：
// Jackson配置 @JsonFormat(shape = JsonFormat.Shape.STRING) private BigDecimal price; // 防止科学计数法 new DecimalFormat("#0.00").format(bigDecimalValue);3.3 工具类封装
建议创建MoneyUtils统一处理：
public class MoneyUtils { private static final int DEFAULT_SCALE = 2; private static final RoundingMode ROUNDING_MODE = RoundingMode.HALF_UP; public static BigDecimal add(BigDecimal a, BigDecimal b) { return a.add(b).setScale(DEFAULT_SCALE, ROUNDING_MODE); } public static boolean isGreaterThan(BigDecimal a, BigDecimal b) { return a.compareTo(b) > 0; } }4. 核心运算的避坑指南
4.1 除法必须指定精度
// 危险操作 - 可能抛出ArithmeticException BigDecimal danger = a.divide(b); // 安全做法 - 指定舍入模式 BigDecimal safe = a.divide(b, 2, RoundingMode.HALF_UP);4.2 四舍五入的八种姿势
| 模式 | 9.99处理(1位小数) | -9.99处理(1位小数) |
|---|---|---|
| HALF_UP (常用) | 10.0 | -10.0 |
| HALF_DOWN | 9.9 | -9.9 |
| UP | 10.0 | -10.0 |
| DOWN | 9.9 | -9.9 |
| CEILING | 10.0 | -9.9 |
| FLOOR | 9.9 | -10.0 |
4.3 金额比较的正确姿势
// 错误示范 - 可能因精度问题失效 if (amount1.equals(amount2)) {...} // 正确方法 - 使用compareTo if (amount1.compareTo(amount2) == 0) {...}5. 性能优化与监控
虽然BigDecimal解决了精度问题，但需注意：
- 创建成本比
double高10-20倍 - 复杂运算可考虑
stripTrailingZeros()去除多余零 - 监控GC日志，避免大数运算引发内存问题
// 去除末尾零示例 BigDecimal value = new BigDecimal("100.00"); System.out.println(value.stripTrailingZeros()); // 输出1E+2在电商大促期间，我们曾通过将频繁计算的优惠金额缓存为String类型，使用时再转为BigDecimal，使QPS提升了35%。这提醒我们：精度与性能需要平衡，关键是要在正确的地方做精确计算。