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