现代并发数据结构

• Lock-Free：系统级前进保证，但单个线程可能饥饿
• Wait-Free：每个线程都有界步数内完成
• 实现难度与工程取舍

两者都是无锁并发（无阻塞互斥锁）的实现。Lock-Free：保证整个系统在任意时刻必然有某个线程在有限步数内取得进展（系统级前进保证），但某个特定线程可能被无限推迟（饥饿），典型如 CAS 自旋循环。Wait-Free：更强的保证——每个线程在有限步数内必然完成自己的操作，不依赖其他线程的进度，即任何线程都不会被饿死。真正的 Wait-Free 实现极其困难，因为它要求每个操作在"其他线程可能无限干扰"的前提下仍保证有界推进，通常需要复杂的辅助机制（如帮助其他线程完成操作、读取时快照、用有限步完成发布），设计复杂度高、常量开销大、内存/同步开销昂贵。工程取舍：绝大多数生产系统用 Lock-Free（如 ConcurrentHashMap、无锁队列）即可，因为其保证已足够且实现简单、性能好；Wait-Free 仅在"最坏情况延迟必须严格有界"的实时系统、硬实时金融/网络场景中才值得，如抽取 RMW 的 wait-free 快照。

二者的本质区别是"前进保证的粒度"：Lock-Free 保证系统前进，Wait-Free 保证每个线程前进。Wait-Free 因要为每个线程提供有界推进，必须处理"并发冲突导致的重试"与"帮助他人"的复杂交互，所以极难实现且常数大。实际工程中 Lock-Free 的 OS 级调度已能避免极端饥饿，故成本收益比更优。

• 读锁共享、写锁互斥
• 写优先 vs 读优先的公平性
• 缓存一致性场景的取舍

读-写锁允许多个读者并发、写者独占，可显著提升读多写少的吞吐。关键在读者与写者的调度策略：读优先（读进入即允许后续读，直到当前写者完成）吞吐高但写者可能长期饥饿；写优先（有写者等待时，新读者被阻塞，等现有读者读完即让写者）保证写者不饥饿、公平性更好，但可能轻微降低读吞吐。缓存一致性场景：缓存往往是"读多写少"，但缓存失效（内存淘汰）与更新是低频写操作。若写操作罕见且可接受延迟，用读优先可最大化读吞吐；若更新频繁且要求写者及时获得锁（如缓存主动失效、避免读旧值过长），用写优先避免写者饥饿。实践中多数缓存采用"写优先 + 写者重入"或直接改用无锁读（如 COW、seqlock、RCU）来彻底消除读锁竞争。权衡要点是：写者多久能拿到锁、读者能否容忍一定延迟。

读-写锁的取舍本质是"读者吞吐"与"写者公平性"的平衡。缓存场景读多写少，写者饥饿是主要风险，故倾向写优先保证写者及时更新；若写极低频且可容忍，读优先更优。更彻底的是用无锁读结构（COW、seqlock、RCU）在读者侧完全去掉锁。

• 头指针与尾指针的含义
• size 计数法区分空与满
• 与 head==tail 法、浪费一格法的对比

环形缓冲用头指针（head，读位置）和尾指针（tail，写位置）管理，读写都沿环前进。判定空/满有多种方案：1) head == tail 判空，(tail+1) % n == head 判满（浪费一格，最多存 n-1 个元素）；2) 用独立计数 size 记录当前元素数，size == 0 为空、size == capacity 为满，读写时更新 size，这样能存满 n 个元素且判定清晰；3) 加额外标志位（is_full）。size 计数法的核心是：通过一个显式计数器就能唯一区分"空"（head==tail 且 size==0）与"满"（head==tail 且 size==capacity），避免 head==tail 同时表示空和满的歧义。代价是 size 需要原子更新（多线程下为 CAS 或专用计数器），但换来精确容量利用与简单判定。

环形缓冲的难点在于"环走到头回到起点"，空与满时头部位置相同（都是 head==tail），必须借助 size 或浪费一格来区分。size 计数法最直观、能满存 n 个元素，是单生产者单消费者（SPSC）与 Disruptor 等场景的常用做法；多线程下用原子 size 或对齐的 sequence 值实现。

• RCU 读者无锁、延迟回收
• 读写锁读者共享锁、写者阻塞
• 无锁结构用 CAS 无阻塞、无回收

三者都是并发读优化手段，但机制与边界不同。RCU：读者进入临界区无锁（仅内存屏障），读者可并发读旧数据；写者通过"复制-修改-发布"更新，旧数据在 grace period（所有读者退出临界区）后才回收。适合读极多、写极少、读者可容忍短暂读到旧值的场景（如内核路由表、Linux 文件系统）。读写锁：读者读时加共享锁，写者加独占锁、阻塞所有读者；读者侧有锁竞争（原子 RMW），但保证读者读到最新值且写者可见语义一致。适合写较频繁、要求读者看到最新更新的场景。无锁链表/队列：用 CAS 原子操作实现并发插入/删除，读者也需 CAS/遍历，无锁不阻塞，但需处理 ABA 与内存回收（Hazard Pointer/EBR）。适合读者写者都频繁、要求无阻塞且低延迟的场景。边界差异：RCU 的读者开销最小（无锁无原子操作），但写者要等 grace period 且读者可能读到旧值；读写锁读者有锁竞争但读最新；无锁结构读者开销高于 RCU 但有前进保证且无旧值问题。选型看读者成本、旧值容忍度、写频率。

三者的本质差异是"读者如何读"与"旧数据如何回收"。RCU 用"发布 + 延迟回收"让读者零锁；读写锁用锁保护临界区保证最新；无锁结构用 CAS 保证无阻塞前进。RCU 适合读者极多且容忍旧值，读写锁适合需最新值，无锁适合高并发无阻塞。

• 序列号 + 读后校验
• 读者重试、写者非阻塞
• 写者饥饿与缓解

Seqlock 用一个偶数递增的序列号（sequence）和写锁配合。读者：读序列号（需为偶数），复制数据，再读序列号并与之前比较；若两次一致（且为偶数）说明读期间无写者，数据有效；若不一致则需要重读。写者：取写锁（自旋），序列号加 1（变奇数），写数据，序列号再加 1（变偶数），释放写锁。读者无锁、无原子 RMW，只有两个普通读 + 一个比较，开销极低，非常快。适合读多写少：读者无锁竞争，可无限并发读，吞吐极高；写者独占写。写者饥饿问题：因为读者不加锁、不参与，写者等待读者时读者不会主动让位，若读者持续重读，写者可能长期抢不到写锁。缓解方式：限制读者重试次数（读到脏数据返回失败而不是无限重试）、写者加退避，或采用"写者定期自旋/读者让位"的公平性策略，以及在大多数实现中读者重试很快（一次写很小），实际饥饿概率低。

