Cassandra 并发与状态审查清单深度解析：从 TOCTOU 到引用计数的并发缺陷排查实战指南-开发者社区

Cassandra 并发与状态审查清单深度解析：从 TOCTOU 到引用计数的并发缺陷排查实战指南

【免费下载链接】cassandraOpen source transactional distributed database. Linear scalability and proven fault-tolerance on commodity hardware or cloud infrastructure without compromising performance.项目地址: https://gitcode.com/GitHub_Trending/cassa/cassandra

本文基于 Apache Cassandra 仓库中deep-concurrency.md这一份"扩展版并发与状态审查清单"，系统梳理分布式数据库并发代码审查中最高频的缺陷模式（TOCTOU、原子性、可见性、生命周期、死锁、线程池饥饿、引用计数等），并结合 Cassandra 源码（Ref引用计数、SEPExecutor共享执行器池、Stage调度阶段、SSTableReader自引用管理等）给出可验证的实现级佐证，帮助读者在审查 Cassandra 这类高并发系统代码时快速定位并发隐患，并理解其底层运行原理。

1. 这份清单解决什么问题

deep-concurrency.md是一份面向代码审查（deep review）场景的结构化缺陷排查清单：它不讨论"并发是什么"，而是逐条列出在并发系统中具体会写错什么——从跨线程共享状态的读写，到生命周期管理、计数器记账、状态机分支、死锁与线程池饥饿，再到特定的可重入与异步边界危害。

对 Cassandra 这类"每个请求都要经过多线程调度、每个 SSTable 都要被引用计数管理、每个 Stage 都有固定线程约束"的系统而言，这份清单的价值在于：它把"并发正确性"拆解成可逐一对照检查的条目，每条都附带权重（high / medium / low），让审查者知道哪些模式一旦出现几乎必然是 bug，哪些只是需要谨慎评估的风险点。

清单的检查对象是"目标文件"（TARGET FILES），使用方式也明确：审查前必须读取目标文件全文（而非只看 diff），先完成五类上下文收集，再逐节过清单。

2. 审查前置：Context Gathering（上下文收集）

清单在进入任何具体检查项之前，强制要求先回答五个问题：

线程模型：哪些线程会访问这个对象？它是否被限定在单一线程内？
锁清单：哪些锁保护这些状态？锁的获取顺序是什么？
生命周期：谁创建、启动、停止、销毁这个对象？
共享状态：哪些字段被多个线程读写？
状态机：这个对象可能处于哪些状态？哪些状态迁移是合法的？

这五问对应到 Cassandra 源码中，就是许多并发基础设施类的设计前提。以执行器为例，src/java/org/apache/cassandra/concurrent/Stage.java中的Stage枚举明确区分了两类线程模型：

单线程阶段：GOSSIP、ANTI_ENTROPY、MIGRATION、MISC、FETCH_METADATA等（() -> 1线程）；
多线程阶段：READ、MUTATION、COUNTER_MUTATION、REQUEST_RESPONSE等（线程数由DatabaseDescriptor::getConcurrentReaders等配置决定）。

"这个 executor 是单线程还是多线程"决定了它的线程约束契约：单线程阶段天然免于同阶段内数据竞争，但一旦有人把状态变更任务错误地调度到其它阶段（见后文"Wrong executor stage"），就破坏了该契约。

类似地，Ref引用计数的注释（src/java/org/apache/cassandra/utils/concurrent/Ref.java）也以"生命周期"为第一原则：被计数对象必须定义一个Tidy清理器，且该清理器不得持有被跟踪对象的引用（只能持有其资源和清理方式），否则会造成清理器与对象互相引用、永远无法回收。

3. TOCTOU 与原子性深度（权重：high）

TOCTOU（Time-of-check to time-of-use）是共享可变状态上最常见的并发错误：先检查、后使用，但检查与使用之间没有统一的原子边界。清单列出了四类典型形态：

字段在一步中读取、在另一步中无同步地依据该值行动；
布尔标志"检查后使用"但没有持锁覆盖两个操作；
状态机检查与状态迁移分离；
存在性检查与创建/插入操作分离；volatile字段或并发集合被读两次而没有本地捕获，导致 check 与 use 之间被并发置空。

清单特别点名了几个高危的非原子复合操作：

