定时任务线程池内存泄漏本质是线程级资源泄漏，表现为线程数持续增长和“unable to create new native thread”错误；根源在于未取消周期任务导致DelayedWorkQueue积压、线程阻塞在take()且无法退出，须显式cancel Future并配合shutdown()、awaitTermination()与shutdownNow()有序关闭。
定时任务线程池（如 ScheduledExecutorService）引发的内存泄漏，往往不表现为堆内存暴涨，而是线程数持续增长、OutOfMemoryError: unable to create new native thread 频发——这是典型的“线程级资源泄漏”，根源在于线程未释放，而非对象未回收。
看线程状态是否卡死在等待队列
用 jstack <pid> 抓取线程快照，重点搜索：
- 线程名含
pool-X-thread-Y或scheduled-* - 状态为
WAITING (parking)，堆栈停留在DelayQueue.take或ScheduledThreadPoolExecutor$DelayedWorkQueue.take
这类线程看似“空闲”，实则被阻塞在无界延迟队列上，只要队列里还有未到期任务，线程就永不退出。哪怕你调用了 shutdown()，只要队列非空或有周期性任务未取消，线程池就不会真正终止。
查任务是否残留未取消
定时任务泄漏最常见原因：提交了 scheduleAtFixedRate 或 scheduleWithFixedDelay 后，忘记调用 Future.cancel(true)。
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 即使服务关闭逻辑中调用了
shutdown()，未显式 cancel 的周期任务仍会持续向队列插入新任务 - 每个
ScheduledFutureTask都强引用着你的 Runnable/Callable，如果其中持有 Service、Mapper、上下文 Map 等大对象，就会间接拖住一堆业务数据
验证方式：在 MAT 中打开堆 dump → 搜索 ScheduledFutureTask → 查其 callable 字段引用的对象类型和大小。
盯紧 DelayedWorkQueue 是否积压
ScheduledThreadPoolExecutor 使用无界 DelayedWorkQueue，它不会拒绝任务，也不会自动清理过期任务。
- MAT 中展开线程池实例 → 找
queue字段（类型为DelayedWorkQueue）→ 右键 “List objects” → “with incoming references” - 观察队列中
ScheduledFutureTask实例数量。若长期 > 100 且持续增长，基本可断定任务提交后未管理生命周期 - 特别注意任务中是否 new 了大对象（如
byte[]、ArrayList<DTO>），这些会被队列长期持有着
检查 shutdown 是否真正生效
仅调用 shutdown() 不够，必须配合等待与强制终止逻辑：
- 调用
shutdown()后，应调用awaitTermination(timeout, unit)等待任务自然结束 - 超时后若仍有活跃任务，再调用
shutdownNow()—— 但注意：这会中断正在执行的任务，需确保任务本身支持中断（比如检查Thread.interrupted()） - 更稳妥的做法是：所有定时任务都封装成可取消的组件，在 Spring 容器销毁钩子（
@PreDestroy）中统一 cancel + awaitTermination
不要依赖 JVM 退出自动清理线程池；容器环境下，线程池必须显式、有序地关闭。