Seqlock 的启发是"读者用两次读序列号校验替代锁"，把读者成本降到近乎零。写多时读者会频繁重试、浪费 CPU，故只适合读多写少。写者饥饿是读者无锁的副作用，通过限制重试次数与写者退避缓解。

• LinkedBlockingQueue 的锁与节点分配开销
• Disruptor 的环形缓冲 + 序号屏障
• 预分配、无锁、伪共享规避

MPMC 队列要支持多个生产者并发写入、多个消费者并发读取，难点是保证并发安全与顺序。LinkedBlockingQueue用锁保护链表（取出与放入各一把锁），每次操作要加锁、分配/释放节点、触发锁竞争，且链表节点分散在内存中破坏缓存局部性，吞吐受限。Disruptor 的 Ring Buffer更快的原因：1)预分配环形缓冲：固定大小数组 + 预分配事件槽，复用对象、避免 GC 分配与节点释放；2) 无锁 + 序号（sequence）：生产者/消费者用单调递增的序号定位槽位，用 CAS 或单生产者/单消费者模式（无 CAS）推进，避免锁竞争；3) 序号屏障（Sequence Barrier）：读者通过序号判断可读范围，生产者通过序号判断可写空间，无需锁；4) 缓存行填充：把每个生产者的序号、消费者序号用 padding 隔离到独立缓存行，规避伪共享（false sharing）；5) 批量处理：一次可取/发布多个事件，减少同步次数。这些让 Disruptor 在单生产者+单消费者下可达到极低延迟、极高吞吐。

Disruptor 与 LinkedBlockingQueue 的差距来自设计哲学：前者用"预分配 + 无锁序号 + 缓存行填充 + 批量"把每个操作的锁、GC、缓存一致性开销降到最低；后者用锁 + 动态节点，简单易用但开销大。Disruptor 适合超高吞吐、低延迟的金融/事件流场景。

• COW 通过复制+原子发布实现读无锁
• seqlock 通过序列号校验实现标量读一致性
• 引用语义 vs 标量语义的适用

COW：写者复制整个数据结构，修改副本，最后用原子指针（如 atomic<shared_ptr>）发布新版本；读者只需原子读取当前指针，无需加锁、无需等待，读到的是某个完整一致的版本。COW 适合"数据结构较大、读方需要拿到一致的对象引用"的场景（如配置快照、路由表、不可变快照），因为读者拿到的是不可变快照引用，可安全无限使用。Seqlock：读者通过两次读序列号校验一套标量数据的一致性，适合"读的是少量标量/紧凑结构（如缓存的最近时间戳、配置数值）"且读方通过值拷贝使用的场景。选择依据：COW 用"原子指针 + 复制"换取读者拿引用，代价是写放大（每次写全量复制）；seqlock 用"序列号 + 重试"换取标量读零复制，代价是写者阻塞与读者重试。COW 不适合标量频繁读（复制开销大），seqlock 不适合大对象（读者重试复制成本高）。故"COW 配原子引用、seqlock 配标量读"是按数据结构形态与使用方式匹配。

两者的共同点是"读者无锁"，但机制不同：COW 靠"复制+原子发布"让读者拿到不可变快照，适合引用型/大对象；seqlock 靠"序列号校验"让读者验证标量复制的一致性，适合标量/紧凑数据。选型的关键是"读者读的是引用还是值"以及"数据大小与写放大成本"。

• 单一执行者线程串行处理所有操作
• 其他线程发布操作并等待结果
• 减少锁竞争与缓存行乒乓

Flat Combining（扁平合并）是一种并发数据结构技术：每个时刻只有一个线程担任"执行者（combiner）"，它持有锁并批量处理队列中所有已提交的操作；其他线程不直接操作数据结构，而是把操作提交到一个发布队列（publication list），然后等待执行者处理并返回结果。这样，原本多线程对数据结构的竞争，被转化为"单一执行者串行处理一批操作"，从而大幅减少锁竞争与缓存行乒乓（cache-line ping-pong）。其收益：1) 批量操作摊薄同步开销；2) 执行者连续访问数据结构，缓存局部性好；3) 竞争线程的 CAS 只发生在发布队列上，避免对共享数据的原子操作。它特别适合"操作执行成本低、竞争激烈"的数据结构（如队列、栈、计数器），当并发度很高时吞吐可显著优于普通锁或无锁实现。

Flat Combining 的核心洞察是"数据结构内部操作本身很快，瓶颈在锁竞争与缓存一致性"，于是把"操作执行"集中到一个线程，其余线程只做发布与等待。它把并发计算转化为"串行批处理 + 并行发布"，在竞争激烈时大幅提升吞吐，但依赖操作粒度小、可批量。

• 读无锁、一致性快照
• 写全量复制带来的写放大
• 适用边界与不适用的场景

COW 容器的核心理念是"写时复制"：读者无锁读取当前版本，写者复制整个容器并在副本上修改，再原子发布。收益：读多写少时，读者完全无锁、无竞争、可无限并发，且每个读者拿到的是某个一致版本的完整快照，无需锁即可保证一致性；读路径无锁无原子操作，吞吐极高。写放大代价：每次写都需要复制整个容器（O(n) 复制成本），写越频繁、容器越大，代价越高；同时旧版本需在读者都释放后回收（内存浪费）。适用边界：适合"读频率远高于写、容器中等大小、写罕见"的场景（如配置快照、字典、不可变映射、共享指针）；不适合"写频繁或容器超大"的场景（复制成本爆炸）以及"需要大量写一致内存"的场景。实现上常配合 atomic<shared_ptr> 或 shared_ptr 的 copy-on-write 语义，或用 std::shared_mutex 做读共享。

COW 的收益与代价都在"复制"上：用"写全量复制"换"读者零锁 + 一致快照"。它把读与写彻底解耦，但写放大是其固有代价，因此只适合读多写少、容器可控的场景。选型时应评估写频率与容器大小，写放大超过收益时改用读写锁或 seqlock。

• 活锁：CAS 反复失败但系统未死亡
• 强竞争下 CAS 循环互相冲突
• backoff 与批次化缓解

