谷歌工程师实测：1个if语句写错，CPU多花20个周期|error|代码|官方文档|编译器|调用|谷歌工程师

你的代码里有多少个if判断？100个？1000个？每个猜错的分支都在让CPU白干活。现代处理器会提前预测程序走向，猜错了就要清空流水线重新来——一次失误15到20个周期，高频循环里这就是性能黑洞。

C++20给了程序员一个「作弊器」：直接告诉编译器哪条路更常走。这篇把从标准语法到Linux内核宏的所有手段捋一遍，看完你能立刻动手优化自己的热路径。

C++20的[[likely]]：终于不用写丑宏了

新标准把分支提示做成了原生属性，语法干净到不像C++。

写法直给：把[[likely]]或[[unlikely]]贴在分支语句后面。编译器会重新排布机器码，让高频路径成为"自然下落"——不用跳转，指令缓存更友好。

看个实际场景。网络包处理里，数据包占99%，错误包偶尔冒头：

if (error_code != 0) [[unlikely]] {handle_error();  // 冷路径扔远点}

switch语句也能用：

switch (packet_type) {[[likely]] case PacketType::Data:   // 热路径紧贴前面process_data();break;[[unlikely]] case PacketType::Error:log_and_drop();break;}

注意这是提示不是命令。编译器在-O0可能完全无视，release模式下才会认真考虑你的建议。

__builtin_expect：老派但稳如狗

GCC和Clang用了二十年的内置函数，至今仍是Linux内核的选择。

语法反直觉：第二个参数是"你期望的结果"。0表示"这条件大概率假"，1表示"大概率真"。

// 期望error_code == 0（即条件为假）if (__builtin_expect(error_code != 0, 0)) {// 冷路径// 期望is_valid为真if (__builtin_expect(is_valid, 1)) {// 热路径}

代码看着像咒语。所以工程实践里没人裸写，全包成宏。

LIKELY/UNLIKELY宏：工程界的土办法智慧

这是高性能代码库的通用方言，从内核到游戏引擎都在用。

典型定义长这样：

#if defined(__GNUC__) || defined(__clang__)#define LIKELY(x)   __builtin_expect(!!(x), 1)#define UNLIKELY(x) __builtin_expect(!!(x), 0)#else#define LIKELY(x)   (x)#define UNLIKELY(x) (x)#endif

双感叹号!!是把表达式强转成布尔值，防止宏展开出意外。微软的MSVC没有等价内置函数，所以 fallback 就是原样返回——至少代码能编译。

用起来舒服多了：

if (UNLIKELY(ptr == nullptr)) {return error;if (LIKELY(count > 0)) {process_batch();}

谷歌的Abseil库、Facebook的Folly、Chrome源码里搜一下，这种宏出现频率高得离谱。不是他们不想用C++20，是得照顾老编译器和各种嵌入式工具链。

编译器标志：让工具自己猜

手动标注是精准打击，编译器自动分析则是地毯式轰炸。

GCC和Clang有-fprofile-generate配合-fprofile-use的流程：先跑一遍真实负载采集分支频率，编译第二遍时用数据指导优化。这叫PGO（Profile-Guided Optimization，配置文件引导优化），效果通常比手写提示更准——毕竟实测数据比程序员的直觉靠谱。

LLVM还有个隐藏武器-mbranch-cost，可以调整编译器对分支代价的预估。默认值是1，设成更高会让编译器更激进地展开循环、向量化代码。

但PGO有门槛：需要可复现的测试负载，CI流程得改，增量编译也会变复杂。很多团队卡在"第一遍数据采集"这一步。