编译器属性与优化：__attribute__((always_inline))、__restrict、__builtin_expect、alignas、noinline

编译器属性，说白了就是给编译器递小纸条。你告诉它：「这里帮我使劲优化，那里别乱动。」我刚开始接触这些属性时，觉得可有可无。直到有一次线上服务因为一个内联决策失误导致性能雪崩……嗯，从那以后我再也不敢小看它们了。

今天咱们聊聊五个常用的编译器属性。它们各自解决不同的问题，但目标一致：让生成的机器码更聪明、更快。

1. always_inline：强制内联，别跟我商量

内联是编译器最常用的优化手段之一。把函数调用替换成函数体本身，省去调用开销。但编译器有自己的判断标准——它觉得函数太大、太复杂，就不会内联。

__attribute__((always_inline)) 就是强制命令：「你必须给我内联，没得商量。」

static inline __attribute__((always_inline)) int add(int a, int b) {
    return a + b;
}

我在项目中遇到过一种场景：一个高频调用的短函数，编译器偏偏不内联。原因是函数内部有分支，编译器觉得「不值得」。我加上 always_inline 后，性能提升了 15%。

2. __restrict：告诉编译器，指针不打架

C/C++ 的指针别名问题，是编译器优化的头号杀手。两个指针指向同一块内存，编译器不敢乱优化，怕改错数据。

__restrict 就是你对编译器的承诺：「这两个指针绝对不会指向同一块内存，你放心优化吧。」

void vector_add(float* __restrict a, float* __restrict b, float* __restrict c, int n) {
    for (int i = 0; i < n; ++i) {
        a[i] = b[i] + c[i];
    }
}

没有 __restrict，编译器每次循环都要重新加载 b[i] 和 c[i]，因为它担心 a 的写入会覆盖它们。加了之后，编译器可以大胆使用 SIMD 指令，一次处理多个元素。

3. __builtin_expect：给分支预测递情报

分支预测失败，代价很大。CPU 流水线要清空重来，几十个时钟周期就没了。

__builtin_expect 让你告诉编译器：「这个分支大概率走这边。」编译器会调整代码布局，让大概率走的分支更紧凑，减少跳转。

if (__builtin_expect(ptr != nullptr, 1)) {
    // 大概率执行
    process(ptr);
} else {
    // 小概率执行
    handle_error();
}

Linux 内核里到处都是这个宏。我曾在网络协议栈里用过它，把错误处理分支标记为 unlikely，吞吐量提升了 3% 左右。

为什么会这样？因为 CPU 有分支预测器，但编译器可以通过代码布局「暗示」预测器。你把大概率路径放在紧挨着条件判断的地方，小概率路径跳转到远处，这样指令缓存命中率更高。

4. alignas：对齐，让内存访问更顺畅

CPU 访问对齐的数据，一次内存操作就能搞定。不对齐的话，可能要访问两次，再拼接。对于高频访问的数据结构，对齐能带来可观的性能提升。

alignas 是 C++11 引入的关键字，用来指定对齐方式。

struct alignas(64) CacheLine {
    int data[16];
};

把结构体对齐到缓存行大小（通常是 64 字节），可以避免伪共享（false sharing）。多线程场景下，两个线程操作不同但位于同一缓存行的变量，会导致缓存行频繁失效。对齐后，每个变量独占一个缓存行，问题就解决了。

我记得有一次优化多线程计数器，把计数器对齐到 64 字节后，性能提升了 4 倍。原因就是伪共享被彻底消除了。

对齐方式	适用场景	性能影响
默认对齐	通用场景	无额外开销
alignas(64)	多线程共享数据	避免伪共享，提升明显
alignas(128)	SIMD 向量化	配合加载指令，减少边界处理

5. noinline：别内联，保持调用栈

有时候，你反而希望编译器不要内联。比如调试时，内联会让调用栈信息丢失，难以定位问题。或者某些函数需要保持独立的地址，用于性能分析。

__attribute__((noinline)) 就是告诉编译器：「这个函数别给我展开，保持原样。」

__attribute__((noinline)) void critical_section() {
    // 需要独立调用栈的函数
    acquire_lock();
    // ...
    release_lock();
}

我曾经在性能剖析时遇到一个坑：一个热点函数被内联到多个调用点，导致 perf 报告里看不到它的真实开销。加上 noinline 后，调用栈清晰了，优化目标也明确了。

知识体系总览

下面这张图总结了五个属性的核心作用和使用场景。你可以把它当作速查表。

避坑指南

这些属性用好了是利器，用不好就是坑。我总结几条经验：

• 不要盲目加 always_inline：我曾经在一个 200 行的函数上加了 always_inline，结果编译出来的二进制体积暴涨，性能反而下降。内联不是免费的。
• __restrict 要谨慎使用：一旦你承诺了「不重叠」，实际却重叠了，编译器会生成错误代码。这种 bug 极难排查。
• __builtin_expect 别滥用：只在真正有偏向的分支上用。我见过有人给所有 if 都加上，结果编译器优化反而变差了。
• alignas 不是越大越好：对齐到缓存行就够了。对齐到 128 字节、256 字节，浪费内存不说，还可能因为缓存行利用率低而变慢。
• noinline 记得去掉：性能分析完，记得把 noinline 去掉或改成条件编译。否则生产环境也会保留非内联状态。

好了，这五个属性就聊到这儿。每个都有它的脾气，用对了事半功倍，用错了事倍功半。你想想看，编译器其实挺听话的——只要你把指令说清楚。

---