活锁（livelock）：多个线程都在运行、都在尝试 CAS，但互相失败重试，系统整体无法取得进展，区别于死锁（无进展+无运行）。无锁队列靠 CAS 循环（如 Michael-Scott 队列的入队 CAS）推进，在强竞争下，多个生产者同时 CAS 同一个尾指针，只有线程 A 成功，其余线程 CAS 失败后立即重试，再次与其他线程竞争，形成"互相干扰、反复重试"的活锁状态，可能长时间无法前进。缓解：1) backoff（退避）：CAS 失败后先随机或指数退避（sleep/yield 若干时间）再重试，让竞争线程错开，减少同时碰撞的概率，类似 CSMA 的拥塞控制；2) 批次化（batching）：把多个操作合并为一次 CAS（如一次把多个元素链接进链表再发布），减少 CAS 次数与竞争窗口；3) 结合"组合"（如 Flat Combining）让单线程集中处理，或使用更强的无锁协议（如帮助机制）。这些方法降低竞争强度，使 CAS 成功概率上升。

活锁的本质是"过分积极的即时重试"放大了竞争。退避通过随机错开降低碰撞概率，批次化通过减少 CAS 次数缩小竞争窗口，都是"牺牲一点延迟换取整体推进"的经典手段。工程上无锁结构常配合退避与批次控制竞争。

• 空与满时 head 与 tail 的位置关系
• "头==尾"的歧义
• 额外标记（size 计数/标志位/浪费一格）的区分

环形缓冲中，头指针（head）和尾指针（tail）都沿环前进。空时 head == tail（读与写位置重合，无数据）；满时若允许存满 n 个元素，写满一圈后 tail 也回到 head，即 head == tail。因此单靠"head == tail"无法区分"空"与"满"两种状态，二者在指针上完全一致，存在歧义。解决方式需要额外标记：1) size 计数法：维护一个元素计数，size==0 判空、size==capacity 判满，可精确区分且能存满容量；2) 浪费一格法：head==tail 判空，(tail+1)%n==head 判满，牺牲一个槽位，无需额外字段；3) 标志位：加一个 is_full 位，与 head/tail 联合判断。本质是"指针状态不足以表达容量是否用尽"，需要 size 或标志位补充容量信息。

环形缓冲的状态空间里，空与满对应相同的指针位置，这不是指针的疏忽，而是"环的容量信息"没有单独表达。引入 size 或浪费一格（让满时 tail 与 head 差一格）实质是给状态空间增加区分维度，从而消除歧义。

• 路由表（路由查找）的读优化
• 文件系统（dentry/inode）的读优化
• RCU 延迟回收保证指针安全

RCU 非常适合内核中"读极多、写极少"的数据结构。路由表：Linux 内核的路由查找（ip_route_output / fib_lookup）在数据包转发路径上调用极频繁，是性能关键路径。内核用 RCU 保护路由表/路由缓存（路由规则、fib 表），读者在路由查找时无锁遍历，写者（更新路由、添加/删除路由条目）通过 RCU 替换并延迟回收旧表，从而让数据包转发不必加锁。文件系统：路径解析使用的 dentry（目录项）缓存、inode 缓存、open/stat 等操作大量使用 RCU。典型如 dentry 的查找（d_lookup）、inode 引用、struct file 与 files_struct 的 fd 表更新，以及 mount 表、namespace 的读优化。机制：读者进入 RCU 临界区（rcu_read_lock）无锁读取指针；写者更新指针后，通过 synchronize_rcu() 等待所有读者退出临界区（grace period），再 kfree_rcu 安全回收旧对象。这样内核关键路径获得了无锁的读性能。

RCU 之所以被内核广泛采用，是因为转发/路径解析是超高频读路径，"读者无锁"是巨大收益。其正确性由"读临界区 + 写后延迟回收"保证：写者发布新指针后，grace period 确保旧指针不再被任何读者引用才回收。路由表、dentry、inode、fd 表都是"读多写少"的典型。

• 延迟释放：不立即回收仍被引用的对象
• RCU 的 grace period 与 GC 的追踪
• 识别"无人引用"的时机

二者的核心相似点是"延迟释放"：不立即回收可能仍被并发使用的对象，而是等到确认"没有任何并发读者/引用者"后才安全回收。RCU：写者更新指针后不立即 free 旧对象，而是等待 grace period（所有读者退出临界区）确认无人再引用旧指针，才回收——"延迟释放"由读临界区与周期同步保证。GC：用户程序释放引用后，对象并未立即被回收，而是等 GC 在某个方便的时刻遍历根集合，确认对象不可达后才回收——"延迟释放"由可达性分析保证。两者都意识到"内存回收要等待并发使用者离开"，都把"何时安全"的判断与"具体回收"解耦。区别在于：RCU 的"安全判断"依赖读者主动声明临界区（显式协议），回收时机由写者控制；GC 的"安全判断"由 GC 追踪可达性自动完成，回收时机由 GC 决定。二者理念相通：为并发安全而延迟回收，用"等待不再被引用"换取安全。

延迟释放是共享内存并发系统的通用思想：直接释放仍在并发读取的对象会导致 use-after-free。RCU 用 grace period 显式等待读者，GC 用可达性追踪自动判断，本质都是"确认无人引用再回收"。理解这一共同点有助于理解 RCU 的回收时机与 GC 的暂停语义。

• 内核读多写少数据结构的无锁读
• 网络路由、文件系统、网络协议
• 通用读多写少场景的适用

Linux 内核中的典型应用：1) 网络子系统——路由表查找（fib）、IPv4/IPv6 路由、netfilter、连接跟踪（conntrack）都以 RCU 保护；2) 文件系统——dentry 缓存、inode 缓存、files_struct 的 fd 表、mount 表；3) 进程——task_struct 的线程组遍历、pid 查找；4) 其他——syscall 表、cgroup、sock 地址查找。这些结构都是"读极多、写极少"，RCU 让读者在关键路径上无锁。通用读多写少场景：RCU 也适用于任何"读远多于写、读者可容忍短暂读到旧值、写者能接受延迟回收"的共享结构，如配置表、指针数组、订阅列表、心跳表等。典型用法：读者 rcu_read_lock() 后无锁读，rcu_read_unlock() 退出；写者复制-修改-发布新指针，synchronize_rcu() 等 grace period 后 kfree_rcu() 回收。限制：写者不能阻塞在临界区、读者不能睡眠在临界区、需容忍旧值，故不适合写频繁或强一致场景。

