Double作为HashMap键的适用场景与替代方案探讨

嘿，这个问题问到点子上了——不少人都踩过Double当HashMap键的坑，咱们一步步捋清楚：

核心问题就是浮点数的精度陷阱和NaN的特殊行为：

• 咱们都知道，像0.1这种十进制小数没法用二进制浮点数精确表示，计算后会产生近似值。比如double a = 0.1 + 0.2; double b = 0.3;，这俩看起来相等，但用equals比较会返回false，HashMap会把它们当成两个完全不同的键，存进去之后根本取不出来对应的值。
• 还有NaN（非数字），它的equals规则很奇葩：NaN.equals(NaN)返回false，这就导致如果把NaN作为键存进HashMap，你永远没法通过键找到它——因为查找时的equals判断永远不成立。

不是说完全不能用，得满足严格的前提：

• 所有作为键的Double值都是二进制可精确表示的浮点数，比如2.0、0.5、128.0这种，它们在二进制里是有限位，不会有精度丢失。
• 绝对不会用计算生成的近似值当键，比如从数据库读取的精确配置值、预先定义的常量，而不是通过加减乘除得到的结果。
• 明确不会涉及NaN或者无穷大的场景。

日常开发里常用的有这几种：

• BigDecimal（首推）：这是处理精确小数的标准方案，它的equals和hashCode都是基于精确数值的。注意创建时要用BigDecimal.valueOf(double)或者传入字符串（比如new BigDecimal("0.1")），别直接用new BigDecimal(0.1)——不然还是会带精度问题。
• 转换为整数：如果你的数值有固定小数位数（比如金额保留两位），直接把数值乘以对应倍数转成long类型，比如12.34变成1234。用long当键完全没精度问题，性能还高。
• 格式化字符串：把浮点数转成固定格式的字符串，比如用String.format("%.2f", num)统一保留两位小数。但要注意格式化规则一致，避免同一个数值因为格式不同变成不同的键，还要小心四舍五入的影响。

从你给出的代码片段来看，应该是用Double.doubleToLongBits(original)把double转成long类型存储，然后基于这个long值实现equals和hashCode对吧？这个思路在面试里绝对是加分项，因为它精准命中了问题的核心：用精确的long值替代有精度问题的double，彻底解决HashMap键的equals和hashCode不一致问题。

不过面试里要把细节说清楚，显得你考虑周全：

• 转换逻辑：用doubleToLongBits还是doubleToRawLongBits？前者会把所有NaN转成同一个long值，后者保留不同NaN的二进制差异。如果你的场景不需要区分不同NaN，用doubleToLongBits更合理；如果需要，就用raw版本。
• equals方法：一定要比较两个MyDouble的value（long值），而不是直接比较original的double值，不然又回到了精度问题的坑里。
• hashCode：直接用value的hashCode就行（Java里long的hashCode是(int)(value ^ (value >>> 32))，完全符合HashMap的要求）。
• 补充：这个方案虽然巧妙，但业务场景里优先用BigDecimal或者整数转换，因为它们是标准库实现，可读性和维护性更好。但作为面试题的解法，这个自定义类的思路完全可以作为最优方案之一——它能体现你对HashMap核心机制、浮点数精度问题的深入理解。

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