__builtin_expect 不是“加了就快”，它仅在分支概率高度偏斜（>90%或
直接说结论：__builtin_expect 不是“加了就快”，它只在分支概率高度偏斜（>90% 或 -O2 及以上优化才可能带来可观收益；用错地方反而干扰编译器自动优化，甚至引入逻辑错误。
什么时候该用 __builtin_expect 而不是普通 if
核心判断依据是：你是否已通过性能工具确认该分支是瓶颈，且运行时行为长期稳定。
- 典型可用场景：
ptr != nullptr（绝大多数调用非空）、errno == ENOMEM（内存充足时几乎不触发）、i （循环内固定数组访问，越界极少发生） - 绝对不该用的场景：用户输入校验、随机数分支、调试开关（如
if (DEBUG) { ... }）、任何概率不可控或随输入剧烈波动的条件 - 验证手段必须前置：用
perf record -e branches,branch-misses ./your_program找出branch-misses占比 >10% 的具体if行号，再决定是否优化
如何安全封装 likely/unlikely 宏
直接写 __builtin_expect(x, 1) 极易出错——类型误判、副作用重复求值、跨编译器失效。必须用宏封装，并加编译器保护。
- 标准定义（放在公共头文件中）：
#ifdef __GNUC__ # define likely(x) __builtin_expect(!!(x), 1) # define unlikely(x) __builtin_expect(!!(x), 0) #else # define likely(x) (x) # define unlikely(x) (x) #endif
-
!!(x)是关键：把任意表达式（指针、整数、bool）强制转为 0 或 1，避免传入-1或2导致提示被忽略 - 不要单独判断
__clang__：Clang 兼容 GCC 内置函数，且通常定义了__GNUC__，额外判断反而冗余 - 禁止在宏里展开带副作用的表达式：
likely(x++)会导致x自增两次——应先赋值再判断
为什么 -O2 是硬性门槛，-O0 下加了也白加
__builtin_expect 是纯编译期指令布局提示，不生成任何运行时代码。它只影响汇编中跳转目标的位置安排，而这个动作只有在启用足够优化等级后才会触发。
立即学习“C++免费学习笔记（深入）”；
-
-O0下：GCC/Clang 直接忽略该提示，生成的汇编与普通if完全一致 -
-O2及以上：编译器重排指令，将likely分支设为直行（fall-through），unlikely分支移至函数末尾并通过跳转进入 - 验证方法：用
g++ -S -O2 main.cpp生成main.s，搜索对应if的je/jne指令，对比主路径是否从跳转目标变成连续地址段
常见误用与隐蔽陷阱
最危险的不是语法报错，而是“看起来正常，实则无效甚至有害”。
- 在调试构建（
-O0）下测性能差异：结果毫无意义，纯属自我安慰 - 对同一变量反复标记：
if (unlikely(ptr == nullptr)) { ... } else if (unlikely(ptr->flag == 0)) { ... }——编译器无法同时优化两条冷路径，反而打乱指令局部性 - 在内联函数里滥用：若函数被内联进多个上下文，分支倾向性可能冲突，编译器会退回到保守策略
- 忽略硬件前提：该优化依赖 CPU 分支预测器本身有效，若程序已因缓存未命中或长延迟访存卡住，加
likely也无济于事
真正起效的前提，永远是：性能工具确认瓶颈 + 概率长期稳定 + 编译器能看见并信任这个提示。缺一不可。
