arrays.sort()已深度优化,无需手写;基本类型用双轴快排,对象数组用timsort;需理解其策略、适用场景及常见陷阱。

直接用 Arrays.sort() 就行,它不是“需要你去调优”的工具,而是已经替你完成所有关键优化的成熟方案——百万级数组排序,重点不在手写逻辑,而在理解它怎么工作、什么时候该用、以及怎么避开常见陷阱。
认清底层策略:基本类型 vs 对象数组
Java 不是统一用一种算法硬扛所有场景:
- 对 int[]、long[]、double[] 等基本类型数组,用的是 双轴快排(Dual-Pivot Quicksort)。它选两个基准值把数组分三段,比传统单轴快排减少比较次数和递归深度;小数组(
- 对 String[]、Integer[]、自定义对象数组,用的是 TimSort。它先扫描识别天然有序片段(Run),再用二分插入+归并合并,对部分有序、含大量重复或已近似排好序的数据特别友好,最坏也是 O(n log n),但实际中常接近 O(n)。
百万数据下真正影响性能的操作
排序本身很快,慢往往出在“准备”和“误用”环节:
- 别对 int[] 强塞 Comparator:编译直接报错。真要降序,先装箱成 Integer[] 再用 Collections.reverseOrder(),但注意装箱开销——百万级 int 装箱会触发大量对象分配和 GC 压力。
- 慎用 Arrays.sort(arr, from, to) 处理子范围:toIndex 是**不包含**的右边界,写错会导致漏排或越界;若只是临时取 top-K,考虑用堆(如 PriorityQueue)比全量排序更省。
- 对象数组排序前,确保 Comparator 实现高效:避免在 compare 方法里反复解析字符串、调用复杂 getter 或创建临时对象。例如按字符串长度排序,直接用 Comparator.comparing(String::length),而不是 new 一个匿名类里再写逻辑。
什么情况下 Arrays.sort 不是最优解?
它很强大,但不是万能钥匙:
- 纯正整数且范围有限(比如用户 ID 全在 0~1000 万之间),计数排序 或 基数排序 可达 O(n) 时间,实测百万级整数比 Arrays.sort 快 4–5 倍,内存占用也更低。
- 只要求随机打乱(如抽奖、洗牌),别用 sort 配 Math.random() 比较器——结果不稳定且效率低,直接用 Collections.shuffle()(底层 Fisher-Yates)。
- 数据持续流入、需动态维护有序性,数组就不是合适结构了,换成 TreeSet 或带索引的跳表更合适。
验证与观察的小技巧
不用猜,用工具看真实行为:
- 加 JVM 参数 -XX:+PrintGCDetails 观察是否因装箱引发频繁 GC;
- 用 JMH 做微基准测试,对比不同 Comparator 写法的吞吐量差异;
- 对同一份数据,分别试 int[] 和 Integer[] 排序耗时,量化装箱成本。










