equals 与 hashCode：让“相同”有一致的含义

比较两个对象前，先决定你说的“相同”是什么意思。例如两份用户资料是按用户编号判断相同，还是只有同一个对象才算相同？引用上的 == 判断是不是同一个对象，Object 默认的 equals 也是如此；String 的 equals 则比较内容。金额还可能需要同时比较币种和数值，不能没想清业务规则就让 IDE 按所有字段生成比较方法。

equals 的规则必须自洽：对象等于自己，交换比较方向不改变结果，a 等于 b 且 b 等于 c 时 a 也应等于 c；相关内容未变，结果也应一致。非空对象与 null 比较应为 false。两个对象 equals 为 true 时，hashCode 必须相同；反过来不成立。哈希集合先用哈希值缩小查找范围，再比较对象，不能只把哈希值当成唯一编号。

参与相等与哈希的字段应在作为键期间保持稳定。可变键放入 HashMap 后再改相关字段，后续查询可能无法按新的哈希定位原条目。优先使用稳定 ID 或由不可变组件组成的值对象。Java17 record 自动提供基于组件的相等与哈希，但它是浅不可变；数组组件默认仍按数组自身的相等语义，不会自动变成逐元素比较。

哈希容器先用哈希信息找到候选位置，再检查是不是同一个键对象，或用 equals 判断是否相等。多个键的哈希发生冲突，并不表示它们就是同一个键；只要它们彼此不相等，且 equals 与 hashCode 遵守约定，容器仍能区分它们。

反过来，两个按业务规则相等的对象如果给出不同哈希值，容器就可能去不同位置查找，导致去重或读取不符合预期。所以要让 equals 与 hashCode 配合，而不是要求所有键都不发生冲突。

继承会让值相等更难设计。父类按编号比较，子类再要求额外字段相等，可能使父对象认为子对象相等，而子对象认为父对象不同，破坏对称性。使用 getClass、instanceof 或可扩展相等协议都有不同约束，不能只背某个模板；对于明确的值对象，限制继承常能缩小推理范围。

“相同”要按具体类型判断。数组的 equals 看的是不是同一个数组对象；要逐个比较元素，应使用相应的 Arrays 方法。BigDecimal.equals 还会比较 scale：数值相同，表示方式不同，也可能被判为不相等；compareTo 比较数值时，则可能把这些值判为相等，返回 0。

因此选择 HashSet 或 TreeSet 前，要确认业务想用 equals 与 hashCode 去重，还是用排序比较结果去重，不能把这两套判断当成总是一样。

真实 Objects.equals 先检查引用是否相同，再在左值非空时调用左对象的 equals。模型把短路表达式展开为分支，便于观察空值处理顺序。它没有反射遍历字段，也没有递归比较任意对象图；内容比较仍然由被调用类型决定。

当两边都是 null，身份分支返回 true；只有左边为 null 时返回 false；左边非空、右边为 null 时调用左对象的 equals，正确实现应返回 false。这个辅助方法减少调用点的空值判断，却不能替类型修复一个不遵守契约的 equals 实现。

如果 left.equals(right) 和反方向比较结果不同，交换 Objects.equals 的两个参数也可能改变答案。集合与通用算法要求相等比较保持对称，应该修复类型自己的规则，而不是每次调用都双向比较、猜业务想要哪个结果。

Objects.equals 不负责计算哈希值。hashCode 和 hash 工具能帮助生成数值，但用哪些字段仍要由作者决定。若把 equals 改为按内容判断相等，却保留 Object 的默认 hashCode，就无法保证相等的不同实例一定有相同哈希；应配套实现。自动生成的方法也要检查可变字段和继承情况。源码虽然短，正确使用仍取决于业务如何定义“相同”。

记录由 group 与 id 组成的 Key，按两组件共同相等汇总出现次数，输出顺序按键首次出现。允许空输入，拒绝 null 列表和 null 键。哈希冲突的不同键必须分别计数。

用 Key 表达复合键，避免把两个字段拼成字符串后依赖易冲突的分隔符。LinkedHashMap 负责按首次插入顺序保存计数；遇到已有逻辑键就增加对应次数，遇到新键才增加一个输出位置。不同实例但组件相等应该进入同一计数项。

合并条件来自 Key.equals，而不是原对象身份或哈希值。特意使用 Aa 与 BB 字符串构造碰撞样本，可以说明相同哈希并不意味着两个不同组名被合并。测试直接确认这组键发生哈希冲突，再确认结果仍然有两项，才能真正覆盖碰撞处理而非仅测试普通不同键。

扫描结束后把映射转成结果列表，使输出格式与内部数据结构分开。次数用精确加法表达不能静默溢出的契约；对于单次 Java List 的普通长度约束通常不会达到溢出，但未来改成持续流时该策略仍清楚。复杂度依赖散列表操作前提，并不把所有敌意碰撞输入都当作常数查找。

每条记录查询更新一次，结束时遍历 k 个键生成结果；具体最坏成本还取决于散列分布、容器冲突结构与键比较成本。

实体身份与值对象相等应分开讨论。数据库实体在持久化前可能没有 ID，若把尚未分配的 null ID 视为相等，会意外合并多个新对象；若生成后再改变参与哈希的字段，放在集合中的键又可能失效。可以避免把这种生命周期变化对象直接作为哈希键，改用稳定业务键或专门标识。

缓存、去重和重复请求处理都需要一致的键规则，但 Java 的 equals 不会自动与数据库唯一约束、其他语言比较方式保持一致。应明确大小写、空白整理和租户编号等规则。漏掉租户，可能让不同用户的数据混到一起；把无关更新时间加进键，又可能让本应相同的对象查不到缓存。

测试相等契约要有不同实例和多个对象组合。自反测试容易通过，对称与传递需要两个或三个有代表性的对象，哈希一致性则应在相等样本上明确断言。碰撞样本验证容器正确性，可变键实验帮助理解风险；正式设计优先消除可变键，而不是写更多补救查找逻辑。