c++++中likely和unlikely的作用是优化分支预测，减少性能损失。它们通过__builtin_expect提示编译器某条件更可能成立或不成立，适用于错误处理、异常情况、状态机低概率路径及热点代码。使用时需注意避免滥用、效果不确定性、宏优先级问题，并在调试时关闭提示。合理使用可提升性能，但不应影响代码清晰度。
在C++开发中，分支预测失误会影响程序性能，尤其是在高频循环或关键路径上。通过使用 likely 和 unlikely 宏，我们可以帮助编译器优化代码执行路径，从而减少因错误预测带来的性能损失。
了解 likely 和 unlikely 的作用
这两个宏本质上是给编译器的提示，告诉它某条分支更可能成立（likely）还是不太可能成立（unlikely）。虽然现代编译器已经很聪明了，但在某些情况下手动干预可以带来性能提升。
它们通常通过内建函数实现，比如 GCC 和 Clang 中使用的：
立即学习“C++免费学习笔记（深入）”；
#define likely(x) __builtin_expect(!!(x), 1) #define unlikely(x) __builtin_expect(!!(x), 0)
这里的 __builtin_expect 告诉编译器预期的布尔值结果，1 表示“很可能为真”，0 表示“很可能为假”。
在哪些场景下值得使用？
不是所有条件判断都适合加 likely/unlikely，下面是一些典型适用场景：
-
错误处理分支：例如检查函数参数是否为空指针，这种情况正常流程中很少触发。
if (unlikely(ptr == nullptr)) { // 处理错误 } 事件处理中的异常情况：比如网络请求中失败的响应码较少出现。
状态机逻辑：某个状态转移发生的概率远低于其他路径。
性能敏感的热点代码：如在循环体内做一些判断，其中某些情况非常少见。
这些场景加上提示后，可以让编译器更好地安排指令顺序，提高 CPU 流水线效率。
使用时需要注意的细节
虽然用起来简单，但有几个点容易忽略：
不要滥用：如果分支概率差不多五五开，强行加 likely 或 unlikely 反而可能导致性能下降。
不能保证效果：最终优化由编译器决定，不同平台和编译器版本行为可能不一致。
优先级问题：宏展开可能会受操作符优先级影响，建议始终把表达式括起来。
-
调试和测试时关闭提示：为了确保所有分支都被覆盖测试，可以在 debug 构建中定义空宏：
#ifdef NDEBUG #define likely(x) __builtin_expect(!!(x), 1) #define unlikely(x) __builtin_expect(!!(x), 0) #else #define likely(x) (x) #define unlikely(x) (x) #endif
总结
合理使用 likely 和 unlikely 能提升程序性能，尤其是在对性能要求较高的系统编程中。关键是识别出那些真正有偏态分布的条件分支，并给出合适的提示。不过别太依赖这个技巧，毕竟清晰、稳定的代码结构才是第一位的。
基本上就这些。
