线程间共享数据全解析：从互斥锁到死锁破解与原子操作实践

线程间共享数据这个东西，平时写单线程代码的时候完全感觉不到它的存在，一旦你的程序里有第二个线程开始跑，同样的代码、同样的变量，结果可能就不受控制了。尤其是做服务器后端、嵌入式开发或者高频交易系统这类对并发要求高的方向，数据竞争、死锁、可见性问题几乎是躲不掉的坎。这篇内容我把“线程间共享数据”这件事从内到外拆开讲，涵盖设计思路、互斥机制、死锁破解、读写优化以及跨语言实践，还会给出我踩过的一些坑和排查手段，希望能给正在啃并发编程的你一些参考。

1. 数据共享的底层逻辑：问题不只在“同时访问”

1.1 竞争条件才是万恶之源

很多初学者以为线程安全就是“多个线程不能同时访问同一个变量”，这个理解其实方向对了一半，但不够精确。真正的问题在于“多个线程同时访问同一个变量，且至少有一个线程在写”。如果所有线程都只读，那根本不存在竞争，甚至可以放心大胆地并发访问。一旦出现写操作，乱子就来了。

举个最简单的例子：两个线程同时对同一个整型变量做自增操作。从代码层面看，count++是一条语句，但在CPU层面它其实是三条指令——读取count值到寄存器、寄存器加1、把新值写回内存。两个线程如果交错执行这三步，就可能出现两个线程都读到同一个旧值，然后各自加1写回，最终count只增加了1而不是2。这个结果不是100%必现的，但一旦数据量大、操作频繁、线程切换进入关键窗口，它就会以极高的概率出现，而且还特别难复现。

这种问题在并发编程里有一个正式的名字，叫“数据竞争”。C++标准里对它的定义是：两个线程同时访问同一个内存位置，其中至少一个在执行写操作，且没有强制规定这两个操作的先后顺序。有意思的是，在C++内存模型下，数据竞争本身属于未定义行为。也就是说，编译器在优化时看到这样的代码，它不会帮你规避问题，反而可能利用“这个程序不存在数据竞争”的假设去做激进优化，导致出现更离谱的错误。

1.2 编译器和CPU重排带来的“可见性”问题

除了交错执行的问题，还有一层更隐蔽的问题，叫做“可见性”。同一个线程里，代码是顺序执行的，你写入一个变量，下一个条指令读它，肯定能读到新值。但多线程环境下就不是这么回事了。每个CPU核心有自己的一级、二级缓存，变量可能被缓存到核心的局部缓存里，写操作在某个时间点只更新了缓存，还没同步到主内存。这时候另一个线程在其他核心上读这个变量，读到的就是旧值。

更棘手的是指令重排。编译器和CPU都可能在保证单线程语义不变的前提下调整指令执行顺序。简单来说，你在代码里写的“先写A再写B”，在另一个线程观察到的效果可能是“B先被看到，A之后才被看到”。经典的就是双重检查锁定（Double-Checked Locking）那个坑——你以为加了判空和加锁就安全了，但因为重排，另一个线程可能看到一个“半初始化”的对象。

这也就是为什么C++11引入了std::atomic和memory_order这套东西。原子操作不仅是“原子性”的问题，更重要的是它提供了“顺序性”和“可见性”的保证。你在一个线程里对原子变量做的写操作，配合合适的内存序，能确保其他线程看到的是最新值，而且不会看到重排后的奇怪顺序。

1.3 从设计层面规避共享：不去共享才是最好的方案

如果让我给并发编程排优先级，我的第一选择永远是“不共享数据”。这不是逃避问题，而是从架构上把复杂度降下来。

比如生产者-消费者模式，生产者和消费者看似共享了一个缓冲区，但你可以在它们之间传递“消息”而不是“指针”。消息本身被移交出去，发送方不再接触它，接收方独占它。这种“所有权转移”的模型在Rust里被发扬光大了，但在C++里我们也可以做类似的约束：把对象的指针从线程A传递到线程B，并且约定传递之后A不再访问它。

再比如用线程局部存储（thread_local）来剪裁数据。有些数据本质上属于某个线程自己的工作，不需要给其他线程看到。最常见的例子就是线程各自的随机数种子、内存池、日志上下文。这类数据用thread_local修饰，每个线程都有自己的独立副本，天然没有共享，也就不用加锁。

