企业官网建设流程全解析

多线程系列写到这里，终于到了我最想聊的部分。

前两篇我们解决了“怎么把线程开起来”和“怎么保证多个线程不互相踩脚”的问题，也就是线程的创建、启动，以及锁、同步这些基础机制。但说实话，那些只是序幕。今天这篇“多线程03”，我想集中火力讲清楚一个更核心的问题：**多个线程之间到底怎么协作？**你会发现，实际开发里几乎没有哪个正经功能是只靠一个线程从头跑到尾的。不管是做Java后端的高并发接口、写Python里的并发爬虫，还是用Qt搞界面和后台任务分离，只要你让多个线程同时存在，就一定会遇到“数据怎么交接”“活怎么分配”“谁等谁、谁叫谁”这些破事。

这篇的内容适合谁看呢？两类人。一是写过多线程但总觉得心里没底，一碰到线程间交互就靠复制粘贴的开发者；二是准备面试，被“生产者消费者”“线程通信”这些经典题反复折磨的同学。我会从最底层的原理讲到可以直接抄的代码，再讲实践中的坑，用尽量不端着的方式把这件事讲透。

1. 为什么说线程协作才是多线程真正的分水岭

1.1 会开线程不等于会写多线程

我面试的时候经常遇到这样的候选人：问线程怎么创建，能一口气背出继承Thread、实现Runnable、线程池三种方式，说得头头是道。但紧接着问“两个线程交替打印1到100，怎么设计”就卡住了。或者问得更实际一点：“你的服务里有个线程往数据库写日志，另一个线程要读这份日志做实时统计，怎么保证数据不错乱、不丢数据、不互相卡死”这类还是一样的沉默。

这其实很正常。开线程说白了就是一行代码的事，哪怕完全不懂原理，照着文档也能把线程跑起来。但让多个线程协作，是在和一个极其不直观的东西打交道：并发的不确定性。单线程程序是一条直线，从上往下走，结果是可以预测的，出了bug也好复现。多线程程序是一团互相交错、随时可能改变执行顺序的乱线，同一个输入可能跑出一百种不同的时序，而只有其中一两种会出问题，还偏偏挑你演示给老板看的时候出。

协作的本质，是几方共同完成一件只有一个人做不了或者做起来太慢的事。用生活里的事来打比方，就像厨房里一个人炒菜：洗菜、切菜、下锅、装盘，全流程一个人干，不需要跟任何人商量。但如果你现在是一个后厨团队：一个师傅负责切菜，一个师傅负责炒菜，一个师傅负责装盘出餐，问题就来了：切菜师傅切完了往哪放？炒菜师傅怎么知道有菜可以炒了？装盘师傅怎么知道哪份菜炒好了？如果切得太快而炒得太慢，切好的菜堆在案板上会不会放坏？如果炒菜太快而切菜跟不上，炒锅空转是不是浪费？

这些问题，就是多线程协作要解决的问题。代码里的多个线程，本质上就是后厨里那几个各司其职的师傅。你要在它们之间建立一套秩序，让它们知道：东西放哪、什么时候该等、活干完了怎么通知下一个人。

1.2 并发协作绕不开的三个底层矛盾

把各种花里胡哨的并发问题剥开来看，核心就是三件事：共享、往返、等待与唤醒。可以这样理解：

共享：多个线程要访问同一份数据，比如同一个库存数量、同一个任务队列。这时候你不能让它们同时动手改，否则数据就乱了。上一篇文章讲的锁、synchronized、各种原子类，解决的就是这个问题——大家排队进门，一次只让一个人动公共资源。

往返：一个线程干完活，要把结果交给另一个线程。这在单线程里毫无成本，变量一赋值，下一条语句就能读。但在多线程里，“A线程写了，B线程能看到吗”这个问题由于内存可见性的存在，变得极其微妙。这也是为什么会有volatile、有各种内存屏障、有各种队列——本质上都是在解决“怎么让另一个线程可靠地看到我写的东西”。

