自研RPC框架：弹性线程池设计与应用

在自研RPC框架客户端中，面对秒杀、大促等场景下的网络高频波峰，单纯依赖自动伸缩的线程池反而会加剧系统崩溃风险；真正有效的方案是摒弃“动态扩容”幻觉，转而采用“手动限额的弹性线程池”——通过固定核心线程数（4～8）、严格有界队列（ArrayBlockingQueue，容量200～500）、主动拒绝策略（返回503而非抛异常）、深度嵌入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