Java处理排序后的数组比没有排序的快？

Java处理排序后的数组比没有排序的快？

牛课网 是我最喜欢逛的一个网站，它是我 Chrome 浏览器的第一个书签。里面有很多很多经典的问题，其中一些回答，剖析得深入我心。就比如说这个：“为什么处理排序后的数组比没有排序的快？”
毫无疑问，直观印象里，排序后的数组处理起来就是要比没有排序的快，甚至不需要理由，就好像我们知道“夏天吃冰激凌就是爽，冬天穿羽绒服就是暖和”一样。
但本着“知其然知其所以然”的态度，我们确实需要去搞清楚到底是为什么？
来看一段 Java 代码：
public class SortArrayFasterDemo { public static void main(String[] args) { // 声明数组 int arraySize = 32768; int data[] = new int[arraySize]; Random rnd = new Random(0); for (int c = 0; c < arraySize; ++c) { data[c] = rnd.nextInt() % 256; } // !!! 排序后，比没有排序要快 Arrays.sort(data); // 测试 long start = System.nanoTime(); long sum = 0; for (int i = 0; i < 100000; ++i) { // 循环 for (int c = 0; c < arraySize; ++c) { if (data[c] >= 128) { sum += data[c]; } } } System.out.println((System.nanoTime() - start) / 1000000000.0); System.out.println("sum = " + sum); }}复制代码
这段代码非常简单，我来解释一下：

声明一个指定长度（32768）的数组。

声明一个 Random 随机数对象，种子是 0；rnd.nextInt() % 256 将会产生一个余数，余数的绝对值在 0 到 256 之间，包括 0，不包括 256，可能是负数；使用余数对数组进行填充。

使用 Arrays.sort() 进行排序。

通过 for 循环嵌套计算数组累加后的结果，并通过 System.nanoTime() 计算前后的时间差，精确到纳秒级。

我本机的环境是 Mac OS，内存 16 GB，CPU Intel Core i7，IDE 用的是 IntelliJ IDEA，排序后和未排序后的结果如下：
排序后：2.811633398未排序：9.41434346
时间差还是很明显的，对吧？未排序的时候，等待结果的时候让我有一种担心：什么时候结束啊？不会结束不了吧？
读者朋友们有没有玩过火炬之光啊？一款非常经典的单机游戏，每一个场景都有一副地图，地图上有很多分支，但只有一个分支可以通往下一关；在没有刷图之前，地图是模糊的，玩家并不知道哪一条分支是正确的。
如果侥幸跑的是一条正确的分支，那么很快就能到达下一关；否则就要往回跑，寻找正确的那条分支，需要花费更多的时间，但同时也会收获更多的经验和声望。
作为一名玩过火炬之光很久的老玩家，几乎每一幅地图我都刷过很多次，刷的次数多了，地图差不多就刻进了我的脑袋，即便是一开始地图是模糊的，我也能凭借经验和直觉找到最正确的那条分支，就省了很多折返跑的时间。
读者朋友们应该注意到了，上面的代码中有一个 if 分支——if (data[c] >= 128)，也就是说，如果数组中的值大于等于 128，则对其进行累加，否则跳过。
那这个代码中的分支就好像火炬之光中的地图分支，如果处理器能够像我一样提前预判，那累加的操作就会快很多，对吧？
处理器的内部结构我是不懂的，但它应该和我的大脑是类似的，遇到 if 分支的时候也需要停下来，猜一猜，到底要不要继续，如果每次都猜对，那显然就不需要折返跑，浪费时间。
这就是传说中的分支预测！
我需要刷很多次图才能正确地预测地图上的路线，处理器需要排序才能提高判断的准确率。
计算机发展了这么多年，已经变得非常非常聪明，对于条件的预测通常能达到 90% 以上的命中率。但是，如果分支是不可预测的，那处理器也无能为力啊，对不对？
排序后花费的时间少，未排序花费的时间多，罪魁祸首就在 if 语句上。
if (data[c] >= 128) { sum += data[c];}复制代码
数组中的值是均匀分布的（-255 到 255 之间），至于是怎么均匀分布的，我们暂且不管，反正由 Random 类负责。
为了方便讲解，我们暂时忽略掉负数的那一部分，从 0 到 255 说起。
来看经过排序后的数据：
data[] = 0, 1, 2, 3, 4, … 126, 127, 128, 129, 130, … 250, 251, 252, …branch = N N N N N … N N T T T … T T T … = NNNNNNNNNNNN … NNNNNNNTTTTTTTTT … TTTTTTTTTT复制代码
N 是小于 128 的，将会被 if 条件过滤掉；T 是将要累加到 sum 中的值。
再来看未排序的数据：
data[] = 226, 185, 125, 158, 198, 144, 217, 79, 202, 118, 14, 150, 177, 182, 133, …branch = T, T, N, T, T, T, T, N, T, N, N, T, T, T, N … = TTNTTTTNTNNTTTN … 复制代码
完全没有办法预测。
对比过后，就能发现，排序后的数据在遇到分支预测的时候，能够轻松地过滤掉 50% 的数据，对吧？是有规律可循的。
那假如说不想排序，又想节省时间，有没有办法呢？
如果你直接问我的话，我肯定毫无办法，两手一摊，一副无奈脸。不过，Stack Overflow 以上帝视角给出了答案。
把：
if (data[c] >= 128) { sum += data[c];}复制代码
更换为：
int t = (data[c] - 128) >> 31;sum += ~t & data[c];复制代码
通过位运算消除了 if 分支（并不完全等同），但我测试了一下，计算后的 sum 结果是相同的。
/** * @author 沉默王二，一枚有趣的程序员 */public class SortArrayFasterDemo { public static void main(String[] args) { // 声明数组 int arraySize = 32768; int data[] = new int[arraySize]; Random rnd = new Random(); for (int c = 0; c < arraySize; ++c) { data[c] = rnd.nextInt() % 256; } // 测试 long start = System.nanoTime(); long sum = 0; for (int i = 0; i < 100000; ++i) { // 循环 for (int c = 0; c < arraySize; ++c) { if (data[c] >= 128) { sum += data[c]; } } } System.out.println((System.nanoTime() - start) / 1000000000.0); System.out.println("sum = " + sum); // 测试 long start1 = System.nanoTime(); long sum1 = 0; for (int i = 0; i < 100000; ++i) { // 循环 for (int c = 0; c < arraySize; ++c) { int t = (data[c] - 128) >> 31; sum1 += ~t & data[c]; } } System.out.println((System.nanoTime() - start1) / 1000000000.0); System.out.println("sum1 = " + sum1); }}复制代码
输出结果如下所示：
8.734795196sum = 1568718000001.596423307sum1 = 156871800000复制代码
数组累加后的结果是相同的，但时间上仍然差得非常多，这说明时间确实耗在分支预测上——如果数组没有排序的话。