比较契约：不是不让你自定义排序，是自定义了就必须自圆其说（027）

知识库文档 28 / 251

覆盖考点：027｜比较契约：Comparable 与 Comparator、契约约束与整数溢出陷阱

适合读者：高级 Java 工程师、技术专家、架构师候选人

预计阅读时长：24 分钟（文末问答不计入）

上一篇讲的集合迭代安全，解决的是"遍历时集合被改了会怎样"的问题，这一篇要讲的是另一个几乎所有排序相关 API 都绕不开的话题：Collections.sort()、TreeMap、TreeSet、PriorityQueue 到底怎么知道两个业务对象该谁排在前面。很多人知道 Comparable 和 Comparator 这两个名字，却说不清楚它们的边界，也不知道自己实现的比较逻辑必须满足一套数学上的约束——一旦违反这套约束，最常见的后果不是抛异常，而是数据在 TreeSet/TreeMap 里悄悄消失。这篇要讲清楚这套"比较器契约"具体要求什么，以及两个最容易被忽略的真实陷阱。

面试官在这个考点上通常这样追问：Comparable 和 Comparator 最核心的区别是什么 → 如果一个类已经实现了 Comparable，还能用 Comparator 排序吗 → 比较器契约具体要求什么 → 违反契约会有什么真实后果 → 手写 compareTo 用减法实现有什么风险 → Comparator 的链式方法 thenComparing 是怎么工作的。本文按这条链展开。

一、为什么排序需要一个"契约"

Collections.sort()、Arrays.sort()、TreeMap、TreeSet、PriorityQueue 这些依赖排序的 API，都有一个共同的前提：它们并不知道你的业务对象该按什么规则排列，必须有人告诉它们"怎么比较两个元素的大小"。Java 给出了两条路径：让对象自己知道怎么和别人比较（Comparable），或者单独写一个"比较规则"传进去（Comparator）。这两条路径的选择、组合方式，以及一旦违反了比较逻辑必须遵守的契约会踩出什么坑，就是这篇要讲的内容。

二、Comparable：对象的"自然顺序"

Comparable<T> 接口只有一个方法：int compareTo(T o)。哪个类实现了这个接口，就相当于给这个类定义了一种自然顺序——比如 Integer、String 都实现了 Comparable，数字按大小、字符串按字典序，这是刻在类定义里的、唯一的一种排序方式。

compareTo() 的返回值语义：负数表示"当前对象小于参数"，正数表示"大于"，0 表示"相等"。Collections.sort(list) 这种不传比较器的重载版本，依赖的就是元素自身实现的 compareTo()。它的局限也很明显：一个类只能定义一种自然顺序，如果同一批对象既想按价格排序、又想按销量排序，Comparable 单独一个接口是不够用的。

三、Comparator：外部定义的排序规则

Comparator<T> 是一个函数式接口，核心方法是 int compare(T o1, T o2)，语义和 compareTo() 完全一致，只是它不需要侵入到目标类内部——你可以为同一个类写任意多个 Comparator 实现，分别代表"按价格排"、"按销量排"、"按上架时间排"，在需要的时候作为参数传给 Collections.sort(list, comparator)、list.sort(comparator)、new TreeMap<>(comparator) 等。

现代写法一般不会手写匿名类，而是用 Comparator.comparing(keyExtractor) 结合方法引用，比如按价格升序：list.sort(Comparator.comparing(Product::getPrice))。

链式方法非常关键：thenComparing(...) 用来在前一个比较结果为 0（相等）时追加下一层比较条件，reversed() 用来把整个比较器的顺序反转。比如按年龄升序、年龄相同再按姓名字典序排列：Comparator.comparing(User::getAge).thenComparing(User::getName)。

四、比较器契约：不是建议，是必须遵守的规则

无论是 compareTo() 还是 compare()，都必须满足几条数学上的约束，这些约束合起来称为"比较器契约"：

符号一致性（反对称）：sgn(compare(x, y)) == -sgn(compare(y, x))。也就是说 x 比 y 大多少，y 就应该比 x 小对应的量级（符号相反）。
传递性：如果 compare(x, y) > 0 且 compare(y, z) > 0，那么必须有 compare(x, z) > 0。排序结果不能出现"A 比 B 大，B 比 C 大，但 A 却不比 C 大"这种自相矛盾的情况。
相等的传递一致性：如果 compare(x, y) == 0，那么对任意 z，compare(x, z) 和 compare(y, z) 的符号必须相同。
（强烈建议但非强制）与 equals 一致：compare(x, y) == 0 应该等价于 x.equals(y)。这一条不是语言层面强制的，但如果违反了，TreeSet/TreeMap 的行为会变得违反直觉——它们判断"两个元素是否相等"用的是 compareTo()/compare() 而不是 equals()。

五、违反契约的真实后果：元素"消失"

最容易踩的坑发生在 TreeSet/TreeMap 上。假设有一个"订单"类，你只用金额字段实现比较器，而不考虑订单 ID：

java

Comparator<Order> byAmount = Comparator.comparing(Order::getAmount);
TreeSet<Order> orders = new TreeSet<>(byAmount);
orders.add(new Order("A", 100));
orders.add(new Order("B", 100)); // 金额相同，但是完全不同的订单
System.out.println(orders.size()); // 输出 1，不是 2！

TreeSet 内部判断"是否已存在"依赖的是 compare() 返回 0，而不是 equals()。两个金额相同的订单被判定为"相等"，第二个订单会被直接忽略——它没有真的被添加进去，也没有抛异常提示你，这是最隐蔽的一类 bug：数据悄悄丢失，业务代码却完全无感知。