RCU 的适用范围由"读者无锁 + 写者延迟回收 + 容忍旧值 + 写者少见"四个条件决定。Linux 内核的路径查询、文件系统查找正是满足这些条件的典型，故 RCU 成为内核最常用的并发读优化手段。通用场景只要满足读多写少 + 容忍旧值，即可借鉴 RCU 思想。

• 写者开销被低估
• 回收时机（synchronize_rcu）的代价
• 临界区限制与旧值容忍

常见误区包括：1) 低估写者开销：很多人以为 RCU 读者无锁就"免费"，但写者要复制-修改-发布，且 synchronize_rcu() 要等待所有读者退出临界区，在读者多或临界区长时，写者可能长时间阻塞，写路径并不便宜；2) 回收时机错误：写完发布指针后必须等 grace period 才能 kfree 旧对象，若过早释放会导致 use-after-free；反之若每次写都 synchronize_rcu() 则写延迟极大，应用 call_rcu/kfree_rcu 异步回收或用版本号延迟释放；3) 在临界区内做耗时操作：读者在 rcu_read_lock 内若睡眠/阻塞/调用可能阻塞的操作，会拖长 grace period、阻塞写者；4) 忽略旧值容忍：RCU 读者可能读到旧指针，若业务要求强一致则不能用 RCU；5) 忘掉内存屏障：发布与读取需要正确配对内存屏障，否则编译器/CPU 重排导致坏数据。缓解：用 call_rcu 异步批量回收、限制临界区长度、按需用 synchronize_rcu + 尽量合并回收。

RCU 的"免费"只在读路径；写路径的复制与回收同步是真实成本。科学使用需理解：写者延迟回收的时机由 grace period 决定，临界区必须短、不可阻塞，业务必须容忍旧值。把"读者无锁"误读为"零成本"是最大的误区。

• 读侧临界区（rcu_read_lock/unlock）
• 宽限期（grace period）与读者退出
• 回收时机：grace period 结束后

RCU 的三个核心概念：1) 读侧临界区（read-side critical section）：读者用 rcu_read_lock() 进入、rcu_read_unlock() 退出的一段区域，期间读者可无锁读取共享指针，但不可阻塞/睡眠；2) 宽限期（grace period）：从"写者发布新指针"到"所有在该发布前已进入的读者都退出临界区"的这段时间。一个宽限期结束意味着"不再有任何读者引用旧指针"；3) 回收（reclamation）：宽限期结束后，写者才安全地 kfree/free 旧版本对象。关系：写者在发布新指针前复制旧数据生成新版本，发布后旧版本仍可能被某些读者读取，因此必须等待一个宽限期（所有读者退出临界区）确认旧指针无人引用，才能回收旧对象。synchronize_rcu() 同步等待一个宽限期结束，call_rcu()/kfree_rcu() 异步登记回调、在宽限期后执行。宽限期长短取决于读者临界区的长度与数量，临界区越短，宽限期越短、写者等待越短。

RCU 正是"读临界区界定读者引用窗口 + 宽限期等待引用消失 + 回收释放内存"三位一体的协议。读者声明"我在用旧指针"（临界区），写者等"没人再用"（宽限期）再"释放"（回收）。正确理解三者关系是安全使用 RCU 的前提。

• 读多写少使读者无锁收益大
• 延迟回收：写者等待 grace period
• 不适用场景

RCU 的适用前提是"读多写少"且"写者能容忍延迟回收"。读多写少：读者无锁、无原子操作、无竞争，吞吐极高，读频率越高收益越大；写少意味着复制-发布-回收的写成本占比低，整体收益显著。写者容忍延迟回收：写者更新后不能立即释放旧对象，必须等宽限期（所有读者退出临界区）才能回收，因此写者要么阻塞等待（synchronize_rcu），要么接受旧对象延迟数毫秒/秒级才被异步回收（call_rcu），内存暂时不能立即复用。若写者要求立即释放、内存要求严格，则 RCU 不适用。不适用场景：写频繁（复制/回收成本爆炸）、读者必须读到最新值（RCU 可能让读者读到旧指针）、临界区需阻塞/睡眠（不可）。典型适用：内核路由表、dentry 缓存、订阅列表、配置表——读极多、写极少、读者容忍短暂旧值、写者接受延迟回收。

"读多写少"让读者无锁的收益最大化，"写者容忍延迟回收"让 RCU 的延迟释放模型可接受。RCU 本质是"用写者的延迟回收，换读者的无锁读"，因此这两个前提缺一不可，是判断 RCU 是否适用的试金石。

• Michael-Scott 队列的入队/出队 CAS 循环
• ABA 问题的成因
• Hazard Pointer 与 EBR 的内存回收

Michael-Scott 队列用带头尾指针的链表，入队用 CAS 把新节点接到尾节点后并推进 tail，出队用 CAS 弹出头节点。其 CAS 循环遇到竞争时重试，问题是ABA 问题：线程 A 读到的指针值 P，在 A 被抢占期间，其他线程把 P 释放、再创建新对象且恰好占用同一地址（值又回到 P），A 恢复后 CAS 比较"值等于 P"而误判成功，实际指向的对象已被重用，导致错误。解决 ABA 的内存回收：1) Hazard Pointer（危险指针）：每个线程在读取共享指针前，把该指针登记到自己的危险指针槽（Hazard Pointer），CAS 或释放前先检查该指针是否被任何线程登记为危险，若被登记则推迟回收。它按"单个指针"粒度保护，实现中等复杂，需要维护 per-thread 槽位；2) Epoch-Based Reclamation（EBR，基于时代）：把时间划分为时代（epoch），线程在临界区进入当前时代，退出时若发现自己是最晚的则推进时代；只有当所有线程都离开旧时代（即时代可以被安全回收）时，才回收那些时代中被释放的对象。它按"时代"批量回收，实现较简单、开销较低，但要求读者定期退出（无界延迟问题）。两者都解决"被其他线程并发引用的对象被提前释放"的 ABA/use-after-free。

ABA 的根源是"内存被重用导致地址值回绕"。Hazard Pointer 用"声明式保护"防止被引用对象被回收，EBR 用"时代批量回收"延迟释放。前者细粒度、延迟低，后者实现简单、开销小，是 Lock-Free 结构中解决 ABA 的两大主流方案。

• 读-复制-更新三步
• 读路径无锁的原理
• Grace Period 与安全回收

