并发线程数限流：防止资源耗尽
引言：QPS限流不能解决所有问题 上一篇我们学习了QPS限流，它是最常用的限流方式。但有些场景下，QPS限流并不够用： 场景：调用第三方支付API // 配置：QPS限流 = 100 @GetMapping("/api/payment/query") public Result queryPayment(@RequestParam String orderId) { Entry entry = SphU.entry("payment_query"); // 调用第三方API（RT=2000ms，非常慢！） PaymentResult result = thirdPartyApi.query(orderId); entry.exit(); return Result.success(result); } 问题分析： QPS = 100 RT = 2000ms（2秒） 需要的线程数 = QPS × RT = 100 × 2 = 200个线程 但Tomcat默认线程池只有200个！ 结果： → 200个线程全部被占用 → 其他接口无法响应 → 系统"假死" 核心问题：QPS限流只管数量，不管时间。对于慢接口，即使QPS不高，也可能耗尽线程资源。 今天我们将学习线程数限流，专门应对这类场景。 一、线程数限流的原理 1.1 什么是线程数限流 线程数限流：限制同时处理某个资源的线程数量。 资源：payment_query 线程数限流：最多10个线程 第1-10个请求：线程1-10处理中 第11个请求：被限流（因为已经有10个线程在处理） 第1个请求处理完毕：线程1释放 第11个请求：可以被线程1处理 图示： 请求1 → 线程1 [处理中...2秒] 请求2 → 线程2 [处理中...2秒] ... 请求10 → 线程10 [处理中...2秒] 请求11 → ❌ 被限流（线程池满） 1.2 线程数限流 vs QPS限流 维度 QPS限流 线程数限流 关注点 请求数量 并发数量 计算方式 时间窗口内的请求总数 当前正在处理的请求数 适用场景 快速接口（RT<100ms） 慢速接口（RT>1s） 保护目标 防止流量过大 防止线程耗尽 限流时机 请求到达时 请求到达时 核心区别： ...