Java集合的排序与比较器的核心概念_技术教程

优先用Comparator：不侵入业务类，支持lambda，适合第三方类或多种排序逻辑；仅当类有唯一稳定自然序（如String、Integer）才实现Comparable。

当需要对 List 或数组排序时，Comparable 用于类“自己定义怎么比”，Comparator 用于“外部临时定义怎么比”。前者必须修改类源码（实现 compareTo()），后者完全解耦，适合第三方类或多种排序逻辑共存的场景。

常见错误：给没实现 Comparable 的类（比如 java.time.LocalDateTime）直接调用 Collections.sort(list)，抛出 ClassCastException: cannot be cast to java.lang.Comparable。

优先用 Comparator：不侵入业务类，支持 lambda 快速写法，如 list.sort((a, b) -> a.getId() - b.getId())
只有类天然有唯一、稳定、全局一致的自然序（如 String、Integer）才考虑实现 Comparable
Comparable.compareTo() 返回负数/0/正数，语义是“小于/等于/大于”；Comparator.compare() 同理，但可随时切换逻辑

是。从 Java 7 开始，两者都基于双轴快排（Dual-Pivot Quicksort）优化版本，对基本类型用 Arrays.sort() 原生实现，对引用类型统一走 Timsort（稳定排序，对部分有序数据极快）。

关键差异在输入类型和泛型约束：

Arrays.sort(int[]) → 原生高效，无装箱开销
Arrays.sort(Object[]) → 要求元素实现 Comparable，或传入 Comparator
Collections.sort(List) → 底层转成数组再调 Arrays.sort()，所以 LinkedList 排序前会先 toArray()，有额外内存开销

性能提示：对 ArrayList 排序最快；对 LinkedList，先 new ArrayList(list) 再排，比直接 Collections.sort() 更省 GC 压力。

因为 comparing() 默认使用 Comparable 的自然序，如果提取的字段为 null，会直接抛 NullPointerException；且链式中任意一环返回 0（相等），才会继续下一级比较 —— 这点容易被忽略。

典型陷阱：

list.sort(comparing(Person::getName)) → getName() 返回 null 就崩
list.sort(comparing(Person::getAge).thenComparing(Person::getName)) → 只有年龄相同时才比姓名，但若 getAge() 是 null（如 Integer 字段未赋值），同样 NPE

安全写法：

list.sort(
    comparing(Person::getAge, nullsLast(naturalOrder()))
        .thenComparing(Person::getName, nullsLast(String::compareTo))
);

注意：nullsLast() 和 nullsFirst() 必须显式包裹比较器，不能只写 nullsLast。

完全一样，都依赖 Comparator 或 Comparable，但行为目标不同：排序是“一次性重排”，而 TreeSet 是“插入时动态维护有序结构”。这意味着：

往已存在的 TreeSet 中添加元素，不会触发全量重排，而是按红黑树规则插入并调整
如果用自定义 Comparator 创建 TreeSet，后续所有 add()、contains()、remove() 都按该逻辑判断“是否相等”——不是看 equals()，而是看 compare() 是否为 0
严重隐患：若 Comparator 与 equals() 不一致（比如按 ID 比较但忽略 name），TreeSet 可能无法正确 contains() 一个逻辑上相等的对象