Comparator接口equals方法：不重写Object.equals为何始终安全？

首先得抓住文档里那句话的核心：

请注意，不重写Object.equals(Object)始终是安全的

为什么这么说？因为JDK中所有依赖Comparator的核心API（比如Collections.sort()、TreeMap、Stream.sorted()这些），根本不会调用Comparator的equals方法。Comparator的本职工作是提供compare()逻辑，这些API只关心你这个compare()能不能正确比较元素，完全不在乎两个Comparator实例是不是“逻辑等价”。

Object类默认的equals是判断引用相等（this == obj），也就是只有当两个Comparator是同一个对象实例时才返回true。这种行为在绝大多数场景下都没问题——毕竟你很少需要去判断两个比较器的逻辑是不是一样。

那什么时候需要重写equals？只有当你的业务逻辑里需要判断两个Comparator的比较规则是否完全等价时，才需要动手。举个例子：如果你有个工具类，需要缓存不同的比较器实例，避免重复创建逻辑相同的对象，这时候重写equals和hashCode就有意义了。

举个具体的代码例子：
默认情况（不重写equals）：

// 两个逻辑完全一样的比较器，但不是同一个实例
Comparator<String> byLength1 = Comparator.comparingInt(String::length);
Comparator<String> byLength2 = Comparator.comparingInt(String::length);

// 默认equals返回false
System.out.println(byLength1.equals(byLength2)); // 输出 false

如果我们自定义一个比较器并重写equals：

class StringLengthComparator implements Comparator<String> {
    @Override
    public int compare(String s1, String s2) {
        return Integer.compare(s1.length(), s2.length());
    }

    @Override
    public boolean equals(Object o) {
        // 只要是同类型的实例，就认为逻辑等价
        if (this == o) return true;
        return o instanceof StringLengthComparator;
    }

    @Override
    public int hashCode() {
        // 为了配合equals，hashCode也要固定（因为所有实例逻辑相同）
        return 31;
    }
}

// 此时两个实例equals返回true
StringLengthComparator comp1 = new StringLengthComparator();
StringLengthComparator comp2 = new StringLengthComparator();
System.out.println(comp1.equals(comp2)); // 输出 true

总结一下：

• 日常使用Comparator时，完全不用管equals方法，默认的引用相等逻辑足够安全，不会影响任何JDK标准API的功能；
• 只有当你自己的业务需要判断比较器逻辑是否等价时，才需要考虑重写equals和hashCode；
• 文档里的“安全”，就是指不重写不会导致任何功能异常，因为核心API根本用不上这个方法。

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