Java BigDecimal HALF_EVEN舍入时后续小数位影响结果问题咨询

使用Java 17.0.3环境测试，启动JShell：

$ jshell
|  Welcome to JShell -- Version 17.0.3
|  For an introduction type: /help intro

使用HALF_EVEN舍入模式将3084.5保留0位小数，得到结果3084：

jshell> new java.math.BigDecimal("3084.5").setScale(0, java.math.RoundingMode.HALF_EVEN)
$13 ==> 3084

相同模式下将3084.51保留0位小数，得到结果3085：

jshell> new java.math.BigDecimal("3084.51").setScale(0, java.math.RoundingMode.HALF_EVEN)
$13 ==> 3085

这个现象完全符合HALF_EVEN舍入模式的设计逻辑，对舍入规则的普遍认知误区在于：
只有当待舍弃部分的数值恰好等于保留位最小计数单位的1/2时，才会触发HALF_EVEN特有的“取相邻偶数”逻辑；只要待舍弃部分的数值大于这个半值阈值，无论超出幅度多小，都会直接向上进位，不会进入奇偶判断分支。

对两个测试场景的具体判定过程：

• 处理3084.5保留0位小数的需求时，保留位是个位，最小计数单位是1，对应的半值阈值为0.5。此时待舍弃的小数部分刚好是0.5，完全匹配半值触发条件，才会进入奇偶判断：保留部分的最后一位是4（偶数），因此舍去小数部分得到3084。
• 处理3084.51保留0位小数的需求时，待舍弃的小数部分是0.51，比0.5的阈值大，不属于“恰好半值”的场景，因此直接向上进位得到3085。这里小数点后第二位的1没有什么特殊作用，本质是它的存在让整个待舍弃段跨过了半值线——哪怕待舍弃部分是0.5000001，只要大于0.5，都会直接进位。

很多人对HALF_EVEN（也叫银行家舍入）的记忆只停留在“遇5奇进偶舍”，完全漏掉了规则的前置条件。该模式的完整判定优先级非常清晰：

1. 先比较待舍弃部分和保留位半值的大小：
   • 待舍弃部分小于半值：直接舍去
   • 待舍弃部分大于半值：直接向高位进1
2. 仅当待舍弃部分完全等于半值（也就是待舍弃段最高位是5，后面所有数位全为0）时，才会判断保留位最后一位的奇偶：奇数则进位凑成偶数，偶数则直接舍去。

这种设计的核心目的是让大量重复舍入操作的正负误差可以相互抵消，避免传统四舍五入规则中逢5就进位导致的统计结果系统性偏高的问题。

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