hashset无法自动处理存入后hashcode改变的问题，对象修改影响hashcode的字段会导致查找失败、删除失效或重复添加；正确做法是设计不可变类，或修改前先remove再add。
HashSet 本身不处理、也无法自动应对存入后 hashCode 改变的问题——这是使用者的责任。一旦对象被加入 HashSet，它的哈希值就“冻结”在某个桶（bucket）里；后续若修改影响 hashCode() 的字段，该对象实际位置不会更新，导致查找失败、删除失效、甚至重复添加。
为什么修改后会“丢失”
HashSet 底层用 HashMap 存储，元素作为 key。插入时：
- 先调用
obj.hashCode()算出数组下标（比如 index = hash & (table.length - 1)） - 再把对象放进对应桶中（链表或红黑树）
- 后续
contains()、remove()都按新值重新算 hash，去另一个桶找——原桶里那个对象就“看不见”了
正确做法：避免修改，或主动同步
不是让 HashSet 适应变化，而是让对象行为符合集合契约：
-
优先设计不可变类：把参与
hashCode()和equals()的字段设为final，构造时赋值，之后不改 -
若必须可变，修改前先移除：要改 name 或 age？先
set.remove(obj)，再改字段，最后set.add(obj) - 绝不允许“原地修改后还留在集合里”：这种操作等同于让对象脱离哈希索引体系，后果是它既查不到、也删不掉、还可能被重复加
常见误区与风险
这些操作看似合理，实则危险：
- 直接调
obj.setName("new")后调set.contains(obj)→ 返回false（即使对象还在集合中） - 修改后又
set.add(new SameObject())→ 可能成功添加，造成逻辑重复 - 用 IDE 自动生成的
hashCode()，但忘了字段是否真的不该变 —— 比如用数据库主键做 hash 基础，而主键在运行时被重置，就会出问题
替代方案：用更合适的集合
如果业务确实需要频繁修改关键字段并保持唯一性，可考虑：
- TreeSet + 自定义 Comparator：基于字段比较排序，不依赖 hash，修改后只要重新插入即可（但要注意 comparator 逻辑稳定）
-
手动维护 Map
：用不变的业务标识（如 id）作 key，对象作 value，修改时按 id 查找替换 -
封装一层代理集合：写个 wrapper，在
update(obj)方法里自动完成 remove + modify + add
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
