hashset元素重复的根本原因是对象的hashcode()与equals()实现不合规或使用不当：必须确保参与equals判断的字段全部参与hashcode计算，且这些字段不可变；否则会导致去重失效、contains失查等脏数据问题。
排查线上系统因 HashSet 元素重复引发的脏数据问题，核心在于确认“本该去重却未去重”的异常行为是否真实发生，并定位其根源——通常不是 HashSet 本身出错，而是对象的 hashCode() 和 equals() 实现不合规或使用方式不当。
确认是否真有重复元素被存入
不要仅凭业务日志或结果反推，需直接验证 HashSet 状态：
- 在关键节点（如去重后、入库前）用
set.size()与原始集合大小对比，若差值异常小，说明去重失效 - 用
set.stream().filter(e -> set.contains(e)).count()验证自身是否含重复引用（极少发生，但可排除 JVM 或严重 bug） - 对可疑对象打印其
hashCode()和toString()，检查相同业务语义的对象是否返回不同哈希值
重点检查自定义对象的 equals/hashCode 实现
90% 的脏数据问题源于此。必须同时满足两个条件：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
所有参与 equals 判断的字段，也必须参与 hashCode 计算 —— 比如用
name和id判等，但hashCode只基于name，就会导致逻辑相等的对象哈希不一致，被分到不同桶，跳过 equals 比较 -
参与计算的字段必须是不可变的（immutable） —— 若对象加入 HashSet 后修改了影响 hashCode 的字段（例如把 List 属性清空、修改时间戳），会导致后续
contains()找不到它（哈希位置已变），甚至同个对象能被重复 add
检查运行时对象状态是否被意外修改
尤其注意以下高危模式：
- 将含可变字段（如
ArrayList、HashMap、StringBuilder）的对象放入 HashSet，之后又调用其add()、clear()等方法 - 多线程共享同一对象实例并并发修改，导致
hashCode()结果在计算中途变化 - 使用 Lombok 的
@Data但未注意字段是否真的稳定；或手写hashCode()时漏掉新添加的业务字段
用诊断性代码快速验证问题路径
在线上灰度或预发环境加入轻量日志：
- 记录每次
set.add(obj)的返回值，标记为true（首次加入）或false（判定重复） - 对返回
false却仍进入后续流程的对象，打印其完整字段 +obj.hashCode()+System.identityHashCode(obj)，确认是否为同一实例被误判为不同 - 抽样采集若干“疑似重复但未被拦截”的对象对，手动调用
a.equals(b)和a.hashCode() == b.hashCode()验证契约是否被破坏
本质上，HashSet 不会无故失效。所谓“重复”，往往是对象契约失守或状态失控的表象。盯住那两个方法的一致性，再看字段是否真的不变，问题基本就清晰了。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
