1. 先把线程安全的敌人认清竞态条件是怎么发生的聊多线程安全之前我一直觉得有个问题必须先说透很多人一听到线程安全就想到加锁好像锁能解决一切。但实际上锁只是手段真正的麻烦是竞态条件。而竞态条件的产生往往不是因为代码逻辑复杂而是因为我们对共享可变状态缺少警惕。1.1 一个计数器足以讲清楚为什么线程会打架先看一个最经典的例子两个线程同时对同一个整数变量执行count。你已经听过无数遍会出现问题但具体是怎么出现的问题我拿 Java 的字节码层面拆开看count不是一条原子指令它实际上是读取 count 的值 - 把值加 1 - 把新值写回三步。当线程 A 读取到 count10线程 B 也读取到 count10然后 A 写回 11B 写回 11两次累加只让 count 从 10 变成了 11丢失了一次更新。这就叫丢失更新。更隐蔽的问题是可见性线程 A 修改了 count但线程 B 可能读到的还是旧值因为 CPU 缓存和寄存器没有及时同步。还有重排序带来的乱序问题编译器为了优化可能把无依赖的语句交换顺序这在单线程下没问题在多线程下可能让另一个线程看到尚未完成的状态。这三者——原子性、可见性、有序性——是线程安全里绕不开的三座大山。你如果不能清晰地指出代码里哪个操作破坏了这三者那后面所有技术手段都容易用错地方。1.2 把抽象概念映射到生活场景我经常用一个多人协作写文档的比喻来解释这三个性质原子性文档里只有一个共享的计数器两个人同时按加一按钮最终只能加一而不是加二。这要求这个按钮的响应必须是不可分割的。可见性你在自己的屏幕上修改了数字但另一个人的屏幕还显示旧数字直到刷新。这就像 CPU 缓存和主内存之间的同步延迟。有序性你先把文档的目录更新了再更新正文内容但另一个读者可能先看到新目录、旧正文形成一种不存在的中间状态。如果代码中出现了共享可变对象比如全局集合、缓存、数据源连接那所有访问这个对象的地方都必须考虑这三个性质。反过来如果这个对象真的只是线程私有的那就根本不存在线程安全问题。所以识别共享和可变两个属性是保证线程安全的第一步。1.3 哪些代码天生就危险先列一个检查清单在实际开发中我一般会在 code review 时自动扫描这几种模式全局静态变量、单例对象中的成员变量尤其是被多个线程读写。集合类如HashMap、ArrayList如果没有同步包装多线程同时写很容易出问题。懒加载的单例比如if (instance null) { instance new X(); }两个线程同时进入判断会导致创建多个实例。简单类型如int、long的读写就算不加锁在 32 位虚拟机下long的读写可能被拆成两次 32 位操作产生撕裂值。还有更隐蔽的复合操作比如检查然后执行check-then-act、读取-修改-写回read-modify-write哪怕每一步单独看是原子的组合起来也不是。我有一个心得体会不要试图把每个危险点都背下来而是养成一个习惯——每次写变量或调用 API 时都问一句这个变量会不会被两个线程同时碰如果答案是可能就必须用线程安全的手段。这个习惯比掌握任何锁都重要。2. 加锁之外的安全手段原子类、不可变对象与线程封闭2.1 synchronized 和 ReentrantLock锁的粒度决定性能与正确性既然竞态条件这么普遍那第一反应自然是加锁。Java 里最常见的两类锁是synchronized和ReentrantLock。synchronized简单可靠方法或代码块加完锁之后同一时刻只有一个线程能进入。但它有两个明显短板一是不能中断等待锁的线程二是默认不支持超时一旦另一个线程持有锁不释放其他线程只能无限等下去。ReentrantLock则提供了tryLock(timeout)、lockInterruptibly等方法灵活性更好但用法也更复杂需要手动解锁强烈建议配合finally释放锁否则一旦中间抛异常锁就永远解不开。加锁最核心的问题不是选哪个 API而是锁的粒度。我见过很多人把整个方法体都锁住比如一个方法只用到局部变量却因为类里有一个共享的日志对象就把整个方法上锁导致所有调用串行化性能直线下降。锁的粒度越粗并发度越低锁的粒度越细代码复杂度越高还容易引入死锁。比较务实的做法是先找出真正的共享可变状态再决定锁罩住的范围只锁保护这个状态的最短代码路径。另外要注意锁的可重入性。synchronized和ReentrantLock都是可重入的也就是说同一个线程可以重复加同一把锁。但如果你自己实现一个简单的布尔标志来模拟锁遇到递归或嵌套调用就会死锁。这是我踩过的坑曾经为了省事用AtomicBoolean做了一个自旋锁结果在回调里又调用了一个需要同一个锁的方法程序直接卡死。后来才明白锁的语义远比加锁-解锁两个动作复杂优先用成熟库而不是自己发明轮子。2.2 AtomicInteger 真的线程安全吗CAS 与它的局限热搜里有atomicinteger线程安全吗这个问题的答案没那么绝对。Java 的AtomicInteger通过 CASCompare-And-Swap实现它保证单个incrementAndGet()操作是原子的也就是说不会出现前面说的丢失更新。所以要回答原子类线程安全吗要看在什么场景如果多个线程只是各自调用incrementAndGet()那确实是线程安全的但如果你的业务逻辑是先读取当前值根据值做一些判断再更新比如如果当前值小于 100 才进行累加那这个复合操作就不是原子的即使每个单独操作都是原子的组合起来依然有竞态。CAS 的机制可以这样理解更新之前先核对内存里的值是不是我预期看到的旧值如果是就把新值写进去如果不是说明其他线程改过了就重试或者放弃。它本质上是一种乐观并发控制多数情况下没有线程竞争所以比锁更轻量。但 CAS 有三个经典问题ABA 问题值从 A 变成 B 又变回 ACAS 无法察觉中间发生过变化、自旋开销高争用下反复重试CPU 空转、只能保证单个变量的原子性。ABA 问题一般通过加版本号解决AtomicStampedReference就是干这个的。如果你关心的是把多个变量作为一个整体来更新就得考虑锁或其他方案了。至于 C 和 C 里的原子操作std::atomic也有类似的意义它只是保证单次读写的原子性同样不能保证读-改-写复合逻辑的安全。所以我一直强调原子类是工具不是银弹。选型时要区分并发安全的基本操作和对多个操作组合的并发控制。2.3 不可变对象最省心的线程安全解决线程安全还有一种思路干脆把可变去掉。一个对象在创建之后所有属性都不再改变那它是天然线程安全的因为多个线程只是在读同一个不会变化的东西没有竞争。Java 里String、Integer、BigDecimal都是不可变类所以多线程共享String从来不用担心线程安全问题前提是你引用本身也别被篡改。实际项目中常犯的错是把不可变对象暴露出去后内部却被修改了。比如你设计了一个配置类构造函数里传入了List然后直接把引用赋值给成员变量外部线程拿到这个 list 后还在往里面加元素那不可变性就形同虚设了。正确做法是在构造函数里做防御性拷贝或者包装成只读视图。C 的const语义类似但要注意const只是编译器层面的约束如果被const_cast强行去掉还是可以改。所以不可变必须是一种设计约定写进代码规范而不是单个关键字能保证的。不可变对象还有一个好处是可以安全地发布到多个线程不需要额外的同步。比如在生产者-消费者模型里把任务数据封装成不可变对象生产者只管构建消费者只管读取中间通过队列传递整体安全性和可理解性都会大幅提升。2.4 线程封闭ThreadLocal 与局部变量的妙用还有一种常常被忽略的线程安全手段是不让两个线程碰同一个东西也就是线程封闭。最简单的做法是尽量用局部变量因为局部变量天然属于当前线程的栈帧不存在共享问题。其次就是用ThreadLocal它会给每个线程保存一份独立的副本。像SimpleDateFormat不是线程安全的多线程并发格式化日期会乱掉一个常见解法就是每个线程一个ThreadLocalSimpleDateFormat。但ThreadLocal有个脏坑线程池场景下线程会被复用如果不显式清理上一个任务留下的数据可能被下一个任务读到。所以使用ThreadLocal一定要记得remove()尤其是在处理完请求之后。我见过不少线上问题就是请求 A 设置了用户信息线程池复用后请求 B 读到 A 遗留下来的上下文导致权限错乱。线程封闭的思路比加锁更干净因为它从根上避免竞争只是它的应用范围有限不是所有共享问题都能通过各自保留一份来解决有些数据本身就是全局性的。3. 生产者-消费者模型从阻塞队列到条件变量的实战对比线程安全最典型的应用场景之一就是生产者-消费者模型。很多项目里都在用但实现方式千差万别。我拿 Java、Python、C/Qt 三个生态各说一段对比着看在工程上到底该怎么选。3.1 阻塞队列最值得优先使用的并发容器Java 里处理生产者-消费者最推荐的做法是直接使用BlockingQueue比如ArrayBlockingQueue或LinkedBlockingQueue。它内部已经处理好了锁和条件通知生产者调用put()在队列满时阻塞消费者调用take()在队列空时阻塞你完全不用自己写wait/notify。这个设计思路值得借鉴并发容器比裸锁更高层用它们可以把更多正确性责任交给经过验证的库。举一个实际的生产者-消费者代码骨架BlockingQueueOrder queue new ArrayBlockingQueue(1024); // 生产者线程 while (running) { Order order fetchOrder(); queue.put(order); } // 消费者线程 while (running) { Order order queue.take(); process(order); }这段代码的安全边界非常清晰生产者和消费者之间唯一的共享对象是queue而BlockingQueue保证了线程安全。你唯一需要关心的是停止信号怎么传递可以用volatile boolean running也可以使用线程中断。我提醒一点不要在生产者和消费者之间再增加额外的共享变量来传递业务数据那会把安全边界重新打破。3.2 Python 多线程中的 queue 与 GIL 的误导Python 的多线程因为 GIL 的存在让很多人产生一种错觉反正同一时刻只有一个线程在执行字节码那是不是没有线程安全问题这个结论是错的。GIL 只保证单个字节码操作是原子的不保证 Python 代码中一段逻辑是原子的。举个例子多个线程同时对一个列表做检查操作if item not in list: list.append(item)两个线程可能同时通过not in检查然后都执行append导致重复元素。因为这两条 Python 语句之间会被 GIL 释放并插入其他线程的执行。还有读取和写入共享字典时虽然单个读写可能没问题但复合操作依然会乱。Python 的多线程更适合 IO 密集型任务比如请求多个外部接口用线程池把等待时间重叠起来。如果需要共享队列标准库的queue.Queue是线程安全的它和 Java 的BlockingQueue类似也内置了锁和通知机制。如果你追求高性能的数值计算那应该考虑多进程而不是多线程因为 GIL 让 CPU 密集型计算的多线程几乎没什么加速效果。所以 Python 里的线程安全更多是在共享数据被多个线程访问时使用线程安全的数据结构而不是依赖 GIL 保平安。3.3 手写等待通知机制最容易出错的三个点有时候项目不让你直接用阻塞队列比如要控制吞吐或做更复杂的批流处理就需要手写等待通知机制。Java 中可以用synchronizedwaitnotifyAll或者Condition。手写的过程中有三大经典错误第一在wait之前没有用while循环检查条件而是用了if。如果多个消费者同时被唤醒第一个线程消费了队列中的唯一元素第二个线程醒来后不检查条件直接取元素就会取到空数据或越界。正确写法是while (isEmpty()) { wait(); }醒来后重新检查条件。第二通知时用了notify而不是notifyAll。如果生产者通知一个消费者而消费者意外被唤醒后去处理了一个不存在的任务或者消费者通知生产者但生产者却是一个错误线程都会导致线程挂死。除非你能非常确定只有一个等待线程和明确的通知目标否则用notifyAll更稳妥。第三在同步块中调用可能阻塞的外部方法。比如队列已满的生产者想通知日志记录器而日志记录器又试图获取同一把锁就会死锁。原则是同步块里只做和共享状态相关的操作不要调用远程方法、不要等待其他锁、不要执行耗时 IO。C 里手写的话就是std::mutexstd::condition_variable逻辑完全一样。Qt 里边则有QMutexQWaitCondition用法也很接近。我建议无论用哪个框架先把whilewaitnotifyAll这个范式背熟它可以解决绝大多数等待通知场景避免自己去琢磨边界情况。3.4 线程池与并发容器的安全边界生产者-消费者后来往往进化为线程池。线程池本身把任务分发和执行的并发细节封装起来了但任务代码里的线程安全不能因此豁免。任务 A 可能在修改一个共享计数器任务 B 也在修改线程池只是提供了并发执行环境并没有帮你管共享数据。所以在写任务函数时你仍然要有这个数据被谁共享的意识。并发容器方面Java 的ConcurrentHashMap、CopyOnWriteArrayList都是比Collections.synchronizedMap更好的选择但也要理解它们的适用边界。ConcurrentHashMap的putIfAbsent、computeIfAbsent是原子的可以用来做缓存初始化但如果你先用containsKey再put那中间就有竞态窗口。Python 的并发场景可以借助多进程的multiprocessing.Manager或消息队列来共享数据尽量避免直接用共享内存墙。另外还要警惕线程安全容器不等于整个操作线程安全容器只保护它内部的结构比如往ConcurrentHashMap里 add 一个元素是安全的但如果你先取值再用这个值做业务业务逻辑若依赖容器状态的连续性还是要靠外部锁。4. 从多线程安全到工程安全选型、排查、设计习惯解决了基本的竞态问题接下来要考虑的是怎么在真实项目里保证不出事和出了事能快速定位。这部分是经验值最高的地方因为很多线程安全问题不是写出来的而是跑出来的。4.1 并发原语选型什么时候上锁什么时候用 CAS什么时候直接上队列我整理了一个简单的决策路径给刚接触多线程的人参考场景描述推荐方案为什么多个线程频繁读、偶尔写共享数据ReadWriteLock或StampedLock读锁可共享写锁互斥避免读线程之间互相阻塞单个计数器的累加/递减AtomicLong或std::atomicCAS 开销低无锁自旋适合高频简单操作复合操作如检查-更新需要锁或者ConcurrentHashMap.computeIfAbsent等原子方法CAS 无法保证多个操作的整体原子性数据传递型生产者-消费者BlockingQueue等阻塞队列封装了同步和通知安全且可读性好复杂状态机 / 多变量一致更新整块锁或数据库事务变量之间需要同时满足约束原子变量办不到线程私有的上下文ThreadLocal避免共享从源头消灭竞态这里我特别想提一句不要因为锁会有性能开销就去追求无锁其实大多数业务系统的并发量还没到锁成为瓶颈的程度。反而无锁实现一旦出错排查难度极大。正确的做法是先求正确再压测让数据告诉你需不需要优化到无锁。4.2 线程池里的线程安全问题工欲善其事必先利其器如果你在 Java 中使用线程池一个容易踩的坑是线程池执行任务时抛出的异常。如果任务不需要返回值你用了execute()异常会被线程池静默吞掉其实会打印到System.err但日志系统未必捕获导致线程安全问题发生时没有任何现场信息。我建议要么用submit()并检查Future.get()的异常要么在多线程任务入口统一捕获异常并记录到日志服务。对于排查竞态条件线上环境最有效的办法之一就是开启 Java 的-XX:PrintConcurrentLocks配合jstack这可以让我们看到线程的锁等待关系。此外ThreadMXBean能找出死锁线程。清单如下抓线程快照jstack pid输出所有线程栈重点看处于BLOCKED或WAITING状态的线程。分析共享对象找到多个线程栈中都出现的合影对象同一个锁的waiting to lock地址基本就能锁定竞态资源。结合日志时间戳在操作共享数据前后打印时间戳对比线程进入和离开的顺序还原竞态时间线。如果本地复现可以使用 Java 的jcstress做并发压力测试或者使用ThreadSanitizer这类工具。C 可以用-fsanitizethread检测数据竞争非常有效Python 的话concurrent.futures之外也可以借助faulthandler和日志定位。4.3 设计习惯让线程安全成为默认属性学了这么多技术最后你会发现一个多线程系统的稳定性很大程度上取决于设计时的数据权属约定。我推荐三个设计习惯能大幅减少线程安全问题的出现第一明确数据的所有者。每个共享对象要有一个明确的归属模块只有该模块能修改它的状态其他模块只能通过模块公开的线程安全方法来访问。这有点像现实中的责任到人没有人负责的数据就是最容易出问题的数据。第二减少共享数据的暴露面。能用局部变量就不用成员变量能返回不可变对象就不返回内部集合引用能传递值拷贝就不传引用。代码里共享变量的数量每少一个潜在的竞态隐患就少一截。第三优先使用现成的并发组件而不是自己造轮子。比如 Java 的BlockingQueue、ConcurrentHashMap、ThreadPoolExecutorC 的std::async、std::futureQt 的QThreadPool、QtConcurrent。这些组件久经考验比自己手写锁的可靠性和可读性都高很多。4.4 重新定义线程安全你担保的边界是什么最后我想纠正一个容易让新人误解的地方线程安全不是一个全局属性它是有边界的。一个AtomicInteger单独看线程安全但你的业务逻辑可能由多个原子步骤组成这些步骤之间没有组合安全。一个方法不管被多线程调用多少次都行为正确这叫方法线程安全但如果方法对外部的某些全局状态有依赖那整体系统的安全需要额外保证。永远要在代码里写清楚这个类在什么前提下是线程安全的比如在构造函数后不再修改字段的情况下线程安全、仅当外部调用者持有某把锁时才线程安全。好的并发设计其实像分层的防线不可变对象防的是状态变化线程封闭防的是共享锁防的是原子性被破坏并发容器防的是集合结构被破坏。每一道防线都有自己的边界交叉运用才能构成一个健壮的多线程系统。实际做项目这些年我最大的体会是线程安全不是写完代码后靠测试发现的而是一开始设计数据流时就该确定规则。画一下哪些数据跨线程流动用什么方式传递一旦流动起来谁能改、谁能读这些在写第一行代码之前就想清楚后面会少踩很多坑。另一个小技巧是平时 review 代码时多问一句如果这个变量的写线程是 A读线程是 B它们之间怎么保证有序性和可见性如果答不上来那这段代码早晚会出问题。多线程安全没有一劳永逸的银弹但它也不是玄学把原子性、可见性、有序性这三件事落实到每一次共享访问上你就已经比大多数项目做得稳妥了。
1. 先把线程安全的敌人认清竞态条件是怎么发生的聊多线程安全之前我一直觉得有个问题必须先说透很多人一听到线程安全就想到加锁好像锁能解决一切。但实际上锁只是手段真正的麻烦是竞态条件。而竞态条件的产生往往不是因为代码逻辑复杂而是因为我们对共享可变状态缺少警惕。1.1 一个计数器足以讲清楚为什么线程会打架先看一个最经典的例子两个线程同时对同一个整数变量执行count。你已经听过无数遍会出现问题但具体是怎么出现的问题我拿 Java 的字节码层面拆开看count不是一条原子指令它实际上是读取 count 的值 - 把值加 1 - 把新值写回三步。当线程 A 读取到 count10线程 B 也读取到 count10然后 A 写回 11B 写回 11两次累加只让 count 从 10 变成了 11丢失了一次更新。这就叫丢失更新。更隐蔽的问题是可见性线程 A 修改了 count但线程 B 可能读到的还是旧值因为 CPU 缓存和寄存器没有及时同步。还有重排序带来的乱序问题编译器为了优化可能把无依赖的语句交换顺序这在单线程下没问题在多线程下可能让另一个线程看到尚未完成的状态。这三者——原子性、可见性、有序性——是线程安全里绕不开的三座大山。你如果不能清晰地指出代码里哪个操作破坏了这三者那后面所有技术手段都容易用错地方。1.2 把抽象概念映射到生活场景我经常用一个多人协作写文档的比喻来解释这三个性质原子性文档里只有一个共享的计数器两个人同时按加一按钮最终只能加一而不是加二。这要求这个按钮的响应必须是不可分割的。可见性你在自己的屏幕上修改了数字但另一个人的屏幕还显示旧数字直到刷新。这就像 CPU 缓存和主内存之间的同步延迟。有序性你先把文档的目录更新了再更新正文内容但另一个读者可能先看到新目录、旧正文形成一种不存在的中间状态。如果代码中出现了共享可变对象比如全局集合、缓存、数据源连接那所有访问这个对象的地方都必须考虑这三个性质。反过来如果这个对象真的只是线程私有的那就根本不存在线程安全问题。所以识别共享和可变两个属性是保证线程安全的第一步。1.3 哪些代码天生就危险先列一个检查清单在实际开发中我一般会在 code review 时自动扫描这几种模式全局静态变量、单例对象中的成员变量尤其是被多个线程读写。集合类如HashMap、ArrayList如果没有同步包装多线程同时写很容易出问题。懒加载的单例比如if (instance null) { instance new X(); }两个线程同时进入判断会导致创建多个实例。简单类型如int、long的读写就算不加锁在 32 位虚拟机下long的读写可能被拆成两次 32 位操作产生撕裂值。还有更隐蔽的复合操作比如检查然后执行check-then-act、读取-修改-写回read-modify-write哪怕每一步单独看是原子的组合起来也不是。我有一个心得体会不要试图把每个危险点都背下来而是养成一个习惯——每次写变量或调用 API 时都问一句这个变量会不会被两个线程同时碰如果答案是可能就必须用线程安全的手段。这个习惯比掌握任何锁都重要。2. 加锁之外的安全手段原子类、不可变对象与线程封闭2.1 synchronized 和 ReentrantLock锁的粒度决定性能与正确性既然竞态条件这么普遍那第一反应自然是加锁。Java 里最常见的两类锁是synchronized和ReentrantLock。synchronized简单可靠方法或代码块加完锁之后同一时刻只有一个线程能进入。但它有两个明显短板一是不能中断等待锁的线程二是默认不支持超时一旦另一个线程持有锁不释放其他线程只能无限等下去。ReentrantLock则提供了tryLock(timeout)、lockInterruptibly等方法灵活性更好但用法也更复杂需要手动解锁强烈建议配合finally释放锁否则一旦中间抛异常锁就永远解不开。加锁最核心的问题不是选哪个 API而是锁的粒度。我见过很多人把整个方法体都锁住比如一个方法只用到局部变量却因为类里有一个共享的日志对象就把整个方法上锁导致所有调用串行化性能直线下降。锁的粒度越粗并发度越低锁的粒度越细代码复杂度越高还容易引入死锁。比较务实的做法是先找出真正的共享可变状态再决定锁罩住的范围只锁保护这个状态的最短代码路径。另外要注意锁的可重入性。synchronized和ReentrantLock都是可重入的也就是说同一个线程可以重复加同一把锁。但如果你自己实现一个简单的布尔标志来模拟锁遇到递归或嵌套调用就会死锁。这是我踩过的坑曾经为了省事用AtomicBoolean做了一个自旋锁结果在回调里又调用了一个需要同一个锁的方法程序直接卡死。后来才明白锁的语义远比加锁-解锁两个动作复杂优先用成熟库而不是自己发明轮子。2.2 AtomicInteger 真的线程安全吗CAS 与它的局限热搜里有atomicinteger线程安全吗这个问题的答案没那么绝对。Java 的AtomicInteger通过 CASCompare-And-Swap实现它保证单个incrementAndGet()操作是原子的也就是说不会出现前面说的丢失更新。所以要回答原子类线程安全吗要看在什么场景如果多个线程只是各自调用incrementAndGet()那确实是线程安全的但如果你的业务逻辑是先读取当前值根据值做一些判断再更新比如如果当前值小于 100 才进行累加那这个复合操作就不是原子的即使每个单独操作都是原子的组合起来依然有竞态。CAS 的机制可以这样理解更新之前先核对内存里的值是不是我预期看到的旧值如果是就把新值写进去如果不是说明其他线程改过了就重试或者放弃。它本质上是一种乐观并发控制多数情况下没有线程竞争所以比锁更轻量。但 CAS 有三个经典问题ABA 问题值从 A 变成 B 又变回 ACAS 无法察觉中间发生过变化、自旋开销高争用下反复重试CPU 空转、只能保证单个变量的原子性。ABA 问题一般通过加版本号解决AtomicStampedReference就是干这个的。如果你关心的是把多个变量作为一个整体来更新就得考虑锁或其他方案了。至于 C 和 C 里的原子操作std::atomic也有类似的意义它只是保证单次读写的原子性同样不能保证读-改-写复合逻辑的安全。所以我一直强调原子类是工具不是银弹。选型时要区分并发安全的基本操作和对多个操作组合的并发控制。2.3 不可变对象最省心的线程安全解决线程安全还有一种思路干脆把可变去掉。一个对象在创建之后所有属性都不再改变那它是天然线程安全的因为多个线程只是在读同一个不会变化的东西没有竞争。Java 里String、Integer、BigDecimal都是不可变类所以多线程共享String从来不用担心线程安全问题前提是你引用本身也别被篡改。实际项目中常犯的错是把不可变对象暴露出去后内部却被修改了。比如你设计了一个配置类构造函数里传入了List然后直接把引用赋值给成员变量外部线程拿到这个 list 后还在往里面加元素那不可变性就形同虚设了。正确做法是在构造函数里做防御性拷贝或者包装成只读视图。C 的const语义类似但要注意const只是编译器层面的约束如果被const_cast强行去掉还是可以改。所以不可变必须是一种设计约定写进代码规范而不是单个关键字能保证的。不可变对象还有一个好处是可以安全地发布到多个线程不需要额外的同步。比如在生产者-消费者模型里把任务数据封装成不可变对象生产者只管构建消费者只管读取中间通过队列传递整体安全性和可理解性都会大幅提升。2.4 线程封闭ThreadLocal 与局部变量的妙用还有一种常常被忽略的线程安全手段是不让两个线程碰同一个东西也就是线程封闭。最简单的做法是尽量用局部变量因为局部变量天然属于当前线程的栈帧不存在共享问题。其次就是用ThreadLocal它会给每个线程保存一份独立的副本。像SimpleDateFormat不是线程安全的多线程并发格式化日期会乱掉一个常见解法就是每个线程一个ThreadLocalSimpleDateFormat。但ThreadLocal有个脏坑线程池场景下线程会被复用如果不显式清理上一个任务留下的数据可能被下一个任务读到。所以使用ThreadLocal一定要记得remove()尤其是在处理完请求之后。我见过不少线上问题就是请求 A 设置了用户信息线程池复用后请求 B 读到 A 遗留下来的上下文导致权限错乱。线程封闭的思路比加锁更干净因为它从根上避免竞争只是它的应用范围有限不是所有共享问题都能通过各自保留一份来解决有些数据本身就是全局性的。3. 生产者-消费者模型从阻塞队列到条件变量的实战对比线程安全最典型的应用场景之一就是生产者-消费者模型。很多项目里都在用但实现方式千差万别。我拿 Java、Python、C/Qt 三个生态各说一段对比着看在工程上到底该怎么选。3.1 阻塞队列最值得优先使用的并发容器Java 里处理生产者-消费者最推荐的做法是直接使用BlockingQueue比如ArrayBlockingQueue或LinkedBlockingQueue。它内部已经处理好了锁和条件通知生产者调用put()在队列满时阻塞消费者调用take()在队列空时阻塞你完全不用自己写wait/notify。这个设计思路值得借鉴并发容器比裸锁更高层用它们可以把更多正确性责任交给经过验证的库。举一个实际的生产者-消费者代码骨架BlockingQueueOrder queue new ArrayBlockingQueue(1024); // 生产者线程 while (running) { Order order fetchOrder(); queue.put(order); } // 消费者线程 while (running) { Order order queue.take(); process(order); }这段代码的安全边界非常清晰生产者和消费者之间唯一的共享对象是queue而BlockingQueue保证了线程安全。你唯一需要关心的是停止信号怎么传递可以用volatile boolean running也可以使用线程中断。我提醒一点不要在生产者和消费者之间再增加额外的共享变量来传递业务数据那会把安全边界重新打破。3.2 Python 多线程中的 queue 与 GIL 的误导Python 的多线程因为 GIL 的存在让很多人产生一种错觉反正同一时刻只有一个线程在执行字节码那是不是没有线程安全问题这个结论是错的。GIL 只保证单个字节码操作是原子的不保证 Python 代码中一段逻辑是原子的。举个例子多个线程同时对一个列表做检查操作if item not in list: list.append(item)两个线程可能同时通过not in检查然后都执行append导致重复元素。因为这两条 Python 语句之间会被 GIL 释放并插入其他线程的执行。还有读取和写入共享字典时虽然单个读写可能没问题但复合操作依然会乱。Python 的多线程更适合 IO 密集型任务比如请求多个外部接口用线程池把等待时间重叠起来。如果需要共享队列标准库的queue.Queue是线程安全的它和 Java 的BlockingQueue类似也内置了锁和通知机制。如果你追求高性能的数值计算那应该考虑多进程而不是多线程因为 GIL 让 CPU 密集型计算的多线程几乎没什么加速效果。所以 Python 里的线程安全更多是在共享数据被多个线程访问时使用线程安全的数据结构而不是依赖 GIL 保平安。3.3 手写等待通知机制最容易出错的三个点有时候项目不让你直接用阻塞队列比如要控制吞吐或做更复杂的批流处理就需要手写等待通知机制。Java 中可以用synchronizedwaitnotifyAll或者Condition。手写的过程中有三大经典错误第一在wait之前没有用while循环检查条件而是用了if。如果多个消费者同时被唤醒第一个线程消费了队列中的唯一元素第二个线程醒来后不检查条件直接取元素就会取到空数据或越界。正确写法是while (isEmpty()) { wait(); }醒来后重新检查条件。第二通知时用了notify而不是notifyAll。如果生产者通知一个消费者而消费者意外被唤醒后去处理了一个不存在的任务或者消费者通知生产者但生产者却是一个错误线程都会导致线程挂死。除非你能非常确定只有一个等待线程和明确的通知目标否则用notifyAll更稳妥。第三在同步块中调用可能阻塞的外部方法。比如队列已满的生产者想通知日志记录器而日志记录器又试图获取同一把锁就会死锁。原则是同步块里只做和共享状态相关的操作不要调用远程方法、不要等待其他锁、不要执行耗时 IO。C 里手写的话就是std::mutexstd::condition_variable逻辑完全一样。Qt 里边则有QMutexQWaitCondition用法也很接近。我建议无论用哪个框架先把whilewaitnotifyAll这个范式背熟它可以解决绝大多数等待通知场景避免自己去琢磨边界情况。3.4 线程池与并发容器的安全边界生产者-消费者后来往往进化为线程池。线程池本身把任务分发和执行的并发细节封装起来了但任务代码里的线程安全不能因此豁免。任务 A 可能在修改一个共享计数器任务 B 也在修改线程池只是提供了并发执行环境并没有帮你管共享数据。所以在写任务函数时你仍然要有这个数据被谁共享的意识。并发容器方面Java 的ConcurrentHashMap、CopyOnWriteArrayList都是比Collections.synchronizedMap更好的选择但也要理解它们的适用边界。ConcurrentHashMap的putIfAbsent、computeIfAbsent是原子的可以用来做缓存初始化但如果你先用containsKey再put那中间就有竞态窗口。Python 的并发场景可以借助多进程的multiprocessing.Manager或消息队列来共享数据尽量避免直接用共享内存墙。另外还要警惕线程安全容器不等于整个操作线程安全容器只保护它内部的结构比如往ConcurrentHashMap里 add 一个元素是安全的但如果你先取值再用这个值做业务业务逻辑若依赖容器状态的连续性还是要靠外部锁。4. 从多线程安全到工程安全选型、排查、设计习惯解决了基本的竞态问题接下来要考虑的是怎么在真实项目里保证不出事和出了事能快速定位。这部分是经验值最高的地方因为很多线程安全问题不是写出来的而是跑出来的。4.1 并发原语选型什么时候上锁什么时候用 CAS什么时候直接上队列我整理了一个简单的决策路径给刚接触多线程的人参考场景描述推荐方案为什么多个线程频繁读、偶尔写共享数据ReadWriteLock或StampedLock读锁可共享写锁互斥避免读线程之间互相阻塞单个计数器的累加/递减AtomicLong或std::atomicCAS 开销低无锁自旋适合高频简单操作复合操作如检查-更新需要锁或者ConcurrentHashMap.computeIfAbsent等原子方法CAS 无法保证多个操作的整体原子性数据传递型生产者-消费者BlockingQueue等阻塞队列封装了同步和通知安全且可读性好复杂状态机 / 多变量一致更新整块锁或数据库事务变量之间需要同时满足约束原子变量办不到线程私有的上下文ThreadLocal避免共享从源头消灭竞态这里我特别想提一句不要因为锁会有性能开销就去追求无锁其实大多数业务系统的并发量还没到锁成为瓶颈的程度。反而无锁实现一旦出错排查难度极大。正确的做法是先求正确再压测让数据告诉你需不需要优化到无锁。4.2 线程池里的线程安全问题工欲善其事必先利其器如果你在 Java 中使用线程池一个容易踩的坑是线程池执行任务时抛出的异常。如果任务不需要返回值你用了execute()异常会被线程池静默吞掉其实会打印到System.err但日志系统未必捕获导致线程安全问题发生时没有任何现场信息。我建议要么用submit()并检查Future.get()的异常要么在多线程任务入口统一捕获异常并记录到日志服务。对于排查竞态条件线上环境最有效的办法之一就是开启 Java 的-XX:PrintConcurrentLocks配合jstack这可以让我们看到线程的锁等待关系。此外ThreadMXBean能找出死锁线程。清单如下抓线程快照jstack pid输出所有线程栈重点看处于BLOCKED或WAITING状态的线程。分析共享对象找到多个线程栈中都出现的合影对象同一个锁的waiting to lock地址基本就能锁定竞态资源。结合日志时间戳在操作共享数据前后打印时间戳对比线程进入和离开的顺序还原竞态时间线。如果本地复现可以使用 Java 的jcstress做并发压力测试或者使用ThreadSanitizer这类工具。C 可以用-fsanitizethread检测数据竞争非常有效Python 的话concurrent.futures之外也可以借助faulthandler和日志定位。4.3 设计习惯让线程安全成为默认属性学了这么多技术最后你会发现一个多线程系统的稳定性很大程度上取决于设计时的数据权属约定。我推荐三个设计习惯能大幅减少线程安全问题的出现第一明确数据的所有者。每个共享对象要有一个明确的归属模块只有该模块能修改它的状态其他模块只能通过模块公开的线程安全方法来访问。这有点像现实中的责任到人没有人负责的数据就是最容易出问题的数据。第二减少共享数据的暴露面。能用局部变量就不用成员变量能返回不可变对象就不返回内部集合引用能传递值拷贝就不传引用。代码里共享变量的数量每少一个潜在的竞态隐患就少一截。第三优先使用现成的并发组件而不是自己造轮子。比如 Java 的BlockingQueue、ConcurrentHashMap、ThreadPoolExecutorC 的std::async、std::futureQt 的QThreadPool、QtConcurrent。这些组件久经考验比自己手写锁的可靠性和可读性都高很多。4.4 重新定义线程安全你担保的边界是什么最后我想纠正一个容易让新人误解的地方线程安全不是一个全局属性它是有边界的。一个AtomicInteger单独看线程安全但你的业务逻辑可能由多个原子步骤组成这些步骤之间没有组合安全。一个方法不管被多线程调用多少次都行为正确这叫方法线程安全但如果方法对外部的某些全局状态有依赖那整体系统的安全需要额外保证。永远要在代码里写清楚这个类在什么前提下是线程安全的比如在构造函数后不再修改字段的情况下线程安全、仅当外部调用者持有某把锁时才线程安全。好的并发设计其实像分层的防线不可变对象防的是状态变化线程封闭防的是共享锁防的是原子性被破坏并发容器防的是集合结构被破坏。每一道防线都有自己的边界交叉运用才能构成一个健壮的多线程系统。实际做项目这些年我最大的体会是线程安全不是写完代码后靠测试发现的而是一开始设计数据流时就该确定规则。画一下哪些数据跨线程流动用什么方式传递一旦流动起来谁能改、谁能读这些在写第一行代码之前就想清楚后面会少踩很多坑。另一个小技巧是平时 review 代码时多问一句如果这个变量的写线程是 A读线程是 B它们之间怎么保证有序性和可见性如果答不上来那这段代码早晚会出问题。多线程安全没有一劳永逸的银弹但它也不是玄学把原子性、可见性、有序性这三件事落实到每一次共享访问上你就已经比大多数项目做得稳妥了。
