[[likely]] 和 [[unlikely]]：C++20里那个“悄悄帮你调性能”的小开关

上周帮同事看一段实时音频处理代码，循环里有个 if (buffer_full) 判断，99.9% 的情况都走 true 分支——但编译器默认按“等概率”生成跳转逻辑，结果分支预测失败率偏高，CPU 流水线老是清空。改完加了 [[likely]]，实测延迟抖动降了 18%。这不是玄学，是 C++20 给我们塞进语法里的、真正能影响机器码的提示符。

很多人把它当成“给编译器画重点的便签纸”，但便签纸不会改变汇编指令顺序——而这两个属性会。

[[likely]] 和 [[unlikely]] 是 C++20 引入的属性（attribute），作用很直接：告诉编译器某个分支大概率/小概率被执行。它们不改变程序行为，但可能显著影响生成的机器码布局——尤其是分支目标地址的物理位置。

关键点来了：它们只对 if、switch、while、for 等语句的 语句块 生效，不是修饰表达式，也不是修饰函数。
错误写法：

if ([[likely]] x > 0) { ... } // ❌ 语法错误  

正确姿势：

if (x > 0) [[likely]] { ... } // ✅ 修饰整个分支块  
// 或更常见地  
if (x > 0) {  
    // ...  
} [[likely]];  

为什么这个位置设计得这么“别扭”？因为 C++ 的属性绑定规则要求它附着在 声明或语句 上，而分支体本身就是一个复合语句（compound-statement）。这看似繁琐，实则精准——你提示的是“执行这一整段代码的可能性”，而不是“判断这个条件的可能性”。

实际效果取决于编译器实现。Clang 和 GCC 都会据此调整代码布局：把 [[likely]] 分支的指令尽量放在紧跟当前指令之后（减少跳转），而把 [[unlikely]] 分支挪到远离热路径的内存区域（甚至放到 .text.unlikely 段）。这种布局直接影响 CPU 分支预测器的命中率和指令预取效率。

举个真实例子：一个网络协议解析器中，正常数据包占 99.5%，错误校验失败仅占 0.5%。原始代码：

if (crc_check(buf)) {  
    parse_payload(buf);  
} else {  
    handle_corruption();  
}  

加属性后：

if (crc_check(buf)) {  
    parse_payload(buf);  
} else [[unlikely]] {  
    handle_corruption();  
}  

GCC 13 在 -O2 下生成的汇编中，handle_corruption 对应的指令被整体后移到函数末尾附近，主流程几乎无跳转。perf 数据显示分支误预测次数下降约 40%。

但注意：属性不会强制编译器做任何事，它只是建议。如果你在 -O0 下编译，大多数编译器会直接忽略它。它需要优化器参与才能落地为实际收益。

还有一个常被忽略的细节：[[unlikely]] 不等于 ![[likely]]。它们是独立提示，且可叠加使用。比如嵌套错误处理：

if (alloc_ok) {  
    if (init_ok) {  
        run();  
    } else [[unlikely]] {  
        cleanup();  
    }  
} else [[unlikely]] {  
    log_error("OOM");  
}  

这里两个 [[unlikely]] 各自生效，编译器会分别将两处错误路径“推远”，而非简单合并。

什么时候该用？三条经验线：

• 已知分布偏差 > 90% 或 < 10%：比如日志级别检查（if (level >= DEBUG) [[unlikely]] {...}）；
• 错误处理路径：文件打开失败、系统调用返回 -1、指针解引用前的空检查（如果业务逻辑保证极少为空）；
• 调试/诊断分支：if (debug_mode) [[unlikely]] { dump_state(); }。

反例也得说清楚：别在循环计数器上乱加。for (int i = 0; i < n; ++i) [[likely]] { ... } 是无效的——[[likely]] 不能修饰 for 语句本身，且循环体执行多次，提示单次概率没意义。

最后提醒一个实战陷阱：属性只影响紧邻的语句块，不穿透作用域。下面这段代码，[[likely]] 只对 do_work() 生效，对 cleanup() 无效：

if (ready) [[likely]]  
    do_work(); // ✅ 提示生效  
else  
    cleanup(); // ❌ 未提示，编译器按默认概率处理  

想提示 else 分支，必须显式写 [[unlikely]]。

它们不是银弹。过早优化可能白忙活，但当你已经定位到某处分支预测失效率高（perf stat -e branches,branch-misses）、且逻辑概率明确时，这两行属性就是成本最低的优化——不用改算法，不增加维护负担，一行提示换回可观吞吐提升。

C++20 的新特性里，这对属性不算耀眼，但足够务实。它不炫技，不抽象，就安静地躺在分号前面，像一个懂编译器的同事，在你写完逻辑后轻轻说一句：“这儿，大概率走这边。”
而现代编译器，真的会听。