根本原因是每次RPC调用新建未管控线程池导致线程数爆炸与栈内存耗尽；应复用单例线程池、禁用newCachedThreadPool、设置合理参数及拒绝策略、应用关闭时正确shutdown，并清理ThreadLocal与闭包强引用。
这不是线程栈内存（-Xss）泄漏，而是线程池滥用引发的线程数爆炸与栈空间耗尽问题。根本原因在于：每次 RPC 调用都新建一个线程池（尤其含未配置核心/最大线程数、无拒绝策略、未显式关闭的 ThreadPoolExecutor），导致大量长期存活线程持续占用栈内存（默认每线程 1MB），最终触发 java.lang.OutOfMemoryError: unable to create new native thread 或系统级资源枯竭。
确认是否真由“每次调用新建线程池”引起
先验证问题模式，避免误判：
- 用
jstack <pid>查看线程数是否随 RPC 调用次数线性增长，线程名是否含自定义前缀（如rpc-worker-*、pool-*） - 用
jstat -gc <pid>观察线程数（TT列）持续上升，而堆内存使用平稳 - 检查 RPC 客户端代码——是否在
invoke()、send()或回调方法内直接 new 了ThreadPoolExecutor或Executors.newCachedThreadPool()
立即停止新建线程池，复用全局实例
RPC 客户端本身不需线程池；若需异步处理响应（如回调、Future）、反压或解耦 I/O 与业务逻辑，应使用**单例、应用生命周期管理的线程池**：
- 将线程池声明为
static final，在 Spring 中定义为@Bean，确保整个应用只有一份 - 避免
Executors.newCachedThreadPool()：它允许无限创建线程且空闲60秒才回收，极易失控；改用带界线的构造：new ThreadPoolExecutor(2, 8, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue<>(1000)) - 务必设置
setThreadFactory()自定义命名，便于排查；设置setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy())防止任务丢失
清理遗留线程池引用，防止 GC Roots 持有
已创建的线程池若未关闭，其内部 Worker 线程会成为 GC Root，导致整个对象图（包括外部类引用、ThreadLocal 值）无法回收：
- 所有手动创建的线程池，必须在应用关闭时调用
shutdown()+awaitTermination()；Spring 环境下用@PreDestroy或实现DisposableBean - 检查是否在 RPC 回调闭包中隐式捕获了外层对象（如
this、Service 实例），造成强引用链；改用静态内部类 + 显式传参 - 若曾用
ThreadLocal存储上下文（如 traceId、用户凭证），每次任务执行完必须remove()，否则在线程复用场景下持续累积
调整线程栈大小仅作辅助，不可替代治理
-Xss 是单线程栈容量，调小（如 -Xss256k）可延缓崩溃，但掩盖了设计缺陷：
- 栈太小可能导致深度递归或大量局部变量时
StackOverflowError - 真正要解决的是“为什么需要成百上千个线程”，而非“让每个线程少吃点”
- 生产环境建议保持默认（Linux 64位通常为 1MB），优先通过线程池复用把线程数压到 10–50 以内
