arrays.sort() 对对象数组使用 timsort 而非双枢轴快排；仅基本类型数组才用双枢轴；timsort 稳定、自适应，依赖自然有序段（run），最佳 o(n)，最坏 o(n log n)。
Arrays.sort() 对大规模对象数组不使用双枢轴快排——它用的是 TimSort，不是 Dual-Pivot Quicksort。这是关键前提，混淆这点会导致误判优化方向。
对象数组默认走 TimSort，不是双枢轴
Java 中 只有基本类型数组（如 int[]、double[]） 才触发双枢轴快排；而 Object[]（包括 String[]、Integer[]、自定义类数组）一律使用 TimSort。TimSort 是一种稳定、自适应的混合排序，核心是识别“自然有序段（run）”，再合并。它在部分有序、含重复值、现实业务数据上表现更优，最坏时间复杂度仍是 O(n log n)，最佳可达 O(n)。
- Integer[] arr = {5, 2, 8, 1}; Arrays.sort(arr); → 调用 TimSort，非双枢轴
- String[] names = {"Alice", "Bob", "Charlie"}; Arrays.sort(names); → 同样是 TimSort
- 想强制对对象用双枢轴？不行。JDK 没提供该入口，也不建议绕过
真正影响对象数组性能的三个实操点
优化对象排序，重点不在“换算法”，而在适配 TimSort 的运行逻辑：
- 预热 run 长度：TimSort 会先扫描找升序/严格降序段。若数据已局部有序（如按创建时间插入的列表），它能自动复用这些 run，大幅减少比较和移动。避免每次排序前打乱或随机化
- 控制 Comparator 复杂度：自定义比较器中避免 I/O、锁、复杂计算。例如 compare(a, b) 里调数据库查字段，会把 O(n log n) 变成不可控延迟。应提前把排序键提取到字段中（如缓存 nameLength、scoreRank）
- 合理设置初始容量与 run 最小长度：TimSort 内部有 MIN_MERGE（默认 32）和 MIN_GALLOP（默认 7）。若你清楚数据特征（如平均 run 长度约 50），可通过 JVM 参数 -Djava.util.TimSort.minRun=64 微调（需实测验证，非通用推荐）
何时该考虑替代方案
当 TimSort 仍不满足性能要求时，说明问题可能不在排序本身：
- 数据量极大（千万级+）且内存受限 → 改用外部排序（如分块排序 + 归并文件）或流式处理（Stream.iterate + sorted + limit）
- 仅需 Top-K 而非全排序 → 用 PriorityQueue 或 Arrays.sort(arr, 0, k) 配合部分排序，避免 O(n log n) 全量开销
- 频繁按不同字段排序 → 建立索引视图（如用 TreeMap 存 key→object 映射），用空间换时间
别踩的坑：强行“模拟双枢轴”反而更慢
有人尝试把 Integer[] 转成 int[] 排序再转回，以为能套用双枢轴。这不仅引入装箱/拆箱开销（尤其对大数组，GC 压力陡增），还丢失稳定性（双枢轴本身就不稳定，而对象排序常依赖稳定语义）。实测显示，这种转换在百万级数组上通常比原生 TimSort 慢 2–5 倍。
TimSort 已深度优化：支持 galloping mode 加速归并、二分插入优化短 run、动态调整合并策略。它的“慢”往往源于数据建模或 Comparator 设计，而非算法本身。
