Java中的java.util.Collections.sort排序稳定性说明_排序算法内幕-java教程-PHP中文网

稳定。Collections.sort()在Java 7+中对对象列表排序时底层调用Arrays.sort(Object[])，采用稳定Timsort算法，保证相等元素相对位置不变；基本类型数组排序虽不稳定，但不参与Collections.sort()调用链。

java中的java.util.collections.sort排序稳定性说明_排序算法内幕

Java的`Collections.sort()`到底稳不稳定？

稳定。只要传入的List实现支持随机访问（比如ArrayList），Collections.sort()在Java 7及以后版本中，底层用的是**双轴快排（Dual-Pivot Quicksort）+ 归并排序（Timsort）混合策略**，但对Object[]数组排序时，实际调用的是Arrays.sort(Object[])——它明确保证稳定。

关键点在于：稳定性只针对**相同元素的相对位置不改变**。如果你用自定义Comparator把两个逻辑上不同的对象判为“相等”，那它们的顺序就由原始位置决定，且这个顺序会被保留。

为什么有时候看着“不稳定”？常见错因

不是算法不稳，而是你没看清比较逻辑或数据状态：

用了int或long比较时写成a - b，导致整数溢出，返回值符号翻转，Comparator行为失常 —— 改用Integer.compare(a, b)或Long.compare(a, b)
自定义Comparator里漏了null处理，遇到null字段抛NullPointerException，排序中途失败，列表可能处于半修改状态
把LinkedList传给Collections.sort()：虽然能跑，但会先转成数组再排，再刷回链表，既慢又容易让人误以为“原地排序失效”
排序前列表已被其他线程修改，或本身是未同步的并发集合（如CopyOnWriteArrayList），排序看到的快照和你预期不一致

`Collections.sort()`和`Arrays.sort()`的区别在哪？

表面看都是排序，底层策略和稳定性保障层级不同：

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

Collections.sort(List)：只接受List，内部调用list.toArray() → Arrays.sort(Object[]) → 最终走Timsort（稳定）
Collections.sort(List, Comparator)：同上，只是多传个比较器，不影响稳定性
Arrays.sort(int[])、Arrays.sort(double[])等基本类型重载：用双轴快排，**不稳定** —— 但这些根本不会出现在Collections.sort()调用链里
所以只要你没绕过Collections.sort()直接去排基本类型数组，就不用操心“不稳”问题

真要验证稳定性？动手试比读源码快

写个带标识的简单类，插入两个“值相等但ID不同”的实例，排序后检查ID顺序：

class Item {
    int value;
    int id;
    Item(int v, int i) { value = v; id = i; }
}
List<item> list = Arrays.asList(new Item(1, 100), new Item(2, 200), new Item(1, 99));
Collections.sort(list, Comparator.comparingInt(i -> i.value));
// 排序后，两个value==1的Item，id为100的一定在id为99的前面（原始顺序）</item>

注意：别用System.out.println(list)草率下结论 —— 确保你打印的是item.id，而不是只看item.value；也别在IDE调试器里靠“观察变量顺序”判断，得靠代码显式断言。

最易被忽略的一点：稳定性只在单次排序内成立。如果排序后又手动改了某个元素的字段，再排一次，那“原始顺序”已经变了，别指望两次排序结果之间有可复现的相对关系。