做面试官这几年我几乎每次问到高并发相关的题目都会抛出一个问题“如果现在有一个核心的下游服务你怎么保证它不被突发的流量打挂”十个人里有八个会告诉我“加个线程池、限个流”但你再往下追问“线程池到底隔离了什么资源它的边界在哪Semaphore和线程池有什么区别”能答清楚的人就很少了。今天这篇就把Java资源隔离这件事彻底聊透。我会从面试官最关心的三个层次展开先搞清楚“隔离”到底隔离什么再从源码角度拆解ThreadPoolExecutor和Semaphore这两件兵器各自的边界和原理最后给你一套可以直接拿去用的组合方案和现场应答话术。正文里所有结论都基于JDK 8的源码实现我尽量用大白话讲清底层机制保证你面试时能从“背概念”变成“讲逻辑”。1. 先把问题问清楚资源隔离到底在隔离什么很多人一提资源隔离脑子里只有“线程池”三个字这是典型的把手段当成了定义。面试官问这个问题真正想听的其实是你有没有意识到一个Java进程里同时跑着几十个业务模块它们共享相同的CPU、内存、网络连接、线程、数据库连接池一旦某个模块出问题凭什么不拖垮其他人1.1 从容器隔离到进程内隔离隔离是有层次的先看字节跳动的架构师对比五年前和现在的分区隔离区别时的一个结论你无法在JVM层直接控制容器已经分配给你的CPU配额。这句话点出了一个关键认知——资源隔离是分层的。第一层是容器/操作系统级别比如K8s里给Pod配置CPU requests、内存limits或者用cgroup限制进程能使用的CPU时间片。这一层解决的是“不让一个Pod吃光宿主机”。第二层是JVM级别比如设置堆内存大小、GC线程数、ForkJoinPool公共池的并行度。第三层才是我们今天的主角程序内的逻辑隔离线程池、信号量、连接池、本地缓存分桶。这三层是互补关系不是替代关系。容器层帮你挡宿主机级别的故障但挡不住你进程内部两个业务模块互相争抢线程反过来你程序内隔离做得再好JVM堆内存被某个模块的缓存撑爆时信号量和线程池也拦不住OutOfMemoryError。1.2 面试官要的“资源隔离”通常指这三样东西结合我面过的候选人能让我给出高分的回答一般会明确把隔离对象分成三类。线程资源。这是最直接的。线程是有限资源Java默认一个线程栈大约1MB一个4C8G的实例最多也就能跑几百个活跃线程多了就开始频繁上下文切换吞吐量反而下降再多了直接OutOfMemoryError: unable to create new native thread。线程池隔离本质上是给每类业务划定一个线程使用上限谁也别想透支公共线程资源。连接/依赖资源。比如数据库连接池、Redis连接、第三方HTTP调用。这类资源的特点是数量有限且每个请求占用时间不可控。如果支付服务和订单服务共用同一个数据库连接池支付服务突然慢查询订单服务去拿连接就全部排队。这时候要隔离的不只是线程还有“能同时打到下游的请求数量”。执行资源/配额。这类更抽象有时是外部依赖方给你定的QPS配额有时是某个接口的RT预算。你没法用线程池去控制“每秒最多调用下游几次”因为线程池管的是并发数不是速率。这种情况就需要Semaphore这种工具来限定“同时在途的请求数”从而保护下游。搞清楚了隔离对象你才能选对工具。这也是面试中第一个加分点不要一上来就背ThreadPoolExecutor参数先把问题定性。2. ThreadPoolExecutor 做隔离每个核心参数都是一道资源边界线程池能从一堆工具里脱颖而出成为“资源隔离”的代名词和它的设计有很大关系。它天生就是一套自带配额机制的线程管理器。很多人背过七大参数但从资源隔离视角重新审视它们的其实不多。2.1 从 execute() 源码看线程池的“资源阀值”逻辑先看一段最核心的JDK源码这是java.util.concurrent.ThreadPoolExecutor#execute的执行主线public void execute(Runnable command) { int c ctl.get(); // 第一道阀当前工作线程数 核心线程数直接新增核心线程 if (workerCountOf(c) corePoolSize) { if (addWorker(command, true)) return; c ctl.get(); } // 第二道阀线程数已到核心数任务尝试进队列 if (isRunning(c) workQueue.offer(command)) { int recheck ctl.get(); // 入队后再检查一次如果线程池被关闭移除任务并拒绝 if (!isRunning(recheck) remove(command)) reject(command); // 如果工作线程数为0核心线程数被设置为0的极端情况补一个线程 else if (workerCountOf(recheck) 0) addWorker(null, false); } // 第三道阀队列满了尝试新增非核心线程到 maximumPoolSize else if (!addWorker(command, false)) // 第四道阀连非核心线程也满了触发拒绝策略 reject(command); }这段代码就是线程池做资源隔离的底层逻辑它本质上是四道依次收紧的闸门核心线程数 → 工作队列 → 最大线程数 → 拒绝策略。从隔离视角看这四道闸门对应四种资源边界参数资源边界含义corePoolSize常驻线程资源配额相当于你为这个业务长期预留的工人数workQueue缓冲资源上限决定任务积压到什么程度才会触碰线程扩容maximumPoolSize峰值线程资源上限防御性扩容的极限rejectPolicy资源耗尽时的降级出口防止请求无限堆积拖垮整个服务这里有个特别多人误解的地方很多人以为“队列满了我把线程扩到最大就行”但忽略了一点——线程是无状态资源的消费者每个线程都要占用内存和CPU时间片。你把最大线程数调大到200核心线程数20一旦流量洪峰到来线程数真的冲到200时上下文切换的开销会直接拖垮老年代GC甚至比限流丢掉请求代价更大。所以maximumPoolSize不是越高越好它本身就是“你愿意为这个业务透支多少线程资源”的上限。2.2 多线程池隔离按业务拆池而不是共享一个池理论说完了看实际方案。生产上最常见的线程池隔离做法是“按业务拆分线程池”。我举个例子一个电商交易系统通常订单、支付、库存、物流四个核心域都会各自独立建池互不共享。// 订单域专属线程池 ThreadPoolExecutor orderPool new ThreadPoolExecutor( 20, 40, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue(1000), new ThreadFactoryBuilder().setNameFormat(order-pool-%d).build(), new ThreadPoolExecutor.CallerRunsPolicy()); // 支付域专属线程池 ThreadPoolExecutor payPool new ThreadPoolExecutor( 10, 20, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue(500), new ThreadFactoryBuilder().setNameFormat(pay-pool-%d).build(), new ThreadPoolExecutor.AbortPolicy());这样做的好处立竿见影支付域如果出现第三方接口超时线程全部阻塞在等待响应上最多也就是耗尽payPool的1020500个资源订单域的orderPool完全不受影响。订单照样能下单物流照样能查轨迹。但拆池之后必然会遇到一个新问题线程池数量怎么定我见过最离谱的团队给每个接口都建一个池结果线上起了60个线程池每个核心线程5个资源白白浪费在空转上。按业务域拆池而不是按接口拆池。订单域内部有创建订单、查询订单、取消订单这些接口它们的资源特征相似可以共享一个池。而支付这种外部依赖RT波动大的单独拆出来。核心原则是资源使用特征相似的业务共享一个池特征差异大的必须隔离。2.3 线程池隔离的边界并发能控速率控不了线程池最大的局限要从“并发”和“速率”这两个概念的区别说起。线程池控制的是并发数——同一时刻最多有多少个任务在被执行。但“每秒允许多少个请求通过”是速率线程池是管不了的。举个例子你给某个线程池配了核心线程数10队列1000。每个任务执行只要10毫秒那么理论上这个池每秒能处理约1000个请求。但如果你用Semaphore把并发限死在10那每秒最多只能过10个请求假设RT不变。这不是说线程池和Semaphore谁更好而是说它们的控制维度不同。线程池擅长的是保护和隔离线程资源Semaphore擅长的是限制同时进入临界区的流量。面试官问“你用什么做资源隔离”你如果能主动说出这两者的维度差异就已经超过大多数候选人了。3. Semaphore 源码级拆解一个基于AQS的流量阀门如果说线程池是“给每类业务划一块专属工位区”那Semaphore就是“在关键入口上装一个只能同时通过N个人的旋转闸机”。它的核心实现比线程池简单得多但正因为简单反而更容易被滥用。3.1 AQS里的state信号量的命根子先看Semaphore的内部构造。JDK里Semaphore通过内部类Sync继承AbstractQueuedSynchronizerAQS来实现它所有的计数逻辑都落在一个字段上// java.util.concurrent.locks.AbstractQueuedSynchronizer private volatile int state;这个state就是信号量剩余的许可证数量。每acquire一次state减一每release一次state加一。当state变为0时后续的acquire就会阻塞直到有线程release归还许可证。看最关键的两个方法。非公平模式下acquire走的是nonfairTryAcquireSharedfinal int nonfairTryAcquireShared(int acquires) { for (;;) { int available getState(); int remaining available - acquires; if (remaining 0 || compareAndSetState(available, remaining)) return remaining; } }这段代码是典型的CAS自旋先读取当前剩余许可证算出扣减后的剩余值。如果剩余为负数说明许可证不够直接返回负数表示获取失败否则用CAS尝试更新state失败就重试。release走的是tryReleaseSharedprotected final boolean tryReleaseShared(int releases) { for (;;) { int current getState(); int next current releases; if (compareAndSetState(current, next)) return true; } }释放逻辑更简单就是CAS把许可证还回去。这里值得注意release方法根本不管你之前acquire过没有它只负责把state加上去。如果你在代码里多调了一次release信号量里的许可证就变多了闸机门禁就形同虚设。3.2 公平模式 vs 非公平模式面试的隐藏考点Semaphore有两个构造器一个默认非公平一个可以传fair参数。这个参数在面试里经常被忽略但恰恰是源码阅读邀功底的好问题。public Semaphore(int permits) { sync new NonfairSync(permits); } public Semaphore(int permits, boolean fair) { sync fair ? new FairSync(permits) : new NonfairSync(permits); }公平模式下acquire会先检查AQS的等待队列里有没有排队的线程protected int tryAcquireShared(int acquires) { for (;;) { // 关键先看是否有线程排在自己前面 if (hasQueuedPredecessors()) return -1; int available getState(); int remaining available - acquires; if (remaining 0 || compareAndSetState(available, remaining)) return remaining; } }hasQueuedPredecessors()这个判断就是公平和非公平的全部区别。公平模式下只要等待队列里有人新来的线程就得乖乖排队不能插队。非公平模式下新线程会尝试直接CAS抢许可证抢不到才去排队。实际项目中我基本都选非公平模式。理由很简单非公平模式吞吐量更高而且Semaphore在资源隔离场景下本来就是用来“快速挡掉超额流量”的那种情况下你根本不在乎谁先谁后只在乎“人数有没有超限”。如果你用公平模式保护一个RT特别敏感的下游反而可能因为排队等待而增加平均响应时间。3.3 除了acquire/release还有几个容易忽略的实用方法源码级别理解Semaphore面试官很可能会问“你平时除了acquire和release还用过什么方法”。以下几个很有实战价值tryAcquire()非阻塞获取拿不到许可立刻返回false。适合用在不希望请求线程长时间阻塞的场景比如直接降级返回兜底数据。tryAcquire(timeout, TimeUnit)带超时的获取在timeout时间内等不到许可就放弃。这是我最推荐的方式既给了系统缓冲时间又不会让线程无限期挂起。acquire(int permits)一次获取多个许可。在“一个请求需要同时占用多个下游连接”的场景下有用。drainPermits()一次性清空剩余许可。常在服务优雅下线时用先把所有入口全关掉再等存量请求处理完。reducePermits(int reduction)强制减少许可数。比如你发现某个下游服务开始不稳定可以在运行期动态收紧信号量相当于手动拧小阀门。这些方法组合起来可以实现比线程池精细得多的流量控制。我在后面的组合方案里会具体演示。4. 组合玩法线程池和信号量最常用的三种搭配现在你已经搞清楚了线程池管“并发线程配额”Semaphore管“流量闸门”。接下来是本文的实战核心这两种工具到底怎么配合才能算一套完整的资源隔离方案。4.1 模式一信号量保护外部依赖线程池隔离线程资源这是最经典的搭配也是我在多数项目中采用的方案。场景是这样的你的核心业务依赖一个第三方接口这个接口的TP99很不稳定偶尔飙到3秒。如果直接在线程池里调用它最坏情况是线程池所有线程都被这个慢接口拖住其他依赖同一个池的快速任务全部饿死。做法是把线程池的隔离和信号量的闸门叠加使用。Semaphore downstreamLimiter new Semaphore(10); // 业务线程池照常执行任务 executor.submit(() - { boolean acquired false; try { // 拿不到许可就直接返回兜底结果不阻塞 acquired downstreamLimiter.tryAcquire(500, TimeUnit.MILLISECONDS); if (!acquired) { // 降级处理返回缓存或默认值 return fallbackResult(); } // 拿到许可才调用慢接口 return callDownstreamService(); } finally { if (acquired) { downstreamLimiter.release(); } } });这样设计的原因要讲透线程池的队列缓冲了任务数量的爆发但缓冲不了“任务执行时长”的爆发。当10个线程都卡在慢接口上池里再多空闲线程也救不了因为线程已经占满。信号量在这里扮演的是“最后一层刹车”最多10个请求能同时在途调用下游多出来的直接走降级绝不进入下游。4.2 模式二信号量限总并发线程池只做异步化另一种场景下信号量不是用来保护某个外部依赖而是用来限制“某个租户/某个渠道的总并发”。比如一个数据导入系统管理端发起导入任务用户端同时也在查询数据。你希望操作系统级的总资源消耗被控制在某个阈值内但又不愿意用固定线程池把并发焊死因为有些任务轻量、有些任务重量级一个重量级任务占用的实际资源可能顶得上十个轻量级任务。这时候可以把Semaphore设成一个全局大闸门线程池只负责把任务异步化执行Semaphore globalLimiter new Semaphore(50); ExecutorService ioExecutor Executors.newCachedThreadPool(); public void submitTask(Runnable task) { ioExecutor.submit(() - { try { globalLimiter.acquire(); task.run(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { globalLimiter.release(); } }); }这套组合的核心思路是线程池只负责提供执行载体它的大小可以按CPU核数配置不做业务隔离真正的流量配额由Semaphore动态控制。当你想把系统总并发从50提到80时只需要globalLimiter.release(30)不需要动线程池配置。注意这个方法我没有用tryAcquire因为导入任务属于非实时场景排队是合理的acquire阻塞正好达到削峰填谷的效果。4.3 模式三多信号量按资源分桶隔离维度比线程池更细线程池隔离的一个尴尬是线程是“同质资源”一个池子只能隔离一类线程。但业务请求往往要占用多种资源数据库连接、外部接口配额、本地文件句柄。Semaphore可以针对每种资源各设一个信号量实现多维度的分桶隔离。举个例子一个报表导出功能同时需要查询MySQL、调用报表引擎服务、写本地文件。三个资源任何一个出问题都应该只影响导出发送率不该影响主流程。做法是每个资源都配一个独立信号量class ReportExportGuard { private final Semaphore dbLimiter new Semaphore(20); private final Semaphore reportEngineLimiter new Semaphore(5); private final Semaphore fileLimiter new Semaphore(10); public boolean tryAcquireAll(long timeout, TimeUnit unit) throws InterruptedException { // 必须全部拿到才放行 if (!dbLimiter.tryAcquire(timeout, unit)) return false; if (!reportEngineLimiter.tryAcquire(timeout, unit)) { dbLimiter.release(); return false; } if (!fileLimiter.tryAcquire(timeout, unit)) { reportEngineLimiter.release(); dbLimiter.release(); return false; } return true; } public void releaseAll() { fileLimiter.release(); reportEngineLimiter.release(); dbLimiter.release(); } }这里有个非常重要的细节部分资源获取失败时必须把已经拿到的许可全部还回去。多资源申请失败导致许可泄漏是这种模式最隐蔽的坑后面踩坑部分我会展开讲。4.4 三种模式怎么选一张对比表帮你决策维度模式一模式二模式三关键词保护慢依赖控制总并发多维资源分桶阻塞策略tryAcquire超时降级acquire排队等待组合申请任一失败回滚线程池角色业务隔离池异步执行载体专用任务池典型场景第三方接口不稳定数据系统总闸门多资源聚合任务风险点释放遗漏线程池任务堆积多许可回滚逻辑面试里如果被问到组合方案你可以把这个表作为你回答的骨架先分场景再说选型理由比单纯背“线程池Pool1、Pool2”看起来有经验至少一个档次。5. 面试官追击环节这几个问题答不上来容易露馅写到这里你大概已经理解了ThreadPoolExecutor和Semaphore的核心原理。但面试官肯定会追着问细节以下几个问题我不止一次在面试里听到也经常看到候选人卡壳。5.1 “Semaphore的acquire和线程池的阻塞队列有什么区别”这是个很尖锐的问题。表面上看都是阻塞底层差别非常大。线程池阻塞队列的阻塞点是任务在队列里等待直到某个工作线程空闲后取走执行。队列阻塞的对象是“任务”不是“线程”。线程池线程数是固定的任务再多也只是排队工作线程本身没变化。Semaphore的阻塞点是调用acquire的线程在AQS的等待队列里挂起直到其他线程release归还许可。阻塞的对象是“线程本身”线程停了下来不做任何事。这个区别的实战含义是用线程池的队列来“限流”实际上是允许任务永无止境地排队队列无限堆积一旦堆积到内存溢出整个服务就挂了。而Semaphore的acquire阻塞是强制让调用线程停下来从源头限制了进入系统的工作量。所以线程池适合“异步化缓冲”Semaphore适合“硬性流量闸门”。补充一个小细节线程池队列里堆积的任务也会占用内存。默认的LinkedBlockingQueue如果不设容量上限任务无限堆积直接OOM。这一点面试提到绝对加分。5.2 “tryAcquire和acquire怎么选你什么时候用哪个”我的回答逻辑分三层。第一层对延迟敏感的业务用tryAcquire超时。比如用户发起支付你不可能让他一直等到信号量有许可500毫秒拿不到就直接提示“系统繁忙”这是保全用户体验。第二层对吞吐量敏感但对延迟不敏感的任务用acquire。比如异步报表生成、批处理任务排队等待是合理的让它们多等几秒无妨。第三层永远不要在循环里用tryAcquire做忙等轮询。那样会白白烧掉CPU比直接阻塞更浪费资源。5.3 “接入了Sentinel或Hystrix为什么还要自己写Semaphore”现在微服务架构里很流行Sentinel和Hystrix。面试官这么问不是想否定工具而是想考察你对内部原理的理解。Hystrix的线程池隔离和信号量隔离底层实现和JDK原生的这两个工具是高度相似的。Hystrix信号量隔离模式就是用了类似Semaphore的计数控制线程池隔离模式就是基于ThreadPoolExecutor封装。Sentinel的信号量限流也类似。但接入框架不意味着你可以不写代码。框架的隔离粒度一般是“按资源名/接口”解决的是“接口A拖垮接口B”的通用问题。但你项目里可能还需要“按用户租户”“按业务渠道”“按下游依赖方”这种更细粒度的隔离框架给不了必须结合Semaphore自己实现。所以正确的说法是框架做通用防护Semaphore做定制化精准控制。5.4 “线程池参数怎么定信号量数量怎么定”这没有标准答案但面试官想听的是你有没有估算逻辑。我一般这样回答核心线程数参考业务的平均并发量和响应时间用公式估算——核心线程数等于每秒请求峰值乘以平均响应时间秒再除以T目标利用率。比如峰值QPS800平均RT0.05秒核心线程数大概在40到50之间。生产环境先用这个估算值上线再通过压测调整。信号量的数量则要参考下游的承载能力。比如数据库连接池上限是100那你打到数据库的信号量就不能超过100一般设置80到90留出10%到20%缓冲。如果下游是第三方就按合同约定的QPS配额反推配额QPS200下游平均RT0.2秒那么信号量数量约等于200乘以0.2等于40保证每秒最多40个请求同时在途就能控制住全局QPS不会突破200。6. 我踩过的坑资源隔离在生产环境的事故复盘好东西用不好照样出事。最后分享几个真实事故都是我和同行在资源隔离这件事上踩过的坑每一个都值得引以为戒。6.1 信号量忘记释放支付回调通道全线瘫痪有一次线上服务突然批量报错排查发现短信发送信号量被耗尽所有短信发送请求全部降级失败。从监控看到短信渠道的信号量许可数从60一路降到0再也没恢复过。定位过程花了不少时间最后把目光锁定在一个异常分支里代码在finally里release了但那个分支是try缓存里抛了一个非受检异常异常在finally的release之前就直接上抛了不对finally应该会执行。真正的问题是另一段代码一个异步任务获取了信号量然后调用了外部接口外部接口抛出一个Error级别的异常代码只catch了ExceptionError直接跳过finally不finally还是会执行的。再挖下去才发现那个项目里有一处用Semaphore做超时控制的代码acquire成功后放在了一个线程本地变量里但只有成功路径调用了release超时分支里忘了还。排查链路的启示是信号量的release必须在finally里执行而且必须确认每一次acquire包括tryAcquire成功都有对应的release。更稳的做法是封装一个工具类用try-with-resources风格管理信号量从根上消灭遗漏public class SemaphoreGuard implements AutoCloseable { private final Semaphore semaphore; private boolean acquired; private SemaphoreGuard(Semaphore semaphore, boolean acquired) { this.semaphore semaphore; this.acquired acquired; } public static SemaphoreGuard tryAcquire(Semaphore semaphore, long timeout, TimeUnit unit) throws InterruptedException { return new SemaphoreGuard(semaphore, semaphore.tryAcquire(timeout, unit)); } public boolean isAcquired() { return acquired; } Override public void close() { if (acquired) { semaphore.release(); } } }6.2 核心线程数拍脑袋定压测模型里外不符另一个大坑是线程池参数的“拍脑袋”。我们曾经给一个订单查询服务配了核心线程数64理由是“双核CPU嘛64核线程吞吐高”。结果压测发现跑到40并发时RT就开始飙升GC也频繁报警。后来一查线程数一多上下文切换开销急剧增加老年代频繁GC把RT拖得更高形成了恶性循环。后来改成按任务执行时长算该服务单次任务平均10毫秒目标单机吞吐量800TPS按公式算核心线程数约等于800乘以0.01等于8配合一个稍大一点的队列压测结果立刻正常。核心线程数从来不是越大越好它是你愿意为这个业务持续预留的资源理论上应该由“任务到达速率”和“任务处理时长”的乘积决定。这个经验看起来简单但没有踩过坑的人很难在面试里讲出这种细节。6.3 队列容量设置无上限系统内存被隐形的任务堆涨爆这个坑出现得最隐蔽。很多人在创建ThreadPoolExecutor时用new LinkedBlockingQueue()这个队列默认容量是Integer.MAX_VALUE等价于无限队列。配合上“核心线程数已满就进队列”的机制结果是队列永远不会满maximumPoolSize形同虚设任务可以无限堆积堆内存被这些待执行任务占满最终OOM。正确做法是给队列设置一个有界容量同时配置好拒绝策略。有界队列才是资源隔离的有效边界。如果业务确实允许任务适度积压容量建议控制在“核心线程数乘以单任务内存占用的可承受范围”内。你在设计线程池时每个参数都必须回答一个问题如果这里被填满系统会怎样回答不出来就是设计隐患。6.4 优雅下线时信号量没有排水存量流量和增量流量打架最后一个坑聊聊优雅下线。服务上线发布时K8s会给Pod一个SIGTERM信号应用开始处理存量请求并拒绝新流量。我们在一个用Semaphore保护数据库连接的服务里发现下线过程中明明已经对外宣称“不接收新请求”但信号量的许可还是被新进来的异步任务占用导致存量请求反而抢不到许可超时失败。原因很简单信号量的acquire并不感知应用的生命周期状态。下线流程开始后异步任务依然可以调用Semaphore的acquire去抢许可。修复方法是在信号量外层加一个全局开关下线时先调用drainPermits()把所有许可清空再从开关层拒绝新的acquire调用public class DrainingSemaphore { private final Semaphore semaphore new Semaphore(60); private volatile boolean draining false; public boolean tryAcquire(long timeout, TimeUnit unit) throws InterruptedException { if (draining) { return false; } boolean acquired semaphore.tryAcquire(timeout, unit); if (acquired draining) { // 竞态窗口内如果已经开始排水立即归还 semaphore.release(); return false; } return acquired; } public void startDrain() { draining true; semaphore.drainPermits(); } }写到这里我想你已经明白了资源隔离这件事表面上是熟悉几个API的问题本质上是对“程序内资源边界”有没有清晰认知的问题。我个人在实际项目中的习惯是先画出整个系统的依赖拓扑标出每个下游的容量上限和失败特征再决定哪些地方用线程池划分业务隔离域哪些地方用信号量做流量闸门。面试时你不用回答得面面俱到但只要你把“隔离对象—工具原理—组合方案—落地踩坑”这条线穿起来面试官基本不会再往下追问了。最后分享一个我很喜欢的判断标准资源隔离不是把系统拆得越碎越好而是让任意一个模块的失败在占满自己配额的同时绝不会伸手去借用别人的配额。做到这一点你手里的ThreadPoolExecutor和Semaphore才算真正玩明白了。