Java线程池可通过重写ThreadPoolExecutor的beforeExecute和afterExecute钩子方法实现轻量级任务监控与耗时统计：前者用ThreadLocal记录起始时间，后者计算纳秒级耗时并按状态上报，需注意ThreadLocal清理、避免阻塞及结合线程池状态联动分析。
在 Java 线程池中，`ThreadPoolExecutor` 提供了 `beforeExecute` 和 `afterExecute` 两个受保护的钩子方法，它们会在每个任务执行前和执行后被调用（无论任务是否正常完成、抛出异常或被取消）。合理扩展这两个方法，是实现轻量级任务监控与耗时统计最直接、侵入性最小的方式。
1. 重写钩子方法并记录开始时间
关键在于：`beforeExecute` 中不能只记日志，而要将任务开始时间绑定到当前线程或任务对象上。由于线程复用，推荐使用 `ThreadLocal` 存储起始时间戳，避免多任务交叉干扰。
示例实现：
private final ThreadLocal<Long> startTime = ThreadLocal.withInitial(System::nanoTime);
<p>@Override
protected void beforeExecute(Thread t, Runnable r) {
super.beforeExecute(t, r);
startTime.set(System.nanoTime());
}2. 在 afterExecute 中计算耗时并上报指标
`afterExecute` 的第二个参数 `Throwable t` 表示任务执行过程中抛出的异常（为 null 表示正常结束或被取消但未抛异常）。结合 `startTime.get()` 即可算出真实耗时，并做分类统计。
立即学习“Java免费学习笔记（深入）”；
建议操作：
- 用 `System.nanoTime()` 计算纳秒级耗时，再转为毫秒（注意除以 1_000_000.0），避免 `System.currentTimeMillis()` 的时钟漂移问题
- 判断 `t != null` 区分成功/失败；若 `r` 是 `FutureTask`，还可通过 `isCancelled()` 进一步识别是否被主动取消
- 将耗时、状态、线程名、任务类型等信息统一打点（如发往 MetricsRegistry、SLF4J MDC 或简易内存计数器）
示例：
@Override
protected void afterExecute(Runnable r, Throwable t) {
long duration = System.nanoTime() - startTime.get();
startTime.remove(); // 必须清理，防止内存泄漏
<pre class="brush:php;toolbar:false;">String status = (t != null) ? "FAILED" : "SUCCESS";
String taskName = r.getClass().getSimpleName();
// 上报：例如记录到 Micrometer Timer 或自定义 Histogram
taskTimer.record(duration, TimeUnit.NANOSECONDS);
taskStatusCounter.labels(status, taskName).inc();}
3. 注意事项与常见陷阱
这些细节直接影响监控数据的准确性与稳定性：
- ThreadLocal 必须 remove()：线程复用下不清理会导致旧时间戳残留，造成负耗时或统计失真
- 钩子方法在任务线程中执行：不要在其中做阻塞操作（如远程调用、同步日志刷盘），否则会拖慢任务执行
- cancel() 不触发 afterExecute？：默认情况下，显式调用 `future.cancel(true)` 后，若任务尚未开始，`afterExecute` 仍会被调用，且 `t == null`；若已运行中被中断，则可能抛出 `InterruptedException`，此时 `t` 非空
- 包装 Runnable/Callable 更灵活？：若需更细粒度控制（如带业务 ID、标签），可在提交任务时统一包装，比依赖钩子更可控，但钩子更适合全局无感埋点
4. 结合线程池状态做辅助监控
钩子方法之外，可定期采样线程池运行指标（如 `getActiveCount()`、`getCompletedTaskCount()`、`getQueue().size()`），与单任务耗时联动分析。例如：
- 活跃线程数持续高位 + 平均耗时上升 → 可能存在慢任务阻塞线程
- 队列积压增长 + 耗时稳定 → 说明吞吐不足，需扩容或优化任务逻辑
这类聚合指标建议通过 `ScheduledExecutorService` 每 10–30 秒采集一次，避免高频影响性能。