RCU 的核心思想是"读-复制-更新"：写者不修改共享数据，而是复制一份、在新副本上修改、再原子发布新指针；读者无锁读取当前指针。读路径无锁：因为读者只读"当前指针"且该指针指向一个完整一致的版本，不与其他读者竞争；写者改变的是指针本身（原子发布），不修改读者正在读的旧数据，因此读者无需锁。Grace Period 确定安全回收时机：写者发布新指针后，旧指针仍可能被一些读者引用；一个宽限期（grace period）是"所有读者退出临界区"所需的时间。当宽限期结束（synchronize_rcu() 返回或 call_rcu 回调触发），意味着旧指针不再被任何读者引用，此刻才安全回收旧对象。Linux 内核应用：路由表查找、dentry/inode 缓存、fd 表、网络协议栈（conntrack）等读多写少结构用 RCU 实现无锁读 + 延迟回收。

RCU 的"读无锁"本质上通过"写者惰性化（复制+发布）"实现：读者永远读最新或旧的全量版本，写者从来不在原处改数据，故读与写不冲突。安全回收由"读者退出临界区"界定，grace period 是连接"发布"与"回收"的桥梁。这是 RCU 与锁、无锁结构最大的区别。

• 跳表 vs 红黑树的实现复杂度与并发
• Redis ZSET 选跳表的原因
• 并发跳表的锁粒度与定位

**跳表（Skip List）**用多层有序链表实现平衡查找，平均 O(log n)，实现简单、无旋转、易并行。Redis ZSET 选跳表而非红黑树：1) 实现简单、调试容易，ZSET 需要按 score 排序、按 member 查找、范围查询、前驱/后继操作，跳表在这些操作上实现直观；2) 跳表天然支持范围查询与 score 排序（红黑树需要额外遍历）；3) 跳表对并发友好（多个层可独立加锁），而红黑树旋转会破坏并发一致性；4) 工程上跳表更易维护与验证。并发跳表的锁粒度：常见两种——per-node 锁（每个节点一把锁，锁粒度细，但插入/删除需在多层上协调，锁翻转复杂）与 per-level 锁（每层一把锁，实现简单，但层间竞争可能死锁需排序）。实践中常用"细粒度 + 乐观定位"：先用无锁/乐观方式定位到目标层，再对涉及节点加锁做修改，或用 CAS 实现无锁跳表（如 Java ConcurrentSkipListMap 用 CAS + 无锁搜索）。锁粒度选择本质是"并发度"与"实现复杂度"的权衡。

跳表受欢迎是因为"简单 + 并发友好 + 支持范围操作"。Redis 选跳表是工程权衡（分数排序、范围查询、实现简单）；并发跳表的锁粒度决定竞争程度，per-node 更细但复杂，per-level 更简单但需处理层间锁序，Java 的 CAS 无锁实现则彻底消除锁。

• Treiber 栈：单指针 CAS
• Michael-Scott 队列：头尾双指针 CAS
• dummy 节点解决空队列歧义

Treiber 无锁栈：只有一个栈顶指针，入栈 push 用 CAS 把新节点链到栈顶，出栈 pop 用 CAS 弹出栈顶（需处理 ABA）。Michael-Scott 队列：有头（head）和尾（tail）两个指针，入队 CAS 到尾、出队 CAS 从头。栈比队列简单：栈只有一个"入口"（栈顶），push/pop 都只改一个指针，CAS 循环简单；队列有头尾两个指针，入队与出队牵涉 tail 与 head 的互动，且当队列为空时 head 与 tail 指向同一节点，操作复杂，还要处理"出队时 head 与 tail 重合"的边界，CAS 循环更复杂。队列需要 dummy 节点：空队列时 head 与 tail 都指向同一个哨兵节点（dummy），这样出队时若 head 追上 tail 说明队列为空，不会误删；若没有 dummy，空队列时 head、tail 指向 NULL，出队/入队会出现 head==tail==NULL 的歧义与 CAS 竞争。dummy 节点让 head 与 tail 的关系有明确不变量，简化了空满判断与 CAS 条件。

栈只有一个栈顶，所有操作都集中在一个指针，天然简单；队列双指针 + 空/满边界需要更精细的不变量。dummy 节点作为"永不为空"的哨兵，让 head 与 tail 的推进有稳定基准，是 Michael-Scott 队列正确性的关键。

• Hazard Pointer：per-thread 危险指针槽
• EBR：时代批量回收
• 内存开销与适用场景

Hazard Pointer：每个线程在读取共享指针前，把该指针登记到自己的危险指针槽（Hazard Pointer slots），释放者回收前检查该指针是否被任何线程登记为"危险"，若被登记则推迟回收。内存开销：每个线程需要固定数量的槽位（通常每线程若干槽），开销随线程数线性增长，且被保护指针的回收可能要等所有线程都越过使用点，可能延迟回收。适用：适合"指针数量中等、回收延迟敏感、需要精确保护"的场景，实现中等复杂。EBR（基于时代）：把时间划分为时代，线程进入临界区时声明当前时代，退出时若自己是最晚的则推进时代；只有当所有线程都离开某个旧时代，才回收该时代释放的对象。内存开销：只需少量全局时代计数器（每线程一个 epoch 标记），开销小，但回收粒度是"时代"，若某线程长时间不退出临界区，会阻塞整个时代的回收，造成内存延迟增长。适用：适合"读临界区短、线程数多、能接受按时代批量回收"的场景，实现简单、开销低。对比：Hazard Pointer 按指针精确保护、延迟低但开销大；EBR 按时代批量回收、开销小但可能延迟大。选型看"回收延迟 vs 内存开销"的权衡。

Hazard Pointer 以"精确到指针"的保护换"低延迟回收"，代价是每线程槽位开销；EBR 以"时代粒度"的批量回收换"低开销"，代价是可能因懒惰线程延迟回收。二者都是"延迟释放"思想在无锁结构中的落地，按延迟与开销预算选择。

• JDK 7 分段锁 → JDK 8 CAS+synchronized
• C++ TBB concurrent_hash_map
• Rust DashMap 的 shard 设计

