【线上故障复盘】RPC 线程池被打满，1024个线程居然不够用？

主要观点总结

文章介绍了线上环境出现大量RPC请求报错，异常原因被线程池拒绝的情况。通过排查，最终发现问题的根源是Guava限流器的阈值过低，导致线程池被堵塞并最终引发问题。

关键观点总结

关键观点1: 故障背景

线上环境出现大量RPC请求报错，异常服务非核心服务，异常量很大但没有实际影响。有人在线上刷数据，产生大量binlog，导致线程池被打满。

关键观点2: 排查过程

对请求量的波动、RPC线程池配置和监控、接口耗时波动情况等进行排查，并分析了代码和异常Trace，最终发现问题根源是Guava限流器的阈值过低。

关键观点3: 问题结论

Guava限流器的阈值过低，导致线程池被堵塞，RPC线程池不断增加新线程处理请求，直到达到最大线程数。之后无法再接收新的请求，导致大量请求被线程池拒绝。

文章预览

1. 故障背景 昨天晚上，我刚到家里打开公司群，就看见群里有人讨论：线上环境出现大量RPC请求报错，异常原因： 被线程池拒绝。 虽然异常量很大，但是异常服务非核心服务，属于系统旁路，服务于数据核对任务，即使有大量异常，也没有实际的影响。 原来有人在线上刷数据，产生了大量 binlog，数据核对任务的请求量大幅上涨，导致线程池被打满。因为并非我负责的工作内容，也不熟悉这部分业务，所以没有特别留意。 第二天我仔细思考了一下，觉得疑点很多，推导过程过于简单，证据链不足，最终结论不扎实，问题根源也许另有原因。 1.1 疑点 请求量大幅上涨， 上涨前后请求量是多少？ 线程池被打满， 线程池初始值和最大值是多少，线程池队列长度是多少？ 线程池拒绝策略是什么？ 影响了哪些接口，这些接口的耗时波动情况？ 服务的 CPU ………………………………