做并发程序最痛苦的地方不是写不出代码而是写出来的代码明明测试全绿一到线上就翻车。我早期在项目里写过不少多线程模块最惨的一次是一个缓存组件单元测试跑了几十遍都过结果在压测时频繁出现数据不一致查了一个通宵才发现是共享Map的put和remove之间存在竞态。后来我彻底改掉了先写实现再补测试的习惯改用TDD的方式做并发程序设计踩过的坑确实少了很多。这篇文章就聊聊我在TDD模式下设计、实现并发程序的一些心得包括为什么会选择TDD、如何让“靠运气”的并发测试变成“可预期”的测试以及一个完整的实操案例。适合正在被多线程问题折磨、想系统化改进测试策略的同学参考。内容会尽量少讲虚的多放真实能用的步骤和代码。1. 为什么并发程序设计更需要TDD1.1 TDD的核心节奏在并发场景下的重新理解TDD测试驱动开发很多人觉得它只是一种“写代码的顺序”但真正用它来写并发程序的时候会发现它其实是一条“先想清楚行为再落实实现”的安全绳。标准的三步走——红、绿、重构——在并发场景里值得重新理解一遍。红不是简单地写一个会失败的测试而是把需求拆成一个可观察的具体行为。并发程序里行为往往是“在多线程同时调用时系统的状态依然正确”。这个行为如果不用测试固定下来代码写完之后你根本不知道自己有没有做对因为并发错误的出现时机完全是随机的。绿意味着用最简实现让这个行为成立。这一步在并发下有个常见误区很多同学一上来就用锁、CAS、队列这些高阶机制实现复杂得吓人。TDD的好处就是逼你先用最简单、显然正确的方式实现等测试通过后再去思考“这个简单实现能不能满足性能”。重构是TDD里最容易被跳过的一步但在并发场景下恰恰最关键。多线程代码的第一次实现往往性能一般比如直接给整个方法加synchronized。此时测试已经证明行为正确你就有底气把它重构为更细粒度的锁、无锁算法或分片结构再跑同样的测试验证没有引入回归。没有安全网的重构在并发代码里几乎等于冒险。1.2 并发对测试的三个“不友好”特性并发程序为什么难测我总结下来主要是三个特性在捣乱不确定性、交叉执行、内存可见性。先说不确定性。线程调度的顺序完全由操作系统决定同一个测试今天跑一百次都能过明天可能第一次就挂。这种随机性让很多人误以为“测试过了就安全”实际上只是没踩到那个时间窗口而已。再说交叉执行。两个线程同时读写同一个变量谁先谁后不同结果可能完全不同。测试必须有能力制造“特定的交叉场景”也就是主动让两个线程在某一步卡住再放行才能真正验证逻辑能不能防住竞态。最后是内存可见性。就算代码执行顺序看起来没问题CPU和JVM为了性能会做指令重排变量也可能被缓存到线程本地。你看到的测试结果和你以为的内存模型根本不是一回事。这也是并发测试比普通单元测试复杂得多的核心原因。1.3 为什么要先写测试再写实现在并发场景里后写测试的最大问题在于你已经知道实现的细节了写出来的测试很容易被实现牵着走。比如你知道自己用了ConcurrentHashMap测试就专门去验证replace这种操作结果测的是实现而不是行为。先写测试等于先定义“对外承诺”任何线程组合下返回值和状态都必须满足某些规则。这个承诺才是并发程序真正需要的东西。而且并发代码一旦写错修起来特别贵。竞态条件、死锁、活锁这些问题往往要跑到线上高并发时才暴露到那时查日志、找现场、回滚版本成本高到让人怀疑人生。TDD至少能把一部分行为层面的问题挡在提交之前让问题出现在本地IDE而不是生产环境。2. 并发TDD的设计拆解从需求到任务拆分2.1 并发需求的三要素安全性、活跃性、性能接到一个并发需求先别急着写测试。我会先用三个维度把需求拆清楚安全性、活跃性、性能。安全性就是“不管线程怎么交错数据都不能坏”。典型的检验方式是不变量比如计数器不能变成负数、集合里不能出现重复值、限流器的通过次数不能超过阈值。安全性的测试要写得非常苛刻各种并发的角度都要覆盖这通常是TDD的第一步。活跃性是“系统能继续往前走”。死锁、饥饿、活锁都属于活跃性问题。单纯靠正确性测试很难覆盖活跃性需要额外设计超时测试、循环检测之类的场景。比如一个线程池出现任务堆积但测试只验证任务结果不关注线程是否卡死这类bug就很容易漏掉。性能是“在满足安全和活跃的前提下吞吐量和延迟能接受”。这一条通常不是TDD里第一个要做的但重构阶段必须盯紧。TDD让你先解决安全和活跃再用性能测试去验证优化是否真的有效顺序不能反。2.2 测试三角形单元测试、并发正确性测试、压力测试我习惯把并发程序的测试分成三层像金字塔一样。最底层是行为层面的单元测试验证单个方法、单个类的功能逻辑。比如一个线程安全队列先测空队列、满队列、大小、迭代这些基础行为。这些测试在并发改造前后都必须保护住只要它们不绿上层测试再漂亮都是空谈。第二层是并发正确性测试重点验证多个线程同时操作时的不变量。这一层需要靠工具辅助比如CountDownLatch、CyclicBarrier、Awaitility甚至可以写一个可复现特定交错序列的测试模拟器。这一层是TDD的主战场也是我会花最多时间的地方。最顶层是压力测试和性能测试。比如用1万个线程、反复跑100万次看系统能不能扛住。这层能发现偶发问题但它不适合作为日常回归测试因为随机性太大跑得也慢。TDD关注的是把底层和第二层做扎实让顶层测试跑起来时有底气。2.3 工具选型怎么组合使用JUnit、Awaitility、JCStress工具选型我给出几个常用组合不是唯一答案但很实用。第一个组合是JUnit加上手写的并发栅栏。利用CountDownLatch把线程对齐到同一个出发点这种写法灵活、可控适合用在正确性测试里。下面实操部分会具体演示。第二个组合是Awaitility。实测下来很稳它的API是等一个异步条件为真失败时候会把等待期间的日志打出来排查随机问题的时候特别有用。不要自己写轮询等待又慢又不稳定而且出了异常还容易把测试卡死。第三个组合是JCStress。这是JMM层面的压力工具专门用来测一些高并发下才暴露的内存可见性问题。它支持定义状态类然后自动多线程跑并生成结果分布。适合作为JMM推理的交叉验证工具。做Go的话可以看go test自带的race detector形态不同但思路一样。工具本身不神秘关键是你得知道每层该用哪个别拿压力测试当单元测试用。3. 实操用TDD从零实现一个线程安全限流器3.1 第一颗红灯先写行为测试我用一个具体案例完整演示一遍。需求实现一个限流器RateLimiter支持tryAcquire方法固定窗口内最多允许N次通过超出部分拒绝。第一步写行为测试。注意先不写任何实现类public class RateLimiterTest { Test public void should_accept_within_limit() { RateLimiter limiter new RateLimiter(3); assertTrue(limiter.tryAcquire()); assertTrue(limiter.tryAcquire()); assertTrue(limiter.tryAcquire()); } Test public void should_reject_when_exceed_limit() { RateLimiter limiter new RateLimiter(3); limiter.tryAcquire(); limiter.tryAcquire(); limiter.tryAcquire(); assertFalse(limiter.tryAcquire()); } }这个测试看起来简单但它的价值在于定义了外部行为允许多少次、超过怎么办。这个行为写清楚了后面不管是加锁、换CAS、改成分布式实现测试都不用变。这就是行为先行的意义也是TDD和“后补测试”最大的区别。3.2 最小绿灯synchronized版本实现让测试通过的最小实现就是给计数器加锁public class RateLimiter { private final int limit; private int count; public RateLimiter(int limit) { this.limit limit; this.count 0; } public synchronized boolean tryAcquire() { if (count limit) { return false; } count; return true; } }这里用了synchronized简单到不能再简单但行为是正确的。注意这个阶段不要过度设计。很多人一开始就写AtomicInteger、Semaphore、Redis的Lua脚本不是说不好而是在行为还没被测试保护住之前复杂实现一旦出错你很难定位是哪一个环节出了问题。先绿灯再重构节奏是对的。3.3 并发测试让线程真正“同时”发起单线程测试通过后接下来要写并发正确性测试。关键点在于“同时”二字。如果只是起10个线程然后让它们自己跑由于线程启动时间不同很可能第一个线程执行完后面的线程才刚启动竞态根本暴露不出来。我常用CountDownLatch来做起点同步Test public void should_allow_only_limit_requests_concurrently() throws InterruptedException { int threadCount 10; RateLimiter limiter new RateLimiter(3); AtomicInteger accepted new AtomicInteger(); CountDownLatch ready new CountDownLatch(threadCount); CountDownLatch start new CountDownLatch(1); CountDownLatch done new CountDownLatch(threadCount); for (int i 0; i threadCount; i) { new Thread(() - { try { ready.countDown(); start.await(); if (limiter.tryAcquire()) { accepted.incrementAndGet(); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { done.countDown(); } }).start(); } ready.await(); start.countDown(); done.await(); assertEquals(3, accepted.get()); }三个CountDownLatch各司其职ready等所有线程就位start统一放行done等全部结束。这样所有线程会尽量同时踏入tryAcquire竞态才有机会暴露。如果实现里没有synchronized用一个普通int当计数器这个测试跑起来accepted大概率会超过3这就是并发正确性测试的价值。3.4 重构升级Semaphore与AtomicInteger的取舍绿灯之后进入重构。synchronized版本的问题是粒度太大所有线程串行进去限流器本身成了瓶颈。在高并发下锁竞争会拖慢整个系统。重构方向可以换成Semaphorepublic class RateLimiter { private final Semaphore semaphore; public RateLimiter(int limit) { this.semaphore new Semaphore(limit); } public boolean tryAcquire() { return semaphore.tryAcquire(); } }Semaphore本身就是并发原语tryAcquire是原子操作行为跟之前一致。注意重构完成后必须把前面所有测试重新跑一遍确保绿灯还在。我再加一个并发测试专门验证当信号量用完后不再放行这样重构的信任度才够。这里补充一个个人心得Semaphore适合“同时最多N个线程进入”的语义但如果限流逻辑里有额外状态比如按秒计数、支持滑动窗口Semaphore就不够用了需要自己用AtomicLong加时间戳实现。TDD的好处是这些替换不会破坏外层行为因为测试已经把行为锁死了。4. 并发TDD的实现细节与边界处理4.1 如何测试死锁和活锁死锁的经典测试手段是超时。JUnit里给测试方法加个超时比如Test(timeout 2000)如果代码卡死测试自动失败。但要注意超时测试只能证明“当前这个用例卡了”不能证明系统一定没有死锁更精确的做法是注入有问题的线程执行轨迹。我试过用ThreadMXBean检测死锁它能在运行时发现JVM层面的死锁循环再结合测试输出把死锁线程的堆栈打出来。这对定位复杂的交叉锁场景很有用。活锁比死锁更隐蔽线程不阻塞但一直互相让测试表现往往是“跑得慢但能通过”。对这种问题我会用计数器检测进展规定一个时间段内必须完成多少有效操作否则判失败。4.2 指令重排与内存可见性问题怎么测普通测试很难稳定抓到指令重排问题因为重排发生的概率可能只有百万分之一。这时候JCStress这类压力工具反而比手写测试靠谱。我一般这样用写一个状态类定义两个线程各自执行的操作序列然后用JCStress跑几千上万次观察所有可能的结果分布。如果出现了理论JMM不允许的结果就说明存在可见性或重排问题。日常项目里我还习惯加一条纪律共享可变字段必须加volatile或者保证通过锁、原子类来访问。这条纪律看着简单但能消灭大量偶发问题。与其依赖测试去抓重排不如从编码规范上把风险源头堵住测试用来验证剩下的边界。4.3 时间相关测试的实际技巧并发程序里时间相关逻辑特别难测比如“5秒后超时”“1分钟内过期”。真实等待既不快也不稳定。我的做法是把时间抽象成一个Clock接口生产代码用真实时钟测试里注入假时钟手动拨快时间。这样测试瞬间完成完全可控不受睡眠等待影响。比如实现一个带过期时间的缓存内部判断是否过期时不要直接调System.currentTimeMillis()而是通过Clock接口获取当前时间。测试就能把时钟拨到过期节点验证get返回null。这个技巧看起来小但对稳定复现并发场景非常关键因为真实时间充满不确定性测试里一旦依赖真实sleep随机失败率会直线上升。5. 常见问题与排查技巧实录5.1 测试偶发失败怎么排查偶发失败是所有并发程序的噩梦我的排查步骤是固定的。第一步保留现场。测试里尽可能把失败时的关键数据打到日志里包括前置条件、当前状态、每个线程的执行路径。没有现场偶发问题就是瞎猜。第二步增大压力。把循环次数从100调到1万线程数从4调到16多数竞态会在更高并发下更频繁地出现。如果压力上去后问题稳定复现那就等于有了一个可靠的“红”测试。第三步隔离变量。锁、共享状态、线程池一次只改一个反复跑同一测试确认问题是不是由一个变量引起的。这一步很枯燥但能快速缩小范围。第四步考虑引入专门的确定性复现工具。比如用自定义的线程交错控制框架让特定执行序列被强制复现。这种做法写起来费时但对那种只在1%概率下出现的bug是唯一靠谱的收口方式。5.2 经典坑位速查坑位现象排查方向预防手段测试里没做起点同步并发测试形同虚设检查是否所有线程都await同一个栅栏用CountDownLatch/CyclicBarrier对齐起点共享字段没加volatile偶发读到过期值检查状态可见性加volatile或者用原子类锁顺序不一致死锁偶发出现抓取线程堆栈统一锁顺序或用tryLock超时用sleep等待异步结果测试慢且随机失败检查等待机制用Awaitility等条件等待把性能测试当正确性测试结果不稳定区分两层目标TDD只写行为测试压测单独跑重构后漏跑老测试回归发现晚检查CI里的测试任务每次重构后全量跑测试这张表是我自己踩坑总结出来的不一定覆盖所有情况但按照这个方向排查效率会比毫无头绪地乱试高很多。5.3 三个我给自己的原则最后分享三个我在实践中给自己定的原则不是教条是真被坑出来的。第一绝不在测试里依赖真实的随机调度来证明正确性。能控制线程交错就控制不能控制的场景就加大压力多跑但脑子要清楚压测是概率性的永远不能说“跑过了就证明对”。第二复杂并发原语的正确性不要靠“相信官方实现”要靠边界测试。比如AQS、Channel、Actor这些机制本身就难写我宁可在它们之上多写几个极限状态的测试比如0容量、重复关闭、异常路径也不愿意上线后靠日志猜。第三日志就是测试的一部分。并发程序里裸测试的输出往往不够定位问题我会在每个关键操作前后埋点记录线程名、时间戳和状态。这不是给生产环境用的业务日志而是测试失败时可以快速回放执行轨迹的现场记录。我在实际项目里把TDD引入并发模块之后最大的改变不是测试数量变多而是设计顺序变了。以前是先写一个并发类再绞尽脑汁想怎么测它现在是先想清楚这个类对外承诺什么行为再让测试拴住这个承诺实现反而简单了。并发编程真正的难点从来不是API用得不熟而是对“并发下会发生什么”缺乏敬畏而TDD恰好能逼着你把这种敬畏变成具体的验证步骤。如果你正被一个偶发的线上并发事故搞得焦头烂额我的建议很直接别急着加锁先停下来写一个测试把事故的行为复现成红灯再开始动手。这个动作可能只需要半个小时但它会给你一个可控的起点。等绿灯亮起你自然知道下一步该怎么走。
用TDD设计并发程序：从竞态到线程安全限流器的实践指南
做并发程序最痛苦的地方不是写不出代码而是写出来的代码明明测试全绿一到线上就翻车。我早期在项目里写过不少多线程模块最惨的一次是一个缓存组件单元测试跑了几十遍都过结果在压测时频繁出现数据不一致查了一个通宵才发现是共享Map的put和remove之间存在竞态。后来我彻底改掉了先写实现再补测试的习惯改用TDD的方式做并发程序设计踩过的坑确实少了很多。这篇文章就聊聊我在TDD模式下设计、实现并发程序的一些心得包括为什么会选择TDD、如何让“靠运气”的并发测试变成“可预期”的测试以及一个完整的实操案例。适合正在被多线程问题折磨、想系统化改进测试策略的同学参考。内容会尽量少讲虚的多放真实能用的步骤和代码。1. 为什么并发程序设计更需要TDD1.1 TDD的核心节奏在并发场景下的重新理解TDD测试驱动开发很多人觉得它只是一种“写代码的顺序”但真正用它来写并发程序的时候会发现它其实是一条“先想清楚行为再落实实现”的安全绳。标准的三步走——红、绿、重构——在并发场景里值得重新理解一遍。红不是简单地写一个会失败的测试而是把需求拆成一个可观察的具体行为。并发程序里行为往往是“在多线程同时调用时系统的状态依然正确”。这个行为如果不用测试固定下来代码写完之后你根本不知道自己有没有做对因为并发错误的出现时机完全是随机的。绿意味着用最简实现让这个行为成立。这一步在并发下有个常见误区很多同学一上来就用锁、CAS、队列这些高阶机制实现复杂得吓人。TDD的好处就是逼你先用最简单、显然正确的方式实现等测试通过后再去思考“这个简单实现能不能满足性能”。重构是TDD里最容易被跳过的一步但在并发场景下恰恰最关键。多线程代码的第一次实现往往性能一般比如直接给整个方法加synchronized。此时测试已经证明行为正确你就有底气把它重构为更细粒度的锁、无锁算法或分片结构再跑同样的测试验证没有引入回归。没有安全网的重构在并发代码里几乎等于冒险。1.2 并发对测试的三个“不友好”特性并发程序为什么难测我总结下来主要是三个特性在捣乱不确定性、交叉执行、内存可见性。先说不确定性。线程调度的顺序完全由操作系统决定同一个测试今天跑一百次都能过明天可能第一次就挂。这种随机性让很多人误以为“测试过了就安全”实际上只是没踩到那个时间窗口而已。再说交叉执行。两个线程同时读写同一个变量谁先谁后不同结果可能完全不同。测试必须有能力制造“特定的交叉场景”也就是主动让两个线程在某一步卡住再放行才能真正验证逻辑能不能防住竞态。最后是内存可见性。就算代码执行顺序看起来没问题CPU和JVM为了性能会做指令重排变量也可能被缓存到线程本地。你看到的测试结果和你以为的内存模型根本不是一回事。这也是并发测试比普通单元测试复杂得多的核心原因。1.3 为什么要先写测试再写实现在并发场景里后写测试的最大问题在于你已经知道实现的细节了写出来的测试很容易被实现牵着走。比如你知道自己用了ConcurrentHashMap测试就专门去验证replace这种操作结果测的是实现而不是行为。先写测试等于先定义“对外承诺”任何线程组合下返回值和状态都必须满足某些规则。这个承诺才是并发程序真正需要的东西。而且并发代码一旦写错修起来特别贵。竞态条件、死锁、活锁这些问题往往要跑到线上高并发时才暴露到那时查日志、找现场、回滚版本成本高到让人怀疑人生。TDD至少能把一部分行为层面的问题挡在提交之前让问题出现在本地IDE而不是生产环境。2. 并发TDD的设计拆解从需求到任务拆分2.1 并发需求的三要素安全性、活跃性、性能接到一个并发需求先别急着写测试。我会先用三个维度把需求拆清楚安全性、活跃性、性能。安全性就是“不管线程怎么交错数据都不能坏”。典型的检验方式是不变量比如计数器不能变成负数、集合里不能出现重复值、限流器的通过次数不能超过阈值。安全性的测试要写得非常苛刻各种并发的角度都要覆盖这通常是TDD的第一步。活跃性是“系统能继续往前走”。死锁、饥饿、活锁都属于活跃性问题。单纯靠正确性测试很难覆盖活跃性需要额外设计超时测试、循环检测之类的场景。比如一个线程池出现任务堆积但测试只验证任务结果不关注线程是否卡死这类bug就很容易漏掉。性能是“在满足安全和活跃的前提下吞吐量和延迟能接受”。这一条通常不是TDD里第一个要做的但重构阶段必须盯紧。TDD让你先解决安全和活跃再用性能测试去验证优化是否真的有效顺序不能反。2.2 测试三角形单元测试、并发正确性测试、压力测试我习惯把并发程序的测试分成三层像金字塔一样。最底层是行为层面的单元测试验证单个方法、单个类的功能逻辑。比如一个线程安全队列先测空队列、满队列、大小、迭代这些基础行为。这些测试在并发改造前后都必须保护住只要它们不绿上层测试再漂亮都是空谈。第二层是并发正确性测试重点验证多个线程同时操作时的不变量。这一层需要靠工具辅助比如CountDownLatch、CyclicBarrier、Awaitility甚至可以写一个可复现特定交错序列的测试模拟器。这一层是TDD的主战场也是我会花最多时间的地方。最顶层是压力测试和性能测试。比如用1万个线程、反复跑100万次看系统能不能扛住。这层能发现偶发问题但它不适合作为日常回归测试因为随机性太大跑得也慢。TDD关注的是把底层和第二层做扎实让顶层测试跑起来时有底气。2.3 工具选型怎么组合使用JUnit、Awaitility、JCStress工具选型我给出几个常用组合不是唯一答案但很实用。第一个组合是JUnit加上手写的并发栅栏。利用CountDownLatch把线程对齐到同一个出发点这种写法灵活、可控适合用在正确性测试里。下面实操部分会具体演示。第二个组合是Awaitility。实测下来很稳它的API是等一个异步条件为真失败时候会把等待期间的日志打出来排查随机问题的时候特别有用。不要自己写轮询等待又慢又不稳定而且出了异常还容易把测试卡死。第三个组合是JCStress。这是JMM层面的压力工具专门用来测一些高并发下才暴露的内存可见性问题。它支持定义状态类然后自动多线程跑并生成结果分布。适合作为JMM推理的交叉验证工具。做Go的话可以看go test自带的race detector形态不同但思路一样。工具本身不神秘关键是你得知道每层该用哪个别拿压力测试当单元测试用。3. 实操用TDD从零实现一个线程安全限流器3.1 第一颗红灯先写行为测试我用一个具体案例完整演示一遍。需求实现一个限流器RateLimiter支持tryAcquire方法固定窗口内最多允许N次通过超出部分拒绝。第一步写行为测试。注意先不写任何实现类public class RateLimiterTest { Test public void should_accept_within_limit() { RateLimiter limiter new RateLimiter(3); assertTrue(limiter.tryAcquire()); assertTrue(limiter.tryAcquire()); assertTrue(limiter.tryAcquire()); } Test public void should_reject_when_exceed_limit() { RateLimiter limiter new RateLimiter(3); limiter.tryAcquire(); limiter.tryAcquire(); limiter.tryAcquire(); assertFalse(limiter.tryAcquire()); } }这个测试看起来简单但它的价值在于定义了外部行为允许多少次、超过怎么办。这个行为写清楚了后面不管是加锁、换CAS、改成分布式实现测试都不用变。这就是行为先行的意义也是TDD和“后补测试”最大的区别。3.2 最小绿灯synchronized版本实现让测试通过的最小实现就是给计数器加锁public class RateLimiter { private final int limit; private int count; public RateLimiter(int limit) { this.limit limit; this.count 0; } public synchronized boolean tryAcquire() { if (count limit) { return false; } count; return true; } }这里用了synchronized简单到不能再简单但行为是正确的。注意这个阶段不要过度设计。很多人一开始就写AtomicInteger、Semaphore、Redis的Lua脚本不是说不好而是在行为还没被测试保护住之前复杂实现一旦出错你很难定位是哪一个环节出了问题。先绿灯再重构节奏是对的。3.3 并发测试让线程真正“同时”发起单线程测试通过后接下来要写并发正确性测试。关键点在于“同时”二字。如果只是起10个线程然后让它们自己跑由于线程启动时间不同很可能第一个线程执行完后面的线程才刚启动竞态根本暴露不出来。我常用CountDownLatch来做起点同步Test public void should_allow_only_limit_requests_concurrently() throws InterruptedException { int threadCount 10; RateLimiter limiter new RateLimiter(3); AtomicInteger accepted new AtomicInteger(); CountDownLatch ready new CountDownLatch(threadCount); CountDownLatch start new CountDownLatch(1); CountDownLatch done new CountDownLatch(threadCount); for (int i 0; i threadCount; i) { new Thread(() - { try { ready.countDown(); start.await(); if (limiter.tryAcquire()) { accepted.incrementAndGet(); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { done.countDown(); } }).start(); } ready.await(); start.countDown(); done.await(); assertEquals(3, accepted.get()); }三个CountDownLatch各司其职ready等所有线程就位start统一放行done等全部结束。这样所有线程会尽量同时踏入tryAcquire竞态才有机会暴露。如果实现里没有synchronized用一个普通int当计数器这个测试跑起来accepted大概率会超过3这就是并发正确性测试的价值。3.4 重构升级Semaphore与AtomicInteger的取舍绿灯之后进入重构。synchronized版本的问题是粒度太大所有线程串行进去限流器本身成了瓶颈。在高并发下锁竞争会拖慢整个系统。重构方向可以换成Semaphorepublic class RateLimiter { private final Semaphore semaphore; public RateLimiter(int limit) { this.semaphore new Semaphore(limit); } public boolean tryAcquire() { return semaphore.tryAcquire(); } }Semaphore本身就是并发原语tryAcquire是原子操作行为跟之前一致。注意重构完成后必须把前面所有测试重新跑一遍确保绿灯还在。我再加一个并发测试专门验证当信号量用完后不再放行这样重构的信任度才够。这里补充一个个人心得Semaphore适合“同时最多N个线程进入”的语义但如果限流逻辑里有额外状态比如按秒计数、支持滑动窗口Semaphore就不够用了需要自己用AtomicLong加时间戳实现。TDD的好处是这些替换不会破坏外层行为因为测试已经把行为锁死了。4. 并发TDD的实现细节与边界处理4.1 如何测试死锁和活锁死锁的经典测试手段是超时。JUnit里给测试方法加个超时比如Test(timeout 2000)如果代码卡死测试自动失败。但要注意超时测试只能证明“当前这个用例卡了”不能证明系统一定没有死锁更精确的做法是注入有问题的线程执行轨迹。我试过用ThreadMXBean检测死锁它能在运行时发现JVM层面的死锁循环再结合测试输出把死锁线程的堆栈打出来。这对定位复杂的交叉锁场景很有用。活锁比死锁更隐蔽线程不阻塞但一直互相让测试表现往往是“跑得慢但能通过”。对这种问题我会用计数器检测进展规定一个时间段内必须完成多少有效操作否则判失败。4.2 指令重排与内存可见性问题怎么测普通测试很难稳定抓到指令重排问题因为重排发生的概率可能只有百万分之一。这时候JCStress这类压力工具反而比手写测试靠谱。我一般这样用写一个状态类定义两个线程各自执行的操作序列然后用JCStress跑几千上万次观察所有可能的结果分布。如果出现了理论JMM不允许的结果就说明存在可见性或重排问题。日常项目里我还习惯加一条纪律共享可变字段必须加volatile或者保证通过锁、原子类来访问。这条纪律看着简单但能消灭大量偶发问题。与其依赖测试去抓重排不如从编码规范上把风险源头堵住测试用来验证剩下的边界。4.3 时间相关测试的实际技巧并发程序里时间相关逻辑特别难测比如“5秒后超时”“1分钟内过期”。真实等待既不快也不稳定。我的做法是把时间抽象成一个Clock接口生产代码用真实时钟测试里注入假时钟手动拨快时间。这样测试瞬间完成完全可控不受睡眠等待影响。比如实现一个带过期时间的缓存内部判断是否过期时不要直接调System.currentTimeMillis()而是通过Clock接口获取当前时间。测试就能把时钟拨到过期节点验证get返回null。这个技巧看起来小但对稳定复现并发场景非常关键因为真实时间充满不确定性测试里一旦依赖真实sleep随机失败率会直线上升。5. 常见问题与排查技巧实录5.1 测试偶发失败怎么排查偶发失败是所有并发程序的噩梦我的排查步骤是固定的。第一步保留现场。测试里尽可能把失败时的关键数据打到日志里包括前置条件、当前状态、每个线程的执行路径。没有现场偶发问题就是瞎猜。第二步增大压力。把循环次数从100调到1万线程数从4调到16多数竞态会在更高并发下更频繁地出现。如果压力上去后问题稳定复现那就等于有了一个可靠的“红”测试。第三步隔离变量。锁、共享状态、线程池一次只改一个反复跑同一测试确认问题是不是由一个变量引起的。这一步很枯燥但能快速缩小范围。第四步考虑引入专门的确定性复现工具。比如用自定义的线程交错控制框架让特定执行序列被强制复现。这种做法写起来费时但对那种只在1%概率下出现的bug是唯一靠谱的收口方式。5.2 经典坑位速查坑位现象排查方向预防手段测试里没做起点同步并发测试形同虚设检查是否所有线程都await同一个栅栏用CountDownLatch/CyclicBarrier对齐起点共享字段没加volatile偶发读到过期值检查状态可见性加volatile或者用原子类锁顺序不一致死锁偶发出现抓取线程堆栈统一锁顺序或用tryLock超时用sleep等待异步结果测试慢且随机失败检查等待机制用Awaitility等条件等待把性能测试当正确性测试结果不稳定区分两层目标TDD只写行为测试压测单独跑重构后漏跑老测试回归发现晚检查CI里的测试任务每次重构后全量跑测试这张表是我自己踩坑总结出来的不一定覆盖所有情况但按照这个方向排查效率会比毫无头绪地乱试高很多。5.3 三个我给自己的原则最后分享三个我在实践中给自己定的原则不是教条是真被坑出来的。第一绝不在测试里依赖真实的随机调度来证明正确性。能控制线程交错就控制不能控制的场景就加大压力多跑但脑子要清楚压测是概率性的永远不能说“跑过了就证明对”。第二复杂并发原语的正确性不要靠“相信官方实现”要靠边界测试。比如AQS、Channel、Actor这些机制本身就难写我宁可在它们之上多写几个极限状态的测试比如0容量、重复关闭、异常路径也不愿意上线后靠日志猜。第三日志就是测试的一部分。并发程序里裸测试的输出往往不够定位问题我会在每个关键操作前后埋点记录线程名、时间戳和状态。这不是给生产环境用的业务日志而是测试失败时可以快速回放执行轨迹的现场记录。我在实际项目里把TDD引入并发模块之后最大的改变不是测试数量变多而是设计顺序变了。以前是先写一个并发类再绞尽脑汁想怎么测它现在是先想清楚这个类对外承诺什么行为再让测试拴住这个承诺实现反而简单了。并发编程真正的难点从来不是API用得不熟而是对“并发下会发生什么”缺乏敬畏而TDD恰好能逼着你把这种敬畏变成具体的验证步骤。如果你正被一个偶发的线上并发事故搞得焦头烂额我的建议很直接别急着加锁先停下来写一个测试把事故的行为复现成红灯再开始动手。这个动作可能只需要半个小时但它会给你一个可控的起点。等绿灯亮起你自然知道下一步该怎么走。