Java ConcurrentHashMap：JDK 7 用"分段锁"（segments，每段是一把 ReentrantLock，通过分段降低竞争），但并发度受段数限制；JDK 8 改为"桶级别 CAS + synchronized"：初始化桶用 CAS，桶内冲突时对该桶的链表头加 synchronized 锁，无锁时用 CAS 更新，并发度提升到桶粒度，且用 sizeCtl 控制扩容、链表长度超阈值转红黑树（TREEIFY_THRESHOLD）优化最坏查找。C++ TBB concurrent_hash_map：用"分桶 + 每桶锁"的粗粒度分段，配合引用计数与并发接口，提供线程安全访问、迭代器安全，牺牲部分并发度换取简单与可迭代保证。Rust DashMap：用"分片（shard）"设计，把桶数组分成多个 shard，每个 shard 一把锁（或 RwLock），通过 hash 定位到 shard 再加锁，减少锁竞争；结合 Rust 的所有权与借用保证内存安全，提供并行迭代。三者都通过"分片/分段降低锁竞争"，但实现的锁粒度与并发保证不同：Java 8 最细（桶 CAS+锁）、TBB 粗粒度、DashMap 分片 RwLock。

并发 hash map 的演进主线是"缩小锁/同步粒度"：JDK 7 段锁 → JDK 8 桶 CAS+锁，TBB 分桶锁，DashMap 分片锁。粒度越细竞争越小、吞吐越高，但实现复杂度与内存/锁开销上升。选择取决于语言生态与并发模型。

• 单生产者/单消费者无 CAS 的推进
• 序号隔离与缓存行填充
• 伪共享原理与规避

Disruptor 的单生产者/单消费者（SPSC）无锁模型：生产者只有一个、消费者只有一个时，通过相邻序号（sequence）推进即可，无需 CAS——生产者写槽位后推进自己的序号，消费者读该序号判断可读范围，两者各自维护序号，无锁、无竞争，达到最低延迟。多生产者/多消费者时用 CAS 或额外同步。伪共享（false sharing）规避：多个不同线程频繁访问的变量（如生产者序号、消费者序号、缓冲槽）若落在同一缓存行（64 字节），任一线程写会令该缓存行在其他核上失效，导致缓存一致性流量（缓存行乒乓），吞吐骤降。Disruptor 用缓存行填充（padding）：在序号前后填充足够字节（如 56 字节 padding）使每个序号独占一个缓存行，生产者序号与消费者序号物理隔离，避免互相触发缓存失效。结合：单生产者/消费者无锁 + 缓存行填充，使 Disruptor 在极端场景下达到极低延迟与极高吞吐。

Disruptor 速度的两大支柱是"无锁序号推进"（省去锁与 CAS 开销）与"缓存行填充"（规避伪共享的缓存一致性开销）。伪共享是隐藏的杀手，padding 把热变量隔离到不同缓存行，是低延迟高性能代码的关键技巧。

• 分段锁 → 桶级别 CAS+synchronized
• sizeCtl 控制扩容阈值
• 链表转红黑树优化

Java 8 的 ConcurrentHashMap 相比 JDK 7 有重大演进：1) 锁粒度：放弃 JDK 7 的分段锁（segment），改为桶级别 CAS + synchronized——桶为空时用 CAS 初始化头节点，桶非空时对该桶头节点加 synchronized 锁（细粒度锁），无锁读与 CAS 写结合，并发度从"段数"提升到"桶数"，竞争更小；2) sizeCtl：一个 volatile 字段，负值表示扩容/初始化进行中，等于 -1 表示初始化，负值绝对值表示扩容线程数；正数表示扩容阈值（容量 * 负载因子）；扩容时通过 sizeCtl 协调多线程协助扩容（多线程并发迁移桶），由 sizeCtl 控制扩容的启动与进度；3) 红黑树退化优化：当桶内链表长度超过 TREEIFY_THRESHOLD（8）且容量达标时，把链表转为红黑树（TreeBin），把最坏查找从 O(n) 降到 O(log n)，应对恶意 hash 冲突；扩容或某桶长度降回 UNTREEIFY_THRESHOLD 时再退化为链表。这些优化使 JDK 8 的并发展开、扩容并发、冲突处理都更高效。

JDK 8 的演进主线是"更细的锁粒度 + 并发的扩容 + 冲突的树化"。桶级 CAS+synchronized 把竞争降到桶粒度，sizeCtl 让扩容多线程协作，红黑树缓解极端 hash 冲突。这些共同提升高并发下的吞吐与最坏情况延迟。

• 多生产者/消费者并发推进指针
• CAS 保证原子更新
• ABA 问题与内存回收

MPMC 无锁队列中，多个生产者和消费者并发操作同一个共享指针（如尾指针、头指针），必须用 **CAS（Compare-And-Swap）**原子地"读取-比较-写入"，才能保证只有一个生产者能成功推进尾指针、只有一个消费者能成功弹出头节点，避免多个线程同时修改同一指针导致数据错乱。CAS 失败则重试，形成无锁循环。ABA 问题：线程 A 读取尾指针值 P，被抢占期间，线程 B、C 完成了 pop 释放节点并用新节点复用同一地址，使指针值又回到 P（值回绕），A 恢复后 CAS 发现"值等于 P"而盲目成功，实际指向的对象已被重用/改变，导致错误。解决：用带版本号的 CAS（Double-CAS / 在指针高位附加版本计数）、Hazard Pointer 或 Epoch-Based Reclamation 保护内存回收，防止被并发引用的节点被提前释放。多生产者场景比单生产者更易触发 ABA，因为竞争更多、释放与重用的交错更频繁。

MPMC 队列的并发正确性依赖 CAS 的原子"比较-写入"，而 ABA 是"值回绕导致误判"的固有风险，尤其在内存被释放重用时。结合版本号或延迟回收（Hazard Pointer/EBR）是标准解法，若无锁结构不处理 ABA 会引入 use-after-free 类错误。

• SPSC 无竞争、无 CAS
• 环形缓冲 + 序号
• 内存屏障保证数据可见性

SPSC 无锁队列只有"一个生产者 + 一个消费者"，二者操作不同的指针（生产者写尾、消费者读头），不存在同一指针的并发竞争，因此不需要 CAS 或锁，只需用**内存屏障（内存序）**保证数据可见性。典型实现是环形缓冲 + 序号：生产者写入槽位后，用 release 语义（写屏障）发布自己的序号，表示"数据已就绪"；消费者用 acquire 语义（读屏障）读取生产者序号，确认数据已发布后再读取数据。内存屏障的作用：在无锁共享内存中，编译器和 CPU 可能重排读写、或数据尚未同步到缓存，导致消费者读到"序号已更新但数据未写入"的脏数据。release 屏障保证"前面的写操作（写数据）在序号发布前完成并可见"，acquire 屏障保证"读到序号后，后续读操作能看到已发布的数据"。这样消费者能安全地读到生产者发布的数据，无需锁。正确使用 acquire/release 序（或 std::atomic 的相应序）即可实现无锁的 SPSC 环形缓冲，达到极高的单线程吞吐。

