大佬也hashcode方法上翻船了，不小心秀了一把！
前些天写了几篇面试题的文章，其中包括《重写equals方法为什么通常会重写hashcode方法？》，有朋友可能会说，这类面试题都是“面试造火箭，工作拧螺丝”。不可否认，有些面试题的确如此。
但就在今天，因为懂了这篇文章中的知识竟然在大佬面前秀了一把，帮大佬解决了疑问，还换来了一个赶明儿请吃饭的“口头支票”，哈哈~~
下面就来聊聊大佬遇到的奇怪问题以及排查解决过程。
大佬的疑惑
大佬在项目中写了类似这样的一段代码：
List<ProjectId> list = new ArrayList<>();
// 省略add数据操作
List<DeviceModel> models = list.stream().map(ProjectId::getDeviceModel).distinct().collect(Collectors.toList());
System.out.println(models);
结果呢，这段代码中的distinct()方法并没有起效，并没有达到去重的预期。
但大佬并没有放弃，先是查了该方法的文档：
Returns a stream consisting of the distinct elements (according to Object.equals(Object)) of this stream.
For ordered streams, the selection of distinct elements is stable (for duplicated elements, the element appearing first in the encounter order is preserved.) For unordered streams, no stability guarantees are made.
This is a stateful intermediate operation.
通过API文档来看并没有问题，进而大佬开启了debug模式，发现奇怪的是实体类的equals方法都没进。
大佬解决问题思路值得我们先学习一波，在大佬决定最终放弃的前，给我发消息了，问有兴趣看一看没。有这么奇怪的现象，怎能不研究一下呢？
解决思路
根据大佬发的部分代码和实现思路，把整个模拟的测试程序补充完整，创建了两个实体类ProjectId和DeviceModel，并重写了equals方法（跟大佬沟通，他重写了equals方法，并且单独使用是生效的）。
DeviceModel实体类，简单重写了equals方法，只比较字段no是否相等。
@Data
public class DeviceModel {
private String no;
@Override
public String toString(){
return no;
}
@Override
public boolean equals(Object other) {
if (this == other) {
return true;
}
if (other == null || getClass() != other.getClass()) {
return false;
}
return this.toString().equals(other.toString());
}
}
ProjectId实体类，重写了equals方法，
@Data
public class ProjectId {
private int id;
private DeviceModel deviceModel;
}
然后，构建了测试类：
public class Test {
public static void main(String[] args) {
List<ProjectId> list = new ArrayList<>();
DeviceModel device1 = new DeviceModel();
device1.setNo("1");
ProjectId projectId1 = new ProjectId();
projectId1.setDeviceModel(device1);
projectId1.setId(1);
list.add(projectId1);
DeviceModel device2 = new DeviceModel();
device2.setNo("1");
ProjectId projectId2 = new ProjectId();
projectId2.setDeviceModel(device2);
projectId2.setId(1);
list.add(projectId2);
DeviceModel device3 = new DeviceModel();
device3.setNo("2");
ProjectId projectId3 = new ProjectId();
projectId3.setDeviceModel(device3);
projectId3.setId(2);
list.add(projectId3);
List<DeviceModel> models = list.stream().map(ProjectId::getDeviceModel).distinct().collect(Collectors.toList());
System.out.println(models);
}
}
先构建了一组数据，然后让device1与device2的no属性一样，重写了equals方法，理论上它们应该是相等的，device3对象用来做对照。
执行上面的程序，控制台打印如下：
[1, 1, 2]
的确还原了大佬的bug，也奇怪为什么会这样。但既然bug已重现，解决就是比较简单的事了。
此时，大佬又发来另外一个线索，说通过for循环形式没事：
List<DeviceModel> results = new ArrayList<>();
for (DeviceModel deviceModel : list.stream().map(ProjectId::getDeviceModel).collect(Collectors.toList())) {
if (!results.contains(deviceModel)) {
results.add(deviceModel);
}
}
System.out.println(results);
这种实现形式恰好又可以用来做对照。
问题排查
进行问题排查时首先也想到了debug，但是同样出现并未走equals方法的情况。
仔细看了一下代码，发现在Stream处理的过程中用到了map操作。而在之前的文章中也提到，Map中判断一个对象是否已经存在是先通过key的hash值定位到对应的数组下标，如果该位置上的Entry没有值，则直接保存；如果已经有存在的值，再通过equals方法比较值是否一样。
那么，是不是因为重写了equals方法，而没有重写hashcode方法导致的呢？于是，在DeviceModel类中新增了hashcode方法：
@Override
public int hashCode() {
// JDK7新增的Objects工具类
return Objects.hash(no);
}
再次执行，测试方法，发现可以成功去重了。很显然，大佬的失误是在重写equals方法时违背了一条原则：如果一个类的equals方法相等，那么它们的hashcode方法必须相等。由于没有重写hashcode方法导致违背这一原则。因此，在隐式使用Map时就出现了莫名其妙的问题。
后续
经过这一番周折，问题终于解决。想必大家更也更加明白了为什么重写equals方法一定要重写hashcode方法了。后面大佬又考问我一个问题：为什么list.contains方法不会出现这个问题呢？
因为List的底层结构是数组，不像Map那样为了提升效率先对Key进行hash处理比较。简单看一下ArrayList中contains方法的核心实现：
public int indexOf(Object o) {
if (o == null) {
for (int i = 0; i < size; i++)
if (elementData[i]==null)
return i;
} else {
for (int i = 0; i < size; i++)
if (o.equals(elementData[i]))
return i;
}
return -1;
}
可以看出如果对象不为null时，还是循环调用的equals方法来处理的。
小结
通过本篇文章讲了一个帮大佬定位问题的故事，感谢大佬给我一个很好的写作素材，这期间有很多值得学习和借鉴的内容。从侧面也证明，有些面试题的确有它的价值，如果你以为只是在造飞机，真有可能是在实践中没遇跳到坑里到而已。
最后，大佬就是因为没好好看公众号的上篇文章，才掉坑里的[捂脸][捂脸][捂脸]。所以，间接说明本公众号的内容对大家还是能提供一些帮助的，感兴趣就关注一下。也欢迎直接加微信好友，探讨一些有意思的技术问题。
往期推荐
如果你觉得这篇文章不错，那么，下篇通常会更好。添加微信好友，可备注“加群”（微信号：zhuan2quan）。
和花一辈子都看不清的人，
注定是截然不同的搬砖生涯。
