惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园 - 【当耐特】
Stack Overflow Blog
Stack Overflow Blog
V
Visual Studio Blog
小众软件
小众软件
The Cloudflare Blog
T
Tailwind CSS Blog
Apple Machine Learning Research
Apple Machine Learning Research
爱范儿
爱范儿
美团技术团队
WordPress大学
WordPress大学
罗磊的独立博客
Microsoft Azure Blog
Microsoft Azure Blog
A
About on SuperTechFans
Last Week in AI
Last Week in AI
月光博客
月光博客
博客园 - Franky
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
G
Google Developers Blog
GbyAI
GbyAI
B
Blog
大猫的无限游戏
大猫的无限游戏
博客园 - 聂微东
Hugging Face - Blog
Hugging Face - Blog
博客园 - 叶小钗

Java

开源:用刚发布的 Spring AI 2.0.1,撸了一个全功能 Agent - V2EX 纯开源 Nexus 替代方案 kkRepo 1.0.0 正式发布,新增 R/CRAN、Go Hosted 和多套 UI 主题 - V2EX 不想写代码,但想要集成一个登录页面? Sa-Token-Quick-Login 帮你实现! - V2EX 善于学习的 Java 后端朋友们,想请教下你是如何榨干自己的工作项目经验,把它沉淀下来慢慢积攒成自己的能力的? - V2EX Java Crac 几乎正式可用 - V2EX Sa-Token v1.46.0 发布 🚀,来看看有没有令你心动的功能! - V2EX 可以下线 Nexus 了:纯开源制品仓库 kkRepo v0.9.0 发布,新增 Alpine、Hugging Face Models 与全局搜索 - V2EX Java 转 native 究竟行不行?无需精通 graalvm native-image 配置就能打包 native exe 方法分享。 - V2EX fastjson 居然停止维护了 - V2EX happens-before 详解 华为的毕昇 JDK 8 AppCDS 特性稳定吗? 我把 Java 开发的 kkRepo 支持 AOT 编译, 1s 极速启动,空闲内存小于 200MB fastjson1.x 最新版本疑似又出 RCE 漏洞了 讲讲我怎么获得 kkRepo 的首个企业用户,成功替换掉 Nexus,每年节省 $1,620 PRO 订阅费用 Sonatype 正引入 Maven Central 仓库发布使用情况可见性和针对高流量发布活动的限制 让 Java 再次伟大,没有人比我更懂得如何打包!(分享一个四两拨千斤的多 jar 打包 exe 方式) 使用 kkRepo 搭建 Maven 私服 Nexus 的平替 neuxs-plus 开源涉嫌商标侵权,被迫改名 kkRepo 我在 IDEA tab 里养了一只猫 Java 确实是内存高效的 用 AI 把 visualvm 的部分功能界面换了个马甲 javaer 现在出去面试 问哪些内容 sa-token + spring cloud gateway 过滤器顺序问题 关于在 wsl 中使用 idea 进行 Java 开发的问题 求助, Fortify 漏扫问题解决 微信 ClawBot 和企微 AIBot 的 Java SDK 老业务信创重构选型大家有啥建议 ai 编程的情况在你们使用什么 IDE 下面这段 Java 多态的代码,如何才能改为 Go、 Python 、JS、C++版本? JDK 26 发布,非 lts 版本
讨论个问题:该不该重写 equal 和 hashcode
WngShhng · 2025-12-23 · via Java

和 AI 交流的时候产生的一个问题:

AI 的大致结论是,对于业务类,如果存在明确的唯一标识,比如 ID ,那么应该重写这两个方法,这样在做哈希表之类的时候才能直接使用业务类。

但我认为的是,因为当把一个对象放进哈希表的时候,我会默认它的 hashcode 方法是默认的,也就是每个对象有唯一的哈希值。如果重写了 hashcode ,那么在使用的过程中如果不知道这个类复写了 hashcode ,那么就容易导致代码问题。

所以,我想知道做 java 后端的,你们一般会重写吗?

AI 的一部分原文:

如果抛开 “数量占比”,聚焦于「开发中需要重点设计、保证正确性的核心场景」,重写的频率会远高于 “不重写” 的核心场景,原因如下:

核心类必重写:所有承载业务数据的核心类(如 User 、Order 、Goods 等),几乎 100% 需要重写 —— 这是保证哈希集合正常工作、业务对象唯一性判断、序列化后比对等核心功能的前提,不存在 “可选” 的空间;

重写的 “重复性” 更高:一个项目中,数据承载类的数量虽少,但每个类的开发都必然包含 “重写 equals/hashCode” 这一步(无论是手动生成、Lombok 注解还是 Record 类),属于 “必做操作”;而不重写的类,只是 “无需额外操作”,并非 “主动开发行为”;

工具的普及佐证高频需求:Lombok 的 @EqualsAndHashCode 、Java 16 + 的 Record 类(默认重写)、IDE 自动生成功能,这些工具的广泛使用,本质是因为 “重写” 是开发中的高频需求,才会有大量工具来简化这一操作。