等待与唤醒：线程之间经常需要配合节奏。比如你是一个消费者线程，要去队列里取任务，但队列是空的，怎么办？不能傻转，那叫忙等待，白白烧CPU。你需要等，等生产者往队列里放了东西再叫你。这就涉及线程从“运行”到“阻塞”再到“唤醒”的状态切换，以及等待谁、别人怎么通知你的机制。

这三个矛盾不是互相独立的，常常揉在一起出现。我见过很多人的第一版并发代码，就是简单粗暴地把共享数据加个锁，结果发现两个线程还是不能配合干活——因为只解决了“共享”问题，没解决“往返”和“等待与唤醒”问题。所以真正要设计一套协作流程，得把这三个问题当成一个整体来看，而不是头疼医头。

2. 生产者消费者模式：几乎所有协作场景的通用答案

2.1 用排队代替扯皮：这个模式到底解决了什么问题

在多线程协作的众多模式里，生产者-消费者模式（Producer-Consumer Pattern）是流传最广、适用面最大、面试出场率最高的一个。它解决的正是上面说的三个矛盾的组合题：一个或多个线程负责生产数据（产生任务、处理请求、生成消息），一个或多个线程负责消费数据（处理任务、落库、响应请求），两边不直接见面，而是通过一个中间的缓冲区来交接。

为什么中间要隔一层？我总喜欢用奶茶店的例子，特别直观。奶茶店里有几个做奶茶的师傅，外面有骑手来取餐。如果每个师傅做出一杯奶茶，要亲自找到对应订单的骑手、亲手交给对方，会发生什么？做奶茶的师傅得满店找骑手，骑手催单的时候还容易拿错。店一忙起来，师傅根本没时间做奶茶，全在干“对接”这种破事。

实际奶茶店怎么干？柜台或架子上有一排做好的奶茶，师傅做完往架上一放，喊一嗓子“xx号好了”，骑手自己来取。这就是生产者和消费者之间的中间缓冲区。它的价值有三个，也是生产-消费模式的核心价值：

第一是解耦。生产者不需要知道消费者是谁、有几个、现在忙不忙，只需要往缓冲区里放东西。消费者也不需要知道生产者是谁、一次放多少，只需要从缓冲区里取。两边各自按自己的节奏干活，互不干涉。

第二是削峰填谷。如果消费者处理速度慢，生产者速度快，没有缓冲区的话，生产者只能等消费者，整体性能被最慢的环节拖死。有了缓冲区，生产者可以先把任务堆在队列里，消费者慢慢消化，系统整体吞吐量就有了缓冲余地。反过来也一样，消费者速度快的空闲时段，缓冲区里没什么活，它也不会阻塞生产者。这个思想在电商大促、网关限流、消息队列的场景里到处都是。

第三是节奏协调。缓冲区空的时候，消费者不该来取东西；缓冲区满的时候，生产者不该再往里面塞东西。这就顺理成章地引出了“等待与唤醒”的问题：空的时候消费者等着，等生产者放进来一个就通知它；满的时候生产者等着，等消费者取走一个再通知它。这个等待和通知的机制，就是下面代码里反复出现的那些wait、notify、put、take命令。

2.2 Java、Python、Qt里各自怎么落地

思想是通用的，但各个语言生态里落地的方式差别还挺大，我简单对比一下，方便大家根据自己主力语言去对照理解。

在Java多线程的世界里，JDK的java.util.concurrent包直接提供了现成的阻塞队列，最常用的就是ArrayBlockingQueue（有界，固定容量）和LinkedBlockingQueue（无界，或指定容量）。它们封装的put和take方法自带阻塞和唤醒逻辑：队列满的时候put会阻塞，队列空的时候take会阻塞，线程之间的通知由JDK内部管好。你只需要创建队列，让生产者线程调put、消费者线程调take即可，几乎不需要自己写一行锁和等待代码。这是我在实际项目里最推荐的做法，可靠、性能好、代码量少。

Python中的多线程思路差不多，标准库的queue.Queue就是为这个场景准备的。它的put和get也自带阻塞行为，配合threading.Thread使用非常顺。不过要注意Python有个GIL（全局解释器锁）的机制，多线程在CPU密集型任务上并不能真正并行，但在IO密集型任务（比如爬虫等待网络响应）里，用多线程配合队列做生产者消费者依然非常顺手。