如果你实在无法避免共享，那就尽量缩小共享范围。共享的数据越少，出问题的面就越小。把大对象拆成小块，让每个线程只写自己负责的区间，这也是非常常用的手段。后面讲读写锁的时候还会再展开。

2. 互斥锁：最基础但不是万能的

2.1 用std::mutex保护共享数据的基本姿势

C++11引入的std::mutex是解决数据竞争最基础的工具。它的用法非常简单：在访问共享数据之前调用lock()，访问完之后调用unlock()。但直接裸调用lock/unlock有一个很大的问题——如果中间代码抛异常，或者在某个分支里提前return了，unlock就不会被执行，锁就永远锁住了，程序直接卡死。

现代C++里几乎不会有人手写lock/unlock，都是配合RAII（资源获取即初始化）来用。std::lock_guard就是最基础的RAII封装，构造时自动加锁，析构时自动解锁。不管函数是正常返回还是抛异常，析构函数都会被调用，锁自然就释放了，非常省心。

std::mutex g_mutex; std::map<int, std::string> g_cache; void update_cache(int key, const std::string& value) { std::lock_guard<std::mutex> lock(g_mutex); g_cache[key] = value; }

2.2 lock_guard和unique_lock的取舍

lock_guard使用场景简单，但灵活性不足。你想实现“加锁之后在某个条件下提前解锁”，或者“用条件变量等待某个状态”，lock_guard就办不到了。这时候需要std::unique_lock。它除了RAII管理锁之外，还允许你手动调lock()和unlock()，可以移动、可以延迟加锁。

我个人的习惯是这样的：如果只是简单地保护一段代码，就用lock_guard，少写代码少出错；如果需要在持有锁的情况下调用条件变量的wait()，或者在函数中途可能释放锁，那就用unique_lock。需要注意的是，unique_lock比lock_guard多维护了一些内部状态，性能和开销稍大一点点，但在绝大多数业务场景下这点开销可以忽略不计。

另外还有一个细节：很多人不知道std::mutex不可复制也不可移动，所以如果你的类把互斥锁作为成员变量，这个类就不能被复制和移动。为了保证安全，这完全是合理的行为，但有些人在容器里存对象时就会遇到编译报错，误以为是mutex的问题。实际上这是好的设计，强迫你以引用或智能指针来传递对象。

2.3 锁的粒度：锁太细出事，锁太粗出性能

锁的粒度是一个非常需要权衡的问题。锁的粒度太细，意味着你把保护拆成很多小块，每个共享数据都有自己独立的锁，并发性提高了，但复杂性也上来了——很多操作其实需要“多个数据作为一个整体保持一致”，这时候拆细了反而容易在代码逻辑里出现不一致。

举一个我实际遇到过的场景：一个交易系统里有两个账户表，A账户和B账户，每个表有自己独立的锁。转账操作需要同时修改A和B，如果线程1先锁A再锁B，而线程2先锁B再锁A，两人的加锁顺序正好相反，就会形成死锁。这个问题后面会详细说，这里先记住一个结论：当多个锁必须同时持有时，要么保证所有线程加锁的顺序一致，要么直接用std::lock一次性锁住多个锁。

锁的粒度过粗，比如用一个“全局锁”保护所有数据，并发性会大打折扣，多线程退化成串行执行，甚至比单线程还慢（因为还要额外付出加锁解锁的开销）。比较务实的做法是“按业务模块划分锁”，每个模块的共享数据由独立锁保护，模块之间的交互尽量减少到“简单、顺序明确”的路径上。

2.4 接口层面的“隐藏共享”值得警惕

最常见的一个坑就是：你以为加了锁，实际上没加全。比如某个类内部用一个std::vector存储数据，所有修改方法都加了锁，但对外暴露了一个size()方法，没加锁。调用方在这个vector正在被其他线程修改时调用了size()，虽然size()本身是几行简单的代码，但它读取的size字段可能处于中间状态，结果可能与预期不符。

还有一种更隐蔽的：类内部维护了一个指向共享数据区的指针，你用锁保护了指针本身的读写，但没保护“通过这个指针去访问的对象”。如果指针指向的对象本身也是共享的，那锁保护的根本就是错的。所以，设计线程安全的类时，一定要想清楚“你锁的到底是不是真正共享且被修改的东西”。接口边界上，任何可能被多线程同时调用的方法都应该被审视，包括常量成员函数——因为const修饰的成员函数也可能返回一个指向成员数据的引用或指针，调用方完全可以绕过锁去修改它。

