【C++多线程】多线程性能调优：伪共享、缓存行对齐与吞吐优化

前面的文章剖析了各种同步原语的底层原理和正确用法，本文将聚焦于多线程程序的性能调优------如何让多线程程序真正"快"起来。我们将系统剖析伪共享的检测与消除、缓存行对齐、NUMA 架构与线程亲和性、锁竞争的量化分析、高并发场景的性能 profiling 方法论，以及工业级系统的性能优化实战。

---

一、问题引入：多线程不一定更快

1.1 一个反直觉的现象

很多初学者认为"线程越多，程序越快"，但实际情况往往相反：

// 一个简单的计数器，用 8 个线程同时递增
std::atomic<int> counter{0};

void worker() {
    for (int i = 0; i < 1000000; ++i) {
        counter.fetch_add(1, std::memory_order_relaxed);
    }
}

在 8 核 CPU 上运行 8 个线程，你可能期望 8 倍加速，但实际可能只有 2-3 倍------甚至在某些情况下比单线程还慢！

原因：

1. 缓存一致性开销：8 个核心同时修改同一个缓存行，缓存行在核心间频繁同步（MESI 的 Invalidate 风暴）
2. 原子操作的竞争：CAS 失败重试，大量 CPU 周期浪费在重试上
3. 上下文切换：线程数超过核心数时，频繁的上下文切换开销
4. 内存带宽瓶颈：多个核心同时访问内存，带宽饱和

多线程性能调优的核心，就是识别并消除这些开销。

1.2 性能调优的方法论

多线程性能调优不是"凭感觉优化"，而是系统化的工程方法：

1. 建立性能基线（Benchmark）
   ↓
2. 性能分析（Profiling）------找到瓶颈
   ↓
3. 根因分析------为什么是瓶颈
   ↓
4. 优化实施------针对性优化
   ↓
5. 验证效果------对比基线
   ↓
6. 重复------直到满足性能目标

铁律：先测量，再优化。 不要在没有性能数据的情况下盲目优化------你优化的可能根本不是瓶颈。

---

二、伪共享（False Sharing）

2.1 什么是伪共享？

伪共享是多线程性能调优中最经典、最常见的问题。

回顾第 06 篇的内容：CPU 缓存以**缓存行（Cache Line）**为单位管理，通常大小为 64 字节。即使只修改一个字节，整个缓存行都会被标记为 Modified，并在核心间同步。

伪共享 ：两个线程修改不同的变量 ，但这些变量在同一个缓存行中，导致缓存行在核心间频繁同步，性能急剧下降。

// ❌ 伪共享：两个计数器在同一个缓存行
struct Counters {
    std::atomic<int> counter1;  // 偏移 0
    std::atomic<int> counter2;  // 偏移 4（和 counter1 在同一个 64 字节缓存行！）
};

Counters counters;

// 线程 1 不断修改 counter1
// 线程 2 不断修改 counter2
// 两个线程的修改互相导致对方的缓存行失效 → 伪共享！

2.2 伪共享的性能影响

伪共享可能导致性能下降 10 倍以上。一个典型的测试：

场景	单线程耗时	2 线程耗时	加速比
独立变量（不同缓存行）	100ms	50ms	2.0x
伪共享（同一缓存行）	100ms	800ms	0.125x（反而更慢！）

伪共享时，2 个线程比 1 个线程慢 8 倍------因为大部分 CPU 周期都浪费在缓存行同步上了。

2.3 伪共享的检测

方法1：性能计数器（Hardware Performance Counters）

使用 perf（Linux）或 Intel VTune 检测缓存一致性事件：

# Linux perf 检测缓存行无效化
perf stat -e cache-misses,cache-references,LLC-store-misses,LLC-load-misses ./program

# 更精确：检测缓存一致性流量
perf stat -e offcore_requests.any_response,offcore_requests.demand_data_rd ./program

关键指标：

• cache-misses / cache-references：缓存未命中率
• LLC-store-misses：最后一级缓存存储未命中（可能是伪共享）
• offcore_requests：片外请求数量（伪共享会导致大量片外请求）

