浮点数等值判断在高并发文件查找中易失真，根本原因是IEEE 754二进制表示缺陷导致舍入误差，不同路径计算或转换使“逻辑相等”的值内存不等；应改用容差比较、整数/BigDecimal替代、标准化后再哈希。

在高并发文件查找场景中，对浮点数做等值判断（比如 == 或 equals）容易失真，根本原因不在并发本身，而在于浮点数的底层表示缺陷被并发放大——多个线程同时读、算、比，让本就微小的精度误差暴露为逻辑错误。

浮点数本身无法精确表达常见小数

0.1、0.01、0.001 这类十进制小数，在二进制下是无限循环小数（类似十进制里的 1/3 = 0.333…）。IEEE 754 标准用有限位（float 23 位尾数，double 52 位）强制截断，必然引入舍入误差。
例如：

• 0.1f + 0.2f 实际存储为 0.30000001192092896
• 0.3f 实际存储为 0.30000001192092896（看似一样，但不同路径计算可能产生细微差异）
• 而 0.1d + 0.2d ≈ 0.30000000000000004，与字面量 0.3d 的二进制表示并不完全一致

这种“看起来相等、内存不等”的现象，在单线程里都足以让 == 失效；在高并发下，问题更突出。

并发环境加剧误差不可控性

多个线程可能通过不同路径获得“同一个逻辑值”：

• 线程 A 从 JSON 文件解析 "0.1" → 转 double → 得到近似值 A₁
• 线程 B 从数据库 DECIMAL 字段读出 0.1 → 转 double → 得到近似值 B₁（因转换环节不同，B₁ ≠ A₁）
• 线程 C 对两个浮点字段做加法再比较 → 中间结果又经一次舍入

即使输入源相同，JVM 优化、CPU 寄存器精度（x87 扩展精度 vs SSE）、JIT 编译时机差异，都可能导致同一段代码在不同线程中产生不一致的浮点中间值。这时用 == 判等，极易出现：

• 同一文件被重复处理（A 认为 key 匹配，B 也认为匹配）
• 关键文件被漏查（A 和 B 算出的 hash key 不同，映射到不同分片）
• 集合去重失败（两个语义相同的浮点 key 被当作不同元素存入 ConcurrentHashSet）

文件查找中常见的失真表现

• 元数据匹配失败：文件尺寸、时间戳、坐标等用 double 存储，按 size == 1024.0 查找，实际 1024.0000000000002 就被跳过
• 哈希分片错位：用 fileScore % N 做并发路由，但 fileScore 是浮点计算结果，微小误差导致取模结果突变
• 条件过滤误判：if (confidence == 0.95) 过滤识别结果，因训练模型输出或反序列化路径差异，0.95 可能变成 0.9499999999999999 或 0.9500000000000001，整条记录被丢弃

正确做法：避开等值，转向稳健比较或结构替换

• ✅ 统一用误差容忍比较

  static boolean eq(double a, double b) {
      double diff = Math.abs(a - b);
      return diff < 1e-9 || diff < 1e-12 * Math.max(Math.abs(a), Math.abs(b));
  }

  注意：必须结合相对+绝对容差，否则在 a=1e10, b=1e10+1 时 1e-9 容错失效。

• ✅ 关键字段不用浮点存储

  • 时间戳用 long 毫秒或纳秒
  • 文件大小用 long 字节
  • 置信度、评分等业务值，若需精确比较，改用整数比例（如 95 表示 0.95）或 BigDecimal 字符串索引

• ✅ 集合操作前做标准化
  对必须用浮点作 key 的场景（如某些向量相似度），先四舍五入到业务可接受精度再哈希：

  String safeKey = BigDecimal.valueOf(score).setScale(6, RoundingMode.HALF_UP).toString();

• ✅ 避免在 ConcurrentHashMap 的 key 中直接放 float/double
  因 hashCode() 和 equals() 对浮点数默认行为不可靠，极易导致 get() 返回 null 即使值“看起来一样”。

不复杂但容易忽略