六、另一个隐蔽陷阱：用减法实现 compareTo 导致整数溢出

早期很多教程会教你这样写 compareTo：

java

public int compareTo(Score other) {
    return this.value - other.value; // 危险！可能整数溢出
}

如果 this.value 是一个接近 Integer.MAX_VALUE 的正数，other.value 是一个接近 Integer.MIN_VALUE 的负数，两者相减会发生溢出，结果的符号可能是错的——本来应该返回正数，实际返回了负数，直接违反了比较器契约里的符号一致性，导致排序结果混乱且难以复现（只在特定数值范围内才会触发）。正确写法应该用 Integer.compare(this.value, other.value)，或者更通用地用 Comparator.comparingInt()，避免自己手写减法。

七、常见误区

以为 compareTo 返回 0 就一定意味着 equals 也返回 true。 语言层面并不强制这一点，TreeSet/TreeMap 判等用的是比较器，HashSet/HashMap 判等用的是 equals/hashCode，两套体系可能给出不同结论，混用时极易踩坑。
用减法实现 compareTo，忽视整数溢出风险。 应该用 Integer.compare()、Long.compare() 等工具方法，或者直接用 Comparator.comparingInt(...)。
以为 Comparable 和 Comparator 可以随意混用而不会有冲突。 传入 TreeSet/TreeMap 的显式比较器会完全覆盖对象自身的 compareTo()——如果两者定义的顺序不一致，实际生效的是你传入的那个比较器，容易造成"为什么排序结果和我预期的自然顺序不一样"的困惑。
忘记比较器要满足传递性。 手写多字段比较逻辑时，如果条件分支写错顺序或者遗漏某个字段的处理，很容易破坏传递性，这种 bug 通常只在数据量变大、触发特定的排序算法内部比较路径时才会暴露，非常难调试。

八、面试追问链

问答（不计入阅读时长）

Q1：Comparable 和 Comparator 最核心的区别是什么？

A：Comparable 是让类自己实现 compareTo()，定义的是这个类唯一的"自然顺序"，写死在类内部；Comparator 是一个独立的、可以传入的排序规则，同一个类可以搭配任意多个不同的 Comparator，不需要修改类本身。简单说：Comparable 是"我知道怎么和别人比"，Comparator 是"外部规定的比较方法"。

Q2：如果一个类已经实现了 Comparable，还能用 Comparator 排序吗？

A：能，而且传入 Collections.sort(list, comparator)、list.sort(comparator) 等方法的显式比较器会完全覆盖对象自身的 compareTo()。如果两者定义的顺序不一致，实际生效的是你传入的那个 Comparator，这也是很多人"明明实现了 compareTo，结果排序不对"的困惑来源。

Q3：比较器契约具体要求什么？

A：三条核心约束：一是对称性，sgn(compare(x,y)) == -sgn(compare(y,x))；二是传递性，如果 compare(x,y)>0 且 compare(y,z)>0，必须有 compare(x,z)>0；三是相等的传递一致性，如果 compare(x,y)==0，那么对任意 z，compare(x,z) 和 compare(y,z) 的符号必须相同。这些约束保证排序结果不会自相矛盾。

Q4：compare() 返回 0 是不是就意味着 equals() 也一定返回 true？

A：不是，语言层面并不强制这一点。TreeSet/TreeMap 判断元素是否相等用的是 compare()/compareTo()，而 HashSet/HashMap 用的是 equals()/hashCode()。两套体系可能给出不同结论：一个只比较金额的比较器会让两个金额相同但 ID 不同的订单被 TreeSet 判定为"重复"，其中一个会被静默丢弃，TreeSet 的 size() 不会增加，也不会抛出任何异常提示你。

Q5：为什么这种"元素消失"的 bug 特别难发现？

A：因为它不报错。TreeSet.add() 在判断到 compare() 返回 0 时，会认为元素已存在，直接放弃插入，返回 false（如果你没检查返回值就完全不会发现）。业务代码看起来运行正常，只是数据莫名其妙少了，往往要等到统计数字不对、或者线上问题排查很久之后才会追溯到比较器只用了部分字段。

Q6：手写 compareTo 时用减法（this.value - other.value）有什么风险？

A：整数溢出。如果 this.value 接近 Integer.MAX_VALUE（正数），other.value 接近 Integer.MIN_VALUE（负数），两者相减会超出 int 的表示范围发生溢出，结果的符号可能是错的——本该返回正数，实际返回了负数，直接违反比较器契约的对称性。而且这种 bug 只在特定数值范围内触发，日常测试很难覆盖到，上线后才会零星复现。正确写法是用 Integer.compare(a, b) 或 Comparator.comparingInt(...)。

Q7：Comparator 的链式方法 thenComparing 是怎么工作的？

A：thenComparing() 是在前一个比较器返回 0（即两个对象在前一个维度上"相等"）时，才会继续用它接的比较逻辑进行下一轮比较。比如 Comparator.comparing(User::getAge).thenComparing(User::getName)：先按年龄比较，年龄不同直接得出结果；年龄相同时，才进一步比较姓名。这样可以组合出任意多级的排序规则，而不需要手写复杂的 if-else 比较逻辑。

Q8：用 synchronized 包一层能保证比较器契约不被破坏吗？

A：不能，这两者完全不是一个维度的问题。synchronized 解决的是多线程并发访问安全，比较器契约是关于比较逻辑本身在数学上是否自洽（对称、传递）的问题——哪怕在单线程环境下，一个写错的比较器（比如减法溢出、或者只比较部分字段）依然会破坏契约，导致排序结果错乱或者集合行为异常，加锁完全无法修复这类逻辑缺陷。