7微秒。这个数字在CPU世界里相当于从北京步行到上海——正常核心间延迟是纳秒级，差了三个数量级。Chester Lam最近测了英特尔Arrow Lake的"分裂锁"（Split Lock）表现，结果像把精密机械表扔进了洗衣机。
分裂锁的本质，是原子操作跨了缓存行边界。现代CPU用缓存一致性协议处理原子操作，锁单个缓存行就行。但英特尔和AMD显然没做"双锁"设计，跨行的原子操作会退化成总线锁——整个系统的内存总线被掐住，其他核心全得等着。
Lam的测试方法很直接：用`_InterlockedCompareExchange64`（编译成x86-64的`lock cmpxchg`）在两个核心间来回弹跳计数器。平时他把目标值放在64字节对齐块的起始位置，这次故意往缓存行末尾蹭——8字节值的前几字节在第一个缓存行，后几字节溜到下一个。
Arrow Lake实测：延迟从纳秒蹦到微秒
正常状态下，Arrow Lake的核心间延迟图是这样的：P核之间、P核与E核之间、E核内部，层次分明。但分裂锁直接把一切抹平——统统7微秒，不管你是大核小核还是跨簇访问。
更微妙的是，Arrow Lake的分裂锁只影响L2未命中场景。Lam的描述停在"close to a"，原文此处截断，但测试逻辑已经清晰：分裂锁的惩罚不是均匀分布的，它卡在特定的缓存层级交互里。
为了隔离变量，Lam关了睿频、压了主频。因为现代CPU的高频模式依赖活跃核心数，测试用的核心对会干扰时钟策略，不控制这个，测出来的噪音比信号还大。
总线锁的"邻里干扰"怎么量化
单纯测延迟不够。Lam同时在"旁观核心"上跑内存延迟/带宽微基准，还有Geekbench 6的照片滤镜和资源压缩负载。前者制造大量缓存未命中流量，后者偏向计算密集。
AMD和英特尔的新核心支持陷阱分裂锁——内核能捕获这类操作，插人工延迟来削峰。Linux默认开这个功能，但惩罚依然存在。Lam的数据没给具体百分比，不过"bad to horrifying"的定性描述，配合7微秒这个硬数字，足够让做高并发的人后背发凉。
一个8字节的原子操作，因为没对齐，把整台机器的内存子系统变成单车道。这事的荒诞之处在于：编译器不会帮你检查，运行时也不报错，只有延迟数字在尖叫。
为什么2025年还在踩这个坑
x86-64的缓存行64字节，原子操作8字节，理论上有7/64的概率跨行——如果地址随机分布的话。但真实代码里，结构体布局、内存分配器的对齐策略，让"意外跨行"比想象更常见。
英特尔和AMD的选择是硬件陷阱+软件缓解，而非彻底修掉总线锁。可能是硅片面积权衡，也可能是遗留兼容性包袱。Lam的测试暗示，Arrow Lake的架构对分裂锁的敏感度有特定模式，不是无差别打击。
对于写锁-free数据结构的开发者，这个测试是个提醒：原子操作的地址对齐不是"优化项"，是正确性的一部分。7微秒的惩罚，足够让精心设计的无锁队列退化成串行瓶颈。
Chester Lam的测试还在进行——原文截断处暗示更多数据待发布。下一个问题是：AMD的Zen 5会不会有同样的7微秒悬崖，还是找到了更优雅的退路？
热门跟贴