第一章：锁竞争的本质——从交易系统的订单簿更新说起

大家好，我是老张。在交易系统这个行当摸爬滚打了十几年，今天咱们来聊聊一个绕不开的话题——锁竞争。

你想想看，一个高频交易系统每秒要处理几十万笔订单。订单簿的更新，说白了就是不停地插入、删除、修改价格档位。多个线程同时操作同一份数据，冲突就来了。

我刚开始做交易系统时，遇到过一件挺尴尬的事。系统上线第一天，延迟直接飙到毫秒级。排查下来，罪魁祸首就是锁竞争。嗯，从那以后，我对锁的敏感度就特别高。

1.1 订单簿更新的典型场景

先看一个简化版的订单簿结构。它维护着买盘和卖盘两个价格队列：

// 订单簿核心结构
struct OrderBook {
    // 买盘：价格从高到低
    std::map<double, OrderList, std::greater<double>> bids;
    // 卖盘：价格从低到高
    std::map<double, OrderList> asks;
    std::mutex mtx;  // 全局锁
};

// 更新订单簿
void addOrder(Order& order) {
    std::lock_guard<std::mutex> lock(mtx);
    if (order.side == BUY) {
        bids[order.price].push_back(order);
    } else {
        asks[order.price].push_back(order);
    }
}

这段代码看起来没问题，对吧？每个线程进来先拿锁，再操作。但问题就出在这个「全局锁」上。

1.2 锁竞争产生的三个根本原因

我归纳了一下，锁竞争的产生离不开这三个因素。缺一个，竞争都不会这么严重。

1. 共享资源的互斥访问——说白了，就是多个线程要读写同一块内存。订单簿的 bids 和 asks 就是典型的共享资源。
2. 临界区执行时间过长——锁持有时间越长，别人等得越久。我见过有人把日志打印、网络发送都放在锁里面，那延迟不爆炸才怪。
3. 线程数量远大于资源数量——64个线程抢1把锁，和4个线程抢1把锁，完全是两个概念。交易系统为了吞吐量，线程数往往很多。

1.3 锁竞争带来的性能代价

锁竞争不只是让线程等着。它还有更隐蔽的代价：

代价类型	具体表现	典型影响
上下文切换	线程阻塞、唤醒	每次切换约 1-5 微秒
缓存颠簸	CPU 缓存行失效	内存访问延迟增加 10-100 倍
优先级反转	低优先级线程持有锁，高优先级线程等待	实时性无法保证
死锁风险	多个锁互相等待	系统完全卡死

你想想看，一个订单处理链路可能涉及订单簿、风控、资金、行情等多个模块。每个模块都加锁，延迟就像滚雪球一样越滚越大。

1.4 从根源理解：锁竞争的本质模型

为了让大家更直观地理解，我画了一张图。它展示了锁竞争的核心逻辑：

这张图很直白。N个线程都想操作订单簿，但锁只允许1个线程通过。剩下的N-1个线程，只能干等着。

1.5 量化锁竞争：怎么判断系统锁竞争严重？

光说理论不行，得能量化。我一般看这几个指标：

• 锁等待时间占比——线程花在等锁上的时间占总运行时间的比例。超过5%就要警惕了。
• 锁争用次数——单位时间内锁被多个线程同时请求的次数。越高说明竞争越激烈。
• 上下文切换频率——每秒上下文切换次数。交易系统里，超过1万次/秒就要排查了。

怎么观测？Linux 下用 perf 或者 lockstat。我习惯在代码里埋点，统计锁等待的耗时分布。这样能精确到每个锁的竞争情况。

1.6 小结：锁竞争的本质

说了这么多，其实就一句话：锁竞争的本质是多个线程对共享资源的串行化访问需求超过了资源的并行处理能力。

订单簿更新只是其中一个典型场景。交易系统里还有资金账户、持仓数据、风控规则……处处都有锁竞争的身影。

理解了这个本质，后面我们才能对症下药。比如：能不能让线程不共享资源？能不能减少锁持有时间？能不能用无锁数据结构？

这些，就是后面章节要讲的内容了。

---