Cassandra 并发与状态缺陷审查清单从竞态、可见性到状态机异常的 24 项实战排查指南【免费下载链接】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 仓库内置了一套面向代码评审Code Review的专项技能skill其中的Concurrency State 专家清单凝练了 24 个最高信号值的检查问题覆盖竞态与原子性、字段可见性、锁与死锁、生命周期与顺序、状态管理、计数与状态机等七个维度。本文以该清单为骨架逐一展开每个检查项背后的并发原理并结合 Cassandra 真实源码SSTable 引用计数、缓存、CommitLog、Memtable、ColumnFamilyStore 等给出可验证的实例。读完本文你将获得一套可以直接用于评审 Cassandra 补丁patch的并发缺陷排查方法论并能精确识别 TOCTOU、可见性泄漏、锁顺序死锁、生命周期逃逸等典型高危模式。清单定位为什么并发与状态值得单独设立专家在 shallow-review 技能 所定义的六专家并行评审流程中Concurrency State 是六个独立视角之一其余为 Logic Types、Boundaries I/O、Resources Serialization、Absence Analysis、API Completeness。该流程先由每个专家执行 Phase 0理解补丁、形成假设再套用各自清单核对最后由主 Agent 合并去重并按置信度排序。根据该技能文件中的统计先验与并发直接相关的缺陷占比相当可观竞态条件Race condition约占 9%状态未清理State not cleaned up约占 7%两者合计约 16%——这正是 concurrency.md 清单开头所标注的16% of all bugs fall in this domain的数据来源。考虑到 Cassandra 是一个典型的多线程、多节点、大量共享可变状态的系统这一比例在意料之中Memtable 的并发写入、SSTable 的引用计数回收、缓存的并发失效与回填、后台 compaction 与前台读写之间的锁交互几乎每个子系统都同时面临竞态、可见性和生命周期三类风险。因此这份清单的目标不是罗列通用并发常识而是提炼出在 Cassandra 这类代码库中反复出现、且能通过阅读补丁表面代码即可发现的高信号模式。下面按清单原始分组逐条展开。一、竞态与原子性Races Atomicity——8 项这是整个清单中最大的一组聚焦检查-然后-行动check-then-act序列被并发打断的各类形态。1. TOCTOU跨读写的非原子检查-然后-行动代码是否在未持锁覆盖整个读-写序列的前提下先读共享字段、再条件性写入TOCTOUTime-Of-Check to Time-Of-Use是所有并发缺陷中最经典的形态两个线程都通过检查如map 中不存在该 key随后都执行写入最终状态取决于调度时序。清单特别提醒跨多个 map 的复合操作get-then-put、check-then-act即使单个操作是原子的整体也不是——ConcurrentHashMap只保证单个方法原子不保证先查后写的组合原子。此时需要外部同步如synchronized块或显式锁将整个序列包起来。在 Cassandra 源码中大量putIfAbsent的用法正是为了规避这一模式而采用的内置原子操作例如 CommitLogSegment.java、Memtable.java、InstrumentingCache.java 等文件中的键/段注册。但putIfAbsent本身也埋着第 3 条检查项的陷阱见下文。2. 共享可变集合的活视图迭代代码是否直接迭代 getter 返回的共享可变集合如map.entrySet()、transaction.originals()、list.subList()而没有先拷贝entrySet()、keySet()、subList()返回的都是活视图live view对视图的迭代实际上是在遍历底层共享结构。如果另一线程同时修改集合轻则读到不一致数据重则抛出ConcurrentModificationException。清单还强调一个对称陷阱在同一集合的 for-each 循环内部调用collection.remove()即使是单线程也会触发 CME因为 for-each 隐式使用迭代器而迭代器会校验modCount。正确做法是先在锁内或通过new ArrayList(...)、toArray()等方式做一次快照拷贝再在锁外迭代快照。3.putIfAbsent()返回值被忽略调用方是否忽略了putIfAbsent()的返回值而继续使用自己传入的参数而不是竞态胜出者putIfAbsent(k, v)的语义是仅当 k 不存在时放入 v并返回已存在的旧值若不存在则返回 null。如果返回值被忽略调用方会默认我放进去了我的 v——但若另一线程抢先放入容器中的实际值是对方的对象。后续代码若用本线程的参数而不是返回值继续操作就会操作一个从未真正进入容器的孤儿对象导致两个写入者各持一份胜利者与失败者视图。正确的模式是V winner map.putIfAbsent(k, mine); V actual (winner ! null) ? winner : mine;——无论竞态结果如何后续一律使用actual。4. 信号/通知先于数据就绪Signal Before Data Readylatch 的countDown()、future 的complete()是否发生在被唤醒线程将要读取的数据结构完全更新之前缓存失效/墓碑广播是否在底层写入提交之前发出导致竞态读者用旧值重新填充缓存这是通知-读取顺序颠倒唤醒wake-up本身是一个同步点但它只保证被唤醒这个事实的可见性不保证被唤醒线程所需数据的可见性。若先 countDown 再写数据被唤醒线程可能读到未更新的中间状态。缓存场景尤其危险读者发现缓存条目被标记失效转而回源读取底层存储——但如果失效信号先于底层提交发出回源读到的仍是旧值于是用旧值重新填充缓存让失效永久失效。正确的顺序永远是先完整更新数据与索引最后才发信号。5. 共享ByteBuffer的get()/read()副作用代码是否在未先调用duplicate()或slice()的情况下对共享/池化/单例的ByteBuffer使用相对定位的get()/read()ByteBuffer的 position 是可变状态相对 get/read 会使 position 前移。若同一缓冲区被多个读者共享或同一线程多次读取第一次读取就会破坏后续所有读者的起始位置。修复手段是duplicate()共享底层数据、独立 position或slice()从当前位置切出一段独立视图。Cassandra 对这一点有大量正确实践可作对照例如 ChunkCache.java 在返回缓存块前执行buffer.duplicate()CQL3Type.java 在解析类型时多处调用buffer.duplicate()。评审补丁时凡是看到共享 ByteBuffer 直接参与相对读写就要追问是否重复用了 position是否调用了 duplicate/slice6. 引用计数资源读前未持有引用读者访问共享的引用计数资源off-heap 缓冲区、SSTable、Chunk、缓存条目时是否在读取之前获取了引用计数并发的驱逐者可能在存在性检查与使用之间释放资源。这是检查-使用竞态在资源生命周期上的投影即使检查时资源存在持有该结论到实际使用时另一线程驱逐器、回收器可能已将其释放/回收造成 use-after-free 或非法内存访问。标准模式是先tryRetain/acquireReference成功再使用最后release。SSTableReader 是这一模式的教科书级实现SSTableReader.java 持有private final RefSSTableReader selfRef并在 L1514 通过selfRef.tryRef()提供非阻塞的引用获取整个生命周期由Ref对象与 tidy 回调管理L491读取完成后在 L2142 释放。tracing 侧也有同类实践TraceState.java 的acquireReference()被 Tracing.java 在访问 trace 状态前调用。评审时若发现先取引用再检查或直接裸用资源的模式应立即标记。7. 原子替换后旧引用仍被写入原子交换atomic swap替换了共享的可变收集器/累加器/标记landmark之后已经解析到旧引用的生产者是否会在旧实例被 drain 之前继续向它写入CAS 替换只保护新的写入者拿到新引用不保护旧的写入者。一个生产者可能在 swap 之前就已把旧引用存入局部变量随后继续向已退役的旧实例写入造成数据丢失或写入失效对象。修复要点是替换前先确保旧实例已 drain排空或所有旧引用已退出或者在旧实例上做已关闭标记并拒绝后续写入。8. 提交/CAS 路径重读版本令牌提交或 compare-and-swap 路径是否重新读取版本令牌或前置条件值而不是复用事务开始时捕获的那份两次读取之间的并发修改会绕过冲突检测。CAS/乐观并发的前提是用同一份快照做校验与提交。若校验时读一次版本号、提交时又读一次两次读取之间若发生修改第二次读取看到的新版本可能恰好与旧版本仍在的判断混淆从而让冲突写入悄悄通过检测。正确做法是一次性捕获版本令牌并在整个事务中复用提交时用该令牌做 CAS 比对。二、可见性与字段Visibility Fields——3 项这一组聚焦 Java 内存模型下的字段可见性问题重点是非 final、非 volatile 共享字段的跨线程读写。9. 无锁跨线程读写非 final、非 volatile 字段非 final、非 volatile 的共享字段是否在一个线程写入、另一个线程读取且两者之间没有锁没有 happens-before 边另一个线程可能永远看不到新值或看到旧值。清单的补充提示是同一共享字段被读取两次而没有局部捕获——两次读取之间若被并发置空nullification就会出现第一次检查非空、第二次使用时空指针的窗口。修复手段包括声明为volatile、加锁读写、或改为AtomicReference在方法内部则应将字段先捕获到局部变量再复用避免重复解引用。10. 排序期间Comparator读取可变字段Comparator是否在排序过程中读取一个活的可变字段并发写入会破坏传递性。排序算法的正确性依赖比较结果满足传递性若 ab 且 bc则 ac。如果比较器在比较 a、b、c 的三个瞬间字段值不同就可能出现 ab、bc、ca 的循环导致排序器陷入死循环或产生错误顺序。若比较器必须依赖可变状态应先捕获快照或保证排序期间该状态不变。11. 锁内捕获快照但下游重读原引用共享字段是否在锁内被捕获到局部变量但同一临界区内下游调用却重新读取未加锁的原引用例如写成this.field.foo()而非local.foo()快照被架空。这是最容易看起来修好了的缺陷明明在锁内做了local this.field后续却依然写this.field.foo()——局部捕获的努力被彻底浪费又一次无锁读取。清单要求评审时盯住临界区内的每个this.field解引用确认其是否真的使用了锁内捕获的局部变量。三、锁与死锁Locking Deadlocks——3 项12.synchronized方法内部调用其他同步代码一个synchronized方法是否调用了另一个类中也带synchronized的方法从synchronized块内部出发的每一条路径只要阻塞在 I/O 或获取另一把锁就要标记。synchronized 是不可重入之外的锁获取很容易形成锁顺序死锁线程 A 持锁 1 等锁 2线程 B 持锁 2 等锁 1。在synchronized块内执行 I/O、网络调用、等待其他锁都会显著放大死锁与停顿风险。清单还点出一个隐蔽变体static synchronized调用会加载其他类的代码可能触发静态初始化器死锁——类加载本身会获取该类的初始化锁若两个类的静态初始化互相依赖对方就会死锁。评审时应对从同步块出发的每条调用路径做递归追踪。13. 消息处理器/任务阻塞在future.get()消息处理器或任务是否阻塞在future.get()上而该 future 的完成恰恰依赖同一个线程池这是典型的自我依赖死锁单线程/受限执行器confined executor上的任务 A 向同一个执行器提交任务 B 并阻塞等待 B 的结果但执行器的线程都被 A 这类任务占满B 永远得不到调度。修复方向避免在受限执行器内同步等待同池任务或将提交与等待解耦异步回调、分离执行器。14. schema/元数据变更绕过后台任务持有的锁schema/元数据变更路径是否绕过了后台任务持有的 per-store flush 或 compaction 锁否则并发 flush 可能为已失效的 schema 写入文件/索引条目。后台 flush/compaction 在运行期间持有 per-store 的锁以保障它们读取的 schema 版本一致。如果前台 schema 变更不获取同一把锁就并行执行后台任务可能基于旧 schema 写出文件或索引条目产生幽灵数据。评审元数据变更路径时必须确认它进入与后台任务相同的锁域。四、生命周期与顺序Lifecycle Ordering——3 项15. 构造函数中逃逸this构造函数是否在构造完成前就启动线程、注册管理回调或启动执行器并捕获this构造函数执行期间对象尚未完全初始化字段可能仍为 null/默认值。若此时启动的线程/回调/执行器立即访问this的字段就会读到不完整的对象状态。修复将启动/注册延迟到构造完成之后如显式start()方法或保证被捕获的字段在启动前已初始化。16. 事件产生后才注册监听器代码是否在事件产生操作已经开始之后才注册监听器监听器注册存在窗口期事件可能在注册之前就已发生并被错过。清单给出的正确顺序是先注册再读状态——即先完成监听器注册再去读取/初始化状态避免注册晚于事件导致的丢失。反过来先读状态再注册也会因状态变化与注册之间的窗口而漏掉事件。17. 关停流程未 join 后台任务关停步骤是否向后台任务发送非阻塞的停止标志/信号后随即清理、截断或删除该任务依赖的状态——而没有 join 或等待任务结束协调者是否在调度循环完成注册所有预期接收者之前就开始处理回复非阻塞停止信号只是请求而非完成。发送信号后立即删除任务依赖的数据任务可能在执行中途发现数据消失产生悬挂引用或损坏状态。正确的关停顺序是发停止信号 →join 等待任务退出→ 再清理状态。后半句对应分布式场景协调者必须在所有预期参与者已完成注册之后再开始收集回复否则会漏掉迟到注册者的响应。五、状态管理State Management——4 项18. 无条件map.put(key, newValue)覆盖已有状态代码是否无条件map.put(key, newValue)而 map 中可能已经存在应被保留或合并的状态是否在未检查旧实例是否存在的情况下就新建对象表示某个实体无脑 put 会静默覆盖已有状态丢失并发写入者或历史累积的数据。若语义是合并/保留应使用merge、compute或先get再决定若语义是唯一实例应先查重。评审时要问这个 put 是新建还是更新如果是更新旧值去哪了19. 重置/截断/清空路径未原子更新全部伴生字段重置/截断/清空路径是否原子地更新了每一个伴生字段map 与 counter、union 缓存与源集合、dirty 标志与 buffer 偏移量状态往往由多个字段共同表达如缓存 它的计数器脏标志 缓冲区偏移。只重置其中一个、漏掉另一个会让状态自相矛盾——例如 counter 归零而 map 仍有内容或 buffer 偏移重置而 dirty 标志未清。所有伴生字段必须在同一临界区内、同一时刻全部更新。20. 清理/记账/通知与所属操作不在同一if块内作用域错配teardown 步骤、记账更新或通知是否落在与其相关的操作之外的if块作用域错配scope mismatch指相关语句被错误地放到条件分支之外或之外的分支内导致语义漂移例如某个操作仅在某些分支执行但其配套的清理/计数却无条件执行或反之。评审时对照每个if块检查其配套副作用是否与条件一一对应。21. 只读查询只查不可变快照集合查询/读取是否只查阅不可变的快照集合而存在一个尚未注册进快照的活的当前指针注册窗口会返回陈旧或空答案。这是快照滞后维护一份不可变快照用于读同时有一个最新指针但新实体被创建后尚未注册进快照。在注册之前的窗口内发起查询会得到陈旧或空结果。修复在实体对外可见发布引用之前先完成快照注册——即先注册后发布。六、计数与记账Counters Accounting——1 项22. 操作失败前先递增计数器且不回滚代码是否在可能失败的操作之前递增计数器且失败时不回滚成功路径是否缺少错误路径执行的清理会话移除、计数器递减、map 驱逐典型的先记账、后做事缺陷递增了 in-flight 计数随后操作失败计数未回滚导致计数漂移、资源泄漏或并发度误判。清单还要求检查对称性错误路径执行的清理如移除 session、递减计数、驱逐 map 条目成功路径是否也执行了两侧不一致会造成泄漏或双清。七、状态机State Machines——2 项23. 状态机分支遗漏其他分支都执行的副作用状态机处理器中是否有某个分支遗漏了其他所有分支都执行的必要副作用周期任务是否在!enabled时短路返回却没有撤回此前发布的状态状态机各分支常共享一个收尾动作发布事件、推进游标、更新指标。若新加的分支忘记执行它就会让状态机进入半完成状态。周期任务变体尤其隐蔽任务在!enabled时直接 return但之前 enabled 时发布的状态如已登记的标记、已广播的公告没有撤回导致已发布但实际已停用的不一致。评审状态机时逐一核对每个分支的副作用集合是否完全一致。24.condition.await()/Object.wait()缺少while(predicate)防护condition.await()或Object.wait()是否缺少while(predicate)循环防护以抵御伪唤醒spurious wakeupJava 规范允许等待在无通知的情况下被伪唤醒。若用if(predicate)判断后进入等待醒来后直接继续条件可能仍未满足。标准写法必须是synchronized (lock) { while (!conditionMet()) { // 必须用 while而非 if lock.wait(); } // 此时条件必然成立 }对Condition.await()同样适用await 可能因中断或伪唤醒提前返回必须放在while循环内重查谓词。这一条在 Cassandra 的高并发路径上随处可见例如 ColumnFamilyStore.java 中latch.await()、L1287 的writeBarrier.await()、L1449 的readBarrier.await()等同步屏障的使用——评审这类等待时重点确认谓词检查被包在循环里而非单次 if。误报清单以下模式不要标记并发审查最大的风险之一是把本来安全的模式误报为缺陷。清单明确给出四类绿灯模式评审时应直接放行CopyOnWriteArrayList/ConcurrentHashMap的迭代前者迭代的是不可变快照后者迭代是弱一致的两者都是为安全并发访问设计的构造函数中赋值、其他线程读取的不可变final字段final 字段在构造完成时有 happens-before 保证仅用于简单关停信号的 volatile boolean 标志单向停止标志是 volatile 的典型正确用法注意第 17 条信号之后的状态清理仍需 join但信号本身无需加锁请求作用域内、无异步交接的ThreadLocal请求线程内自生自灭的 ThreadLocal 不跨线程不存在可见性问题一旦出现异步交接线程池、回调跨线程才需要重新审视。这四类反模式清单与 24 项正向检查同等重要它划定了哪些看起来可疑但其实安全的边界能显著降低误报率让真正的高信号发现不被噪声淹没。落地如何用这份清单执行一次并发专项审查结合 shallow-review 技能 的流程将本清单投入实战时建议按以下步骤执行先理解后检查Phase 0用 23 句话概括补丁的意图是特性、修复、重构还是搬移列出 35 个这类改动可能出什么并发问题的假设再带着假设读清单——清单用于验证与扩展假设而不是机械地从第 1 条扫到第 24 条。标注代码形态在补丁中圈出共享状态、锁、集合、生命周期操作四类形态与第 124 条逐一比对把精力集中到与假设匹配的条目上。逐条验证并输出对每个命中项给出位置、置信度High/Medium/Low与哪里错了的一句话说明若无命中明确输出 No finding in my domain。合并与去重若多个专家在同一位置命中如本清单的第 6 条引用计数与 Resources 专家的泄漏检查重叠合并并提升置信度任一发现需通过三点测试构造确实存在于 diff、在当前可见上下文中确实可能触发、修复建议可执行。这份清单的价值正在于它把并发缺陷这个庞大主题压缩成了 24 个可操作的判断题。对照 Cassandra 源码中的正向实践SSTableReader 的selfRef/tryRef引用计数、ChunkCache 与 CQL3Type 的buffer.duplicate()、ColumnFamilyStore 的 await 屏障逐一印证后这些模式会内化为评审直觉——下一次读到一段共享状态代码时你会条件反射地追问读前持引用了吗快照用上了吗信号比数据先到了吗谓词在 while 里吗这就是并发审查的专家之道。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考