方法2：Intel VTune / AMD uProf

专业性能分析工具可以直接定位伪共享的源代码位置，显示哪些变量在同一个缓存行中被频繁修改。

方法3：代码审查

检查以下模式：

• 多个 std::atomic 变量相邻定义
• 结构体中多个线程分别修改的字段相邻
• 数组中相邻元素被不同线程修改
• 全局变量中相邻的线程特定数据

2.4 伪共享的消除

方法1：缓存行对齐（Cache Line Alignment）

将需要独立缓存行的变量对齐到缓存行边界：

// ✅ 缓存行对齐，避免伪共享
struct alignas(64) Counters {
    std::atomic<int> counter1;  // 在缓存行 0
    // 填充到 64 字节边界
    char padding[64 - sizeof(std::atomic<int>)];
    std::atomic<int> counter2;  // 在缓存行 1
};

更简洁的写法（C++17）：

#include <new>

// C++17 提供了硬件干扰大小常量
constexpr size_t CACHE_LINE_SIZE = std::hardware_destructive_interference_size;

struct Counters {
    alignas(CACHE_LINE_SIZE) std::atomic<int> counter1;
    alignas(CACHE_LINE_SIZE) std::atomic<int> counter2;
};

std::hardware_destructive_interference_size 是编译期常量，表示避免伪共享所需的最小对齐大小（通常 64 字节）。

方法2：填充（Padding）

在变量之间填充字节，确保它们不在同一个缓存行：

struct Counters {
    std::atomic<int> counter1;
    char padding[64];  // 填充 64 字节
    std::atomic<int> counter2;
};

注意：填充大小需要考虑编译器对齐，alignas 比手动填充更可靠。

方法3：线程局部存储（TLS）

如果每个线程只需要修改自己的计数器，用 thread_local 完全避免共享：

// ✅ 每个线程独立的计数器，完全无竞争
thread_local int t_counter = 0;

void worker() {
    for (int i = 0; i < 1000000; ++i) {
        t_counter++;  // 纯线程局部操作，极快
    }
}

如果需要汇总，可以定期将本地计数器累加到全局计数器（减少竞争频率）。

方法4：数据结构重组

将被不同线程修改的字段分散到不同的缓存行，或者将同一线程访问的字段聚集在一起（提高缓存利用率）。

---

三、缓存行对齐与数据布局优化

3.1 缓存行对齐的其他应用

除了消除伪共享，缓存行对齐还有其他应用：

1. 避免跨缓存行访问（Split Access）

如果一个变量跨越两个缓存行（未对齐），CPU 需要两次内存访问才能读取/写入，性能下降。原子操作如果跨缓存行，在 x86 上可能退化为总线锁（性能极差）。

// ❌ 可能跨缓存行
struct [[gnu::packed]] Bad {
    char a;      // 偏移 0
    int64_t b;   // 偏移 1，可能跨越 64 字节边界！
};

// ✅ 对齐到 8 字节边界
struct Good {
    char a;      // 偏移 0
    char padding[7];
    int64_t b;   // 偏移 8，对齐
};

2. 热点数据对齐

频繁访问的热点数据对齐到缓存行边界，确保一次缓存行加载就能获取完整数据。

3.2 数据布局优化（Data Layout Optimization）

数据布局对性能的影响往往比算法优化更大。关键原则：

1. 空间局部性（Spatial Locality）

将同时访问的数据放在一起，提高缓存行利用率：

// ❌ 差的布局：同时访问的字段分散
struct Particle {
    double x, y, z;           // 位置
    double vx, vy, vz;        // 速度
    double mass;               // 质量
    int id;
    // ... 其他字段
};

// 物理计算时同时访问 x,y,z,vx,vy,vz,mass → 好的布局
// 这些字段相邻，可能在同一个或相邻缓存行中

2. 结构数组（AoS）vs 数组结构（SoA）

// AoS（Array of Structures）：适合访问单个对象的所有字段
struct Particle { double x, y, z; };
std::vector<Particle> particles;