ConcurrentHashMap上无外部锁的 get-then-put、check-then-act；
跨多个并发 map 的无共享锁操作；
putIfAbsent的返回值被忽略，调用方仍使用自己构造的参数对象（这个问题在清单末尾的"Specific Concurrency Patterns"中再次出现，权重为 low 但语义相同：putIfAbsent不检查返回值，后续代码操作的是新创建对象而不是竞态胜出者）。

Cassandra 源码中对"检查与使用必须原子"的正面示范是SEPExecutor的许可（permit）管理。在 src/java/org/apache/cassandra/concurrent/SEPExecutor.java 中，SEPExecutor用一个AtomicLong permits打包存储两类许可：

低 32 位：排队任务数（task permits），范围[0..maxTasksQueued]；
高 32 位：可用工作许可（work permits），范围[-resizeDelta..maximumPoolSize]。

takeTaskPermit采用标准的 CAS 自旋循环：读当前值 → 计算新值 →compareAndSet，失败则重读重算，将"检查许可是否可用"与"扣减许可"合并为一个原子操作；takeWorkPermit同理，同时扣减工作许可与任务许可，任一不足即返回false。这正是清单所强调的"check 与 act 必须处于同一原子操作"的实现模板。

清单中还有两类值得注意的次高频模式：

生产者-消费者别名（权重 medium）：生产者把对象放入队列（queue.put(obj)）后仍保留引用并继续修改它；
原子交换后旧实例仍有并发写者（权重 low）：AtomicReference.getAndSet(newCollector)之后，如果在新引用上排空旧收集器，而旧引用上的写者尚未停止，会造成旧实例上的写入被丢弃或重复；
锁下快照被下游无同步重读破坏（权重 low）：持锁把共享字段捕获到局部变量后，临界区内后续调用却重新读取原始引用（写this.field.foo()而非local.foo()），或传给辅助函数的局部变量在函数内部又间接解引用宿主对象的字段。

4. 集合并发深度

4.1 ConcurrentModificationException（权重：high）

清单列出三种必然触发ConcurrentModificationException的写法：

for-each 迭代共享可变集合，同时另一线程修改它；
在 for-each 同一集合的过程中调用collection.remove()；
循环体内部的方法修改正在被迭代的集合。

4.2 共享集合的无同步读（权重：high）

共享HashMap/ArrayList在同步块内写、同步块外读；
.keySet()、.entrySet()、.values()作为**活视图（live view）**返回而未拷贝；
在保护集合的锁之外迭代集合。

清单进一步把"活视图迭代"列为独立模式：迭代map.entrySet()或list.subList()之前不拷贝；getter 直接返回内部 Map/Set/List 字段，导致外部在锁外迭代。

4.3 共享 ByteBuffer 的 position 副作用（权重：high）

这是一个非常 Cassandra 风格的检查项——相对读写（relative get/put）会推进position，而position是共享可变状态：

共享/池化ByteBuffer未先duplicate()或slice()就直接相对get()；
反序列化辅助方法返回静态/单例缓冲区的引用而非新拷贝，调用方会"永久耗尽"它；
比较器或序列化器推进了调用方传入缓冲区的 position 后再 rewind/flip，让并发观察者暴露在中间状态；
堆缓冲区 slice 后，索引底层数组时遗漏arrayOffset()。

对照清单的告诫，正确的做法是：需要保留原缓冲区 position 时先duplicate()（共享内容但独立 position/limit），需要绝对寻址时用slice()并正确计算arrayOffset()。

5. 可见性与内存模型深度

5.1 缺失 volatile（权重：medium）

三类典型场景：

非 final、非 volatile 的共享字段在一线程写、另一线程读；
跨线程共享的懒初始化缓存字段没有 volatile；
可变单例引用没有可见性保证。

清单的言下之意是：即使没有"同时写"的数据竞争，缺少 volatile（或其它 happens-before 边）也会导致读线程永远看不到写线程的最新值。

5.2 信号先于发布（Signal before publish）（权重：medium）

在等待者将要读取的数据结构完全更新之前，就latch.countDown()或完成 future；数据必须以释放栅栏（volatile 写、synchronized 退出）发布。这是"先发布信号、后发布数据"的时序反转，属于典型的初始化/唤醒竞态。

5.3 比较器读取活状态（权重：medium）

Comparator在排序过程中读取 volatile、共享或持续更新的字段；并发写入可能在排序中途改变值，违反比较器的传递性（transitivity），导致排序结果不可预期甚至抛异常。

6. 生命周期与初始化深度

6.1 构造器发布 this（权重：medium）

构造函数启动捕获this的线程；
构造函数以this注册监听器、管理回调或观察者；
构造函数启动引用this的执行器。

