大佬也hashcode方法上翻船了,不小心秀了一把!

简介: 大佬也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方法来处理的。

小结

通过本篇文章讲了一个帮大佬定位问题的故事,感谢大佬给我一个很好的写作素材,这期间有很多值得学习和借鉴的内容。从侧面也证明,有些面试题的确有它的价值,如果你以为只是在造飞机,真有可能是在实践中没遇跳到坑里到而已。

最后,大佬就是因为没好好看公众号的上篇文章,才掉坑里的[捂脸][捂脸][捂脸]。所以,间接说明本公众号的内容对大家还是能提供一些帮助的,感兴趣就关注一下。也欢迎直接加微信好友,探讨一些有意思的技术问题。

目录
相关文章
|
存储 并行计算 调度
深入理解操作系统:从基础到高级
本文将深入探讨操作系统的基本原理、发展历程以及现代操作系统的设计和实现。我们将从操作系统的定义和功能开始,逐步介绍进程管理、内存管理、文件系统等核心概念,并探讨操作系统在多核处理器和云计算时代的新挑战。通过本文的学习,读者将能够更好地理解操作系统在计算机系统中的重要性,并为进一步学习和研究打下坚实的基础。
|
10天前
|
存储 关系型数据库 分布式数据库
PostgreSQL 18 发布,快来 PolarDB 尝鲜!
PostgreSQL 18 发布,PolarDB for PostgreSQL 全面兼容。新版本支持异步I/O、UUIDv7、虚拟生成列、逻辑复制增强及OAuth认证,显著提升性能与安全。PolarDB-PG 18 支持存算分离架构,融合海量弹性存储与极致计算性能,搭配丰富插件生态,为企业提供高效、稳定、灵活的云数据库解决方案,助力企业数字化转型如虎添翼!
|
8天前
|
存储 人工智能 Java
AI 超级智能体全栈项目阶段二:Prompt 优化技巧与学术分析 AI 应用开发实现上下文联系多轮对话
本文讲解 Prompt 基本概念与 10 个优化技巧,结合学术分析 AI 应用的需求分析、设计方案,介绍 Spring AI 中 ChatClient 及 Advisors 的使用。
388 130
AI 超级智能体全栈项目阶段二:Prompt 优化技巧与学术分析 AI 应用开发实现上下文联系多轮对话
|
2天前
|
存储 安全 前端开发
如何将加密和解密函数应用到实际项目中?
如何将加密和解密函数应用到实际项目中?
197 138
|
9天前
|
人工智能 Java API
AI 超级智能体全栈项目阶段一:AI大模型概述、选型、项目初始化以及基于阿里云灵积模型 Qwen-Plus实现模型接入四种方式(SDK/HTTP/SpringAI/langchain4j)
本文介绍AI大模型的核心概念、分类及开发者学习路径,重点讲解如何选择与接入大模型。项目基于Spring Boot,使用阿里云灵积模型(Qwen-Plus),对比SDK、HTTP、Spring AI和LangChain4j四种接入方式,助力开发者高效构建AI应用。
374 122
AI 超级智能体全栈项目阶段一:AI大模型概述、选型、项目初始化以及基于阿里云灵积模型 Qwen-Plus实现模型接入四种方式(SDK/HTTP/SpringAI/langchain4j)
|
2天前
|
存储 JSON 安全
加密和解密函数的具体实现代码
加密和解密函数的具体实现代码
194 136
|
21天前
|
弹性计算 关系型数据库 微服务
基于 Docker 与 Kubernetes(K3s)的微服务:阿里云生产环境扩容实践
在微服务架构中,如何实现“稳定扩容”与“成本可控”是企业面临的核心挑战。本文结合 Python FastAPI 微服务实战,详解如何基于阿里云基础设施,利用 Docker 封装服务、K3s 实现容器编排,构建生产级微服务架构。内容涵盖容器构建、集群部署、自动扩缩容、可观测性等关键环节,适配阿里云资源特性与服务生态,助力企业打造低成本、高可靠、易扩展的微服务解决方案。
1344 8
|
7天前
|
监控 JavaScript Java
基于大模型技术的反欺诈知识问答系统
随着互联网与金融科技发展,网络欺诈频发,构建高效反欺诈平台成为迫切需求。本文基于Java、Vue.js、Spring Boot与MySQL技术,设计实现集欺诈识别、宣传教育、用户互动于一体的反欺诈系统,提升公众防范意识,助力企业合规与用户权益保护。