8. 分支预测优化：likely/unlikely 宏、减少复杂条件表达式、使用查找表替代分支

分支预测，说白了就是CPU在猜你的代码下一步会走哪条路。猜对了，流水线顺畅跑得飞快；猜错了，流水线要清空重来，那代价可不小。我见过不少项目，性能瓶颈就卡在几个看似不起眼的条件判断上。

今天咱们就聊聊怎么让分支更「听话」。我个人习惯把这部分优化分成三个层次：给编译器递小抄、把复杂条件拆简单、干脆不用分支。

8.1 likely/unlikely 宏：给编译器递小抄

先看个例子。你写了个错误检查：

if (ptr == nullptr) {
    // 处理错误，很少执行
    return -1;
}
// 正常逻辑，经常执行

CPU的分支预测器会基于历史统计来猜。但如果这个分支很少走，预测器可能还在那瞎猜。这时候likely/unlikely宏就派上用场了。

在Linux内核和很多高性能库中，你会看到这样的写法：

#define likely(x)   __builtin_expect(!!(x), 1)
#define unlikely(x) __builtin_expect(!!(x), 0)

if (unlikely(ptr == nullptr)) {
    // 告诉编译器：这个分支很少走
    return -1;
}

这俩宏本质上是__builtin_expect的包装。它的作用不是改变程序逻辑，而是告诉编译器：「老弟，这个条件大概率是true/false，你看着安排代码布局吧。」

我在项目中遇到过这样一个场景：一个网络库的报文解析函数，90%的报文都是正常数据，只有10%是控制报文。我在判断报文类型时加上了likely，编译出来的代码性能提升了约8%。嗯，这个收益其实挺可观的。

8.2 减少复杂条件表达式

你想想看，一个条件表达式里塞了五六个逻辑运算符，CPU看着都头大。分支预测器面对这种复杂条件，基本就是瞎蒙。

举个例子：

// 糟糕的写法
if (a > 0 && b < 100 && c != 0 && d == 1 && e > 10) {
    do_something();
}

这个条件里，只要任何一个子条件不满足，整个表达式就短路了。但问题是，CPU没法提前知道哪个子条件最容易失败。它只能等一个个算完。

优化思路其实很简单：把最容易失败的条件放在最前面。

// 更好的写法
if (c != 0 && a > 0 && d == 1 && b < 100 && e > 10) {
    do_something();
}

假设c != 0这个条件90%的情况下都不成立，那放在最前面就能快速短路，后面的条件根本不用算。

我曾经优化过一个日志系统，里面有个判断是否要写日志的条件，包含了七八个开关。我把最常关闭的那个开关挪到最前面，结果日志写入的吞吐量提升了15%。

8.3 使用查找表替代分支

这是我最喜欢的手法。有时候，分支判断的本质就是一个映射关系。比如：

int get_grade(int score) {
    if (score >= 90) return 'A';
    else if (score >= 80) return 'B';
    else if (score >= 70) return 'C';
    else if (score >= 60) return 'D';
    else return 'F';
}

这个函数每次调用都要做4次比较。如果被频繁调用，分支预测错误率会很高。换成查找表呢？

const char grade_table[] = {
    'F', 'F', 'F', 'F', 'F', 'F', 'F', 'F', 'F', 'F',  // 0-9
    'F', 'F', 'F', 'F', 'F', 'F', 'F', 'F', 'F', 'F',  // 10-19
    // ... 中间省略 ...
    'D', 'D', 'D', 'D', 'D', 'D', 'D', 'D', 'D', 'D',  // 60-69
    'C', 'C', 'C', 'C', 'C', 'C', 'C', 'C', 'C', 'C',  // 70-79
    'B', 'B', 'B', 'B', 'B', 'B', 'B', 'B', 'B', 'B',  // 80-89
    'A', 'A', 'A', 'A', 'A', 'A', 'A', 'A', 'A', 'A'   // 90-99
};

int get_grade(int score) {
    if (score < 0 || score > 100) return '?';
    return grade_table[score];
}

你看，一次数组访问就搞定了。没有分支，没有比较，CPU的流水线跑得飞起。

当然，查找表不是万能的。它适合那种输入范围有限、映射关系固定的场景。我曾在图像处理中用查找表替代了颜色空间转换里的分支判断，性能提升了将近一倍。

知识体系总览

下面这张图总结了分支预测优化的三个核心方向：

避坑指南

我曾经在一个项目中过度使用likely/unlikely，几乎每个if都加上了。结果呢？性能反而下降了。因为编译器被太多「提示」搞糊涂了，不知道该信哪个。

还有一次，我用查找表替代了一个分支，但表太大了（几MB），频繁的缓存缺失反而让性能更差了。嗯，查找表不是越大越好，得考虑CPU的L1/L2缓存大小。

分支预测优化，说白了就是帮CPU少走弯路。你想想看，CPU流水线那么长，一次预测错误就要清空十几级流水线，这代价可不小。用好今天讲的这三个技巧，你的代码在热点路径上能跑得更顺畅。

---