这是"溢出构造"（leakingthis）问题：对象尚未完全构造完成，其它线程就已经能看到并操作它。

6.2 双重检查锁定（DCL）（权重：medium）

离开 synchronized 块后重新读取字段；
空检查和取值是两次独立的字段访问；
其它线程可能观察到中间状态。

经典 DCL 需要volatile字段才能正确发布，清单要求审查者确认"字段是否在同步块外被重读"以及"是否可能观察到中间状态"。

6.3 监听器注册时机（权重：medium）

事件监听器在初始状态快照之后才注册；
监听器在异步操作发起之后才注册；
存在"快照与注册之间的事件丢失窗口"。

6.4 关闭顺序（权重：high）

关闭是否与启动严格镜像（逆序）；
标志是否在受保护操作完成之前被设置；
静态初始化器是否过早触发；
离线工具是否假设集群在线。

Cassandra 的Stage枚举本身就携带了关闭顺序信息：Stage的构造参数shutdownBeforeCommitlog标记了"该 executor 应在优雅关闭提交日志分配器之前先被关闭"，因为发出变更（mutation）任务的 executor 可能无限期阻塞等待新的提交日志段，不先排空它们就无法干净地关闭提交日志——这正是"关闭顺序与启动顺序镜像"在真实系统中的落地。

6.5 非阻塞停止信号后接破坏性状态变更（权重：medium）

关闭流程给后台任务发"停止"标志/信号后，不 join、不等待、不确认任务已退出，就直接 clear / truncate / delete 该任务正在读写的数据；或功能禁用路径在周期性任务仍处于迭代中途时反注册/置空协作者。此类"发信号即拆房"的模式会在后台任务与清理动作之间制造竞态。

6.6 引用计数未在并发读取前获取（权重：high）

读取者访问共享的引用计数资源前未先 acquire 引用；
并发的驱逐者/删除者/压缩器可能在"空值/存在性检查"与"读取"之间释放资源，造成 use-after-free；
引用计数增量与 CAS 结合时，竞态失败方可能让计数膨胀。

这一条在 Cassandra 中对应着完整的引用计数体系，值得展开：

RefCounted接口（src/java/org/apache/cassandra/utils/concurrent/RefCounted.java）定义了两个获取方法：

tryRef()：尝试获取新引用并递增计数，已释放时返回 null（这是"先获取引用再安全读取"的入口）；
ref()：获取新引用，已释放时抛IllegalStateException。

Ref实现（src/java/org/apache/cassandra/utils/concurrent/Ref.java）用PhantomReference+ 全局状态实现"最后一个引用被释放时执行清理"：

Target --> selfRef --> [Ref.State] <--> Ref.GlobalState --> Tidy ^ | Ref ---------------------- | Global --------------------

每个Ref对应一个State（继承PhantomReference<Ref>），通过AtomicIntegerFieldUpdater<State>上的released字段保证每个引用恰好释放一次；
引用被 GC 回收而从未显式release()时，State.release(true)会记录LEAK DETECTED错误日志，并可通过OnLeak回调上报；
对已释放引用再次release()会记录BAD RELEASE并抛IllegalStateException；
提供enableTestTracing()/disableTestTracing()用于测试中追踪分配/释放线程与栈轨迹。

Refs批量管理（src/java/org/apache/cassandra/utils/concurrent/Refs.java）是一次性持有多个Ref的集合，release()释放全部引用并清空内部映射，releaseIfHolds(T)则仅在确实持有时释放。

SSTableReader是"引用计数 + 并发读取"的典型使用者（src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java）：它实现SelfRefCounted<SSTableReader>，持有private final Ref<SSTableReader> selfRef，构造时selfRef = new Ref<>(this, tidy)；查询路径通过tryRef()先获取引用再读取，避免读操作与压缩器/驱逐者删除文件之间的 use-after-free——这正对应清单 6.6 的三条检查项。

7. 计数器与记账深度

7.1 增量无匹配减量（权重：medium）

计数器在可能失败的操作之前递增；
每条失败分支是否都有回滚路径；
计数器在关联清理完成之前就递减。

7.2 指标放在错误的点（权重：high）

指标在被测操作之前更新（早退路径会虚增）；
指标在另一个操作之后更新（测错了对象）；
指标在控制被测操作的守卫之外；
指标位于与真实选择循环不一致的估算循环中。

7.3 大小/计数累加器缺口（模式）

