手动限额的弹性线程池通过显式限流、有界队列（ArrayBlockingQueue，容量200～500）和主动拒绝策略（自定义RejectedExecutionHandler返回503）协同控流，固定核心线程数（4～8），嵌入RPC调用链路并配合连接池限制、短超时（800ms）与禁用重试，实现突发流量的匀速转化。
在自研 rpc 框架客户端中，用“手动限额的弹性线程池”平抑网络高频波峰，核心不是靠线程数量自动伸缩，而是通过显式限流 + 队列节制 + 主动拒绝三者协同，把突发流量转化为可控、可预期的处理节奏，避免线程暴涨、内存溢出、连接雪崩等物理层冲击。
明确线程池边界：固定核心数 + 严格有界队列
不使用无界队列（如 LinkedBlockingQueue）或默认的 Integer.MAX_VALUE 容量。选用 ArrayBlockingQueue，并手动设定容量上限（例如 200～500，依据单机 CPU 核数和平均 RT 调整）。核心线程数设为固定值（如 4～8），拒绝使用 allowCoreThreadTimeOut 或动态扩容逻辑。这样能确保：
- 线程总数始终 ≤ 核心数，杜绝线程创建风暴
- 待处理请求被强制排队，而非无限堆积在内存中
- 队列满时立即触发拒绝策略，不阻塞调用方线程
拒绝策略必须主动且业务友好
拒绝策略不用默认的 AbortPolicy。改用自定义 RejectedExecutionHandler，做到两点：
- 记录被拒请求的接口名、参数摘要、时间戳，供监控告警（如触发 Prometheus counter+alert）
- 对调用方返回预定义的快速失败响应（如 RpcException.withCode(503).message("client overload")），不抛 unchecked exception 导致上层线程中断
这相当于在客户端就完成第一道“熔断”，把压力挡在系统门外，而不是让它穿透到网络层或服务端。
与 RPC 调用生命周期强绑定
线程池不独立存在，而是嵌入在每次调用的执行链路中：
- 每个 RPC 方法调用（如 reduceStock）都走同一个共享线程池，不按服务维度隔离（避免资源碎片）
- 在 Proxy 的 invoke() 中，不直接 submit(Runnable)，而是 submit(Callable
- 配合超时控制：submit 后立即 get(timeout, unit)，超时则主动 cancel，释放队列占位
这样，线程池真正成为调用节奏的“节拍器”，而非后台任务容器。
配合连接与请求级限流形成纵深防御
线程池只是客户端限流的一环，需与以下机制联动：
- 连接池限制：Netty ChannelPool 最大连接数设为固定值（如 16），防止高频调用打爆远端端口或本地文件句柄
- 单请求超时压缩：将默认 3s 超时压至 800ms，让失败更快返回，加速线程/队列资源回收
- 退避重试关闭：禁用自动重试（尤其幂等性未保障时），避免波峰叠加成脉冲
这几层合起来，能把一次突发的 5000 QPS 冲击，压制为稳定输出 800～1200 QPS 的匀速流，CPU 和 GC 压力曲线变得平滑可预测。
