Arrays.sort 比 Collections.sort 更快，核心在于避免数组与集合互转的包装和复制开销；前者直接操作底层数组，后者需先转数组再写回，且 LinkedList 排序额外产生 O(n) 时间与空间开销。

Arrays.sort 比 Collections.sort 更快，核心原因不是算法不同，而是少了两层开销：数组到集合的包装转换 + 集合再转回数组的复制过程。

底层调用关系决定性能落差

Collections.sort 并不自己排序，它把 List 先转成 Object[] 数组，调用 Arrays.sort(Object[], Comparator)，排完再“写回”原 List（对 ArrayList 是直接操作底层数组；对 LinkedList 则需额外复制）。

• ArrayList.sort() 内部调用的是 Arrays.sort((Object[]) elementData, 0, size, comparator) —— 直接复用底层数组，省去一次复制，但仍有从 List 接口提取数组的间接成本
• LinkedList.sort() 必须先 new Object[size] 复制全部元素，排序后再逐个 set 回链表 —— O(n) 时间 + O(n) 空间双重开销
• Arrays.asList(xxx).sort() 表面是 List，实际返回的是 Arrays 的私有静态类，其 sort 仍走 Arrays.sort，但前提是传入的数组可修改（如 new Integer[]{...}），否则会抛 UnsupportedOperationException

基本类型场景：Arrays.sort 具有绝对优势

int[]、double[] 等基本类型数组只能用 Arrays.sort。Collections.sort 不接受基本类型集合（如 int 不是泛型参数），若强行用 Integer[] + Arrays.asList → Collections.sort，会触发自动装箱 + 包装类数组创建 + 多余对象分配。

• 10 万整数排序实测：Arrays.sort(int[]) 通常比 Collections.sort(Arrays.asList(Integer[])) 快 1.5–2 倍
• 装箱开销明显：Integer.valueOf(i) 在频繁调用时产生大量短期对象，增加 GC 压力
• 没有 Comparable 实现负担：基本类型排序无需接口实现或比较器，JVM 可深度优化

对象数组 vs List<T>：稳定性与可控性权衡

两者都默认稳定（相等元素相对位置不变），但稳定性保障机制不同：

• Arrays.sort(Object[]) 使用 TimSort（Java 7+），稳定且适应部分有序数据
• Collections.sort(List) 调用的也是 TimSort，但因涉及 List 接口抽象，对某些非随机访问 List（如 LinkedList）无法跳过遍历，实际排序前的“转数组”步骤已破坏局部性
• 若需极致可控性（如指定并行、自定义阈值、避免 GC），直接用 Arrays.sort 更透明；若业务逻辑天然基于 List（如 Spring Data 返回 Page<T>），则 Collections.sort 语义更清晰

真实建议：按数据源头选，不为“看起来高级”绕路

别为了统一 API 把数组转 List 再 Collections.sort，也别把 List 强转为数组硬套 Arrays.sort —— 类型错配会导致编译失败或运行时异常。

• 手头是 int[]、String[]、MyObj[]？→ 用 Arrays.sort
• 手头是 ArrayList、CopyOnWriteArrayList、Vector？→ 用 Collections.sort
• 手头是 LinkedList 或自定义 List 实现？→ 优先考虑是否真需要它；若必须排序，评估是否可先转 ArrayList 再排
• 性能敏感批量处理（如日志聚合、实时计算）？→ 尽量保持数组形态，避免无谓包装