DynamicTp线程池拒绝策略下的内存泄漏问题分析与修复

问题背景

在使用DynamicTp 1.1.6.1版本时，发现当线程池采用AbortPolicy拒绝策略并频繁触发拒绝时，会导致严重的内存泄漏问题。具体表现为ThreadPoolStatProvider中的stopWatchMap不断增长，最终可能达到数GB级别而无法被GC回收，最终导致应用崩溃。

技术原理分析

DynamicTp框架为了增强线程池监控能力，在任务执行前后添加了性能监控逻辑。核心机制如下：

1. 任务执行监控：通过PerformanceMonitorAware在任务执行前记录开始时间
2. 拒绝策略增强：通过RejectedInvocationHandler对原生拒绝策略进行代理增强
3. 时间记录存储：使用ConcurrentHashMap保存任务与开始时间的映射关系

内存泄漏根源

问题出在拒绝策略的处理链路上：

1. 当任务被提交时，PerformanceMonitorAware会先将任务放入stopWatchMap
2. 如果线程池已满，会触发拒绝策略
3. 对于AbortPolicy这类会抛出异常的拒绝策略，由于异常抛出导致afterReject清理逻辑未能执行
4. 结果就是stopWatchMap中的条目只增不减，最终耗尽内存

关键代码缺陷在于RejectedInvocationHandler中没有在finally块中执行清理逻辑，导致异常抛出时资源无法释放。

解决方案

修复方案的核心思路是确保无论拒绝策略是否抛出异常，都能正确清理stopWatchMap中的条目。具体实现方式是将afterReject调用放入finally块中：

@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
    try {
        beforeReject((Runnable) args[0], (Executor) args[1]);
        Object result = method.invoke(target, args);
        return result;
    } catch (InvocationTargetException ex) {
        throw ex.getCause();
    } finally {
        afterReject((Runnable) args[0], (Executor) args[1]);
    }
}

临时规避方案

在修复版本发布前，可以通过以下方式临时规避问题：

1. 设置系统属性-Ddtp.execute.enhanced=false禁用执行增强
2. 使用不会抛出异常的拒绝策略，如CallerRunsPolicy

最佳实践建议

1. 对于高并发场景，建议及时升级到修复版本
2. 合理配置线程池参数，避免频繁触发拒绝策略
3. 监控stopWatchMap的大小，设置告警阈值
4. 根据业务特点选择合适的拒绝策略

总结

这次内存泄漏问题揭示了框架在异常处理路径上的资源管理缺陷。通过分析我们可以看到，在增强原生组件功能时，必须特别注意异常情况下的资源清理工作。这也提醒我们在开发类似功能时，应当遵循"资源获取即初始化"(RAII)原则，确保在任何执行路径下都能正确释放资源。