// SoA（Structure of Arrays）：适合批量访问同一字段
struct Particles {
    std::vector<double> x, y, z;
};

• AoS：适合面向对象访问，单个对象的字段在缓存行中聚集
• SoA：适合向量化（SIMD）和批量处理，同一字段的连续数据在内存中连续

选择取决于访问模式：如果循环中同时访问对象的多个字段，用 AoS；如果循环中只处理一个字段（如对所有 x 坐标做变换），用 SoA。

3. 冷热数据分离

将频繁访问的"热数据"和不常访问的"冷数据"分开存储，避免冷数据占用缓存行空间：

// ❌ 冷热数据混合
class Connection {
    int fd;              // 热：每次 IO 都访问
    std::string address; // 热
    char buffer[4096];   // 冷：只有大消息时使用
    std::string log_tag;  // 冷：只在日志时使用
};

// ✅ 冷热分离
class Connection {
    int fd;
    std::string address;
    // 热数据结束，对齐到缓存行
    alignas(64) char buffer[4096];
    std::string log_tag;
};

---

四、NUMA 架构与线程亲和性

4.1 什么是 NUMA？

NUMA（Non-Uniform Memory Access，非统一内存访问）是多处理器系统的内存架构。在 NUMA 系统中，每个 CPU 插槽（Socket）有自己的本地内存，访问本地内存快，访问其他插槽的内存慢（需要跨插槽的互联总线）。

┌─────────────┐         ┌─────────────┐
│  CPU Socket 0 │         │  CPU Socket 1 │
│  ┌─────────┐ │         │  ┌─────────┐ │
│  │ 8 核心   │ │         │  │ 8 核心   │ │
│  └─────────┘ │         │  └─────────┘ │
│  本地内存 32GB│◄──互联──►│  本地内存 32GB│
└─────────────┘         └─────────────┘

访问本地内存：~80ns
访问远程内存：~150-200ns（慢 2 倍！）

4.2 NUMA 对性能的影响

如果线程在 Socket 0 上运行，但频繁访问 Socket 1 的内存，内存访问延迟会增加 2 倍，性能可能下降 30%-50%。

NUMA 相关的性能问题：

1. 内存跨节点访问：线程访问非本地内存
2. 线程跨节点迁移：操作系统调度器将线程从一个 Socket 迁移到另一个
3. 内存分配策略：默认的内存分配可能在第一次访问的节点上分配，导致后续跨节点访问

4.3 线程亲和性（CPU Affinity）

线程亲和性将线程绑定到特定的 CPU 核心或 Socket，避免跨节点迁移，提高缓存命中率和内存访问局部性。

Linux 设置线程亲和性：

#include <pthread.h>
#include <sched.h>

// 将线程绑定到指定 CPU 核心
void set_affinity(std::thread& t, int cpu_id) {
    cpu_set_t cpuset;
    CPU_ZERO(&cpuset);
    CPU_SET(cpu_id, &cpuset);
    pthread_setaffinity_np(t.native_handle(), sizeof(cpu_set_t), &cpuset);
}

// 将线程绑定到整个 Socket 0 的所有核心
void set_socket_affinity(std::thread& t, int socket_id) {
    cpu_set_t cpuset;
    CPU_ZERO(&cpuset);
    // 假设每个 Socket 有 8 个核心
    for (int i = 0; i < 8; ++i) {
        CPU_SET(socket_id * 8 + i, &cpuset);
    }
    pthread_setaffinity_np(t.native_handle(), sizeof(cpu_set_t), &cpuset);
}

Windows 设置线程亲和性：

#include <windows.h>

void set_affinity(std::thread& t, DWORD_PTR mask) {
    SetThreadAffinityMask(t.native_handle(), mask);
}

// 绑定到核心 0 和 1
set_affinity(t, 0x03);

4.4 NUMA 感知的内存分配

在 NUMA 系统上，使用 libnuma 库进行 NUMA 感知的内存分配：

#include <numa.h>

// 在指定节点上分配内存
void* alloc_on_node(size_t size, int node) {
    return numa_alloc_onnode(size, node);
}