SPSC 之所以无锁，是因为"生产者与消费者访问不同的指针、无竞争"，唯一的同步需求是"生产者发布的数据对消费者可见"，这正是 acquire/release 内存序解决的。相比 MPMC，SPSC 少了 CAS 与竞争，靠屏障即可正确，是高性能队列（如 Disruptor 的 SPSC 模式）的基础。

• 低延迟、无阻塞、高吞吐
• 无锁带来的调试与维护难度
• 收益与风险的权衡

真实收益：1) 低延迟：无锁队列避免锁获取、锁等待与上下文切换，在高频交易（订单撮合、行情推送）中延迟能降到微秒级，避免锁竞争导致的抖动；2) 高吞吐：消除锁竞争与缓存行乒乓，多生产者/消费者场景吞吐更高；3) 无阻塞：无锁结构不阻塞线程，避免锁等待导致的优先级反转、死锁，实时性更好；4) 低抖动：无锁的延迟更加稳定，适合对延迟方差敏感的金融/日志管道。调试难度：1) 难以复现：无锁 bug 依赖并发时序，偶发难复现；2) 内存回收难：ABA、use-after-free 需要 Hazard Pointer/EBR 等复杂回收，出错极难定位；3) 内存序错误：acquire/release/屏障搭配错误会引入偶发脏数据，编译器与 CPU 重排难以肉眼排查；4) 工具支持弱：传统调试器/锁分析工具对无锁结构无效，需专门的压力测试、TSan/ASan、模型检查。权衡：无锁的高性能收益显著，但正确性与维护成本高，通常只在性能关键路径（高频交易、日志管道）使用，其余场景用锁更划算。

无锁的价值在"锁是主要瓶颈"的场景（高频交易、日志管道）中才充分体现：低延迟、高吞吐、无阻塞。但其代价是验证与调试极难，需要严格的并发测试与专业工具。因此工程上"只在关键路径用无锁，其余用锁"是务实选择。

• ABA 问题的成因
• 版本号法（带版本计数）
• 双字 CAS（128 位原子）

ABA 问题：线程 A 读到指针值 P，被抢占期间，B 和 C 并行操作：B 释放 P 对应对象、C 创建新对象恰好占用同一地址，使值又回到 P，A 恢复后 CAS 比较"值等于 P"而误判成功，实际对象已被替换。解决：1) 版本号法：CAS 比较"指针 + 版本计数"两个值，只有指针和版本号都匹配才成功。每次修改指针时版本号 +1，即使地址重新被用，版本号不同，CAS 也会失败。Java 的 atomic 常用 AtomicStampedReference（带时间戳）实现；C++ 可在指针高位嵌入版本号或配合 std::atomic 规避。2) 双字 CAS（Double-CAS / DCAS）：把"指针 + 版本号"（或两个相关字段）打包成一个 128 位原子单元，用 CPU 的 128 位 CAS（如 cmpxchg16b）一次原子比较与写入两个值，从而在"指针值 + 版本号"同时匹配时才算成功。这样既避免拆分字段的中间态，又让版本号随指针一起原子更新，彻底解决 ABA。两种方法本质都是"在比较中引入额外信息（版本号）打破地址回绕的歧义"。

版本号/Double-CAS 的共性是"给共享指针增加一个随每次修改递增的版本维度"，使"地址相同但已换代"被识别为不匹配。版本号法实现简单、兼容性好；双字 CAS 用 128 位原子保证两个字段一体更新，是硬件层面的强解法。

• 无锁环形缓冲
• 序号屏障协调生产/消费
• 预分配与批量处理

Disruptor 的核心是无锁环形缓冲（ring buffer）+ 序号屏障（Sequence Barrier）。ring buffer：预分配的固定大小数组，事件槽预先分配、复用，避免 GC 与动态分配；生产者与消费者通过"序号（sequence）"定位槽位。序号屏障：生产者依据自己可写的序号（相邻生产者或消费者进度）判断可写范围，消费者依据生产者序号判断可读范围，通过共享序号（Sequence）与屏障协调，避免越界读写。无锁实现：单生产者/消费者场景直接用相邻序号推进，无需 CAS；多生产者用 CAS 抢占序号。高吞吐来源：1) 无锁无竞争，减少锁与上下文切换；2) 预分配环形缓冲，避开 GC 与节点分配；3) 缓存行填充规避伪共享；4) 批量处理——一次可消费/发布多个事件，减少同步次数；5) 序号屏障让生产者/消费者精确同步，避免等待与重试。这一组合让 Disruptor 在事件驱动的高吞吐场景（金融撮合、日志）达到超低延迟。

Disruptor 把"缓冲区管理"与"并发控制"分离：ring 负责存储，序号屏障负责生产者/消费者的同步边界。无锁 + 预分配 + 缓存行填充 + 批量，四者叠加成就了其高吞吐。序号屏障是"无锁协调"的关键，取代了锁的等待-通知机制。

• acquire/release 语义
• 数据可见性与重排控制
• 无锁结构正确性的基础

在无锁（lock-free）结构中，没有锁来隐式同步内存，因此需要**显式内存序（memory order）**保证多线程间数据可见性与顺序。release 语义：写者在发布共享数据（如更新指针、写入序号）时使用 release，保证"该写之前的所有写操作"在 release 写之前完成并对其他线程可见，即 release 之前的写入不会重排到 release 之后。acquire 语义：读者在读取共享数据（如读序号、读指针）时使用 acquire，保证"该读之后的所有读操作"在 acquire 读之后，不会重排到 acquire 之前，从而读到 release 发布的数据后能看到其之前的所有写入。作用：release 与 acquire 配对，形成"发布-获取"同步：写者 release 发布数据，读者 acquire 读取后即可安全看到数据且知道其前置写入已就绪。这替代了锁的同步，是无锁队列、无锁栈、无锁 hash map 正确性的基础。若不使用正确内存序（或全用宽松序），编译器和 CPU 的重排会让读者读到"序号已更新但数据未写入"的脏数据，引入偶发 bug。关键点：acquire/release 只保证"单向的 happens-before"，提供的是"数据先行可见"而非"全序"，需在正确位置使用。

