Arrays.parallelSort 并非万能，仅在数组长度≥8192、使用基本类型、CPU核心数≥4时才显著快于Arrays.sort；误用Integer[]、频繁新建数组或边I/O边排序反而更慢。
Arrays.parallelSort 不是“一用就快”的万能开关，它真正提速需要满足几个硬性条件：数组够大、类型合适、环境支持。用错场景反而比 Arrays.sort 还慢。
什么时候 parallelSort 才真快？
它只在特定条件下释放并行优势：
- 数组长度 ≥ 8192（约 8K 元素），JDK 内部才会启用并行分支；小数组自动退化为串行 sort，避免线程开销反超收益
- 优先使用基本类型数组（int[]、long[]、double[]）——它们走高度优化的双轴快排 + 归并混合路径，提速最明显
- 引用类型（如 String[] 或自定义对象数组）虽支持，但若 Comparator 中有 IO、锁或复杂计算，并行收益会急剧下降
- CPU 核心数 ≥ 4 效果才显著；默认使用 ForkJoinPool.commonPool()，线程数 ≈ Runtime.getRuntime().availableProcessors()
怎么写才能不拖后腿？
常见低效写法会直接抵消并行优势：
- 别用 Integer[] 替代 int[]：装箱/拆箱带来额外 GC 和比较开销，实测百万级排序，int[] 的 parallelSort 比 Integer[] 快 2–3 倍
- 别在循环里反复 new 数组再排序：复用同一数组 + Arrays.fill() 重置，减少内存压力
- 别手动切片提交到线程池：parallelSort 已内置分治+归并策略，手动拆分反而破坏 ForkJoinTask 的工作队列负载均衡
- 排序前确保数据已加载完成：不要一边从磁盘/网络读数据一边调用 parallelSort，I/O 会成为瓶颈
怎么验证它真的变快了？
光看代码没报错，不代表并行生效：
立即学习“Java免费学习笔记（深入）”；
- 用 System.nanoTime() 计时，不用 System.currentTimeMillis() —— 后者精度不足，易掩盖真实差异
- 先做 5–10 轮预热（warm-up）：JIT 编译稳定后性能才可比
- 固定随机种子和数组内容：排除数据分布干扰，例如用 ThreadLocalRandom.current().nextInt(1000000) 生成相同序列
- 用 jstack 或 JMX 观察 ForkJoinPool.commonPool-worker-x 是否活跃：没看到多线程跑，说明根本没进并行路径
什么情况该换别的方法？
parallelSort 不是终极解，遇到这些场景建议绕道：
- 只要 Top-K（比如取前 100 名）：用 PriorityQueue 或快速选择算法，O(n) 或 O(k log n)，远优于全量排序
- 数组近似有序（如每天追加少量新数据）：插入排序或 TimSort（Arrays.sort 对 Object 默认就是它）可能更快
- 数组超大（几十 GB）、内存扛不住：改用外部排序（如 Spark sortByKey 或分块+归并）
- 需要精细控制稳定性或合并逻辑：手动拆子数组 + ForkJoinTask，比黑盒 parallelSort 更可控
