1. 线程同步到底在解决什么问题1.1 从一次线上数据对不上说起前阵子帮朋友看一段代码逻辑特别简单起十个线程每个线程给同一个计数器加十万次最后打印结果。他预期的是一百万实际跑出来九十八万多而且每次都不一样。单线程跑一遍数字分毫不差。他第一反应是机器坏了第二反应是编译器有 bug唯独没想到问题出在自己写的代码上。这个现象就是典型的竞态条件Race Condition。十个线程同时读同一个变量、加一、写回去中间任何一步都可能被其他线程插队。A 线程读到 100还没来得及写回 101B 线程也读到了 100两边都写 101一次自增就这么凭空消失了。线程同步机制的存在就是为了把这类插队行为约束住让多个线程在访问共享资源时有个先后秩序。很多人第一次接触线程同步会觉得它是为了正确性牺牲性能的无奈之举。这个理解只对了一半。同步确实会带来开销但在绝大多数业务场景里不加同步导致的错误排查成本远比那点性能损耗高得多。一个偶发的脏数据可能要花你三天时间翻日志、加埋点、反复压测才能定位。相比之下在临界区外面套一把锁成本几乎可以忽略。这篇内容我打算把线程同步的来龙去脉讲清楚它解决的是什么问题常用的几种线程同步机制各自适合什么场景怎么选、怎么写、怎么排错。不管你是刚学多线程的新手还是写过几年并发代码但总觉得知其然不知其所以然的老手应该都能从里面找到点有用的东西。代码示例我会用 C、Java、Python、Go 几个语言交叉着给思路是通的语法差异不是重点。1.2 三个绕不开的基础概念临界区、竞态条件、内存可见性要理解线程同步先把三个词吃透后面所有机制都是围绕它们转的。临界区Critical Section指的是一段访问共享资源的代码。共享资源可以是内存里的一个变量、一个对象、一个文件句柄也可以是一块硬件设备。临界区的关键特征是同一时刻只能有一个或有限个线程在里面执行。比如counter这行代码看起来是一条语句实际拆成读内存、寄存器加一、写回内存三步整个过程就是临界区。竞态条件指的是程序的执行结果依赖于线程调度的时序。换句话说同样的输入跑十次可能出十种结果。竞态条件不一定发生在多线程里多进程、信号处理函数、甚至某些异步回调里都会出现。判断一段代码有没有竞态最简单的办法是问自己如果两个线程在这段代码里任意位置被打断并交换执行顺序结果还对吗如果答案是否定的那就有竞态。内存可见性这个最容易被忽略。现代 CPU 为了性能会把变量缓存在寄存器或者各级缓存里写操作不一定会立刻刷回主内存。线程 A 改了flag true线程 B 可能过了好几毫秒还在读旧值false。更麻烦的是编译器和 CPU 都可能对指令做重排序只要单线程语义不变就行。这在单线程里没问题多线程里就会出大乱子。所以线程同步机制除了互斥往往还承担着内存屏障的职责——保证一个线程的写操作对另一个线程可见。注意很多人以为加了volatile就万事大吉其实volatile在不同语言里的语义差别极大。C/C 的volatile只保证不被优化掉不保证原子性和内存序Java 的volatile保证可见性和禁止部分重排序但不保证复合操作的原子性。别把这两个混为一谈。1.3 为什么说同步不等于慢新手常有的一种抵触是加锁会让程序变慢能不加就不加。这个直觉在早期单核时代有点道理但在今天的多核机器上完全站不住脚。先说清楚锁的开销到底在哪。一把没有竞争的锁加锁解锁也就是几十个时钟周期比一次内存访问贵不了多少。真正贵的是竞争多个线程同时抢一把锁抢不到的要挂起、要上下文切换、要被操作系统调度回来这一套下来动辄几微秒。所以优化的方向从来不是消灭锁而是减少锁的竞争比如缩小临界区、降低锁粒度、用读写分离、用无锁结构。再换个角度算笔账。假设一个接口平均响应 10 毫秒其中临界区占 0.1 毫秒。你为了省这 0.1 毫秒去掉了锁结果每十万次请求出现一次数据错乱排查加修复加上线验证人力成本可能就是两三天。这笔账怎么算都不划算。除非临界区确实是热点中的热点压测数据明明白白指着它否则老老实实加锁才是工程上更稳的选择。还有个常见误区是把并发和并行当成一回事。并发是说多个任务在逻辑上同时推进并行是说多个任务在物理上真正同时执行。线程同步解决的是并发环境下的正确性问题跟你机器有几个核没关系。哪怕单核跑多线程时间片轮转照样会打断临界区该出错还是出错。2. 常用的线程同步机制逐个拆解2.1 互斥锁用得最多也最容易用错互斥锁Mutex是最基础的同步原语同一时刻只允许一个线程持有。所有语言都有对应实现C 的std::mutex、Java 的synchronized和ReentrantLock、Python 的threading.Lock、Go 的sync.Mutex。先看一段最朴素的写法四个语言对照着看// C std::mutex mtx; int counter 0; void worker() { for (int i 0; i 100000; i) { std::lock_guardstd::mutex lock(mtx); // RAII出作用域自动解锁 counter; } }// Java public class Counter { private int value 0; public synchronized void inc() { value; } }# Python import threading lock threading.Lock() counter 0 def worker(): global counter for _ in range(100000): with lock: counter 1// Go var ( mu sync.Mutex counter int ) func worker() { for i : 0; i 100000; i { mu.Lock() counter mu.Unlock() } }这里的核心原则是加锁和解锁必须成对出现且任何异常路径都不能漏掉解锁。C 里推荐用lock_guard或unique_lock这种 RAII 封装Python 用withJava 用try-finally或者synchronized代码块。手动lock()然后忘了unlock()程序会直接卡死这种 bug 在线上极难排查因为线程栈看起来一切正常就是不往下走。关于互斥锁有几个坑值得单独说第一别在持锁期间做耗时操作。文件 IO、网络请求、日志打印这些统统要挪到临界区外面。我见过最离谱的一段代码是在持锁状态下调了一个 HTTP 接口接口超时 30 秒整台机器的线程全堵在这把锁上服务直接雪崩。第二注意锁的重入性。C 的std::mutex不可重入同一个线程二次加锁会死锁需要重入就用std::recursive_mutex。Java 的synchronized和ReentrantLock本身就可重入。Python 的threading.Lock不可重入要重入得用threading.RLock。第三锁的粒度要拿捏。粒度太粗并发度上不去粒度太细管理复杂度飙升还容易出死锁。一个实用的经验是锁保护的应该是数据而不是流程把同一份数据的所有访问都放进同一把锁的保护范围逻辑上最清晰。2.2 读写锁读多写少的场景能救你一命互斥锁的问题在于过于严格就算十个线程都是只读也得排队一个一个来。可现实中大量场景是读多写少比如配置中心、路由表、本地缓存。这时候读写锁就派上用场了。读写锁的规则是读锁之间可以共存读锁和写锁互斥写锁和写锁互斥。直观理解就是多个人可以同时看书但有人要改书的时候所有人都得停下。// C std::shared_mutex rw_mtx; std::mapstd::string, std::string config; std::string get(const std::string key) { std::shared_lockstd::shared_mutex lock(rw_mtx); // 读锁 auto it config.find(key); return it config.end() ? : it-second; } void set(const std::string key, const std::string val) { std::unique_lockstd::shared_mutex lock(rw_mtx); // 写锁 config[key] val; }// Java private final ReentrantReadWriteLock rwLock new ReentrantReadWriteLock(); private final MapString, String config new HashMap(); public String get(String key) { rwLock.readLock().lock(); try { return config.getOrDefault(key, ); } finally { rwLock.readLock().unlock(); } } public void set(String key, String val) { rwLock.writeLock().lock(); try { config.put(key, val); } finally { rwLock.writeLock().unlock(); } }读写锁不是万能的有两点必须提醒。一是写锁可能饿死如果读请求源源不断写线程可能一直排不上队。大部分实现的读写锁默认不保证公平Java 的ReentrantReadWriteLock可以传true开启公平模式但吞吐会下降。二是读锁并不等于无锁读锁内部也有引用计数之类的共享状态要维护如果临界区极短比如就读一个 int读写锁的开销可能比互斥锁还大。这种情况下原子变量后面会讲是更好的选择。实操心得读写锁换来的是读并发收益大小完全取决于读操作占比和读操作耗时。如果读操作本身只有几纳秒那把读锁的开销就占了大头不如直接上原子的读写快照。判断标准很简单压测对比两种方案的 QPS别凭感觉。2.3 条件变量等一个信号而不是空转互斥锁和读写锁解决的是互斥访问但有一类需求它们搞不定线程 A 需要等某个条件成立才继续而这个条件由线程 B 来满足。比如生产者-消费者模型里消费者发现队列空了得等生产者放数据进来。最笨的办法是轮询消费者不停地加锁、检查队列、解锁、睡一会、再来一遍。这种写法 CPU 空转延迟还高。正确的做法是用条件变量Condition Variable。条件变量的用法有固定的套路必须配合一把互斥锁使用// C std::mutex mtx; std::condition_variable cv; std::queueint q; void producer(int val) { { std::lock_guardstd::mutex lock(mtx); q.push(val); } cv.notify_one(); // 通知可以放在锁外面减少一次唤醒后的竞争 } int consumer() { std::unique_lockstd::mutex lock(mtx); cv.wait(lock, [] { return !q.empty(); }); // 必须带谓词防虚假唤醒 int val q.front(); q.pop(); return val; }# Python import threading cond threading.Condition() queue [] def producer(val): with cond: queue.append(val) cond.notify() def consumer(): with cond: while not queue: # 用 while 而不是 if防虚假唤醒 cond.wait() return queue.pop(0)// Java private final Object lock new Object(); private final QueueInteger queue new LinkedList(); public void produce(int val) throws InterruptedException { synchronized (lock) { queue.offer(val); lock.notify(); } } public int consume() throws InterruptedException { synchronized (lock) { while (queue.isEmpty()) { // 同样用 while lock.wait(); } return queue.poll(); } }这里有三个点必须强调几乎每个新手都会踩第一wait 必须放在 while 循环里不能写成 if。原因是存在虚假唤醒Spurious Wakeup操作系统在某些情况下会无缘无故唤醒等待的线程。用 while 重新检查条件是最稳妥的写法。Java 的wait()和 Python 的wait()都要求这样写C 的wait(lock, pred)内部已经帮你循环了传谓词就行。第二条件变量本身不保存状态。如果notify发生在wait之前这次通知就丢了等待的线程会一直睡下去。所以共享状态比如队列非空必须由互斥锁保护wait在挂起前会原子性地释放锁被唤醒后再重新加锁这套机制保证了不会丢通知。第三notify_one和notify_all要选对。只有一个消费者时用notify_one多个消费者且唤醒条件对所有人都成立时用notify_all否则可能唤醒了 A 但 A 不满足条件满足条件的 B 还在睡。2.4 信号量控制同时访问资源的数量互斥锁的并发度是 1信号量Semaphore把并发度扩展到 N。它内部维护一个计数器acquire让计数减一减到负数就阻塞release让计数加一。当 N 等于 1 时信号量就退化成互斥锁。最典型的应用是限流和连接池。比如数据库连接池最多同时给 20 个线程用第 21 个请求就得排队# Python import threading sem threading.Semaphore(20) # 最多 20 个并发 def query(sql): with sem: # 从连接池拿连接、执行、归还 pass// Java Semaphore sem new Semaphore(20); public void query(String sql) throws InterruptedException { sem.acquire(); try { // 执行 SQL } finally { sem.release(); } }// C std::counting_semaphore20 sem(20); void query() { sem.acquire(); // ... 业务逻辑 sem.release(); }信号量和互斥锁的一个关键区别是互斥锁必须由加锁的线程解锁信号量可以由任意线程 release。这个特性让信号量能表达一个线程等另一个线程完成的语义比如初始化线程做完准备工作后release其他线程acquire之后才开始干活。还有一个常见变体叫计数信号量用于资源计数另一种是二值信号量行为接近互斥锁。注意不要拿二值信号量当互斥锁用因为语义不同互斥锁有所有者概念信号量没有混用会导致一些微妙的 bug比如优先级反转处理上的差异。2.5 原子操作与无锁能不用锁就别用锁前面几种机制都靠阻塞来协调原子操作Atomic走的是另一条路底层用 CPU 提供的原子指令比如 CASCompare-And-Swap在不阻塞线程的前提下完成操作。它没有线程挂起和上下文切换的开销在高竞争场景下反而是更轻的选择。最简单的用法是原子计数器// C std::atomicint counter{0}; void worker() { for (int i 0; i 100000; i) { counter.fetch_add(1, std::memory_order_relaxed); } }// Java private final AtomicInteger counter new AtomicInteger(0); public void inc() { counter.incrementAndGet(); }// Go var counter atomic.Int64 func worker() { for i : 0; i 100000; i { counter.Add(1) } }这段代码跑出来结果精确等于一百万且不需要任何锁。原理是fetch_add在硬件层面就是一条不可分割的指令其他线程无法在中途插进来。原子操作的适用范围是有边界的。它擅长单变量的读改写比如自增、交换、比较并交换。一旦涉及多个变量的一致性更新单纯的原子操作就不够了这时候要么用锁要么用更复杂的无锁算法而且要配内存序来保证可见性。内存序Memory Order是原子操作里最难的部分。上例里的memory_order_relaxed只保证操作本身原子不保证其他内存访问的顺序。默认的memory_order_seq_cst最严格也最慢。C 里还有acquire、release、acq_rel等。如果你对这套还没建立起直觉我的建议是先用默认的seq_cst等压测真的发现瓶颈了再往下调。为了省几十纳秒去调内存序结果调出个偶发 bug实在不划算。关于无锁队列这类结构我持谨慎态度。教科书上的无锁实现往往有几个隐含前提CAS 指令的性能、ABA 问题的处理、内存回收机制比如 hazard pointer、epoch 回收。没有把这些都想清楚就上手写出来的无锁很可能比加锁还慢甚至存在正确性缺陷。业界成熟的无锁队列如 Java 的ConcurrentLinkedQueue、C 的 moodycamel::ConcurrentQueue都是反复打磨过的用现成的比自己造轮子靠谱得多。3. 真实场景下怎么选四个典型案例的落地过程3.1 生产者-消费者队列这是并发编程的经典模型我把它当成检验同步机制理解的试金石。需求是这样的多个生产者线程往队列里放任务多个消费者线程取任务执行要求不丢任务、不重复、队列满时生产者等待、队列空时消费者等待。一个完整可用的实现需要三样东西互斥锁保护队列、两个条件变量分别管理非空和非满、一个固定容量上限。// Java 版手写实现对比 JDK 自带的 ArrayBlockingQueue public class BoundedQueueT { private final QueueT queue new LinkedList(); private final int capacity; private final ReentrantLock lock new ReentrantLock(); private final Condition notFull lock.newCondition(); private final Condition notEmpty lock.newCondition(); public BoundedQueue(int capacity) { this.capacity capacity; } public void put(T item) throws InterruptedException { lock.lock(); try { while (queue.size() capacity) { notFull.await(); } queue.offer(item); notEmpty.signal(); } finally { lock.unlock(); } } public T take() throws InterruptedException { lock.lock(); try { while (queue.isEmpty()) { notEmpty.await(); } T item queue.poll(); notFull.signal(); return item; } finally { lock.unlock(); } } }为什么用两个条件变量而不是一个因为等待的原因不同。生产者等的是队列不满消费者等的是队列不空。如果共用一个条件变量生产者放进一个元素后notify_all唤醒的可能是另一个生产者——它一看队列还是满的又睡回去了真正的消费者却没被唤醒。分开之后每次signal都能精准唤醒需要的那类线程减少无谓的唤醒开销。这个模型在真实系统里到处都是线程池的任务队列、消息中间件的本地缓冲、日志异步落盘、网络框架的事件派发。理解了它一大半并发场景就通了。3.2 双重检查锁定的单例初始化单例模式看似简单多线程环境下写对却不容易。先看一个错误的版本// 错误示范 public class Singleton { private static Singleton instance; public static Singleton getInstance() { if (instance null) { // 检查一 synchronized (Singleton.class) { if (instance null) { // 检查二 instance new Singleton(); } } } return instance; } }这段代码看起来逻辑严密实际有严重问题。问题出在instance new Singleton()这行它在字节码层面是三步分配内存、调用构造函数、把引用赋给 instance。编译器和 CPU 可能把第二步和第三步重排序。结果就是另一个线程在检查一那里看到instance ! null直接返回了一个还没构造完的对象用起来就是各种莫名其妙的空指针或者字段为零。修复方式是把instance声明为volatileprivate static volatile Singleton instance;volatile在这里的作用是禁止指令重排序保证构造完成后才把引用写出去。Java 5 之后这套写法才成立之前版本的内存模型有缺陷。// C 11 之后的写法 class Singleton { public: static Singleton getInstance() { static Singleton instance; // C11 保证静态局部变量初始化的线程安全 return instance; } Singleton(const Singleton) delete; Singleton operator(const Singleton) delete; };C 的方案更省心C11 标准明确要求静态局部变量的初始化是线程安全的编译器会自己加锁。这也是为什么现代 C 里手工写双重检查锁定的场景越来越少了。实操心得除非有明确需求比如需要延迟初始化、需要传参绝大多数场景下类的静态初始化和依赖注入框架已经能解决单例问题。为了省那一点初始化时间手写双重检查锁定反而容易踩内存序的坑。3.3 高频计数与限流器秒杀场景里要给接口做限流QPS 上限一千。最简单的做法是计数器每秒清零请求进来先加一超过一千就拒绝。朴素实现是加锁计数但每秒几千次请求锁的竞争会成为瓶颈。用原子变量改进// Java public class RateLimiter { private final AtomicLong windowStart new AtomicLong(System.currentTimeMillis()); private final AtomicInteger count new AtomicInteger(0); private final int limit; public RateLimiter(int limit) { this.limit limit; } public boolean tryAcquire() { long now System.currentTimeMillis(); long start windowStart.get(); if (now - start 1000) { // 尝试开启新窗口只有一个线程能成功 if (windowStart.compareAndSet(start, now)) { count.set(1); return true; } } return count.incrementAndGet() limit; } }这里用到了 CAScompareAndSet(start, now)只有当前值还等于start时才更新成功从而保证同一时刻只有一个线程能开启新窗口。其余线程会在计数上加一超过阈值就拒绝。这种固定窗口计数器有个已知缺陷流量可能在窗口边界处突刺。比如前 0.9 秒来了九百个请求后 0.1 秒又来九百个两个窗口各算各的瞬时压力接近两倍。解决办法是滑动窗口或者令牌桶但底层依赖还是这些同步原语。3.4 后台任务优雅退出服务要下线得等正在处理的任务做完再退出不能一刀切。这个需求看着不起眼写不好就是数据不一致。常见的坑是用一个布尔标志位控制循环// 不推荐 private boolean running true; public void run() { while (running) { // 处理任务 } } public void shutdown() { running false; // 主线程改工作线程可能永远看不到 }running不是volatile工作线程可能一直读缓存里的旧值导致死循环退不出来。即使加了volatile如果工作线程阻塞在队列的take()上也感知不到标志位变化。正确做法是中断 条件变量唤醒的组合private volatile boolean running true; private final BlockingQueueTask queue new LinkedBlockingQueue(); public void run() { while (running || !queue.isEmpty()) { Task task; try { task queue.poll(100, TimeUnit.MILLISECONDS); } catch (InterruptedException e) { Thread.currentThread().interrupt(); break; } if (task ! null) { process(task); } } } public void shutdown() throws InterruptedException { running false; // 主动投递一个毒丸任务唤醒阻塞在 poll 上的线程 queue.offer(POISON_PILL); }poll带超时这样即使没有被唤醒最多一百毫秒也会检查一次running。volatile保证标志位对其他线程可见。如果再配合一个CountDownLatch主线程可以await所有工作线程退出后再结束进程。4. 踩坑实录死锁、性能塌方与排查手段4.1 死锁的四个必要条件与复现死锁是同步代码里最让人头疼的问题因为触发条件往往很微妙测试环境跑一万遍不出事线上一上量就卡住。死锁的产生需要四个条件同时成立互斥资源同一时间只能被一个线程持有、持有并等待线程持有资源同时等待其他资源、不可抢占资源不能被强行夺走、循环等待存在一个线程等待环。打破任意一个条件死锁就解了。最经典的复现是两个线程以相反顺序获取两把锁// 线程 1 synchronized (lockA) { Thread.sleep(100); synchronized (lockB) { /* ... */ } } // 线程 2 synchronized (lockB) { Thread.sleep(100); synchronized (lockA) { /* ... */ } }两个线程各持一把锁等另一把谁也放不下程序永远卡在这。预防的手段主要有几个。一是统一加锁顺序所有线程都按 lockA - lockB 的顺序获取循环等待就不成立了。这是最简单也最有效的办法代价是需要在设计阶段就把锁的层级定下来并写进代码规范。二是用带超时的锁tryLock(1, TimeUnit.SECONDS)拿不到就放弃并释放已持有的锁避免无限等待。三是减少锁的数量能用一把大锁解决的场景就别拆成五把。排查线上死锁工具很重要。Java 里jstack pid会直接打印死锁检测结果标出哪几个线程在互相等堆栈一目了然。C 的 gdb 可以 attach 上去看线程栈或者用pstack。Go 更省事一旦检测到所有 goroutine 都阻塞运行时会直接 panic 并打印所有 goroutine 的堆栈fatal error: all goroutines are asleep - deadlock!这行提示救过不少人。4.2 锁粒度、伪共享与性能塌方代码正确了不代表性能没问题。同步代码常见的性能问题有三类。第一类是临界区过大。把整个方法都synchronized里面包含数据库查询、网络调用、复杂计算结果所有线程串行执行。改进方法是只锁真正的共享数据访问把耗时操作挪出去。改造前后 QPS 差十倍都是常见的。第二类是锁竞争激烈。几百个线程抢一把锁大部分时间花在挂起和唤醒上。典型的解决思路有分段锁ConcurrentHashMap 早期的做法就是把哈希表分成十六段各段独立加锁、读写锁、无锁结构、线程本地存储ThreadLocal避免共享。第三类是伪共享False Sharing。这个概念比较隐蔽。CPU 缓存是按缓存行通常 64 字节加载的如果两个不同线程频繁写的变量恰好落在同一个缓存行里即使它们逻辑上无关也会互相导致缓存行失效性能断崖式下降。// 有问题a 和 b 很可能落在同一个缓存行 struct Counters { std::atomiclong a; std::atomiclong b; }; // 改进用填充把两个变量隔开 struct alignas(64) AlignedCounter { std::atomiclong value; };Java 里可以用Contended注解需要开启-XX:-RestrictContended或者是继承自AbstractPaddingObject之类的填充类。这个问题在低并发时不明显一到几十个核的机器上就暴露出来压测时如果发现 CPU 占用高但吞吐上不去可以往这个方向查。实操心得性能优化永远从测量开始。不要凭直觉猜瓶颈在哪先用 perf、async-profiler 或者语言自带的 profiler 定位热点。我见过有人为了优化锁把代码改得面目全非最后发现真正的瓶颈是日志打印。4.3 常见问题速查表把上面这些坑整理成一张表出问题的时候可以对着查现象可能原因排查手段解决思路程序卡死无响应死锁jstack / pstack / Go panic 日志统一加锁顺序、用 tryLock 超时计数结果偏小竞态条件加日志观察交错执行加锁或用原子变量改了标志位不生效内存可见性检查变量是否有 volatile加 volatile 或用锁保护线程无故被唤醒虚假唤醒检查 wait 是否在 while 里改为 while 循环检查条件通知丢失条件变量无状态检查 notify 是否早于 wait状态由锁保护谓词判断CPU 高但吞吐低伪共享或自旋过多perf 看缓存失效缓存行填充、减少自旋偶尔返回半初始化对象指令重排序检查双检锁写法加 volatile 或改静态初始化写线程长期不执行读写锁写饥饿观察锁等待时间分布开启公平模式或改用互斥锁这张表是我这些年实际踩过的坑总结不一定全但覆盖了八成以上的常见问题。5. 跨语言视角各平台同步原语的差异5.1 C、Java、Go、Python 的同步模型对比同样是同步不同语言的抽象层次差别很大理解这些差异能帮你在换语言时不迷路。C 走的是贴近硬件的路线。std::mutex、std::condition_variable、std::atomic、std::shared_mutex一应俱全还允许你指定内存序。自由度最高责任也最大。写 C 并发代码你得懂内存模型得知道std::atomic在不同平台上的实现差异。好处是性能天花板高坏处是坑多。Java 把内存模型JMM明确写进了语言规范。synchronized关键字既保证互斥又保证可见性volatile保证可见性和禁止部分重排序java.util.concurrent包提供了大量成熟工具类。ReentrantLock、CountDownLatch、CyclicBarrier、Semaphore、ConcurrentHashMap、BlockingQueue几乎你能想到的场景都有现成的。Java 开发者的幸福感很大程度来自这个包。Go 的口号是用通信代替共享内存。它提供了sync.Mutex、sync.RWMutex这些传统原语但官方推荐用 channel 来协调 goroutine。channel 底层也是锁只是把同步逻辑藏起来了。// Go 用 channel 实现信号量效果 sem : make(chan struct{}, 20) // 容量 20 的信号量 func query() { sem - struct{}{} // 获取 defer func() { -sem }() // 释放 // 业务逻辑 }这种写法读起来更直观出错概率也低。不过 channel 不是银弹涉及复杂共享状态时sync.Mutex依然是更好的选择。Python 的情况特殊因为有 GIL全局解释器锁。GIL 保证同一时刻只有一个线程执行 Python 字节码所以纯 Python 代码里的很多竞态其实被 GIL 挡住了。但这不意味着可以不用锁counter 1这种操作在字节码层面可能被打断共享数据的保护仍然必要。另外 GIL 只保护 Python 层的对象C 扩展里的数据结构不受它保护。真要做 CPU 密集计算多进程或者用 C 扩展绕过 GIL 才是正路。5.2 选型的几条实用判断标准结合上面这些我总结了几条选型思路供参考。能用语言提供的封装就别自己造。Java 的BlockingQueue、C 的std::atomic、Go 的 channel都是经过大量验证的自己手写一套大概率不如它们。除非有明确的性能或语义需求否则直接用。先想清楚是互斥还是协作。互斥是说这段代码同时只能一个人进用互斥锁或读写锁协作是说我要等到某个条件成立用条件变量、信号量或者 channel。这两类需求用的原语完全不同混用会写出很别扭的代码。从粗粒度开始按需细化。一开始就用一把大锁把共享数据全保护起来逻辑清晰不容易错。等压测真的发现锁竞争成为瓶颈再考虑拆分。过早优化不仅浪费时间还容易引入 bug。同步代码的可读性比性能重要一个数量级。一段需要看十分钟才能理解的同步代码未来改动的风险极高。加锁顺序、临界区边界、条件判断这些都应该让读者一眼看明白。如果做不到说明设计有问题该重构了。别忽视测试。并发 bug 的特点是概率性、难复现。写完之后用压测工具跑一跑用-raceGo、ThreadSanitizerC/Go、jcstressJava这类专门的检测工具扫一遍能提前发现不少问题。这些工具的投入产出比很高值得花时间学一下。我在实际项目里用得最多的一套组合是状态共享用互斥锁或读写锁线程间传递任务用阻塞队列或 channel计数和标志位用原子变量或 volatile需要等待条件时用条件变量需要控制并发度用信号量。这套组合覆盖了九成以上的场景剩下的边缘情况再具体问题具体分析。踩过几次坑之后你会发现同步代码写得好不好跟用了多高级的原语关系不大关键还是对共享状态的理解够不够清楚。