HashSet中对象属性修改后remove失败，本质是hashCode与equals逻辑不一致导致定位失效：对象修改后哈希码变化，remove时查找错误桶位，无法找到原对象，造成“丢失”而非内存泄漏。
HashSet 中对象属性修改后 remove 失败，本质是哈希码（hashCode）与 equals 逻辑不一致导致的定位失效，不是内存泄漏本身，而是对象“丢失”在集合中无法被清理。
为什么修改属性后 remove 不生效
HashSet 底层基于 HashMap 实现，添加/查找/删除都依赖对象的 hashCode() 和 equals()。当对象被加入 HashSet 后，其 hashCode 决定了它存放在哪个桶（bucket）；后续 remove 时，会先用当前对象的 hashCode 找桶，再在该桶内遍历比较 equals。
如果修改了影响 hashCode 计算的字段（比如 name、id 等参与重写的字段），会导致：
- 原对象在 HashSet 中的存储位置（桶）与修改后对象计算出的桶不一致
- remove 时去错的桶里找，自然找不到，返回 false
- 对象仍留在 HashSet 中，但再也无法通过正常方式访问或移除
哪些修改会引发这个问题
只要改动了参与 hashCode() / equals() 计算的字段，且未同步更新哈希表结构，就会出问题。常见场景包括：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
- 使用 Lombok 的 @Data 或手动重写了 equals/hashCode，字段如 userId、status、name 被修改
- 对象放入 HashSet 后调用 setter 修改了关键属性
- 使用可变对象（如 StringBuilder、ArrayList）作为 equals/hashCode 的成员，且后续修改了其内容
如何避免和修复
核心原则：**存入 HashSet 的对象，其参与 equals/hashCode 的字段应保持不可变（immutable）**。具体做法：
- 将用于 equals/hashCode 的字段设为 final，构造时赋值（推荐）
- 若必须可变，修改前先 remove，改完再 add 回去（注意并发安全）
- 排查代码中是否对已加入集合的对象调用了 setter —— 这是最常见的疏漏点
- 使用 IDE 检查：重写 equals/hashCode 时，确认所有字段都被包含且逻辑一致；启用 “warn if mutable fields used in hashCode” 类似检查（部分插件支持）
快速定位技巧
遇到 remove 返回 false 且对象疑似“还在”时，可加临时日志验证：
- 打印待删对象的 hashCode() 和 equals() 结果（对比集合中实际存在的对象）
- 遍历 HashSet，手动调用 equals 判断是否存在逻辑相等但 hashCode 不同的对象
- 用 debugger 查看该对象在 HashMap table 中的实际索引（table[(n-1) & hash]），对比修改前后 hash 值变化