Qt多线程是另一种思路。Qt最强的优势是信号槽机制，跨线程通信就是靠信号槽的队列连接（QueuedConnection）完成的。简单说，一个工作线程处理完数据，发射一个信号，另一个线程对应的槽函数会被异步调用，数据参数随之传递过去。Qt里还有个高大上的类叫QThreadPool和QtConcurrent，配合信号槽也可以实现任务分发和结果回收。用Qt写多线程协作，上手其实是三个生态里最“软化”的——因为信号槽把线程间的往返封装得非常好，不需要你直接操作锁和等待原语。

下表简单对比一下：

看到这些对照你会发现，不管用什么工具，背后的核心骨架都还是那条：一个中间缓冲区 + 两个方向的等待通知。

3. 从wait/notify到高级并发工具：一套能直接用的实现方案

3.1 版本一：手写wait/notify，先把原理吃透

我始终认为，要理解Java里高级并发工具的价值，得先手写一遍底层。不然你永远不知道BlockingQueue那几个方法背后替你干了多少脏活累活。下面这个版本不用任何并发工具类，纯靠最原始的synchronized、wait、notifyAll来实现生产者消费者。

import java.util.LinkedList; import java.util.List; public class ProducerConsumerDemo { private static final int CAPACITY = 5; // 缓冲区容量 private final List<Integer> buffer = new LinkedList<>(); private final Object lock = new Object(); // 所有线程共用同一把锁 private int count = 0; // 生产者：往缓冲区放数据 public void produce() throws InterruptedException { synchronized (lock) { // 缓冲区满了，生产者必须等待，直到消费者取走数据 while (buffer.size() == CAPACITY) { System.out.println(Thread.currentThread().getName() + " 等待，缓冲区已满"); lock.wait(); } buffer.add(++count); System.out.println(Thread.currentThread().getName() + " 生产 " + count + "，当前容量：" + buffer.size()); lock.notifyAll(); // 唤醒所有等待中的线程 } } // 消费者：从缓冲区取数据 public void consume() throws InterruptedException { synchronized (lock) { // 缓冲区空了，消费者必须等待，直到生产者放入数据 while (buffer.isEmpty()) { System.out.println(Thread.currentThread().getName() + " 等待，缓冲区为空"); lock.wait(); } int value = buffer.remove(0); System.out.println(Thread.currentThread().getName() + " 消费 " + value + "，剩余数量：" + buffer.size()); lock.notifyAll(); } } public static void main(String[] args) { ProducerConsumerDemo demo = new ProducerConsumerDemo(); // 两个生产者线程 for (int i = 0; i < 2; i++) { new Thread(() -> { while (true) { try { demo.produce(); Thread.sleep(300); // 模拟生产耗时 } catch (InterruptedException e) { Thread.currentThread().interrupt(); break; } } }, "生产者-" + i).start(); } // 两个消费者线程 for (int i = 0; i < 2; i++) { new Thread(() -> { while (true) { try { demo.consume(); Thread.sleep(500); // 模拟消费耗时 } catch (InterruptedException e) { Thread.currentThread().interrupt(); break; } } }, "消费者-" + i).start(); } } }

这段代码有四个关键细节，新手最容易栽跟头，我逐个说：

第一，wait()必须放在synchronized块里。lock.wait()会释放当前线程持有的lock锁，并进入等待状态。如果没持有锁就调用wait，直接抛IllegalMonitorStateException。这个设计是有道理的：wait的意思是“我检查了条件，发现不满足，需要把锁让出来，等条件满足了再回来抢锁”，只有持锁者才有资格决定让出。

第二，条件检查必须用while，不能用if。网上很多老教程写if (buffer.size() == CAPACITY) { wait(); }，这是有隐患的。线程从wait被唤醒后，会回到wait语句的下一条继续执行，但这时它并没有重新抢到锁——它在等锁队列里排队，等其他线程释放锁。等它真正拿到锁往下走的时候，条件可能已经被别的线程改过了。比如两个消费者同时等空队列，生产者放入一条消息后调用notifyAll，两个消费者都被唤醒，但队列里只有一条数据。如果用的是if，第二个抢到锁的线程会直接remove(0)，而这时候缓冲区已经是空的，就会越界。用while的好处是：每次拿到锁后都重新检查条件，不满足就继续等。这个设计叫“循环等待”，可以同时防止虚假唤醒和信号丢失。

第三，通知要选择notifyAll而不是notify。notify只会随机唤醒一个等待线程，如果唤醒的是同类线程，比如缓冲区满时，生产者都在等，你唤醒了一个生产者——它一看还是满的，继续等，而死等的消费者永远不被唤醒，程序就卡死了。notifyAll把所有线程都叫醒，各自去抢锁、重新检查条件，虽然竞争激烈一点，但绝对不会出现“该被叫醒的人没被叫到”的问题。

第四，sleep和wait是两个完全不同的东西。这里的Thread.sleep(300)模拟的是“干活耗时”，sleep不会释放锁，所以一定要放在synchronized代码块外面，不然一个线程在睡觉，其他线程全部被堵死。这也是很多初学版本把sleep写在同步块里面之后程序突然变慢、甚至变卡的原因。

3.2 版本二：BlockingQueue一行入队，生产环境该用就用

看完手写版本，再来看JDK提供的现成方案，你就能体会到什么叫“科技与狠活”。下面这个版本，用一个ArrayBlockingQueue就把上面对三个底层矛盾的处理全部解决了：

import java.util.concurrent.ArrayBlockingQueue; import java.util.concurrent.BlockingQueue; public class BlockingQueueDemo { public static void main(String[] args) { // 有界队列，容量5 BlockingQueue<Integer> queue = new ArrayBlockingQueue<>(5); // 生产者线程 Thread producer = new Thread(() -> { int i = 0; while (true) { try { queue.put(++i); // 队列满了会自动阻塞 System.out.println(Thread.currentThread().getName() + " 生产 " + i + "，队列剩余：" + queue.size()); Thread.sleep(200); } catch (InterruptedException e) { Thread.currentThread().interrupt(); // 恢复中断标记 break; } } }, "生产者"); // 消费者线程 Thread consumer = new Thread(() -> { while (true) { try { Integer value = queue.take(); // 队列空了会自动阻塞 System.out.println(Thread.currentThread().getName() + " 消费 " + value + "，队列剩余：" + queue.size()); Thread.sleep(500); } catch (InterruptedException e) { Thread.currentThread().interrupt(); break; } } }, "消费者"); producer.start(); consumer.start(); } }

对比一下，手写版本三十多行核心逻辑，换成BlockingQueue之后，核心只有put和take两行。但这里我特别想说两个细节，因为很多人在实际项目里照样用错：

一个是**“有界”与“无界”的选择**。ArrayBlockingQueue必须要指定容量，这一点很多人觉得麻烦，但它是保护你系统的关键。如果有消费者处理速度跟不上，无界队列会无限堆积任务，最终内存被打爆，甚至拖垮整个应用。有界队列则相当于给缓冲区设了极限，生产者等不进去的时候会被迫阻塞，形成天然的背压（Backpressure）——消费能力跟不上，生产速度自动降下来。这在高并发接口设计里是非常重要的思想。我在项目里默认用有界队列，容量根据峰值流量和平均消费耗时估算，宁可让调用方等一等，也不能让它无限堆任务。

另一个是中断处理。代码里的catch (InterruptedException e) { Thread.currentThread().interrupt(); break; }，新手往往不理解为什么要多写那一行。当线程被interrupt时，JDK会清除线程的中断标记，你catch住异常后如果不把标记重新设置回去，上层代码再检查Thread.currentThread().isInterrupted()的时候就会得到false，等于把“有人要求我中断”这个信息弄丢了。规范做法是：捕获InterruptedException后，要么直接退出，要么恢复中断标记再退出。这是Java并发代码里的一个约定，面试时你能说出这个细节，会显得非常专业。

3.3 三个进阶工具：CountDownLatch、CyclicBarrier、Semaphore

除了阻塞队列，JDK还提供了一组更细粒度的协作工具。它们不是处理生产消费链路的，而是处理“多个线程之间互相等”的各种具体场景。

CountDownLatch，可以理解成“倒计时门闩”。你设置一个计数值N，创建N个线程各自干活，主线程调用await()等待，直到N个线程都干完或者都调用countDown()把计数减到0，主线程才被放行。最适合的场景是：一个任务需要拆成多个子任务并发执行，主线程汇总所有子任务的结果。比如批量导出报表，开四个线程分别查四个数据源，全部查完再合并写文件。注意CountDownLatch是一次性的，计数减到0就不能再用了。

CyclicBarrier，可以理解成“人齐了再出发”。与CountDownLatch相反，它是多个线程之间互相等：N个线程都到达屏障点才一起放行。很适合“分阶段并发”的场景，比如模拟并发压测时，所有线程先准备好，在同一个瞬间同时发出请求。CyclicBarrier的循环体现在“Cyclic”这个单词上，它是一次性用完可以继续复用的，适合做多轮任务。生活类比就是旅游团集合：所有人到齐了，导游才带着一起进景点，进入下一站之前再次集合。

Semaphore，信号量，可以理解成停车场入口的闸机。它维护一个许可证数量，线程调用acquire()获取许可证，拿不到就阻塞等待，用完调用release()归还。它解决的是“限流”问题：同一时刻最多允许多少个线程访问某段代码。比如你的接口最多支持10个并发调用，超过的就得排队，Semaphore就能精确控制这个数字。与前面两个工具不同，Semaphore强调的是并发度的控制，而不是阶段性的集合等待。

这几个工具在实际项目里各有用途，面试也常被拿来对比。下面这个表是我经常拿来跟人讲解的对比，收好就行：

用Java做后端的朋友把这些吃透以后，基本可以应付日常95%以上的协作场景了。至于更高阶的CompletableFuture、StampedLock，那是另一个深水区的知识，这篇就不展开了。关键是先把这个基础盘子盘住。

4. 面试题与实战踩坑：常见问题的定位和排查

4.1 高频面试题：这些坑几乎每个人都会踩

多线程面试题可以说是Java后端面试的重头戏，搞懂了也确实是检验功力的好方法。结合多线程和高并发这两个面试大热门，我把最高频的几个坑整理一遍，每个都说说背后的原理和回答要点，这样不管是真面试还是自查，都有抓手。

虚假唤醒到底是什么。这是最经典的一道题，也是验证你写过代码没有的分水岭。前面讲while循环那里我提了一嘴，但面试官会专门问：if和while有什么区别？标准回答是：多线程环境下，线程可能在没有被notify、也没有其他任何线程调用notifyAll的情况下自发地醒来（这在底层是允许的），这叫虚假唤醒。更常见的情况是，多个线程同时被唤醒，但共享资源的状态只允许其中一个继续执行。无论是哪种情况，如果用if判断条件，唤醒后会直接往下走，可能操作非法状态；用while就可以醒来后重新检查条件，不满足再回去等。回答时顺便引出“所以wait()永远要放在while循环里”这个结论，基本这题就过关了。

死锁是怎么产生的？四个必要条件背下来先：互斥（共享资源同时只能被一个线程持有）、持有并等待（持有一个资源的同时还想去拿另一个）、非抢占（资源不能被别人强行抢走）、循环等待（多个线程互相持有对方需要的资源，形成环）。光背这个不算完，面试官还会让你写一个死锁demo，或者问你“如何避免死锁”——标准答法是破坏四个条件之一：比如按固定顺序加锁（避免循环等待）、用tryLock设置超时（防止无限等待）、尽量缩短同步块范围（降低持有等待的时间）。我给一个实用建议：在项目里制定一个“所有人按照同样的顺序获取多把锁”的团队约定，这是成本最低的死锁预防手段。

上下文切换为什么影响性能？一个CPU核心在任意时刻只能真正执行一个线程，多线程所谓的“并发”靠的是时间片轮转。每次切换，操作系统都要保存当前线程的上下文（寄存器、程序计数器、栈）、加载下一个线程的上下文，这本身就有开销，更别说切换可能触发缓存失效。这就是为什么高并发场景下不是线程越多越好：线程太多了，大量时间花在切换上，实际干活的时间反而少了。面试回答这个问题的关键点是——能说出上下文切换带来的三个成本：寄存器保存/恢复、CPU缓存失效、系统调用开销。

锁的粒度怎么设计？有些人的第一版并发代码，图省事用一个synchronized把整个方法都锁住，结果并发量上不去，所有线程都在抢同一把锁，相当于又退化回单线程了。锁的粒度就是“你保护的数据范围有多大”。锁越小，允许同时执行的线程越多，并发度越高，但太细又会增加获取锁和死锁的复杂度。实际项目里的经验法则是：只锁真正需要保护的共享变量操作，不要锁无关代码；多个变量有关联性的时候也不能拆得太碎，否则中间态会被别人看到，具体怎么权衡要结合业务判断。

线程池的参数怎么设置。高并发面试几乎必问线程池七个参数：核心线程数、最大线程数、空闲存活时间、存活时间单位、任务队列、线程工厂、拒绝策略。问得最多的就是核心线程数怎么定。网上流传的公式很多，但都是经验值，我常用的参考：CPU密集型任务设为核心线程数 = CPU核数 + 1；IO密集型任务设为核心线程数 = CPU核数 * 2 + 1。公式给完之后记得补一句：这只是起跑线，真正要结合压测调优，看线程池的监控数据来修正。这一句会让面试官觉得你是真做过项目的人，而不是背了八股文。

4.2 线程卡死时的排查三板斧

多线程最恶心的一点是：bug不一定会稳定复现，但生产环境一卡顿，排查起来无数种可能。我踩过几次这样的坑以后，总结出了一套固定流程，分享出来给大家。

第一步，抓线程转储。如果你的应用是Java，最简单的办法是jstack命令，把指定进程ID的线程快照打出来。命令大概是这样的：

jstack -l <pid> > thread_dump.txt

打开这个文件，你会看到每个线程的状态和调用栈。关键看两种状态：BLOCKED和WAITING。BLOCKED表示线程在等锁，能清楚看到它在等哪个锁、哪个线程持有这把锁；WAITING表示线程在等条件，能看到它在哪个对象上等待。如果生产环境不方便连机器，也可以通过应用暴露的JMX端口远程获取ThreadMXBean的线程信息，原理一样。我一般是在监控系统里直接集成线程转储的抓取功能，卡顿发生时自动留证。

第二步，给日志加上线程名和时间戳。很多线程问题查不出来，是因为日志根本看不出是哪个线程打的。我在实际项目里统一要求日志格式必须带线程名和毫秒级时间戳，这样一翻日志，就能顺着时间线把线程的执行轨迹拼出来。比如排查一次“消费者消费速度突然变慢”的问题，日志里能看到多个消费者线程都在同一条WAITING状态，就知道是等待队列出问题了，还是生产者的put被什么逻辑卡住了。这一步最大的价值在于：把“猜”变成了“看”。

第三步，带上线程名做堆栈分析。拿到线程转储以后，不要只看单个线程，要看线程之间的依赖关系。A线程BLOCKED等一把锁，锁被B线程持有；B线程BLOCKED又等另一把锁，被A线程持有——这就是典型的循环等待，死锁实锤。如果是WAITING状态，再去查对应代码里的wait条件，看看是不是生产线程没有按预期notify。经验是：一个线程转储有时候看不出问题，因为它们刚好都在正常运行。那就隔几秒连续抓三到五次，看哪个线程的状态一直不变、卡在那里不动，那个基本上就是问题线程。

再说一个我自己的真实案例。有一次一个异步任务处理服务突然吞吐量下降，CPU占用率却居高不下。一开始以为是代码性能问题，怎么优化都不见起色。后来抓了一次线程转储，发现几十个工作线程全部卡在同一个队列的poll()方法上，原来是有个线程在无限循环里消费队列，但消费的速率极慢，导致任务积压。而真正原因更离谱：那个消费者线程每次取任务后都会调用一个外部接口，外部接口超时时间设得太长，超时期间线程一直在等待，队列里的任务越积越多。本质上这不是阻塞队列的问题，而是“阻塞在外部依赖”导致消费能力下降，触发了背压。用线程转储看清楚卡点后，把外部超时时间缩短、加一层本地缓存，问题立刻解决。

4.3 高并发场景下的协作设计经验

说完面试题和排查，最后聊几个我在高并发场景下实实在在用过、并且觉得值得沉淀的设计经验。这些不是教科书上的标准答案，而是踩坑之后长记性的那种感悟。

能用队列中间层就别让线程直连。这是最高频的协作设计原则。我说一个场景：订单支付成功之后，要给用户发短信、发通知、积分解冻、更新报表，如果这些操作都在支付请求的线程里同步完成，一个接口等五个服务响应，响应时间直接爆炸。正解是：支付线程只负责更新订单状态，然后把“支付成功”这个事件放入消息队列或者本地阻塞队列，再由后面的消费线程异步处理短信、积分、报表。生产者线程快速返回，消费者按自己的节奏慢慢处理，这就是生产消费模式在架构层的应用。很多分布式系统里的MQ，本质上干的就是这个事，把不同服务解耦开。

优先选择有界队列，保护自己。前面讲BlockingQueue的时候已经提过有界队列的价值，这里从更高的视角再说一次。系统设计的时候，任何时候都要有“如果下游跟不上，会发生什么”这个意识。有界队列会迫使上游阻塞，形成背压，让全链路以最慢节点的能力为准，这是最稳妥的自我保护。无界队列表面上好像是“不会失败”，实际是把风险往后挪，最终可能导致内存耗尽、进程崩溃、数据丢失——这比让调用方稍等片刻可怕得多。

线程数量不是越多越好。高并发的核心是吞吐量最大化，而不是线程数最大化。一个线程执行计算任务时如果频繁阻塞（等数据库、等网络、等外部接口），说明它不占CPU，这时候多开几个并发线程能提高利用。但如果逻辑都在CPU上跑，开太多线程只会增加CPU切换开销，吞吐量反而下降。所以我做容量规划时候，第一件事永远是分析任务的类型：是CPU密集还是IO密集，再决定线程池大小。而且每增加一点并发，一定要配合压测数据说话，别靠感觉。

任务拆分要考虑结果汇总的等待方式。开多个线程做并行处理很容易，等它们汇合的环节反而容易设计错。我用CountDownLatch做并发汇总的时候踩过一个坑：主线程await()设置了一个很长的超时时间，以为很安全，结果某个子线程因为外部依赖迟迟不返回，导致主线程也超时了，整体响应被拖慢。后来学乖了，凡是用并行拆分的地方，都会给子任务设定独立的超时上限，并且汇总时再设置一个比所有子任务上限都小的总超时，保证“宁可放弃最慢的那个任务，也不能拖垮整体”。

回到“多线程03”这个标题本身，这一篇讲的其实是整个多线程里最“承上启下”的环节：会锁、会开线程只是基础，能用协作把这些零件组装成能干活的生产线，才是真正进阶。你可以把你正在做的任何一个功能拿来想想：哪些环节是生产，哪些环节是消费，中间要不要加个缓冲区？哪个线程在等什么、在通知谁？想清楚了，并发代码就不再是“靠运气跑通”的黑盒子。我个人写了几年并发代码，最大的体会就是：阻塞队列这个中间层解决了我90%的协作问题，而剩下那10%的疑难杂症，全要靠对wait/notify这种底层机制的理解才能定位。所以这篇特意把底层手写版本和高级API都放出来，就是希望各位既能用上趁手的工具，又不至于把原理丢掉。最后分享一个小小的习惯：所有线程代码里，我要求log里必须带上线程名，排查问题的时候这一条能帮你省下一大半时间。