核心问题是调度节奏与执行能力错配，导致任务堆积、线程占满、内存失控；解决关键在于用fixedDelay或手动重调度替代fixedRate，配专用有界线程池，加超时兜底，并监控真实水位。
Java 中线程池在定时任务调度中引发崩溃，核心问题不是“任务太多”，而是“调度节奏和执行能力严重错配”——任务还没执行完，下一轮又触发了，线程被长期占住，队列持续堆积，内存和线程数双双失控。解决关键在于切断“盲目触发→排队→滞留→OOM”的链路。
用 fixedDelay 替代 fixedRate 做串行可控调度
Spring 的 @Scheduled(fixedRate = 5000) 或 Quartz 的 SimpleTrigger 默认按固定间隔反复提交任务，不管上一个是否结束。一旦单次执行超时（比如数据库慢查询），就会立刻堆积。
改用基于完成回调的重调度方式：
private void reschedule() {
executor.schedule(() -> {
try {
doWork(); // 实际业务逻辑
} finally {
reschedule(); // 无论成功失败，都触发下一次
}
}, 5, TimeUnit.SECONDS);
}
这样调度权回到业务代码，确保前一个任务彻底结束（或异常退出）后才启动下一个，天然避免堆积。注意：必须放在 finally 块里；若任务失败需重试，应加入指数退避（如第一次等 1s，第二次等 2s，第三次等 4s）。
立即学习“Java免费学习笔记（深入）”；
为定时任务单独配线程池，且必须有界
别把定时任务塞进全局共用线程池，更不能用 Executors.newCachedThreadPool() 或 newFixedThreadPool() —— 前者线程无限增长，后者搭配无界队列（LinkedBlockingQueue()）等于给内存堆叠开绿灯。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
正确做法是手动构建专用线程池：
- 核心线程数设为 1～3（多数定时任务无需并发执行，1 个足够）
- 最大线程数与核心一致（避免突发创建多余线程）
- 队列必须有界：
new ArrayBlockingQueue<>(20)，容量根据最长执行耗时和容忍延迟反推（例如每 10 秒跑一次、单次最多 30 秒，则最多积压 3 个） - 拒绝策略用
AbortPolicy或带日志告警的自定义策略，让堆积发生时能被快速感知
给任务加超时兜底，防止线程卡死
即使调度可控，单个任务内部阻塞（如 HTTP 调用未设 timeout、数据库连接池耗尽、流未关闭）也会导致线程长期占用，最终拖垮整个池。
推荐组合手段：
- 使用
CompletableFuture.orTimeout(30, TimeUnit.SECONDS)包裹耗时操作，超时自动中断 - 数据库访问设置 queryTimeout，HTTP 客户端配置 connect/read timeout
- 任务逻辑中避免持有大对象引用（如缓存 List、未关闭的 InputStream），防止 GC 无法回收
- 关键路径加上
Thread.interrupted()检查，响应中断信号及时退出
监控线程池真实水位，不靠猜
很多崩溃发生在“看起来还正常”的时候。光看 CPU 和堆内存没用，要盯紧线程池自身指标：
-
executor.getActiveCount()：当前正在执行的任务数（持续 ≥ 核心线程数就危险） -
executor.getQueue().size()：等待队列长度（超过容量 80% 就该告警） -
executor.getCompletedTaskCount()与System.nanoTime()结合算 TPS，判断是否跟得上节奏
把这些指标打点到 Prometheus 或接入日志系统，设置阈值自动触发降级（比如队列满时跳过本次任务、返回默认值）。