// 释放
void free_numa(void* ptr, size_t size) {
    numa_free(ptr, size);
}

// 将当前线程绑定到节点
void bind_to_node(int node) {
    numa_run_on_node(node);
}

或者使用 mmap + move_pages 系统调用将内存页移动到指定节点。

4.5 什么时候需要考虑 NUMA？

• 多插槽服务器（2 个以上 CPU Socket）
• 内存访问密集型应用（数据库、内存缓存、大数据处理）
• 延迟敏感型应用（高频交易、实时系统）
• 线程数多、数据量大的场景

如果是单插槽桌面系统，或者计算密集型（内存访问不是瓶颈），NUMA 影响不大。

---

五、锁竞争的量化分析与优化

5.1 锁竞争的检测

方法1：性能计数器

# 检测锁竞争相关的事件
perf stat -e mutex_lock,mutex_unlock,mutex_lock_contended ./program

# 或者用 perf lock 子命令
perf lock record ./program
perf lock report

方法2：ThreadSanitizer

ThreadSanitizer 可以检测锁竞争，但它主要检测数据竞争和死锁，不直接量化锁竞争的开销。

方法3：自定义锁竞争统计

在锁的包装类中统计竞争次数和等待时间：

class InstrumentedMutex {
public:
    void lock() {
        auto start = std::chrono::steady_clock::now();
        mtx_.lock();
        auto end = std::chrono::steady_clock::now();
        auto wait_time = std::chrono::duration_cast<std::chrono::nanoseconds>(end - start).count();
        total_wait_time_.fetch_add(wait_time);
        if (wait_time > 1000) {  // 等待超过 1μs 算竞争
            contention_count_.fetch_add(1);
        }
        lock_count_.fetch_add(1);
    }

    void unlock() {
        mtx_.unlock();
    }

    // 统计信息
    uint64_t lock_count() const { return lock_count_.load(); }
    uint64_t contention_count() const { return contention_count_.load(); }
    uint64_t total_wait_time() const { return total_wait_time_.load(); }

private:
    std::mutex mtx_;
    std::atomic<uint64_t> lock_count_{0};
    std::atomic<uint64_t> contention_count_{0};
    std::atomic<uint64_t> total_wait_time_{0};
};

5.2 锁竞争的优化策略

策略1：缩小临界区

这是最有效、最常用的优化。只保护真正需要互斥的操作：

// ❌ 临界区过大
void bad_update() {
    std::lock_guard<std::mutex> lock(mtx);
    auto data = read_from_database();  // 耗时 IO，不应在锁内
    auto result = expensive_compute(data);  // 耗时计算，不应在锁内
    shared_data = result;  // 只有这行需要锁
}

// ✅ 最小临界区
void good_update() {
    auto data = read_from_database();  // 无锁
    auto result = expensive_compute(data);  // 无锁
    {
        std::lock_guard<std::mutex> lock(mtx);
        shared_data = result;  // 最小临界区
    }
}

策略2：细化锁的粒度

将一把大锁拆分为多把小锁，减少竞争范围：

// ❌ 一把大锁保护所有数据
class BigLock {
    std::mutex mtx;
    std::unordered_map<int, Data> data;
public:
    void update(int key, const Data& value) {
        std::lock_guard<std::mutex> lock(mtx);
        data[key] = value;
    }
};

// ✅ 分片锁（Striped Lock）
class ShardedLock {
    static constexpr int NUM_SHARDS = 16;
    std::mutex mtx[NUM_SHARDS];
    std::unordered_map<int, Data> data[NUM_SHARDS];

    int shard(int key) { return key % NUM_SHARDS; }
public:
    void update(int key, const Data& value) {
        int s = shard(key);
        std::lock_guard<std::mutex> lock(mtx[s]);  // 只锁对应的分片
        data[s][key] = value;
    }
};

分片锁将数据分成多个分片，每个分片有独立的锁，不同分片的操作可以并发执行。

策略3：读写锁（读多写少）

读多写少场景用 shared_mutex 代替普通 mutex，允许多个读者并发：

