likely和unlikely是gc++/clang中用于优化分支预测的宏定义。1.它们通过__builtin_expect告知编译器条件分支的预期结果，提升流水线效率；2.适用于错误处理、异常状态转移、调试路径等低频分支；3.使用时需避免滥用并优先保证代码可读性；4.c++20提供了标准属性[[likely]]/[[unlikely]]作为替代方案。
在C++开发中，分支预测对程序性能的影响往往被低估。现代CPU依赖分支预测来保持流水线的高效运行，而错误预测会导致严重的性能损失。使用
likely()和
unlikely()宏（或类似的编译器内建函数），可以辅助编译器优化代码布局，提高预测准确率，从而减少流水线停顿。
什么是 likely 和 unlikely 宏？
likely()和
unlikely()是用于告诉编译器某个条件分支更可能为真还是假的宏定义，它们并不是标准C++的一部分，而是GCC和Clang等编译器支持的扩展功能。常见定义如下：
#define likely(x) __builtin_expect(!!(x), 1) #define unlikely(x) __builtin_expect(!!(x), 0)
其中，
__builtin_expect是一个内建函数，告诉编译器表达式
(x)的预期结果是 1（很可能）还是 0（不太可能）。这会影响生成的汇编代码中分支指令的顺序，使更常见的路径连续执行，减少跳转带来的开销。
立即学习“C++免费学习笔记（深入）”；
在哪些场景下应该使用 unlikely/likely？
不是所有条件判断都值得加这些宏，通常适用于以下几种情况：
- 错误处理分支：例如检查指针是否为空、函数返回错误码等情况通常是“罕见”的。
- 状态机中的异常路径：某些状态转移不常发生，比如超时、重试等。
- 配置开关或调试路径：如日志输出、调试断言，在生产环境中很少触发。
举个例子：
if (unlikely(ptr == nullptr)) {
// 处理错误，这种情况极少发生
handle_error();
}这样可以让编译器把正常流程放在主路径上，避免因为频繁跳转影响指令缓存和流水线效率。
使用注意事项与技巧
- 不要滥用：只有当你确信某条分支的执行频率明显偏高或偏低时才用。误判反而可能导致性能下降。
- 逻辑清晰优先：代码可读性比微优化更重要，除非你已经在热点函数中发现了分支预测失败的问题。
- 结合性能分析工具：使用 perf、Valgrind 等工具检测实际运行中的 branch misprediction 情况，再决定是否需要优化。
-
不同平台行为可能不同：虽然 GCC 和 Clang 支持良好，但 MSVC 不支持
__builtin_expect
，需要用其他方式模拟或忽略。
替代方案与未来趋势
如果你不想依赖非标准宏，也可以考虑：
-
使用 C++20 中的
[[likely]]
和[[unlikely]]
属性语法：if (ptr == nullptr) [[unlikely]] { handle_error(); }这是语言级别的支持，更安全也更具可移植性，不过目前主流编译器的支持程度还在逐步完善中。
编译器自动优化：现代编译器已经能通过 profile-guided optimization（PGO）来自动生成更优的分支布局，但这需要额外构建步骤和测试数据。
总的来说，使用
likely()和
unlikely()是一种轻量级的优化手段，适合在性能敏感的关键路径上提升执行效率。它并不复杂，但如果盲目使用也可能带来维护负担。建议在确认有收益的情况下再进行添加。
基本上就这些。
