collections.sort()本质是委托list.sort()原地排序，仅支持list子类，不返回新列表；依赖元素实现comparable或传入comparator，需防null、不可变列表及并发问题。
Collection.sort() 本质是原地调用 List.sort()
Collections.sort() 并不是自己实现排序逻辑，而是把任务委托给传入的 List 实例自身的 sort() 方法。源码里只有一行：
list.sort(null);或
list.sort(c);。这意味着： - 它**只支持
List 及其子类**（ArrayList、LinkedList、Vector），对 Set、Map 等直接报错
- 排序是否高效，取决于底层 List 是否支持随机访问：
-
ArrayList→ 走 TimSort（插入+归并混合），O(n log n)稳定 -
LinkedList→ 先转数组再 TimSort，多一次遍历开销，不推荐用于频繁排序
自然排序 vs 自定义排序：接口选择决定能否跑通
两种重载方法背后是两套契约：
public static <T extends Comparable<? super T>> void sort(List<T> list)要求所有元素必须实现
Comparable，比如 String、Integer 没问题；但如果你往里面塞了没实现该接口的自定义对象（比如裸写的 Person 类），运行时直接抛 ClassCastException。
public static <T> void sort(List<T> list, Comparator<? super T> c)完全绕过
Comparable 要求，靠你传进来的 Comparator 定义大小关系。常见坑：
- Comparator 中写 a - b 对 int 安全，但对 long 或大整数会溢出 → 改用 Long.compare(a, b)
- 匿名内部类或 Lambda 中引用外部变量，变量必须是 final 或“事实 final”
- Comparator.comparing(...) 链式调用时，若字段为 null，默认抛 NullPointerException → 加 thenComparing(Comparator.nullsLast(...)) 更健壮
常见崩溃现场：null、不可变列表、线程安全陷阱
这些错误不报编译错，但一运行就炸：
- Arrays.asList("a", "b", "c") 返回的是固定大小列表（底层是私有静态内部类），调 Collections.sort() 没问题；但如果你后续又调 add() 或 remove()，会抛 UnsupportedOperationException —— 因为它不支持结构修改
- 列表含 null 元素，且没传 Comparator：自然排序下 null.compareTo(...) 必空指针；传了 Comparator 也要自己处理 null，否则同上
- 多线程环境下直接对共享 ArrayList 调 sort()：无锁操作，可能被其他线程并发修改导致数据错乱或 ConcurrentModificationException —— 此时应先加锁，或改用 Collections.synchronizedList() 包装（注意：仅同步单个操作，sort() 本身仍需额外同步）
替代方案：什么时候不该用 Collections.sort()？
它很常用，但不是万能解：
- 需要排序后保持原列表不变？→ 不要用，改用 list.stream().sorted().collect(Collectors.toList())（创建副本）
- 数据量极大（百万级）且只读？→ 考虑 TreeSet 插入时自动排序，或预建索引
- 要按多个字段动态组合排序（如“先按部门升序，部门相同时按薪资降序”）？→ 用 Comparator.comparing(Person::getDept).thenComparing(Comparator.reverseOrder().thenComparing(Person::getSalary))，别手写嵌套 if
- 对数组排序？→ 直接用 Arrays.sort()，它针对数组做了底层优化，比先转 Arrays.asList() 再 Collections.sort() 少两次包装/拆箱
真正容易被忽略的，是它对输入列表的“信任假设”：它假定你传进来的是可修改的、非 null 的、类型一致的 List —— 而现实里，这些条件往往在上游就被悄悄破坏了。