// ❌ 普通 mutex：读操作也互相阻塞
std::mutex mtx;
int read() {
    std::lock_guard<std::mutex> lock(mtx);
    return data;
}

// ✅ shared_mutex：多个读者并发
std::shared_mutex rw_mtx;
int read() {
    std::shared_lock<std::shared_mutex> lock(rw_mtx);  // 共享锁
    return data;
}
void write(int value) {
    std::unique_lock<std::shared_mutex> lock(rw_mtx);  // 独占锁
    data = value;
}

详见第 04 篇。

策略4：无锁数据结构

高竞争场景下，用无锁数据结构（如无锁队列、无锁栈）代替有锁数据结构。详见第 14 篇。

策略5：线程局部存储（TLS）

如果每个线程只需要自己的数据，用 thread_local 完全避免共享和竞争。详见第 11 篇。

策略6：批量操作

将多次小的锁操作合并为一次大的锁操作，减少锁的获取次数：

// ❌ 循环中每次加锁
for (int i = 0; i < 1000; ++i) {
    std::lock_guard<std::mutex> lock(mtx);
    shared_queue.push(i);
}

// ✅ 批量处理，一次加锁
{
    std::lock_guard<std::mutex> lock(mtx);
    for (int i = 0; i < 1000; ++i) {
        shared_queue.push(i);
    }
}

---

六、性能 Profiling 工具与方法论

6.1 常用性能分析工具

工具	平台	功能
perf	Linux	性能计数器、CPU 采样、锁分析
Intel VTune	Linux/Windows	全面的性能分析，包括缓存、NUMA、锁竞争
AMD uProf	Linux/Windows	AMD 平台的性能分析
gprof	跨平台	函数级 CPU 采样
valgrind --tool=callgrind	Linux	函数调用图和耗时分析
ThreadSanitizer	跨平台	数据竞争、死锁检测
perf lock	Linux	锁竞争分析
numastat	Linux	NUMA 内存访问统计
Windows Performance Recorder	Windows	系统级性能追踪

6.2 perf 常用命令

# 1. CPU 采样分析（找到热点函数）
perf record -g ./program
perf report

# 2. 缓存分析
perf stat -e cache-misses,cache-references,LLC-load-misses,LLC-store-misses ./program

# 3. 锁竞争分析
perf lock record ./program
perf lock report

# 4. 调度分析（上下文切换）
perf sched record ./program
perf sched latency

# 5. NUMA 分析
perf stat -e offcore_requests.demand_data_rd,offcore_requests.demand_code_rd ./program

6.3 性能调优的检查清单

□ 1. 建立性能基线（Benchmark），记录关键指标
□ 2. CPU 利用率分析（是否有核心空闲？是否有核心过载？）
□ 3. 缓存分析（缓存未命中率？LLC 未命中？）
□ 4. 伪共享检测（相邻变量被不同线程修改？）
□ 5. 锁竞争分析（锁等待时间？竞争次数？）
□ 6. 上下文切换分析（是否过于频繁？）
□ 7. NUMA 分析（是否有跨节点内存访问？）
□ 8. 内存带宽分析（是否饱和？）
□ 9. 线程数分析（是否过多或过少？）
□ 10. 针对瓶颈优化后，重新测量验证

---

七、工业级性能优化实战

7.1 高并发计数器优化

问题：8 个线程同时递增一个全局计数器，性能差。

优化步骤：

Step 1: std::atomic<int> + fetch_add → 高竞争，CAS 重试多
Step 2: 分片计数器 → 16 个分片，线程按 ID 选择分片，减少竞争
Step 3: thread_local 计数器 + 定期汇总 → 完全无竞争，性能最优

// ✅ 最优方案：thread_local + 定期汇总
class HighPerformanceCounter {
public:
    void increment() {
        local_count_++;  // 纯线程局部，极快
    }

    uint64_t get_total() {
        uint64_t total = 0;
        // 遍历所有线程的本地计数器（需要维护线程列表）
        // 或者用定期汇总的方式
        return total;
    }

private:
    static thread_local uint64_t local_count_;
};

