修改Java HashSet中对象属性值后contains方法失效问题

问题核心原因 #

HashSet底层基于HashMap实现，它的查找逻辑是先靠hashCode定位哈希桶，再在桶内用equals比对元素。你的问题根源在于修改了元素中决定hashCode的属性，导致元素的实际存储位置和新hashCode对应的位置完全不匹配：

1. 当你把n1(val=1)添加到HashSet时，它的hashCode为1，被存入哈希桶1的位置。
2. 遍历集合修改n1的val为5后，n1的hashCode变成了5，但它物理上仍留在哈希桶1里——HashSet不会自动重新计算元素的存储位置。
3. 再次调用contains(n1)时，会先计算n1当前的hashCode=5，然后去哈希桶5查找，而这个桶是空的，所以直接返回false，根本没机会触发equals方法。

代码对应验证 #

从你的运行结果能看到，修改val后n1.getVal()输出为5，说明对象本身确实被修改了，但HashSet的存储结构没有同步更新。equals方法里的打印语句未执行，正好印证了「没找到对应哈希桶，所以没进入equals比对环节」的逻辑。

解决方案 #

要避免这类问题，有两种可行方案：

• 把影响hashCode的属性设为不可变：比如将Node类的val用final修饰，禁止后续修改。
• 如果必须修改属性，修改后先从HashSet中移除该元素，再重新添加，让HashSet根据新的hashCode重新定位存储位置：

  // 修改val后执行
  s.remove(n1);
  s.add(n1);
  

额外注意 #

Java规范明确要求：若两个对象equals相等，它们的hashCode必须相等；反过来，hashCode相等的对象不一定equals相等。但更关键的是，如果一个对象要放在哈希集合（HashSet/HashMap）中，它的hashCode值应该在存储期间保持不变——否则就会出现这种「元素明明在集合里，却查不到」的异常情况。

内容的提问来源于stack exchange，提问作者JakeQ