1、锁竞争的本质：为什么锁会成为高频交易的性能杀手？
做高频交易的朋友都知道，延迟就是金钱。每纳秒的延迟，都意味着真金白银的损失。而锁竞争，恰恰是延迟的头号杀手。
我个人习惯把锁竞争比作高速公路上的收费站。没有收费站时，车流畅通无阻。一旦设了收费站，所有车都得排队通过。哪怕只有一辆车在缴费，后面的车也得等着。这就是锁的本质——串行化。
1.1 从CPU缓存一致性协议说起
要理解锁为什么慢，得先搞清楚CPU是怎么工作的。现代CPU都有多级缓存，L1、L2、L3。每个核心有自己的L1/L2缓存，共享L3缓存。
这里有个关键问题：多个核心同时读写同一块内存时，怎么保证数据一致？
答案就是MESI协议。MESI代表四种缓存行状态：
| 状态 | 含义 | 说明 |
|---|---|---|
| M | Modified（已修改） | 缓存行被当前核心修改，与其他核心不一致 |
| E | Exclusive（独占） | 只有当前核心持有该缓存行，且与内存一致 |
| S | Shared（共享） | 多个核心持有该缓存行，且与内存一致 |
| I | Invalid（无效） | 缓存行已失效，需要重新加载 |
嗯，这里要注意：锁操作本质上就是缓存行状态的频繁切换。当你对一个变量加锁时，其他核心的缓存行会从S状态变成I状态。下次访问时，就得重新从内存加载。这个代价有多大？
关键数据：
- L1缓存命中：约1纳秒
- L2缓存命中：约7纳秒
- L3缓存命中：约20纳秒
- 内存访问：约100纳秒
- 缓存行失效后的重新加载：约50-100纳秒
我在项目中遇到过这样的情况：一个看似简单的锁操作，实际延迟可能达到几百纳秒。在高频交易中，这个数字足以让你错过一个套利机会。
1.2 操作系统锁的实现代价
操作系统提供的锁，比如pthread_mutex，底层是怎么实现的？
// 伪代码：pthread_mutex_lock 的简化流程
pthread_mutex_lock(mutex) {
// 第一步：尝试CAS原子操作
if (atomic_compare_exchange(mutex->lock, 0, 1)) {
return; // 成功获取锁
}
// 第二步：CAS失败，进入内核态
// 系统调用：futex_wait
// 上下文切换：保存当前线程状态
// 线程挂起：加入等待队列
// 第三步：被唤醒后，再次尝试
// 系统调用返回
// 上下文切换恢复
goto retry;
}
你看，一次锁竞争可能引发：
- CAS原子操作：约10-20纳秒
- 系统调用：约100-200纳秒（进入内核态）
- 上下文切换：约1-5微秒（保存/恢复寄存器）
- 线程调度：约10-100微秒（取决于调度器）
避坑指南：我曾经在一个项目中，用pthread_mutex保护一个简单的计数器。结果发现，在高并发下，锁竞争导致的上下文切换占了总延迟的80%以上。后来改用原子操作，延迟直接降了两个数量级。
1.3 锁竞争的连锁反应
锁竞争不只是让当前线程变慢。它还会引发一系列连锁反应：
- 缓存污染：锁变量所在的缓存行被频繁失效，其他无关数据也被波及
- 总线风暴：多个核心同时竞争内存总线，导致总线带宽被锁操作占满
- 优先级反转：低优先级线程持有锁，高优先级线程被阻塞
- 死锁风险：多个锁互相等待，系统直接卡死
说白了，锁竞争就像多米诺骨牌。你推倒第一张，后面跟着倒一片。在高频交易系统中，这种连锁反应是致命的。
1.4 核心结论：锁的延迟代价
我总结一下锁竞争带来的延迟代价：
| 场景 | 延迟范围 | 对高频交易的影响 |
|---|---|---|
| 无竞争（CAS成功） | 10-20纳秒 | 可接受 |
| 轻度竞争（自旋等待） | 100-500纳秒 | 开始有影响 |
| 中度竞争（系统调用） | 1-10微秒 | 明显延迟 |
| 重度竞争（上下文切换） | 10-100微秒 | 不可接受 |
个人经验：在高频交易系统中，我建议把锁竞争导致的延迟控制在100纳秒以内。超过这个阈值，你就得考虑无锁编程了。记住：锁不是不能用，而是要用对地方。
1.5 本章知识体系
下面这张图展示了锁竞争的核心知识结构：
这张图把锁竞争的核心要素都串起来了。从MESI协议到操作系统实现，再到连锁反应，每一步都在告诉我们：锁竞争不是小事，它牵一发而动全身。
好了，这一章就到这里。下一章我们会聊聊如何用原子操作来替代锁，以及CAS指令的正确使用姿势。