size 累加器只在部分写路径更新而非全部；
墓碑（tombstones）、元数据、索引块是否都计入累加器。

Cassandra 的SEPExecutor提供了一个"指标与操作对齐"的正面例子：completedTasks计数只在onCompletion()中incrementAndGet()，而onCompletion()是任务真正完成时被调用的钩子，保证指标与"已完成任务"这一语义严格同步。

8. 状态机深度

8.1 分支中缺失副作用（权重：high）

列出状态机处理器的所有分支，检查每个分支是否执行了应有的副作用；
重点检查：gossip 同步、指标更新、状态传播、传输停止。

8.2 状态清理（权重：high）

reset / clear / truncate 是否更新了每一个伴随结构；
懒初始化if (x == null) x = init()是否把"尚未初始化"与"已关闭"混为一谈；
成功路径是否缺失错误路径才有的清理；
持久状态是否在操作开始时（而非提交时）被写入；
周期性任务是否在!enabled时短路返回却没有撤回已发布的状态。

9. 死锁深度

9.1 处理器中的阻塞 get（权重：low）

RPC verb 处理器内future.get()是否饿死处理器线程池；
被等待 future 的完成是否依赖同一个池——若是，则形成自我死锁。

9.2 锁顺序（具体模式）

持锁代码段委托给一个会独立再获取同一把锁的公共 API；
synchronized方法调用会重入同一把锁的 Netty/IO 回调；
static synchronized调用会加载另一个带自身静态初始化的类（静态初始化死锁）。

9.3 线程池饥饿（具体模式）

SynchronousQueue+CallerRunsPolicy是否会阻塞提交者；
Netty 流水线中的有界阻塞队列是否会阻塞排空它所需的 I/O 线程。

9.4 共享元数据变更缺少锁（权重：low）

元数据变更路径是否跳过了并发后台任务持有的 flush / compaction 锁；
后台任务是否在元数据对象已失效后仍写文件、索引项或偏移量。

10. 作用域与守卫不匹配深度

10.1 作用域不匹配（权重：high）

teardown 步骤位于其所对应操作的if块之外；
通知无条件执行，而它本应位于条件内部；
不变式守卫位于可选分支内而非外围作用域；
校验逻辑只存在于一条路径（如本地应用 local-apply），另一条路径（远程广播 remote-announce）没有。

10.2 条件递减链（模式）

跨多个 if/else 分支的条件递减链是否数错；
dirty 标志是在写循环内部设置，还是在循环结束后才设置。

11. 线程池与调度深度

11.1 错误的执行器阶段（权重：medium）

消息处理器、任务或状态变更被调度到错误的执行器阶段，脱离了其线程约束契约。Cassandra 的Stage枚举正是用来防止这类错误的：每个阶段有固定线程模型，调度方必须按阶段语义提交任务。

11.2 计数器作用域（权重：medium）

计数器递增位于条件大括号之外，无条件触发；本意只统计匹配项，实际每个迭代都计数。

11.3 在受限/单线程执行器上自我调度（权重：medium）

已在单线程执行器（或线程约束 actor）上运行的代码，又向同一执行器提交新工作并阻塞等待结果；
协调者与副本处理器运行在同一执行器上时，为本地副本又调度回同一执行器。

11.4 Cassandra 的 SEPExecutor：无锁许可调度的实现参照

SEPExecutor（src/java/org/apache/cassandra/concurrent/SEPExecutor.java）是 Cassandra 自研的"共享执行器池 + 自旋工作线程"调度器，其核心设计正是对清单多个条目的正面示范：

无锁入队与唤醒：addTask先把任务加入ConcurrentLinkedQueue，再用permits.getAndAdd递增任务许可；若此前任务许可为 0，则调用pool.maybeStartSpinningWorker()（src/java/org/apache/cassandra/concurrent/SharedExecutorPool.java 中通过spinningCount.compareAndSet(0, 1)保证只有一个worker 进入自旋状态）——任务先入队再发信号，正是"先发布数据、后发布信号"的正确顺序；
CAS 保证"扣许可必有活干"：takeTaskPermit的 CAS 循环保证一旦扣减成功，随后的tasks.poll()必有任务可取；
立即执行优化：maybeExecuteImmediately在持有工作许可时直接在当前线程执行任务（通过ImmediateTaskHolder记录嵌套立即任务），否则回退到入队路径，并在 finally 中归还工作许可、重新maybeSchedule()维持调度不变量。

