浮点数等值判断在高并发文件查找中易失真，根本原因是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 <p>注意：必须结合相对+绝对容差，否则在 <code>a=1e10, b=1e10+1</code> 时 <code>1e-9</code> 容错失效。</p> -
✅ 关键字段不用浮点存储
- 时间戳用
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 即使值“看起来一样”。
不复杂但容易忽略
