Arrays.sort对基本类型用双轴快排（性能优先、不稳定）、对象数组用TimSort（稳定优先、支持Comparator）；前者不支持自定义比较，后者需保证Comparator与equals语义一致，稳定性直接影响业务公正性。
Arrays.sort 对基本类型和对象数组用的是两套完全不同的算法，不是“同一个排序方法换了个参数”，而是从设计目标、实现逻辑到行为表现都存在根本区别。
底层算法完全不同
基本类型数组（如 int[]、double[]）走的是双轴快速排序（Dual-Pivot Quicksort），核心是性能优先：原地排序、空间开销小、平均比较次数更少；而对象数组（如 String[]、Person[]）默认使用 TimSort，本质是增强型归并排序，核心是稳定性优先：保证相等元素的原始相对顺序不变。
- int[] 排序时，两个值都为 7 的元素，排完后可能互换位置——这是允许且预期的行为
- String[] 中两个相同字符串，或 Person[] 中 score 相同的两个对象，排序后它们的先后顺序一定和原来一致
- TimSort 还会主动识别天然有序段（比如已排好序的子序列），对短段补足后用二分插入排序，再归并，因此对部分有序数据特别快
是否支持自定义比较逻辑
基本类型数组无法传 Comparator——编译直接报错。因为 int、long 等没有引用语义，也不具备对象层面的“可比性”抽象。
- 想对 int[] 降序？只能先升序再翻转，或转成 Integer[] 再用 Comparator.reverseOrder()
- 对象数组只要实现 Comparable，或显式传入 Comparator（Lambda 或方法引用），就能灵活控制排序依据
- 注意：Comparator 的逻辑必须与 equals 语义一致，否则看似“稳定”，实则业务上出现顺序错乱
稳定性与业务影响直接挂钩
稳定性不是技术细节，而是业务约束。比如按成绩排序学生名单，若同分者原始录入顺序被打乱，家长可能质疑结果公正性；而对纯数值中间计算（如统计直方图边界），谁先谁后根本不重要。
立即学习“Java免费学习笔记（深入）”；
- 基本类型排序天然不稳定，且无法绕过——没接口、没选项、没兜底方案
- 对象数组默认稳定，但前提是：你没写一个把不同对象判为“相等”的 Comparator
- 如果业务既需要高性能又要求稳定，且数据全是数值型，可考虑用 IntStream.range() 配合索引映射，避免装箱开销
性能表现取决于数据特征而非数组大小
不是“越大越慢”，而是“越接近有序，TimSort 越快；重复值越多，双轴快排越省事”。百万级数组跑得慢，大概率不是算法不行，而是误用了装箱、写了低效 Comparator，或在不该全量排序的地方调用了 sort。
- 对已基本排好序的 String[]，TimSort 可能接近 O(n)，比双轴快排还快
- 对含大量重复整数的 int[]，双轴快排的三向切分能跳过重复块，显著减少交换次数
- 用 Arrays.sort(arr, from, to) 做局部排序时，务必确认右边界是“不包含”的——写成 toIndex + 1 就会越界或漏排
