什么是CPU分支预测？

原创于 2025-11-07 21:52:40 发布 · 909 阅读

30 ·

CC 4.0 BY-SA版权

文章标签：

#java #CPU

文章目录

引言
一、核心问题：流水线的"急刹车"
二、解决方案：分支预测
三、分支预测器是如何工作的？
四、一个影响性能的经典例子
五、启示
总结

引言

在Dubbo的代码里存在着这样一个优化，将swtich分支放到if else的else分支里面，看到这里，大家肯定不禁不住疑惑了为什么要这样不伦不类的优化，其意义何在？纯if的条件分支或是纯switch的分支不好吗？那么，接下来，就可以顺理成章地提出CPU分支预测。

一、核心问题：流水线的"急刹车"

要理解分支预测，首先要明白现代 CPU 的指令流水线。

想象一下汽车装配线，它被分成了多个阶段（安装引擎、安装车门、喷漆等）。当一辆车在喷漆时，下一辆车已经在安装车门，再下一辆则在安装引擎。这样同时有多辆车在生产线上，极大地提高了效率。

CPU 的指令流水线也是类似的原理，它将一条指令的执行分解为多个步骤（如：取指、译码、执行、访存、写回）。当第 N 条指令在执行阶段时，第 N+1 条指令已经在译码，第 N+2 条指令正在被读取。流水线越深，并行度越高，性能越好。

那么问题来了：当 CPU 遇到一个"分支"（比如 if-else 条件判断）时会发生什么？

if (condition) { // 这是一个"分支"
    // 分支 A：执行一些指令
} else {
    // 分支 B：执行另一些指令
}
// 后续指令

CPU 在"取指"阶段，需要知道下一条要取的是哪条指令。但在"执行"阶段之前，它无法知道 condition 的结果是 true 还是 false。这就好比一个岔路口，在走到跟前之前，你不知道该走左边还是右边。

如果没有分支预测，CPU 会怎么办？
它会暂停流水线，等待 condition 的计算结果出来。这被称为 流水线冒泡 或 控制冒险。在高频、深流水线的现代 CPU 中，这种停顿可能会浪费 10-20 个时钟周期，性能损失巨大。

二、解决方案：分支预测

为了解决这个问题，CPU 设计师引入了 分支预测器。它的核心思想是：猜！

预测：在条件结果未知的情况下，CPU 会根据历史经验预测条件最可能的结果（true 或 false）。
投机执行：CPU 会根据预测结果，提前将指令填入流水线并开始执行。
验证与回退：当条件的真实结果出来后，验证预测是否正确。
- 如果预测正确：太棒了！流水线没有任何停顿，继续执行。这叫预测命中。
- 如果预测错误：糟了！CPU 必须清空整个流水线中所有基于错误预测而执行的指令，然后从正确的分支重新开始填充流水线。这叫预测失败，并会带来一次分支预测惩罚。

关键在于：只要预测的准确率足够高，其带来的性能收益就远远大于偶尔预测错误带来的惩罚。

三、分支预测器是如何工作的？

分支预测器是一个硬件单元，它非常智能，主要有以下几种策略：

静态预测
最简单的方式，不依赖历史。
- 总是预测不跳转：简单但准确率一般。
- 预测后向分支为"跳转"，前向分支为"不跳转"：在循环中非常有效。因为循环的结束条件（比如 i < 100）在大部分迭代中都是 true（向后跳转继续循环），只有在最后一次才是 false（向前跳出循环）。
动态预测（现代CPU的核心）
动态预测器会为每个分支指令维护一个"历史记录"，并基于这个记录进行预测。

饱和计数器（1位预测器）
- 为每个分支指令分配一个位（bit）。
- 0 表示上次未跳转，1 表示上次跳转。
- 预测逻辑：上次跳转了，这次也预测跳转；上次没跳，这次也预测不跳。
- 弱点：对于一个交替变化的分支（T, NT, T, NT…），它的预测总是错的。例如，对于一个循环for (int i=0; i<10; i++)，在最后一次迭代（i=10）时，预测器因为上次（i=9）跳转了，所以这次也会预测跳转，但实际是false，导致预测失败。下一次循环（i=0）时，它又因为上次未跳转而预测不跳转，但实际是true，再次失败。
两位饱和计数器（经典策略）
- 这是最广泛使用的基础策略。它为每个分支指令分配 4 种状态，而不是2种：
  - Strongly Not Taken (强不跳转)
  - Weakly Not Taken (弱不跳转)
  - Weakly Taken (弱跳转)
  - Strongly Taken (强跳转)
