线程安全实战：从原子性、可见性到同步与无锁方案

1. 所有莫名其妙的Bug最后都指向了同一个问题先说一个很多开发都经历过的场景。系统上线前压测一切正常结果一上生产数据就开始悄悄出错。用户A的余额被扣了两次库存显示还有1件但下单永远失败日志里同一个订单号出现了两条记录。第一反应是数据库问题查半天没毛病最后才发现是代码里那个不起眼的共享变量被多个线程同时改了。这种问题有个统一的名字叫线程安全问题。线程安全说白了就是多个线程同时访问同一份数据时程序的最终结果不再符合预期。它不像接口报错那样直接更多时候是“数据脏了”却不自知等到影响业务才暴露。处理这类问题最难的从来不是技术本身而是“复现”和“定位”——大多数时候本地跑没问题测试环境跑没问题一旦并发量上来问题就随机出现。这篇文章不打算讲那些高深的理论只聊一个主线线程安全问题的根因是什么、常见的坑长什么样、以及我实际工程中用过的解决方案。适合刚接触多线程开发的初级工程师也适合那些已经写了一段时间并发代码、想系统梳理一遍的开发者。读完你能获得一套可以直接落地的排查思路和代码写法。2. 从根源理解为什么并发环境下代码会出错2.1 三个核心问题原子性、可见性、有序性线程安全问题虽然表现各异但最终根源都可以归结到三个底层问题上。理解了这三个你就能看懂后面所有的解决方案。第一个是原子性。原子性指的是一段操作要么全部执行完要么全部不执行中间不能被其他线程插入。经典例子就是i这一行代码看起来是一条语句实际在CPU层面拆成了三步读 i 的值、把值加1、把新值写回。两个线程同时执行i可能都读到了同一个旧值然后各自加1写回最终 i 只增加了1而不是2。这就是典型的“读-改-写”操作失去原子性。第二个是可见性。Java内存模型里每个线程有自己的工作内存也就是CPU缓存线程读变量时优先从缓存读。如果线程A修改了一个变量的值但没有及时刷新回主内存线程B读到的还是旧值。这种问题最隐蔽因为它不一定会导致程序崩溃只是让结果“有点不对劲”。比如一个布尔标志位用来控制线程是否停止主线程改了标志位工作线程却一直无限循环——这就是可见性没保证。第三个是有序性。为了提升性能编译器和CPU会对指令进行重排序。在单线程下这种重排不影响最终结果但多线程下就可能出问题。一个典型的例子是双重检查锁定创建单例如果没有正确的同步措施另一个线程可能拿到一个还没初始化完全的半成品对象。这三点经常叠加在一起出问题。比如前面说的i既有原子性问题也有可见性问题读取的可能是缓存里的旧值。所以解决线程安全问题本质上就是围绕这三个维度做文章。2.2 生活化类比火车票窗口与数据竞争为了让你更直观地理解我拿售票窗口打个比方。假设一个车站只有一个票务系统窗口A和窗口B同时售票。余票只剩最后一张窗口A的售票员查了下系统显示还有1张票正准备出票。同一瞬间窗口B的售票员也查了系统显示还有1张票也准备出票。两个人都没意识到对方正在操作结果就是同一张票卖给了两个人。在这个过程中查询票数、扣减库存、出票这个整体操作就是需要保证原子性的“临界区”。两个售票员各自的系统缓存就是工作内存他们之间的信息不同步就是可见性问题如果售票员为了省事先打票后登记那就是重排序。数据库或者专门的并发控制机制相当于给窗口加了一把锁一次只允许一个售票员操作。这个类比基本能解释80%的并发问题。你把代码里的每个共享变量想象成售票系统里的余票数把每个线程想象成售票员很多设计上的问题瞬间就清晰了。3. 最常见的几个“雷区”这些代码一写就出事3.1 计数器与累加操作i 看似简单实则危机四伏我印象最深的一个生产事故就是计数器。库存扣减用stock--来实现上线第二天就出现了超卖。当时第一反应是事务没生效排查了半天SQL没问题后来在代码里加了日志才发现多个线程同时执行stock--最终只减了一次。这种错误在代码Review里很难发现因为单看逻辑完全正常。我后来给自己定了个规矩凡是涉及共享可变变量的读改写操作一律不直接写裸代码要么用AtomicInteger要么加锁同步。尤其是计数器、总价累加、库存扣减、序号生成这四类场景高危中的高危。再补充一个容易被忽略的细节很多人以为用了Integer包装类就安全了实际上Integer对象本身是不可变的但引用可变。如果你的代码里有一个static Integer count多个线程对它做count操作实际上是在反复创建新对象不仅有并发问题还会引起不必要的GC压力。3.2 集合类的并发写入HashMap 扩容死循环与 ArrayList 越界如果说计数器问题是有惊无险那并发环境下使用非线程安全的集合类就是“炸得你头破血流”。知名度最高的当属HashMap在多线程下扩容时形成环形链表导致get操作死循环CPU飙到100%。虽然JDK 1.8之后改用了尾插法死循环问题被修复但数据丢失、脏读依旧存在。ArrayList的问题相对温和一些并发添加元素时可能报ArrayIndexOutOfBoundsException。当时看到这个异常第一反应是“下标算错了”后来查了源码才确认是多个线程同时扩容、给同一个下标赋值导致的。碰到这种场景我现在的处理方式很直接如果集合的确定性不高、无法保证只有一个线程写那就直接用并发容器。CopyOnWriteArrayList适合读多写少ConcurrentHashMap适合读多写多且键值对较多。虽然性能和普通的集合比有一点折扣但换来的是安全和省心这点开销完全值得。3.3 懒加载单例双重检查锁定到底行不行单例模式里有一个“经典中的经典”——双重检查锁定。这段代码看起来做足了同步先判断实例是否为空再进同步块进去再判断一次。但JDK 5之前这段代码是有问题的因为instance new Singleton()不是原子操作它分为分配内存、初始化对象、把引用指向内存地址三步。指令重排序后可能先把引用指向了未初始化的内存另一个线程拿到引用后调用方法直接空指针。JDK 5之后只要给instance加上volatile关键字这个问题就解决了。volatile在这里有两个作用禁止指令重排序同时保证可见性。我个人的经验是如果不是对性能有极端的追求直接用静态内部类的写法来实现单例代码简洁、线程安全、懒加载还不用考虑volatile这种细节。双重检查锁定可以当作一道面试题去理解但实战中它带来的性能收益用静态内部类完全能覆盖。4. 解决方案梯队从锁到无锁从重到轻4.1 同步机制synchronized 与 Lock 的选型标准解决线程安全最传统的手段就是加锁。synchronized从JDK 1.6开始经历过几次大改版引入了偏向锁、轻量级锁、重量级锁的升级路径大多数场景下性能已经不错。它最大的优势是使用简单修饰方法、修饰代码块、修饰静态方法三种用法覆盖了几乎所有需要同步的场景。Lock是java.util.concurrent包下的接口实现类主要是ReentrantLock。它比synchronized多了一些能力可中断获取锁、超时获取锁、公平锁、多个条件队列。这些能力在特定场景下很实用比如一个线程获取锁后需要等待另一个线程的信号用synchronized只能配wait/notify用Lock则可以配多个Condition逻辑更清晰。我的选型标准是这样的如果只是简单的互斥优先synchronized因为它写起来最不容易出错如果涉及到等待超时、可中断、多个条件变量或者需要公平锁避免线程饥饿用ReentrantLock。再往后如果只是需要读多写少场景下的并发访问ReentrantReadWriteLock和StampedLock可以作为进阶选择。4.2 锁的本质与锁粒度为什么缩小临界区比换锁更重要很多人以为用了synchronized就万事大吉其实锁的性能损耗主要在争用。两个甚至更多线程同时抢一把锁才会产生上下文切换和线程阻塞。如果临界区里的操作只有一行代码加锁的开销反而比操作本身更大。因此控制锁粒度是一门基本功。核心思路是把耗时操作移出临界区只对真正需要保护的那几行代码加锁。举个例子一个订单创建方法里先生成订单号再校验库存再扣减库存最后调用远程接口通知。如果整个方法都加锁远程调用期间锁一直被占着并发直接被卡死。正确做法是只对“校验并扣减库存”这段加锁其他操作全部放到临界区外面。这里有一个我踩过的坑把锁对象写成了局部变量。比如在方法内部Object lock new Object()然后synchronized(lock)。实际上这样每次进来都是不同的锁根本起不到互斥作用。锁对象必须是所有线程共享的同一个引用通常用局部变量是为了保护局部资源这种情况极少见多半是代码写岔了。4.3 无锁方案volatile 与原子类的正确打开方式有锁方案虽然安全但并不是唯一的出路。对于单一变量的读改写操作java.util.concurrent.atomic包提供了一系列原子类比如AtomicInteger、AtomicLong、AtomicReference。它们底层的核心是CASCompare And Swap指令也就是比较并交换先读当前值计算新值提交前再次检查当前值是否还是最初读到的那个值如果是就写入不是就重试。这个过程不需要锁住任何资源所以竞争特别激烈的时候性能反而比加锁好。volatile是解决可见性和有序性的利器但它不解决复合操作的原子性。用volatile修改变量的场景必须满足一个条件新值不依赖旧值。比如一个状态开关volatile boolean shutdown false主线程把它置为true工作线程检查到变化后退出循环这种用法是标准的。但如果是volatile int count两个线程同时执行count依然会丢数据。注意volatile适用场景可以记成一句话——“一个线程写多个线程读”。多个线程同时写同一个字段即使字段是volatile也必须加锁或使用原子类。在我实际项目里状态机推进、开关控制、双重检查锁定中的标志位都用volatile计数累加、序号生成、库存扣减都用原子类。这套组合基本覆盖了90%的无锁场景。4.4 线程封闭与不可变最省心的两种思路有一种解决并发问题的思路是从源头消灭共享——线程封闭。ThreadLocal就是这种思路的典型实现。每个线程通过ThreadLocal存取变量时数据实际上存放在线程自己的ThreadLocalMap里其他线程无法访问。最常见的用法就是存放用户会话信息、数据库连接、SimpleDateFormat实例。不过ThreadLocal有一个必须警惕的坑内存泄漏。如果使用线程池线程会复用ThreadLocal里存放的对象如果不及时清理会被后续任务读到脏数据问题也可能一直占据内存无法释放。我的习惯是用完立即调用remove()最好放在finally里。另外如果ThreadLocal里存的是线程不安全的对象本质上并没有解决问题只是把共享范围缩小到了单个线程——单线程内如果同一个对象被多次修改依然可能出现状态错乱。另一种更彻底的思路是尽量让对象不可变。不可变对象比如String、Integer、用final修饰字段的类天生是线程安全的因为它们的内部状态一旦创建就不能被修改多线程读取同一个不可变对象不会出现任何同步问题。设计一个自定义类时如果字段不会变化就加final。这不仅是代码风格问题更是并发安全的第一道防线。5. 实战记录一个库存扣减接口的线程安全改造全流程5.1 初始代码与问题定位下面这份代码是我从以前的项目里简化出来的非常典型。Service public class StockService { private int stock 100; public boolean deductStock(int quantity) { if (stock quantity) { // 模拟一些耗时操作比如检查、校验 stock stock - quantity; return true; } return false; } }这段代码的问题一目了然stock是共享可变变量if (stock quantity)和stock stock - quantity之间的执行是分离的。两个线程同时进来都判断库存充足都执行了扣减库存最终只减了一份但接口返回了两个“扣减成功”。在高并发的秒杀场景下这就是超卖。定位阶段我用了两个手段。第一个是压测并发100线程同时发起扣减请求跑完后检查库存值发现远小于预期。第二个是加日志把stock的读写操作都打印出来能看到同一个初始值被重复使用多次。实际上到了这一步已经能确认是并发问题了不需要再深挖。5.2 方案一同步方法改造最直接的做法是给方法加synchronizedpublic synchronized boolean deductStock(int quantity) { if (stock quantity) { stock stock - quantity; return true; } return false; }这个写法能解决问题但性能不理想。因为synchronized加在方法上等价于锁住整个对象导致所有调用该方法的线程只能串行执行。对于库存扣减这种高频操作这种改造能扛住业务量极小的系统稍微上点规模就会成为瓶颈。5.3 方案二同步代码块缩小锁范围如果扣减之外还有一些耗时操作比如远程校验、日志记录就应该把耗时逻辑移到临界区外面public boolean deductStock(int quantity) { // 模拟耗时操作比如远程校验 boolean valid checkRemote(); if (!valid) { return false; } synchronized (this) { if (stock quantity) { stock stock - quantity; return true; } } return false; }这样锁的范围只覆盖了“读库存、判断、扣减、返回”这段核心逻辑耗时操作完全不阻塞其他线程。这种改法相比全方法加锁并发能力会有明显的提升。不过这里有个细节要注意checkRemote()操作消耗的时间越长整体请求的响应时间就越长但其他线程不会被阻塞等待这个操作吞吐量保持在合理水平。如果业务允许多个线程同时校验和扣减这种改法已经足够了。5.4 方案三使用原子类实现无锁扣减如果库存本身可以接受“乐观”策略也就是先扣减再判断可以使用AtomicIntegerprivate AtomicInteger stock new AtomicInteger(100); public boolean deductStock(int quantity) { while (true) { int current stock.get(); if (current quantity) { return false; } if (stock.compareAndSet(current, current - quantity)) { return true; } } }这里的核心是compareAndSet如果当前库存没被其他线程修改过就更新否则返回false循环重试。这种方式没有加锁线程之间竞争比较激烈时大部分线程会在CAS失败后快速重试而不是阻塞等待唤醒所以在高并发场景下吞吐量反而好。但要注意一个业务层面的差异AtomicInteger的扣减并不包含“余额校验”这个业务逻辑所以需要自己在循环里判断。这里的while (true)相当于一个自旋重试机制只要线程没有其他事情可做自旋就是合理的。5.5 方案四数据库层面的兜底说句大实话高并发下把库存放在JVM内存里本身就是一个危险的设计。最终防线永远是数据库UPDATE stock_table SET stock stock - #{quantity} WHERE id #{productId} AND stock #{quantity}通过affectedRows是否等于1来判断扣减是否成功。这个SQL利用数据库行锁保证原子性是业务中真正兜底的手段。如果你在企业项目里碰到秒杀、抢购场景前端用分布式锁或者Redis限流后端用数据库条件更新JVM内存里的并发控制只是辅助提速核心的“保证不超卖”必须靠数据库。5.6 四种方案对比与选型建议方案优点缺点适用场景synchronized 方法写起来最简单不容易出错锁粒度大并发性能受限并发量低、方法内无耗时的场景synchronized 代码块锁粒度可控性能较好需要明确锁对象有锁竞争方法内有耗时操作只保护核心逻辑AtomicInteger CAS无锁高性能线程竞争时吞吐量好代码稍复杂业务校验需要自己写高频计数、库存扣减等单变量操作数据库条件更新绝对可靠跨进程安全数据库压力大性能上限低分布式场景、必须保证数据准确以我经验来看这四种方案不是互相替代的关系而是层层兜底的关系。代码里用原子类或锁控制JVM层面的并发数据库条件更新做最终数据一致性校验这样即使JVM层面出现bug也不会造成不可挽回的数据损失。6. 排查线程安全问题的思路怎么定位隐藏的并发Bug6.1 先看共享变量三个问题帮助定位排查线程安全问题的第一步不是看代码而是先问自己三句话这个变量是不是多线程共享的这个变量是否是可变的多个线程操作它的方式是否包含“读-改-写”这种复合操作这三个问题如果都回答“是”那几乎可以锁定问题就出在这里。回答过程中要特别小心一些“看起来安全”的写法比如把变量封装在一个对象里通过getter/setter访问并不意味着它线程安全只是把问题藏得更深了。6.2 复现并发问题的利器压测与日志线程安全问题最头疼的环节是复现。本地跑一次没问题没法定论。我推荐两个工具组合使用第一是压测工具比如JMeter或者自己写一个简单的并发测试类用CountDownLatch或者CyclicBarrier控制线程同时启动制造并发场景。第二是日志在共享变量的读、写位置都加日志打印当前线程名、时间和值跑一轮压测后对比日志基本能看到重复读、漏写等问题。如果一个bug在低并发下不出现而在高并发下出现不要怀疑是自己看错了大概率就是线程安全问题。这种情况下固定多线程数量、增大循环次数往往能稳定复现。6.3 工具协助JVisualVM 和 Thread Dump 的使用如果问题已经导致线程卡死或者CPU飙高jstack导出的线程快照会很有用。看线程状态如果多个线程处于BLOCKED状态且阻塞在同一个锁对象上说明存在严重的锁竞争如果发现RUNNABLE状态的线程执行到了HashMap.get之类的代码且CPU占用极高极可能就是并发修改导致的死循环。JVisualVM可以查看线程的实时运行状态和采样CPU配合线程dump使用定位效率会高很多。但工具只是在已经出问题的时候帮助你确认原因真正要避免线上故障还得靠代码层面的预防——写并发代码时多想一下有没有共享可变变量有没有复合操作。7. 避坑指南与独家实操心得7.1 锁对象选取别把可变字段当锁我见过不少人把锁对象设计成一个可变字段比如private Integer lock 1; public void doSomething() { synchronized (lock) { // ... } }这个写法极其危险因为lock字段一旦被修改比如lock新旧线程拿到的就不是同一个锁对象同步直接失效。更合适的做法是用private final Object lock new Object();作为专门的锁对象。这个对象不参与任何业务逻辑只负责充当同步的锁逻辑清晰也不会被意外修改。7.2 锁与事务的纠缠先提交还是先释放在一个Service方法上同时加事务注解和同步锁时顺序大有讲究。Spring事务默认的提交时机是方法返回前也就是说如果同步块内部执行完直接返回事务可能还没提交下一个线程就进入临界区读到的是旧数据。比较常用的处理方式有两种第一种是让同步代码块包裹的范围大于事务中的数据库操作也就是在方法最外层加锁事务提交完成后再释放锁第二种是将数据操作拆分成两个方法外层方法加锁内层方法加事务注解这样能保证锁释放时事务已经提交完成。具体用哪种需要看业务场景但核心原则是锁释放的时机不能早于数据可见的时机。7.3 String 做锁为什么等于没做String常量池是一个经典陷阱。两个线程使用内容相同的字符串常量作为锁对象比如synchronized(lock)它们拿到的其实是同一个对象引用这个锁会意外地扩大到所有使用同样字符串的代码段造成无意义的阻塞。更麻烦的是如果字符串是用new String(lock)创建的两个线程可能拿到两个不同的对象同步又完全失效。所以锁对象最好是一段代码专用不要用常量字符串。7.4 线程池下的并发问题ThreadLocal 必须清理线程池复用线程这个特性会让ThreadLocal的“线程隔离”演变成“任务隔离”失效。比如一个任务在ThreadLocal里存了用户信息没做清理下个任务复用了同一线程读取到的是上一个任务的用户信息正儿八经的串号问题。我的习惯是在任务开始和结束的地方分别set和remove()把remove()放在finally里保证任何异常路径也不会泄漏数据。8. 最后的建议从解决问题的思维升级到避免问题的思维刚入行时我解决问题的方式很直接——哪里报错改哪里。处理线程安全问题时就是加锁锁了还有问题就加更大的锁。后来踩的坑多了才明白真正成熟的并发代码靠的是设计层面上的规避而不是出了问题再去修补。写任何一段涉及共享数据的代码前先问自己一个问题这个数据真的需要被多个线程共享吗很多场景下其实可以有更好的选择。比如尽量使用局部变量让数据在线程栈上封闭比如尽量把对象设计成不可变的减少状态被修改的可能比如善用并发容器避免手动加锁带来的复杂性。如果实在绕不开共享可变数据那就明确选择一个解决方案并且知道为什么选它需要保证复合操作的原子性用同步代码块或者原子类只有一个线程写、多个线程读用volatile每个线程独享一份数据用ThreadLocal多个进程间需要保证一致性用数据库或者分布式锁。能做到这一步并发问题对你的困扰就已经消除了大半。最后分享一个我个人的小习惯代码评审时看到static修饰的变量先留个心眼看到i之类的操作自动警觉看到共享集合直接问一句“线程安全吗”。技术方案没有银弹但一个好的代码习惯可以帮你避开绝大多数并发炸弹。