7.2 高并发消息队列优化

问题：多生产者多消费者队列，锁竞争严重。

优化方案：

1. 无锁队列：用 Michael-Scott 无锁队列（第 14 篇）
2. 每线程队列 + 窃取：每个生产者有自己的队列，消费者从任意队列窃取（类似工作窃取）
3. 批量操作：生产者批量入队，消费者批量出队，减少同步次数
4. 有界环形缓冲区：用预分配的环形缓冲区代替动态分配节点，减少内存分配开销

7.3 高频交易系统的延迟优化

高频交易系统对延迟极度敏感（微秒级甚至纳秒级），优化手段：

1. 线程亲和性：将交易线程绑定到专用核心，避免上下文切换
2. 忙等待（Busy Wait）：用自旋等待代替条件变量，避免阻塞唤醒的延迟（但消耗 CPU）
3. 无锁数据结构：用无锁队列传递订单和行情数据
4. 预分配内存：避免运行时动态分配（malloc 有锁且耗时）
5. 缓存行对齐：所有共享数据对齐到缓存行，避免伪共享
6. NUMA 感知：线程和内存绑定到同一个 Socket
7. 避免系统调用：关键路径上避免任何系统调用（包括 IO、锁的阻塞路径）
8. 编译器优化 ：使用 -O3 -march=native，开启链接时优化（LTO）
9. 大页内存（Huge Pages）：减少 TLB 未命中
10. 实时调度策略 ：使用 SCHED_FIFO 或 SCHED_RR 实时调度策略

---

八、面试高频问题

Q1：什么是伪共享？如何检测和消除？

伪共享（False Sharing）是指两个线程修改不同的变量，但这些变量在同一个 CPU 缓存行中（通常 64 字节），导致缓存行在核心间频繁同步（MESI 的 Invalidate 风暴），性能急剧下降。伪共享可能导致性能下降 10 倍以上。检测方法：（1）硬件性能计数器------用 perf stat 检测 cache-misses、LLC-store-misses、offcore_requests 等指标；（2）专业工具------Intel VTune、AMD uProf 可以定位伪共享的源代码位置；（3）代码审查------检查相邻的 atomic 变量、结构体中被不同线程修改的字段。消除方法：（1）缓存行对齐------用 alignas(64) 或 C++17 的 std::hardware_destructive_interference_size 将变量对齐到缓存行边界；（2）填充------在变量之间填充字节确保不在同一缓存行；（3）线程局部存储------用 thread_local 让每个线程有独立副本，完全避免共享；（4）数据结构重组------将被不同线程修改的字段分散。

Q2：多线程程序的性能调优方法论是什么？

多线程性能调优是系统化的工程方法，核心是"先测量再优化"。步骤：（1）建立性能基线------用 Benchmark 记录当前的吞吐量、延迟、CPU 利用率等关键指标；（2）性能分析（Profiling）------用 perf、VTune 等工具找到瓶颈（CPU 热点、缓存未命中、锁竞争、上下文切换、NUMA 跨节点访问等）；（3）根因分析------确定瓶颈的根本原因（是伪共享？锁竞争？线程过多？内存带宽？）；（4）针对性优化------根据根因选择优化手段（缩小临界区、细化锁粒度、缓存行对齐、线程亲和性、无锁数据结构等）；（5）验证效果------重新运行 Benchmark，对比基线，确认优化有效且没有引入回归；（6）重复迭代------直到满足性能目标。关键原则：不要在没有性能数据的情况下盲目优化，你优化的可能根本不是瓶颈。

Q3：什么是 NUMA？它对多线程性能有什么影响？如何优化？