- 工作方式：需要连续两次错误预测，才会改变"强"状态下的预测结果。
  - 例如，在 Strongly Taken 状态下，预测"跳转"。如果第一次预测失败，它会退回到 Weakly Taken，但依然预测"跳转"。只有当它在 Weakly Taken 状态下再次预测失败，才会切换到 Weakly Not Taken 并开始预测"不跳转"。
- 优势：对循环的末尾判断非常友好。在最后一次迭代预测失败后，它只是从"强跳转"变为"弱跳转"，当下一次循环开始时（i=0，条件为true），预测"跳转"是正确的，预测器会立刻回到"强跳转"状态。它容忍了单次的、规律性的预测失败。
局部历史预测与全局历史预测
- 局部历史：记录单个分支指令自身的历史模式（例如，它最近8次是 T, T, T, NT, T, T, T, NT …）。
- 全局历史：记录所有分支指令的跳转历史，形成一个全局的跳转模式位向量。因为分支之间可能存在关联（例如 if (a) …; if (b) …，b 的判断可能与 a 的结果有关）。
- 现代预测器（如 Tournament Predictor）会同时使用局部和全局历史，并动态选择哪种策略对于当前分支更有效。
分支目标缓冲区
- 光预测"是否跳转"还不够，还需要知道"跳转到哪里"。
- BTB 是一个缓存，它存储了分支指令的地址和它上次跳转的目标地址。当预测器预测"跳转"时，CPU 会立刻从 BTB 中取出目标地址，并开始从那里取指执行。

四、一个影响性能的经典例子

下面的代码是说明分支预测对性能影响的绝佳例子。

// 数组数据是乱序的
int[] data = new int[32768];
for (int i = 0; i < data.length; i++) {
    data[i] = random.nextInt(256);
}

// 排序数组
Arrays.sort(data);

long start = System.nanoTime();
long sum = 0;

for (int i = 0; i < 100000; i++) { // 循环多次以放大效果
    for (int c = 0; c < data.length; c++) {
        if (data[c] >= 128) { // ！！！核心分支！！！ 
            sum += data[c];
        }
    }
}

long end = System.nanoTime();
System.out.println("Time: " + (end - start) / 1000000 + " ms");
System.out.println("sum = " + sum);

会发生什么？

当数据已排序时：

在循环的初期，data[c] 的值都很小（比如小于128），if 条件一直为 false。
在循环的后期，data[c] 的值都很大（比如大于等于128），if 条件一直为 true。
这对于两位饱和计数器预测器来说是极其友好的。它很快会进入 Strongly Not Taken 状态，并稳定预测"不跳转"，直到某个临界点后，再进入 Strongly Taken 状态，并稳定预测"跳转"。整个过程中，预测失败只发生两次（在条件从false变为true的边界处）。

当数据完全乱序时：
- data[c] >= 128 的结果是完全随机的（50% 的概率为 true，50% 为 false）。
- 分支预测器根本无法找到任何规律，预测准确率会接近 50%。
- 这意味着有将近一半的预测是错误的，导致流水线不断地被清空，性能急剧下降。

实验结果：排序后的数据运行速度通常比乱序数据快 2-3 倍甚至更多，这就是分支预测的威力！

五、启示

虽然分支预测是硬件自动完成的，但我们可以编写"对分支预测友好"的代码来提升性能：

尽量编写条件概率明显的分支：让 if-else 的一个分支成为"热路径"，另一个成为"冷路径"。
避免在紧凑循环中使用无法预测的条件：如果可能，尝试消除循环内部的分支。

例子：上面的代码可以改写为无分支版本（虽然可能可读性下降）：

// 使用位运算来避免分支
int t = (data[c] - 128) >> 31; // 如果 data[c] < 128, t 为全1 (即 -1)，否则为全0
sum += ~t & data[c]; // 当 data[c] >= 128 时， ~t 为全1，相加；否则为0，不加。

使用编译器的内置预测提示（如 GCC 的 __builtin_expect），告诉编译器哪个分支更可能发生，以便优化代码布局。

总结

CPU 分支预测 是一种为了克服指令流水线因条件分支而产生的"停顿"问题，而采用的"猜测并提前执行"的硬件优化技术。它通过动态记录分支历史，以极高的准确率预测分支走向，从而保持流水线的充盈。预测失败时的"清空流水线"操作是其主要性能代价。理解这一原理，有助于我们编写出更能发挥现代 CPU 性能的代码。