优先用Comparator：不侵入业务类，支持lambda，适合第三方类或多种排序逻辑；仅当类有唯一稳定自然序（如String、Integer）才实现Comparable。
Comparable 和 Comparator 到底该用哪个？
当需要对 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()同理，但可随时切换逻辑
Arrays.sort() 和 Collections.sort() 的底层是不是一回事？
是。从 Java 7 开始，两者都基于双轴快排（Dual-Pivot Quicksort）优化版本，对基本类型用 Arrays.sort() 原生实现，对引用类型统一走 Timsort（稳定排序，对部分有序数据极快）。
关键差异在输入类型和泛型约束：
立即学习“Java免费学习笔记（深入）”；
-
Arrays.sort(int[])→ 原生高效，无装箱开销 -
Arrays.sort(Object[])→ 要求元素实现Comparable，或传入Comparator -
Collections.sort(List<t>)</t>→ 底层转成数组再调Arrays.sort()，所以LinkedList排序前会先toArray()，有额外内存开销
性能提示：对 ArrayList 排序最快；对 LinkedList，先 new ArrayList(list) 再排，比直接 Collections.sort() 更省 GC 压力。
Comparator.comparing() 链式调用为什么有时结果不对？
因为 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。
TreeSet / TreeMap 的比较逻辑和 sort() 一样吗？
完全一样，都依赖 Comparator 或 Comparable，但行为目标不同：排序是“一次性重排”，而 TreeSet 是“插入时动态维护有序结构”。这意味着：
- 往已存在的
TreeSet中添加元素，不会触发全量重排，而是按红黑树规则插入并调整 - 如果用自定义
Comparator创建TreeSet，后续所有add()、contains()、remove()都按该逻辑判断“是否相等”——不是看equals()，而是看compare()是否为 0 - 严重隐患：若
Comparator与equals()不一致（比如按 ID 比较但忽略 name），TreeSet可能无法正确contains()一个逻辑上相等的对象
最稳妥做法：除非明确需要多级排序或忽略大小写等特殊逻辑，否则优先用 Comparable 实现自然序，并确保 compareTo() 与 equals() 保持一致。
