arrays.sort() 通常比手写快排更快，因其对基本类型采用优化的双轴快排（含三向切分、小数组插入排序），对对象数组使用适应部分有序数据的timsort；仅当数据极小、场景特殊且手写版本针对性优化时，手写快排才可能更快。
Arrays.sort() 通常比手写快速排序更快，但这个结论不是绝对的——它取决于数据规模、类型、初始有序程度，以及你写的快排是否做了关键优化。
基本类型排序：Arrays.sort 用双轴快排，胜在工程级调优
对 int[]、double[] 等基本类型数组，Arrays.sort() 底层采用 Dual-Pivot Quicksort（双轴快排），它不是教科书版单轴快排的简单复刻，而是做了多项工业级优化：
- 引入两个 pivot，一次划分成三段，减少递归深度和比较次数
- 小数组（默认长度 ≤ 47）自动切回插入排序，避免递归开销
- 对重复元素做三向切分（Dutch National Flag partitioning），显著提升含大量重复值时的性能
- 随机化 pivot 选择策略已内置，规避最坏 O(n²) 场景
而多数手写快排只实现单轴+固定 pivot（如取首/尾元素），没做小数组优化或重复值处理，实测在 10⁴ 以上数据量时，Arrays.sort 通常快 1.5–3 倍。
对象数组排序：TimSort 更稳，尤其面对部分有序数据
对 String[]、Integer[] 或自定义对象数组，Arrays.sort() 切换为 TimSort（归并+插入混合算法），它天然稳定且对部分有序数据极其友好：
- 扫描数组识别已有序的“run”，直接合并而非重排
- 最小 run 长度动态计算，平衡预处理与归并开销
- 最坏时间复杂度仍是 O(n log n)，但实际运行常接近 O(n)
手写快排默认不稳定，且无法感知局部有序性。若你排序的是日志记录（按时间戳基本递增）、数据库导出结果（主键有序），TimSort 可能比快排快一个数量级；而快排在此类场景下仍会强行分治，白白消耗资源。
什么时候手写快排可能更快？
不是“能不能写”，而是“有没有必要绕过 Arrays.sort”——只有满足以下全部条件时，才值得考虑：
- 数据规模极小（
- 业务逻辑要求严格控制 pivot 策略（例如必须用中位数 pivot 保证最坏性能）
- 排序字段是原始计算结果（如 Math.sqrt(x)），而你能在快排 compare 中缓存该值，避免 Arrays.sort 的 Comparator 多次调用开销
- 你明确知道数据分布（如几乎全逆序），并针对性优化分区逻辑（比如用三数取中+尾递归）
注意：JDK 的 Arrays.sort 已针对 HotSpot JIT 做了深度适配，手写代码若未充分预热或触发内联，反而可能因解释执行拖慢整体速度。
别忽略比较器开销——真正的瓶颈常在这里
对对象排序，性能差异往往不出在“算法本身”，而出在 compare() 的实现上：
- 避免在 lambda 或 compare 方法里反复解析字符串、调用 getter、计算哈希——提前缓存中间结果
- 用 Comparator.comparing(User::getAge).thenComparing(User::getName) 比嵌套 if-else 更安全高效
- 含 null 元素时，用 Comparator.nullsLast(Comparator.naturalOrder()) 替代手动判空，JVM 对其做了特殊优化
一个低效的 Comparator 可能让 Arrays.sort 比手写快排慢好几倍，这不是算法问题，是逻辑写法问题。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