SharedExecutorPool.spinningCount的 CAS 用法也值得注意：它用compareAndSet(0, 1)把"是否有 worker 正在自旋等待任务"这个布尔状态做成无锁原子更新，避免了多线程同时唤醒多个空转 worker 的浪费——对应清单中"CAS 选举单一写者"的正面形态。

12. 可重入与异步危害

12.1 可重入（权重：low）

持有锁的方法回调了会修改同一共享状态的代码；这在取消与驱逐路径中尤其常见。

12.2 ThreadLocal 跨异步边界（权重：low）

线程本地状态（tracing、请求上下文）在提交者线程设置、在异步任务中读取；
提交者可能在任务读取前就清除 ThreadLocal。

Cassandra 的ExecutorLocals（src/java/org/apache/cassandra/concurrent/ExecutorLocals.java）与WithResources机制正是为跨线程传递请求上下文而设计：任务包装器负责把提交者的局部状态绑定到任务执行线程，这正是对"ThreadLocal 跨异步边界"问题的系统性解决。

12.3 CAS 重试安全（权重：low）

无界 CAS 重试循环用在竞争不短暂（brief）的场景；
布尔 CAS 选举了单一写者，而其它参与者继续使用陈旧状态。

12.4 中断破坏共享 I/O 通道（权重：low）

任务在持有或使用共享网络通道时被中断；
后续对该共享通道的阻塞调用抛出ClosedByInterruptException，把中断传播到被中断任务范围之外；
应评估：通道应每任务专用，或中断应在本地吸收。

13. 可变性与不可变性违规

清单在此部分只列了一个明确模式：返回不可变集合但调用方期望可变（权重：low）。方法返回Arrays.asList()、Collections.singletonList()或不可修改列表，调用方却对其调用add()/remove()，抛出UnsupportedOperationException。这类问题常见于内部 API 演进后调用方契约未同步更新的场景。

14. 特定并发模式（Specific Concurrency Patterns）

清单最后专门汇总了一批"具体的、可点名的"并发反模式，按权重排序：

权重	模式	要点
high	版本门控的条件字段只在一个分支读写	序列化/反序列化中受消息变体/类型/状态门控的字段只出现在一个分支；`serializedSize`早退绕过共享尾字段；协议版本未贯穿到集合元素解码器；标志在条件早退前被消费；版本门控字段被冗余写入但没有匹配的反序列化逻辑
high	配置选项被静默丢弃	配置旋钮被解析但未传入 builder：cipher suites 传 null、流式加密设置被丢、最大帧大小未设置
medium	`Throwable.getMessage()`/`getCause()`/ 空栈迹未判空	无参构造器的`getMessage()`返回 null；无链式原因时`getCause()`为 null；`writableStackTrace=false`时栈迹数组为空
medium	复制粘贴错误	复制的代码块两次引用同一变量/列名/字面量，而非各自应有的不同值
medium	原子计数器与集合失同步	存活/完成检查用原子计数器，而实际数据在另一集合；计数器因 CPU 重排超前推进
medium	注册与资源就绪之间的竞态	资源跟踪集合的注册或可用性标记在资源真正就绪之前/之后设置
medium	异常处理器捕获类型不匹配绕过清理	try 块分配了池化资源，catch 只处理一种异常类型；其它类型的异常完全逃逸 catch，清理被跳过
low	getter 修改状态	名为`getCompletedTasks()`的方法调用`incrementAndGet()`而非`get()`
low	ThreadLocal 用于实例级状态	ThreadLocal 缓存的值逻辑上属于某个对象实例；多实例共享线程时缓存值互相污染
low	实例级共享游标/遍历状态	类把可变遍历游标作为实例字段；并发调用方互相破坏对方状态
low	清理完成前递减	资源准入计数器在关联清理（socket 关闭、线程退出）完成前递减
low	`putIfAbsent`返回值被忽略	后续代码操作新创建对象而非竞态胜出者
low	重试/重入路径未处理幂等性	可重试操作未区分"哪里需要幂等"与"重复意味着 bug"
low	测试中全局/静态标志未在 finally 复位	断言前切换的全局标志在 try 体末尾复位；断言失败后遗留脏状态
low	单例响应对象跨并发请求复用	携带每请求可变字段的协议消息类被暴露为静态单例
low	并发目录创建竞态	`mkdirs()`的结果驱动错误路径，未考虑并发创建者可能竞争
low	锁已获取但关键工作在 lock() 与 try 之间	变更放在`lock.lock()`与配对`try`之间，实际在临界区外执行
low	finally 抛异常抑制后续资源清理	finally 内可抛异常的调用抑制了原始异常并阻止后续清理
low	竞态失败方未释放资源	对象在 putIfAbsent 前已构造并持有资源，失败方未 dispose
low	独立更新计数器数组的缓存行竞争	相邻原子计数器互相伪共享（false sharing），需检查填充或分段（striped）设计
low	发后不理的异步操作无在途去重	提交到执行器的异步抓取未被跟踪；第二个调用方触发并行操作
low	广播失效引发惊群重算	缓存失效广播导致所有持有者同时竞争重新填充