3. 死锁的成因、破解与避坑

3.1 死锁发生的四个必要条件

死锁不像数据竞争那样“时有时无”，发生之后程序就彻底卡死在那里，非常直观，也让人非常崩溃。它的产生需要同时满足四个条件：互斥（资源每次只能被一个线程使用）、持有并等待（线程持有自己的锁，同时等待别的锁）、不可剥夺（锁不能被别人夺走）、循环等待（线程间形成环形等待链）。

一个典型场景就是两个线程需要同时锁住锁A和锁B，但线程1持有A等待B，线程2持有B等待A，两者互相谦让，谁也不放手，程序就僵住了。在多线程编程中这是很经典的反面教材。在排查时，光是确认锁的持有关系就够费一番功夫，后面会讲一些工具和思路。

3.2 破局方案：std::lock、固定顺序、超时机制

破解死锁有三板斧。第一板斧是保证加锁顺序。如果所有线程都按固定的顺序加锁（比如总是先锁A再锁B），就不会出现循环等待，因为所有人的“下一步等待”方向是一致的。这个方法简单直接，但在锁很多、嵌套很深的时候维护这个顺序很痛苦。

第二板斧是用std::lock一次性锁定多个锁。C++11提供了std::lock这个函数，它可以同时锁住指定的一组锁，内部采用某种算法避免死锁（通常是“尝试性锁”加“回退”的组合策略）。只需注意一点：std::lock成功时，传进去的锁已经被全部锁住了，但哪个排前面哪个排后面，它不保证顺序，所以你后续手工unlock时也得小心些。

