Java中HALF_UP舍入与Math.round结果不一致的疑问

你的理解没有错误，RoundingMode.HALF_UP确实是常规的"四舍五入"逻辑（舍弃部分≥0.5时向上舍入）。问题出在浮点数的精度限制：你用到的9999.005、999.005这类十进制小数，无法被二进制浮点数（Java的double类型）精确存储，实际内存中的值和字面量存在微小偏差，导致舍入逻辑的触发条件不同。

具体原因分析 #

1. BigDecimal构造器的精度陷阱 #

当使用new BigDecimal(double)构造对象时，传入的double值已经是不精确的近似值：

• 9999.005作为double，实际存储的是略小于9999.005的数值（比如9999.004999999999...），此时保留两位小数时，舍弃的部分是0.004999...，小于0.005，所以不会触发向上舍入，结果为9999.00。
• 9.005作为double，实际存储的是略大于9.005的数值（比如9.005000000000001...），舍弃部分≥0.005，触发向上舍入，得到9.01。

用精确构造方式验证：

// 正确的精确构造方式
new BigDecimal("9999.005").setScale(2, RoundingMode.HALF_UP); // 结果为9999.01
new BigDecimal("999.005").setScale(2, RoundingMode.HALF_UP); // 结果为999.01
new BigDecimal("9.005").setScale(2, RoundingMode.HALF_UP); // 结果为9.01

2. Math.round的误差传递 #

Math.round(9999.005*100)的计算过程同样受精度影响：

• 9999.005*100的实际结果是999900.499999...，Math.round会将其舍入为999900，除以100后得到9999.0。
• 999.005*100的实际结果是99900.500000...，刚好触发向上舍入，得到99901，除以100后为999.01。

正确的解决方法 #

要避免浮点数精度导致的舍入异常，必须保证初始数值的精确性：

• 优先使用BigDecimal(String)构造器，直接解析十进制字符串，彻底避免二进制浮点数的精度损失。
• 如果必须从double转换，使用BigDecimal.valueOf(double)方法，它会将double转换为对应的十进制字符串再构造，比new BigDecimal(double)更可靠。

示例代码：

// 推荐方式：字符串构造
BigDecimal num1 = new BigDecimal("9999.005");
System.out.println(num1.setScale(2, RoundingMode.HALF_UP)); // 9999.01

// double转BigDecimal的可靠方式
BigDecimal num2 = BigDecimal.valueOf(9999.005);
System.out.println(num2.setScale(2, RoundingMode.HALF_UP)); // 9999.01

内容的提问来源于stack exchange，提问作者user2769607