无锁结构去掉了锁，也去掉了锁内建的同步屏障，必须用手动内存序补上"数据可见性"。release 负责"发布数据先行"，acquire 负责"读取后可见"，二者配对是无锁编程正确性的基石。误用或遗漏内存序是无锁 bug 的最大来源。

• 无锁读的显性收益
• 内存屏障的指令开销
• 缓存一致性协议（MESI）的隐性成本

无锁读不一定总是更快，虽然省去了锁获取/等待，但引入了隐性成本：1) 内存屏障开销：无锁结构需要显式内存屏障（或 acquire/release 原子操作），屏障会禁止一定范围的指令重排，可能影响 CPU 流水线/乱序执行，带来指令级开销；在某些架构上原子操作或屏障指令本身有成本。2) 缓存一致性（MESI 协议）：多核共享缓存行时，一个核写缓存行会令其他核的缓存行失效（invalidate），其他核读时需重新从总线/缓存获取，产生缓存一致性流量（cache-line ping-pong）。无锁结构若频繁写共享指针，会反复触发缓存失效，导致读侧也要等待缓存同步，成本可能高于锁。3) 竞争：无锁结构在低竞争下开销小，但高竞争下 CAS 重试与缓存失效激增，性能可能不如自适应锁。结论：无锁读的收益主要体现在"无阻塞、无锁等待、低抖动"与"低竞争下的吞吐"，但它并非免费——内存屏障与缓存一致性都是隐性成本。只有在"读多写少、低竞争、或锁竞争是主要瓶颈"时，无锁才真正更快；否则锁（尤其读写锁/无锁读的替代 COW/RCU）可能更划算。

无锁不是魔法，它把"锁竞争"的成本转移成"内存屏障 + 缓存一致性"的成本。在低竞争、读多写少场景这些成本低、收益大；在高竞争或频繁写共享变量的场景，缓存失效与屏障成本可能使无锁并不更快。选型需实测而非直觉。

• COW 的复制与 RCU 的复制
• 延迟共享与延迟释放
• 读者共享一致性版本

COW 与 RCU 在思想上相通，都围绕"复制旧数据、修改后发布、旧版本延迟处理"展开。COW（写时复制）：数据结构（或页表）在写时才复制，多个读者共享同一份旧版本，写者复制一份修改后切换引用，读者看到的仍是旧的一致快照。RCU：写者复制旧数据结构、修改、原子发布新指针，读者无锁读当前或旧指针，旧版本在 grace period 后回收。联系：1) 都让"读者共享一个一致快照"，读者无需担心写者修改；2) 都通过"写者复制 + 原子发布"隔离读与写，实现读者无锁；3) 都对"旧版本"采取延迟处理——COW 的旧版本在写者完成复制后不再被引用（引用计数归零才释放），RCU 的旧版本在 grace period 后回收；4) 本质上都是"用时间换空间/一致"的"惰性复制 + 延迟释放"思想。区别：COW 侧重"写时少复制"（共享只读版本），RCU 侧重"读者无锁 + 延迟回收"；COW 常用于用户态数据结构（如 atomic shared_ptr、文件系统页表），RCU 常用于内核与高性能共享结构。二者理念同源，都是"读者无锁读一致快照"的并发优化。

COW 与 RCU 共享"复制 + 发布 + 旧版本延迟"的模式，区别在应用场景与回收机制。理解了 COW 的"写时复制、读者共享快照"，就能理解 RCU 的"读无锁、写复制发布、grace period 回收"为何奏效。二者是"延迟释放/延迟共享"思想在不同层的体现。

• 写者复制-修改-发布
• 读者读当前指针不竞争
• 读临界区与内存屏障

RCU 让读者完全无锁的关键在于"写者从不原地修改数据，读者只读指针"。具体机制：1) 写者复制-修改-发布：写者不修改共享数据，而是复制一份、在新副本上修改、用一次原子写（内存屏障 release）发布新指针；读者读到的要么是旧指针要么是新指针，都是完整一致版本。2) 读者只读指针：读者读取当前指针（volatile/atomic 读），因任何时刻只有一个被发布的有效指针，读者之间无竞争，读与写也不冲突（写者改的是"指针"而非"读者正在读的数据"）。3) 读临界区（rcu_read_lock/unlock）：读者进入临界区仅仅是为了"声明我在用这个指针"，防止写者过早回收旧版本，临界区内无锁、无原子操作（仅内存屏障），读者开销趋近于零。4) 写者延迟回收：写者发布新指针后，等 grace period（所有读者退出临界区）才回收旧版本，因此读者永远安全引用旧指针。结论：读者无锁 = 写者"惰性化"（不在原地改数据）+ 读者只读指针拿一致快照 + 读临界区仅做声明 + 延迟回收保证安全。读者路径上没有锁、没有 CAS、没有原子 RMW，只有读与屏障。

RCU 读者无锁的根源是把"写"从"原地修改"改为"复制发布"，从而读者与写者不在同一数据上竞争。读者只需"读指针 + 声明临界区"，所有同步由写者承担（复制、发布、等 grace period）。这就是"读者无锁"的代价转移：写者变慢，读者变快。

• 序列号奇偶状态
• 读者两次读校验
• 读者重试而非加锁

seqlock 用一个**偶数递增的序列号（sequence）**来标记写者状态。写者：取写锁后序列号 +1（变奇数，标记"正在写"），写数据，序列号再 +1（变偶数，标记"写完成"），释放写锁。读者：读序列号（应为偶数），复制数据，再读序列号；若两次读到的序列号相同且为偶数，说明读期间没有写者发生，数据一致，直接使用；若两次不同或为奇数，说明有写者并发，数据可能被撕裂，读者重试（重新读序列号并复制数据）。核心：读者不靠加锁，而靠"序列号作为校验签名"检测写者是否并发。奇数序列号 = 有写者在写，偶数 = 写已完成；两次序列号一致 = 读期间无写者。这样读者无锁、无原子 RMW，只有两次普通读 + 比较，开销极低，可无限并发读。代价：写者必须独占写（写者之间要互斥），且读者在写发生时可能重试多次（浪费 CPU），故只适合读多写少。与锁的区别：读者不阻塞、不等待，而是"检测到并发就重试"，这是 seqlock 读者无锁的本质。

seqlock 用"序列号奇偶 + 两次读校验"作为一致性签名，让读者自主检测并重试，而非去抢锁。这把"并发检测"从锁机制转移到数值校验，读者遂无锁。序列号在一个完整写周期内至少变化两次（奇→偶），保证读者能捕捉到任何写。