std::mutex lock_a; std::mutex lock_b; void transfer(int from, int to, int amount) { std::unique_lock<std::mutex> guard_a(lock_a, std::defer_lock); std::unique_lock<std::mutex> guard_b(lock_b, std::defer_lock); std::lock(guard_a, guard_b); // 同时持有两把锁，操作共享数据 }

第三板斧是锁超时。std::timed_mutex和try_lock_for、try_lock_until可以设置最长等待时间。如果等不到锁就放弃，先释放自己已有的锁，重试或者记录错误。这种方式适合那些“等不到锁就要做其他处理”的业务场景，能有效避免永久性死锁，但要注意“超时后释放已有锁再重试”的逻辑，处理不当可能造成活锁。

3.3 活锁和饥饿：看起来在动，实际上没有进展

死锁是“完全不动了”，活锁则是“线程一直在运行，但就是做不完正事”。最常见的活锁场景是：两个线程都检测到潜在冲突，于是各自谦让，“你先来你先来”，结果永远在相互避让。在分布式系统中这种问题更多，但多线程里也偶有发生。解决活锁的一种策略是引入随机化退避，稍微等待一段随机时间再重试，减少“重复碰撞”的概率。

饥饿则是某个线程迟迟抢不到锁，一直处于等待状态。普通的std::mutex不保证“公平性”，也就是说线程调度器可能一直把锁分给新的请求线程，而某个老线程一直拿不到锁。在极端情况下，频繁加锁解锁的临界区里，饥饿问题真实存在。如果你需要更公平的调度，可以用std::condition_variable做更精细的控制，或者用支持公平策略的第三方实现（比如std::shared_mutex在某些实现下也是公平队列）。

4. 读写分离：shared_mutex和原子操作的进阶玩法

4.1 什么时候适合读写锁

现实场景里，有一种非常普遍的模式：大部分线程只是“读”数据，只有一小部分线程偶尔“写”数据。比如一个游戏服务器里的配置表，加载之后几乎不变，但会有多个线程去查询。或者一个缓存系统，读的QPS远大于写。

对于这种场景，用普通的互斥锁会严重浪费并发能力——明明所有线程只读，完全可以并行，结果因为一把互斥锁全挤在一起了。C++17引入了std::shared_mutex，它有两种锁模式：共享锁（shared_lock）和独占锁（lock_guard或unique_lock）。多个线程可以同时持有共享锁，但独占锁会排斥所有其他锁。

std::shared_mutex g_rw_mutex; std::map<int, std::string> g_config; std::string get_config(int key) { std::shared_lock<std::shared_mutex> lock(g_rw_mutex); return g_config[key]; } void set_config(int key, const std::string& value) { std::unique_lock<std::shared_mutex> lock(g_rw_mutex); g_config[key] = value; }

这里面有个性能细节：shared_mutex的加锁解锁开销通常比std::mutex略高，因为它要维护多个读者计数的状态。如果临界区非常小（只有一行读操作），用shared_mutex未必比普通互斥锁快，因为读者们抢锁的开销可能大于并发执行带来的收益。所以读写锁适合“读操作临界区较大”或者“读者数量极其多”的场景，实践时需要自己benchmark。

4.2 原子操作：从底层理解std::atomic

原子操作是在硬件层面提供的不可分割的读写操作，不会出现“读了一半被写”这种情况。C++11的std::atomic<T>就是封装了这些底层原语的模板类。对原子变量的操作，默认使用“顺序一致性”内存序，这是最安全但是也是性能开销最大的模式。

你在Java里见过volatile，在C#里见过volatile，它们在语义上与C++的默认memory_order_seq_cst并不完全等同——Java的volatile可以看作“可见性保证+禁止局部重排”，而C++的原子变量在默认设置下是全序的。初次接触C++原子操作时很容易犯一个错误：拿原子变量去当作“轻量级锁”来保护一个复杂的临界区。这是不行的，原子操作只保证单个变量本身的读写原子性和排序关系，并不保证“多个变量组合操作”的原子性。

一个常见的使用场景是计数器：

std::atomic<int> g_counter{0}; void worker() { for (int i = 0; i < 1000; ++i) { g_counter.fetch_add(1, std::memory_order_relaxed); } }

fetch_add就是“读取-加一-写回”的原子版本，在底层通常对应CPU的LOCK XADD或类似的指令。memory_order_relaxed表示“只要求原子，不要求相对顺序”，对于只是做计数统计、人畜无害的场景，这就是最快的用法。

4.3 memory_order到底该不该碰

网上讨论memory_order的帖子特别多，很多人感觉越是深入了解越糊涂。我的建议是：默认全用std::memory_order_seq_cst，除非你确实知道自己在优化什么。顺序一致性最难出错，符合人类直觉。等你通过性能分析确认某个热路径的原子操作成了瓶颈，再考虑降级为acquire/release甚至relaxed，同时补上充足注释。

理解内存序最关键的两个概念是“Acquire”（获取）和“Release”（释放）。简单理解为：一旦线程A对一个变量做了release写操作，那么此刻所有的写操作都会对其他线程“可见”，直到线程B对同一个变量做acquire读操作。这样，acquire-read就能看到release-write之前的所有非原子写操作。这个模式非常漂亮，也是很多无锁队列实现的基石。但前提是，你要严格保证配对的变量关系，不要在一个变量上做release，结果用另一个变量做acquire来试图看到甲的效果——那是不行的。

5. 其他语言里的同款问题与差异化取舍

5.1 Java：synchronized、ReentrantLock与并发集合

Java的线程共享数据问题本质上和C++一模一样，只是它把很多“底层自由”变成了“规则约束”。Java内置了volatile关键词来保证可见性和一定的有序性，所有对象都可以作为monitor被synchronized块锁定。相比之下，Java里没有那么多的内存序让你操心，大部分情况下用好synchronized和ReentrantLock就够。

Java并发里最值得学习的是它那个庞大的并发集合类库：ConcurrentHashMap、CopyOnWriteArrayList、BlockingQueue等。这类集合类内部已经实现了分段锁或者无锁算法，直接使用能省掉自己造轮子的风险。我在C++里就特别羡慕Java有ConcurrentHashMap这么成熟的东西，C++社区虽然也有类似库，但确实没有标准库的现成实现。

关于Java线程池（结合搜索热词“java线程池参数合理配置”），线程池里的线程任务共享了同一个任务队列，这个任务队列本身就是个线程安全的数据结构。当你设置线程池参数时（核心线程数、最大线程数、阻塞队列大小、拒绝策略），你本质上就是在配置“任务队列”的共享方式。队列满了怎么办——丢弃、抛出异常还是调用者自己执行，这些选择背后都是对共享数据边界的设计。

5.2 Python：GIL的存在让数据竞争“没那么容易发生”，但仍然会发生

Python的GIL（全局解释器锁）是一个很有意思的存在，它保证同一时刻只有一个线程在执行Python字节码，这基本上杜绝了“多个线程同时修改同一块Python对象”的情况。很多人因此误以为Python多线程不需要考虑数据共享问题。

这是一个常见的误解。GIL只保证“Python字节码层面”的原子性，但你在多行字节码之间是可以切换线程的。比如对一个字典做两步操作：“先判断key是否存在”和“然后再插入”，中间完全可能被另一个线程打断。更典型的是复合运算，比如list.append是原子的，但if len(list) < 10: list.append(x)这个组合绝对不是原子的。所以，Python里做线程安全照样需要锁（threading.Lock），或者用queue.Queue这种线程安全的队列来传递数据。

顺便提一个PyCharm调试线程时的老坑：子线程断点经常不命中。我之前排查一个问题，发现主线程断点会命中，但子线程里设的断点压根不触发。后来发现是PyCharm的运行配置里“子线程断点”的选项没有打开——PyCharm默认会在主线程调试器停止时挂起所有线程，但如果你勾选的是“只挂起当前线程”，子线程被新线程继续独立跑，断点自然就乱了。这个细节和“线程共享数据”的关系在于：你在调试时看到的变量状态，很可能只是某一个线程的局部快照，不代表全局状态。

5.3 C#：lock语法糖与线程安全集合

C#提供了非常舒服的lock语法糖，本质上就是对Monitor类Enter和Exit的封装。用起来比C++的RAII更简单，因为它连“创建锁对象”都内建了——任何引用类型对象都能作为锁。

当然，C#同样有类似的数据共享问题。比如你用一个List<T>在多个线程里并发Add，它整个内部结构的修改不是原子的，会直接抛异常甚至内存损坏。.NET提供了一整套线程安全的集合类，比如ConcurrentBag<T>、ConcurrentDictionary<K,V>、ConcurrentQueue<T>，还有用于精确控制线程协作的ManualResetEventSlim、SemaphoreSlim等。这些工具类的存在说明了一件事：现代语言的并发库越来越像“积木”，你用它们的目的不是为了炫技，而是为了减少自己手动处理“共享数据”时出错的概率。

C#里还有一个值得提的点：任何UI框架都要求只能在主线程更新界面控件。后台线程做完异步任务后想去更新界面上的文字，直接访问控件会抛异常，必须用Invoke或者await回到UI线程的上下文。这本质上是一种线程亲缘性约束。Qt里也有类似的规则：只有主线程可以处理GUI事件，子线程更新UI必须发信号让主线程处理。这些框架级别的约束，其实就是在用一种“半强制”的方式限定数据共享的路径。

5.4 线程池场景下的共享数据

搜索热词里“线程池”出现次数非常多。线程池能复用线程，减少创建销毁的开销，但代价就是“任务之间共享线程资源”。你在单线程模型里从构造函数传一个self进入worker，那是安全的，因为只有一个worker。但线程池里有多个worker同时跑，它们都在访问这个共享的self，不加保护照样竞争。

还有一个常见的问题是：线程池任务提交顺序和执行顺序不一定一致。如果你依赖某个任务先执行完再执行另一个，光靠“先提交task A再提交task B”是不够的。要么用future等待上一个任务完成，要么把这两个任务合并成一个更大的任务，要么改用有依赖关系的任务调度框架。我自己在C++里排异步任务时吃过这个亏——两个日志写入任务，一个负责清空临时缓冲，另一个负责把缓冲内容落盘，结果因为顺序颠倒，日志批量丢了不少。后来改成用一个“组合任务”把它们串在一起，才彻底解决。

6. 问题排查实战：从工具到思路

6.1 数据竞争检测：TSAN让未定义行为现形

如果你在Linux上写多线程程序，强烈建议开启ThreadSanitizer（TSAN）来做数据竞争检测。它是一个编译期插桩工具，运行时跟踪每个内存访问并记录先前的线程关系，只要检测到“同一内存位置被不同线程访问，且至少有一个是写操作，且没有同步关系”，就会立刻报错并打印详细的调用栈。

g++ -fsanitize=thread -g -O1 -o my_app my_app.cpp

TSAN报错的信息非常清晰，会告诉你是哪两个线程、哪两条指令、共享的地址是什么。最实用的一点是，TSAN能在测试阶段就把问题暴露出来，而不是等到线上偶发才去抓。代价就是运行开销变大（通常慢5~15倍），内存占用也高，不适合做性能测试，但做功能测试和压力测试时开着它就对了。

我在一个C++网络服务项目里，数据竞争出现过一次特别诡异的表现：程序偶发在free()时崩溃，但堆栈上毫无规律。后来用TSAN跑了一晚上的压力测试，直接报了两个线程在并发修改同一个std::vector内部的size字段，问题当场现形。从那以后，但凡涉及多线程的代码，我坚决在CI里加一个TSAN构建。

6.2 死锁定位三板斧

死锁的定位比数据竞争容易一些，程序直接卡死不退出。第一步是看堆栈。gdb中thread apply all bt打印所有线程的调用栈，能看到每个线程阻塞在哪个锁上。第二步是查锁的持有关系，pthread_mutex_t本身一般不带持有者信息，但gdb有时能通过内部结构猜出来。更直观的方式是用core dump加gdb分析，或者用strace看线程在等待什么系统调用。

第三步是用pstack、gstack这类工具直接打印进程内所有线程的栈信息。死锁通常显示为多个线程都在__lll_lock_wait或pthread_mutex_lock里阻塞，再结合栈上的函数名，很快就能还原出“谁持有谁在等谁”的关系。如果有日志系统，加上一些关键路径的日志（哪把锁、哪个线程、什么时候加的锁），排查速度会快很多。

我个人的一个习惯是：在关键临界区的加锁和解锁处用__FILE__、__LINE__记录日志（只开在debug模式），一旦业务告警说“卡住”，马上看日志就能定位到锁的位置。

6.3 一个典型死锁案例的复盘

我用一个经典场景来复盘：有两个账本A和B，业务接口“从A转账到B”和“从B转账到A”可能会并发执行。

std::mutex lock_a, lock_b; void transfer(int amount, bool a_to_b) { std::lock_guard<std::mutex> first(a_to_b ? lock_a : lock_b); std::lock_guard<std::mutex> second(a_to_b ? lock_b : lock_a); // 模拟转账 }

这个代码的关键在于：线程1执行转账（A→B）时先锁A再锁B，线程2执行转账（B→A）时先锁B再锁A，结果两个线程持有一个锁互相等另一个锁，形成死锁。修正方案就是上面提到的std::lock，或者规定一个固定顺序：无论转账方向如何，都先锁A账户再锁B账户。用账户ID的大小来排序，既简单又实用，这也是金融系统中常用的手段。

6.4 常见并发问题速查表

7. 动手实验与思考扩展

理论讲再多，也不如亲手做一个带数据竞争的程序来感受一下。我推荐一个小实验：用4个线程同时对同一个int变量自增10万次，不做任何保护，跑完之后打印结果。你会发现结果经常不是40万，甚至每次运行都不一样。然后把它改成std::atomic<int>，再次运行，结果就稳定了。这个实验能帮你快速建立“共享数据必须同步”的直觉。

再进一步：把std::atomic<int>换成std::atomic<long long>，在一个64位的机器上分别用32位和64位的数据跑压力测试，观察结果差异。这能引出“原子性不是免费午餐”的思考——64位变量在32位架构上可能无法原子地读写，两个半段可能会被不同线程看到错配的组合。这个问题在跨端开发、嵌入式开发里真实存在。

最后如果你有兴趣深挖，可以研究一下无锁编程的几个经典实现，像是无锁队列、无锁栈。它们利用原子操作和内存序，在“不用锁”的前提下实现了线程安全。无锁的好处是避免了死锁和线程调度开销，但坏处是编写难度极高、正确性很难验证。我在生产环境里一般会非常谨慎地使用无锁结构，只在确有性能瓶颈时才会采用，而且要配大量的单元测试和TSAN跑数据竞争检测。

我个人整理这块知识点的时候，最大的体会是：线程间共享数据的核心难题并不是“某个具体锁怎么用”，而是“你愿不愿意在动手写代码之前，先花时间去梳理哪些数据是真正共享的、哪些是每个线程私有的一部分、哪些可以通过设计避免共享”。这个思考过程越充分，后面加锁、调优、排查问题的工作量就越小。另一方面，我强烈建议你掌握一种数据竞争检测工具（C++就用TSAN，Java可以了解JMM的规则和各类分析工具，Python可以结合faulthandler和threading调试）。工具不是万能的，但它能在你在那里挠头怀疑人生的时候，直接告诉你问题出在哪个文件第几行。

希望这篇内容对你有帮助。如果你最近正被某个线程共享问题折磨，不妨按照里面的排查思路走一遍，也许问题就浮出水面了。