Collections.sort() 报错因元素未实现 Comparable 接口或 Comparator 未提供，需实现 compareTo() 或传入 Comparator；它稳定、非线程安全，底层用 Timsort，慎用于不可变集合或大数据量场景。
为什么直接用 Collections.sort() 会报错
因为 Collections.sort() 默认要求列表元素实现 Comparable 接口，否则抛出 ClassCastException 或 IllegalArgumentException。如果你的自定义类（比如 Person）没重写 compareTo()，调用 Collections.sort(list) 就会失败。
常见错误信息：java.lang.ClassCastException: Person cannot be cast to java.lang.Comparable
- 不是所有对象天生可比，Java 不知道你希望按
name排还是按age排 - 即使类实现了
Comparable，如果compareTo()返回值逻辑错（比如用了==比较字符串），排序结果也会异常 - JDK 8+ 后更推荐用
list.sort()或Stream.sorted()，但Collections.sort()仍广泛用于遗留代码或需明确指定List实例的场景
两种安全写法：实现 Comparable 或传入 Comparator
前者适合「自然排序」逻辑唯一且稳定（如 Person 总是按 id 升序）；后者更灵活，同一类可多套排序规则（比如一次按姓名，一次按年龄）。
实现 Comparable 示例：
public class Person implements Comparable<person> {
private String name;
private int age;
@Override
public int compareTo(Person o) {
return this.name.compareTo(o.name); // 字符串自然排序
}
}</person>
调用：Collections.sort(personList)
使用 Comparator 示例（JDK 8+ 推荐）：
Collections.sort(personList, Comparator.comparing(p -> p.getAge())); // 或按姓名降序 Collections.sort(personList, Comparator.comparing(Person::getName).reversed());
- 注意
Comparator.comparing()的 lambda 参数不能为null，否则触发NullPointerException - 若字段可能为空，改用
Comparator.nullsLast(Comparator.comparing(...)) - 链式调用（如
.thenComparing()）可用于多级排序，但每级都影响性能，大数据量时留意
排序稳定性与线程安全要注意什么
Collections.sort() 是稳定排序（相等元素相对位置不变），这点常被忽略，但在处理分页、去重或依赖顺序的业务逻辑时很关键。
- 它只对
List本身排序，不保证线程安全——如果排序过程中其他线程在修改该列表，结果不可预测 - 底层用的是
Timsort（Python 也用它），对部分有序数据效率高，但最坏时间复杂度仍是O(n log n) - 若列表是
Arrays.asList()包装的数组返回值，它是固定大小的，排序没问题；但若误传了不可修改列表（如Collections.unmodifiableList()），会抛UnsupportedOperationException
替代方案：什么时候不该用 Collections.sort()
当你的数据源不是 ArrayList 或 LinkedList，而是来自数据库查询、流式 API 或需要惰性求值时，硬套 Collections.sort() 反而增加内存和延迟。
- 从 MyBatis/JPQL 查出的数据，优先在 SQL 层加
ORDER BY，避免全量加载再排序 - 如果只是取 Top-K（如前 10 名），用
PriorityQueue或Stream.limit()+ 自定义比较器更省资源 - 对不可变集合（如 Guava 的
ImmutableList），Collections.sort()会失败，必须先new ArrayList(immutableList)
真正麻烦的往往不是语法，而是没想清楚：这个排序是临时视图需求，还是领域模型的固有约束？前者用 Comparator 临时传入，后者才值得让类实现 Comparable。
