4、锁竞争与无锁编程：锁的开销分析、读写锁 vs 互斥锁、原子操作与CAS、无锁队列实现（基于Ring Buffer）

聊到锁竞争，我脑子里第一个蹦出来的画面，就是几年前在某个期货公司做低延迟系统优化时的场景。当时我们有一台机器，CPU 使用率才 30%，但交易延迟就是下不来。我盯着火焰图看了半天，发现有一半的 CPU 时间都花在 pthread_mutex_lock 和 pthread_mutex_unlock 上。说白了，线程们都在排队等锁，真正干活的没几个。

从那天起，我就养成了一个习惯：能不用锁，就不用锁；实在要用，也得用最轻量的那把锁。今天咱们就来聊聊，锁到底有多贵，以及怎么绕过它。

锁的开销分析

很多人觉得锁就是一条指令的事，能有多慢？我告诉你，一次锁竞争引发的上下文切换，代价是纳秒级的指令执行变成微秒级的线程挂起。你想想看，这中间差了上千倍。

锁的开销主要来自三个层面：

• 争用等待：线程拿不到锁，被操作系统挂起，然后调度其他线程。这个切换过程涉及用户态到内核态的切换，代价极高。
• 缓存行颠簸：多个线程在同一个缓存行上修改锁变量，导致 CPU 缓存一致性协议频繁广播失效消息。我在项目中见过，光这个就能让性能下降 40%。
• 锁的持有时间：锁里干的活越重，其他线程等得越久。这个很好理解，但很多人容易忽略。

我曾经在一个高频交易系统里做过测试：一个简单的自旋锁，在无竞争时延迟约 20ns；当 4 个线程同时争抢时，平均延迟飙升到 1.2μs。整整 60 倍！

读写锁 vs 互斥锁

互斥锁（Mutex）是最朴素的锁——要么你拿，要么我等，没有中间态。读写锁（RWLock）则聪明一点：读读不互斥，读写互斥，写写互斥。

听起来读写锁很美好，对吧？但我得泼盆冷水：读写锁不是银弹。

特性	互斥锁	读写锁
读读并发	不允许多个读线程同时访问	允许多个读线程同时访问
写写并发	不允许多个写线程同时访问	不允许多个写线程同时访问
读写并发	不允许多个读写线程同时访问	不允许多个读写线程同时访问
内部开销	较低	较高（需要维护读计数和写状态）
适用场景	写操作频繁，或读写比例接近	读多写少，且读操作耗时较长

我个人的经验是：如果读操作只是几十纳秒的事，读写锁带来的额外开销可能比互斥锁还大。我曾经在一个行情数据分发模块里，把读写锁换回互斥锁，性能反而提升了 15%。为什么？因为读操作太快了，读写锁内部的原子计数和条件判断反而成了瓶颈。

原子操作与CAS

原子操作是 CPU 直接支持的、不可中断的操作。最常见的包括 atomic_add、atomic_sub、atomic_exchange 等。而 CAS（Compare-And-Swap）是其中最核心的一个——它先比较内存中的值是否等于预期值，如果相等，就交换为新值；否则什么都不做。整个过程是原子的。

CAS 的伪代码长这样：

bool CAS(int* ptr, int expected, int new_value) {
    if (*ptr == expected) {
        *ptr = new_value;
        return true;
    }
    return false;
}

你可能会问：这不就是个 if 判断加赋值吗？有什么特别的？特别就特别在它是原子的。在多线程环境下，这个操作不会被其他线程打断，也不需要加锁。

我在项目中用 CAS 实现过一个简单的计数器：

#include <atomic>

class AtomicCounter {
private:
    std::atomic<int> count_{0};
public:
    void increment() {
        int old = count_.load();
        while (!count_.compare_exchange_weak(old, old + 1)) {
            // CAS 失败时，old 已经被更新为最新值
            // 直接重试即可
        }
    }
    
    int get() const {
        return count_.load();
    }
};

这里有个坑，我踩过：compare_exchange_weak 可能会因为伪失败（spurious failure）而返回 false，所以必须放在循环里。而 compare_exchange_strong 则保证不会伪失败，但性能稍差。嗯，这里要注意，在循环中两者差别不大，但如果你在写无锁数据结构，weak 版本通常更高效。

无锁队列实现（基于Ring Buffer）

聊了这么多，终于到重头戏了。无锁队列，说白了就是不用锁也能安全地让多个线程读写数据。最经典的实现就是基于 Ring Buffer（环形缓冲区）。

Ring Buffer 的核心思想很简单：一块固定大小的连续内存，用两个指针（或索引）分别表示读位置和写位置。生产者往写位置写数据，消费者从读位置读数据。当指针到达缓冲区末尾时，自动绕回开头。

下面是我手写的一个单生产者单消费者（SPSC）无锁队列：

template<typename T, size_t Size>
class SPSCRingBuffer {
private:
    static constexpr size_t kMask = Size - 1;
    static_assert((Size & kMask) == 0, "Size must be power of 2");
    
    std::array<T, Size> buffer_;
    std::atomic<size_t> write_index_{0};
    std::atomic<size_t> read_index_{0};
    
public:
    bool push(const T& item) {
        size_t write = write_index_.load(std::memory_order_relaxed);
        size_t read = read_index_.load(std::memory_order_acquire);
        
        if ((write - read) >= Size) {
            return false; // 缓冲区满了
        }
        
        buffer_[write & kMask] = item;
        write_index_.store(write + 1, std::memory_order_release);
        return true;
    }
    
    bool pop(T& item) {
        size_t read = read_index_.load(std::memory_order_relaxed);
        size_t write = write_index_.load(std::memory_order_acquire);
        
        if (read == write) {
            return false; // 缓冲区空了
        }
        
        item = buffer_[read & kMask];
        read_index_.store(read + 1, std::memory_order_release);
        return true;
    }
};

这段代码有几个关键点：

• Size 必须是 2 的幂，这样可以用位运算代替取模，快很多。
• 内存序（memory order）：relaxed 用于本线程内不需要同步的加载，acquire 保证读到其他线程的最新写入，release 保证本线程的写入对其他线程可见。
• 没有锁：整个队列只用了两个原子变量，没有任何互斥锁或自旋锁。

下面这张图展示了 Ring Buffer 的核心逻辑：

你看，整个无锁队列的核心就是两个原子索引。生产者只修改写索引，消费者只修改读索引。没有锁，没有等待，数据就在内存里高效流转。

我曾经在一个行情网关里用这个 SPSC 队列，把生产者（网络线程）和消费者（策略线程）之间的数据传递延迟从 1.5μs 降到了 200ns 以内。嗯，这个优化带来的收益，比我在其他地方折腾一个月都大。

最后总结一下：锁竞争是性能杀手，但也不是洪水猛兽。先搞清楚你的场景，再选择合适的方案。能用原子操作解决的，就别上锁；能用 SPSC 队列的，就别用 MPMC；能用读写锁的，也别滥用。我个人的经验是，80% 的锁竞争问题，都可以通过更合理的数据结构设计来避免。

---