怎么在 Java 中使用 Comparator 接口实现自定义排序规则

先说说几个核心判断。Comparator接口的compare()方法，看起来就是个简单的比较函数，但实际项目里因为用法不当导致的排序错乱、空指针甚至数据“消失”，并不少见。下面这几个要点，算是经验之谈，希望能帮读者少走些弯路。

Comparator.compare() 方法必须返回 int，不能只写 true/false

很多新手在写 compare() 方法时，会本能地想返回布尔值——比如直接写 a.name.equals(b.name) 或 a.age > b.age，结果编译器直接报错，或者排序结果完全乱序。这其实挺常见的。Ja va的排序算法依赖的是三值语义——负数代表a小于b，0代表相等，正数代表a大于b。所以，正确的做法是使用减法（对数值类型）或者更安全的 Integer.compare()、String.compareTo() 等内置方法：

public int compare(Person a, Person b) {    // ✅ 安全：避免整数溢出    return Integer.compare(a.getAge(), b.getAge());    // ❌ 危险：age 是 int，a.age - b.age 可能溢出    // return a.getAge() - b.getAge();}

• 对于字符串、LocalDateTime 等无法直接相减的类型，必须使用 .compareTo() 方法。
• double/float 类型，用 Double.compare(a.val, b.val)，别用 == 或减法——浮点数比较有精度问题，减法也不安全。
• 多字段组合排序时，优先级高的字段先比较，一旦返回非零值，就直接返回结果，后面的字段不用再比了。

使用 Lambda 表达式时，别漏掉参数类型推导的边界情况

Lambda 表达式让代码变得简洁，比如 Comparator.comparing(p -> p.getName())，但运行时如果字段为 null，就会直接抛出 NullPointerException。Ja va 8+ 提供了 Comparator.nullsFirst() 和 Comparator.nullsLast() 来兜底，但它们必须包裹在比较器内部，不能放在链式调用的末尾。

常见错误写法是：comparing(p -> p.getName()).nullsLast() —— 这行不通，因为 nullsLast() 返回的是一个新比较器，不能作为方法直接跟在 comparing() 后面。正确的打开方式有两种：

• ✅ 正确：comparing(…, nullsLast(String::compareTo))
• ✅ 或拆成两步：Comparator.comparing(Person::getName, nullsLast(String::compareTo))
• ⚠️ 如果 Person::getName 返回 String，而某些对象的 name 字段为 null，不处理就会直接崩掉。这在实际项目中非常容易发生。

Comparator.reversed() 不改变原比较器，且不能链式复用多次

reversed() 方法并不会修改原比较器本身，而是返回一个新的比较器。有些开发者误以为调用一次后后续所有排序都会反向，实际上并不会这么生效。更危险的是写 comp.reversed().reversed()，虽然语法上合法，但每次都会创建新对象，带来不必要的开销。

• 需要反复切换排序方向时，建议提前定义两个常量：ASC 和 DESC。
• 排序前才决定方向？直接用 list.sort(direction == ASC ? ASC_COMP : DESC_COMP)，不要在排序现场调用 reversed()。
• Stream 排序中可以用 sorted(comp.reversed())，但别在循环里反复调用它来生成新实例——虽然性能影响不大，但代码风格不够优雅。

在 TreeSet/TreeMap 中传入 Comparator，必须保证“相等性”与 compare 结果一致

如果自定义的 compare() 方法对两个不同的对象返回了 0，而它们的 equals() 方法却返回 false，TreeSet 就会认为它们是同一个元素，拒绝插入；TreeMap 则可能覆盖 key。这不是 bug，而是 Ja va 明确规定的契约：Comparator 定义的“相等”才是集合判断的依据。

• 例如按姓名排序的 Person，若两人同名但身份证号不同，compare() 返回 0，TreeSet 就会认为它们是同一个元素。
• 解决办法：在 compare() 中加入次级判据，比如 Integer.compare(a.getId(), b.getId())，确保真正不同的对象不会返回 0。
• 这个细节在 List.sort() 里可能不敏感，但在基于红黑树的集合里，它会直接暴露行为差异——数据要么丢失，要么被错误覆盖。

实际项目里最常见的踩坑点，往往不是语法本身，而是两个认知偏差：一个是“以为 compare 返回布尔就是对的”，另一个是“忘了 null 和相等性契约”。这两个点不校验，上线后要么空指针，要么数据莫名其妙地“消失”。值得警惕。