15. 状态清理——并发域模式（State Cleanup）

15.1 耦合数据结构仅部分复位/清理（权重：high）

"reset"、"clear"、"truncate" 触碰到多个耦合结构之一时，遗漏了其它结构——派生计数器、伴随 map、版本跟踪器或缓存联合（cached unions）。

15.2 合并或库升级破坏接口方法签名（权重：high）

合并后，一个或多个实现类保留旧签名；没有@Override时，不匹配是静默的（方法变成重载而非重写，调用点仍走旧签名）。

15.3 成功路径缺失错误路径才有的清理（权重：medium）

清理逻辑存在于错误处理器，但正常完成路径缺失。

15.4 用陈旧快照做删除/清理（权重：medium）

通过快照 diff 计算"什么变了"的代码，在快照被跳过时会漏掉变更。

15.5 其余低权重模式

基类构造器调用虚方法返回陈旧默认值：可覆写方法在基类构造器中调用时，子类尚未完成初始化，返回默认值；
段间清除 open 标记/游标：迭代器状态机在"读取"当前 open 状态时将其重置为副作用，丢失跨越迭代边界的信息；
包装类 enable/disable 生命周期未传播到内部委托：状态变更只影响包装类自身的标志，不影响委托对象；
滚动升级中不安全地移除守卫（权重 medium）：守卫被移除，但滚动升级中的旧节点仍依赖被守卫的行为；
共享集合的 clear-and-refill 竞态窗口（权重 low）：共享集合先清空再回填，clear 与 refill 之间的并发读者看到空状态；
构造器参数被接受但从未存储或使用（权重 low）：构造函数接受参数但从未赋值给字段。

16. 如何把这套清单落到 Cassandra 代码审查中

结合以上分析与仓库源码，建议按如下顺序使用这份清单：

先做 Context Gathering：对目标类，明确线程模型（对照Stage的单/多线程约束）、锁清单、生命周期（对照Stage.shutdownBeforeCommitlog等关闭顺序信息）、共享字段、状态机；
优先检查 high 权重条目：TOCTOU 与原子性、共享集合无同步读、ByteBuffer position 副作用、关闭顺序、引用计数先获取再读取（对照Ref.tryRef()/RefCounted/SSTableReader.selfRef）、状态机分支缺失副作用、耦合结构部分清理；
对照仓库基础设施验证写法：凡是涉及线程池调度的，对照SEPExecutor的 permit CAS 与SharedExecutorPool.spinningCount的原子唤醒；凡是涉及引用释放的，对照Ref的双重释放检测（BAD RELEASE）与泄漏检测（LEAK DETECTED）；
为测试代码单独过一遍清单：Ref提供enableTestTracing()/disableTestTracing()供测试追踪分配/释放轨迹；清单中"全局/静态标志未在 finally 复位""计数器与集合失同步"等条目在测试代码中同样高频。

17. 总结

deep-concurrency.md提供了一份按权重排序、可直接对照执行的并发缺陷排查清单：从上下文收集的五个前置问题，到 TOCTOU/原子性、集合并发、可见性、生命周期、计数器、状态机、死锁、作用域、线程池、可重入、可变性，再到二十余条具名并发反模式与状态清理模式。

在 Cassandra 仓库中，这份清单的每一条几乎都能找到对应的真实实现或真实风险：Ref/RefCounted/Refs用 PhantomReference + 原子字段更新器实现了"恰好释放一次、泄漏可检测、双重释放即报错"的引用计数；SEPExecutor与SharedExecutorPool用打包 AtomicLong 许可与 CAS 自旋实现了"检查与扣减原子、信号晚于数据发布"的无锁调度；Stage枚举把线程模型与关闭顺序固化成类型系统的一部分。理解这些实现，再回头逐条核对清单，就能把"看起来正确的并发代码"升级为"可论证正确的并发代码"。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考