comparator 是 java 的函数式接口，通过外部定义 compare() 方法实现不修改实体类的灵活排序。它支持 lambda、链式组合（thencomparing）、空值处理（nullslast）及类型特化（comparingint），推荐静态常量复用且线程安全。
Comparator 是什么，为什么它能不改实体类就排序
Comparator 是 Java 提供的一个函数式接口，只定义了一个 compare() 方法。它把“怎么比”从类内部抽出来，变成外部可插拔的逻辑。只要实体类字段可访问（public / 有 getter），你完全不用动它的源码，甚至不需要它实现 Comparable。
常见错误是试图在实体类里改代码加 implements Comparable，或者硬塞 compareTo()——这反而破坏了开闭原则，也违背“不侵入”的初衷。
用匿名内部类或 Lambda 写 Comparator 的实操要点
最直接的方式就是现场写一个 Comparator 实例传给 sort() 或 TreeSet 等容器：
List<user> users = ...; users.sort((u1, u2) -> Integer.compare(u1.getAge(), u2.getAge()));</user>
注意几个关键点：
-
Integer.compare()比直接用u1.getAge() - u2.getAge()安全，避免整数溢出导致比较结果翻转 - 如果字段为
null，Objects.compare(u1.getName(), u2.getName(), String::compareTo)可处理空值 - Lambda 参数类型通常可省略（编译器能推导），但一旦报错，加上泛型如
Comparator<user></user>显式声明会更快定位问题
复用和组合多个 Comparator：用 thenComparing 和 nullsLast
真实业务中很少只按一个字段排。比如“先按年龄升序，年龄相同时按姓名降序”，这时别手写嵌套 if，用 thenComparing() 链式组合：
users.sort(Comparator.comparing(User::getAge)
.thenComparing(User::getName, Comparator.reverseOrder()));
容易踩的坑：
-
thenComparing()后面跟的Comparator如果涉及可能为null的字段（如getNickname()），必须显式包装：thenComparing(Comparator.nullsLast(Comparator.naturalOrder())) -
Comparator.comparing()默认抛NullPointerException，不自动跳过 null；nullsFirst()和nullsLast()必须套在具体比较器外面，不是链式调用的末尾修饰符 - 如果字段是基本类型（如
int），用comparingInt(User::getAge)更高效，避免装箱
把 Comparator 抽成静态常量或独立类，避免重复定义
当同一套排序逻辑在多处使用（比如 API 返回列表、后台导出、缓存预热），硬编码 Lambda 会导致散落、难维护、难测试。推荐两种方式：
- 在工具类里定义
public static final Comparator<user> BY_AGE_THEN_NAME</user>，用上面的链式表达式初始化 - 单独写一个
UserAgeNameComparator implements Comparator<user></user>类，重写compare()——适合逻辑复杂、需注入依赖（如翻译服务）或要单元测试的场景 - 不要用 Spring
@Component注入Comparator，它无状态、无生命周期，DI 反而增加启动开销和理解成本
真正容易被忽略的是：Comparator 实例本身是线程安全的（只要不持有可变状态），所以静态常量或单例复用完全没问题；但如果你在 compare 里偷偷改了某个共享 map 或计数器，那就已经不是“纯比较”了。