NUMA（Non-Uniform Memory Access，非统一内存访问）是多处理器系统的内存架构：每个 CPU 插槽（Socket）有自己的本地内存，访问本地内存快（_{80ns），访问其他插槽的远程内存慢（}150-200ns，慢 2 倍）。影响：如果线程在 Socket 0 运行但频繁访问 Socket 1 的内存，内存访问延迟增加 2 倍，性能可能下降 30%-50%。线程被操作系统调度器跨 Socket 迁移也会导致缓存失效和性能波动。优化方法：（1）线程亲和性------用 pthread_setaffinity_np（Linux）或 SetThreadAffinityMask（Windows）将线程绑定到特定核心或 Socket，避免迁移；（2）NUMA 感知内存分配------用 libnuma 库的 numa_alloc_onnode 在指定节点分配内存，确保线程访问本地内存；（3）数据分布------将数据按 Socket 分片，每个 Socket 的线程只访问本地数据；（4）NUMA 感知的调度------将相关线程和数据调度到同一个 Socket。NUMA 优化主要适用于多插槽服务器和内存密集型应用。

Q4：锁竞争的优化策略有哪些？

锁竞争的优化策略（按效果和常用程度排序）：（1）缩小临界区------只保护真正需要互斥的操作，将耗时操作（IO、计算、内存分配）移出锁外，这是最有效的优化；（2）细化锁粒度------将一把大锁拆分为多把小锁（如分片锁 Striped Lock），不同分片的操作可并发；（3）读写锁------读多写少场景用 shared_mutex 代替普通 mutex，允许多个读者并发；（4）无锁数据结构------高竞争场景用无锁队列/栈代替有锁数据结构，用 CAS 代替锁；（5）线程局部存储（TLS）------如果每个线程只需要自己的数据，用 thread_local 完全避免共享和竞争；（6）批量操作------将多次小的锁操作合并为一次大的锁操作，减少锁的获取次数；（7）乐观锁------用版本号或时间戳实现乐观并发控制，先读后写，冲突时重试；（8）减少锁的持有时间------在锁内只做必要的状态更新，将通知、回调等移出锁外。

Q5：线程数应该如何选择？过多或过少有什么问题？

线程数的选择取决于任务类型：（1）CPU 密集型任务------推荐线程数 = CPU 核心数 或 核心数+1，过多线程导致频繁的上下文切换（保存/恢复寄存器、切换页表、缓存失效），反而降低性能；（2）IO 密集型任务------推荐线程数 = 核心数 × (1 + 平均IO等待时间/平均计算时间)，因为线程大部分时间在阻塞等待 IO，更多线程可以提高吞吐量；（3）混合型任务------使用动态线程池，根据负载自动调整。线程过少的问题：CPU 资源利用不足，任务排队等待时间长，吞吐量低。线程过多的问题：上下文切换开销大（每次切换约 1-5μs），内存占用高（每个线程栈 1-8MB），调度器负担重，缓存命中率下降，锁竞争加剧。实际选择应该通过性能测试和监控（CPU 利用率、队列等待时间、上下文切换次数）来确定最优值，而不是仅凭理论公式。

Q6：什么是忙等待（Busy Wait / Spin）？什么时候用它代替条件变量？

忙等待是指线程在循环中不断检查条件是否成立，而不是阻塞等待。典型实现是自旋锁（Spin Lock）：用 atomic_flag 的 test_and_set 循环等待。忙等待的优点：延迟极低（条件成立时立即响应，没有阻塞唤醒的上下文切换开销，约 1-5μs）；缺点：消耗 CPU 资源（等待期间 CPU 利用率 100%），长时间忙等待会浪费电力并影响其他线程。代替条件变量的场景：（1）等待时间极短（通常 <1μs），如无锁数据结构内部的短暂等待；（2）延迟极度敏感的场景，如高频交易系统的订单处理；（3）CPU 核心有富余，可以 dedicate 一个核心专门忙等待；（4）不能阻塞的上下文，如中断处理程序、实时系统的关键路径。不应该用忙等待的场景：（1）等待时间长且不确定（如等待网络 IO、用户输入）；（2）CPU 资源紧张；（3）需要节能的场景（移动设备、数据中心）。实际工程中常用混合策略：先自旋等待一段时间（如 100 次循环或 1μs），如果条件仍不成立则转为阻塞等待（如自适应互斥锁 pthread_mutex_adaptive_np）。

---