Spring线程池泄漏问题分析与Ruoyi框架解决方案

1. 问题现象与背景分析

最近在基于Ruoyi前后端分离框架开发企业级应用时，遇到了一个棘手的运行时问题：当项目中引入异步线程池后，每次热部署或服务重启都会出现线程资源未正确释放的情况。具体表现为：

• 服务重启后，部分异步任务仍在旧线程池中执行
• 反复重启会导致线程数持续增长
• 最终出现"Unable to create new native thread"的OOM错误

这个问题在开发阶段可能不明显，但在生产环境的滚动发布场景下会造成严重隐患。经过排查发现，这与Spring容器生命周期管理和线程池资源释放的机制密切相关。

2. 线程池配置的典型实现

Ruoyi框架中常见的线程池配置方式如下：

java复制@Configuration
public class ThreadPoolConfig {
    
    @Bean("asyncTaskExecutor")
    public Executor asyncTaskExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(10);
        executor.setMaxPoolSize(50);
        executor.setQueueCapacity(200);
        executor.setThreadNamePrefix("async-task-");
        executor.initialize();
        return executor;
    }
}

这种配置在单次运行中表现良好，但存在两个关键缺陷：

1. 未实现DisposableBean接口，容器销毁时不会自动关闭线程池
2. 线程池未设置等待任务完成的超时时间

3. 问题根因深度解析

3.1 Spring容器的优雅关闭机制

当应用收到停止信号时，Spring会依次执行：

1. 发布ContextClosedEvent事件
2. 销毁所有单例Bean
3. 关闭底层BeanFactory

但默认线程池Bean没有注册销毁回调，导致线程池中的工作线程无法感知应用关闭事件。

3.2 线程泄漏的具体过程

1. 旧容器关闭时，正在执行的异步任务线程未中断
2. 新容器启动后创建新的线程池实例
3. 旧线程池中的线程仍持有任务队列引用
4. 反复重启导致线程数呈阶梯式增长

4. 完整解决方案实现

4.1 改进的线程池配置类

java复制@Configuration
public class SafeThreadPoolConfig implements