afterExecute是ThreadPoolExecutor中任务执行完毕后调用的钩子方法，无论成功或异常均触发，运行在任务线程中，适用于耗时统计、异常捕获与日志上报，具有零侵入、全覆盖、上下文准确三大优势。
线程池的 afterExecute 是一个被很多人忽略但非常实用的钩子方法——它在每个任务执行完毕（无论成功或抛出异常）后被调用，且运行在执行该任务的线程中。这使得它天然适合做**任务粒度的耗时统计、结果观察、异常捕获与日志上报**，而无需侵入业务逻辑代码。
为什么选 afterExecute 而不是 try-catch 或 AOP？
相比在任务内部手动加计时或 try-catch，afterExecute 有三个关键优势：
- 零侵入：不修改原有 Runnable/Callable 实现，对业务完全透明；
-
全覆盖：无论任务是通过
execute()还是submit()提交，只要在线程池中执行，都会触发； - 上下文准确：能拿到原始任务对象、执行线程、实际耗时、以及可能的异常（即使被 Future.get() 吞掉，这里仍可捕获）。
如何实现任务执行耗时统计？
核心思路是在 beforeExecute 中记录开始时间，在 afterExecute 中计算差值。注意：必须成对使用，且需线程安全地存储起始时间（推荐用 ThreadLocal）。
示例代码片段：
private final ThreadLocal<long> startTime = ThreadLocal.withInitial(System::nanoTime);
<p>@Override
protected void beforeExecute(Thread t, Runnable r) {
startTime.set(System.nanoTime());
}</p>
<p>@Override
protected void afterExecute(Runnable r, Throwable t) {
long duration = System.nanoTime() - startTime.get();
startTime.remove(); // 避免内存泄漏</p>
<pre class="brush:php;toolbar:false;">// 上报到监控系统，例如 Micrometer Timer
taskTimer.record(duration, TimeUnit.NANOSECONDS);
// 或打点日志（建议仅对慢任务）
if (duration > TimeUnit.MILLISECONDS.toNanos(500)) {
log.warn("Slow task: {} took {}ms", r.getClass().getSimpleName(),
TimeUnit.NANOSECONDS.toMillis(duration));
}
}
如何捕获并上报未处理异常？
afterExecute 的第二个参数 t 就是任务执行过程中抛出的未捕获异常（包括 Runnable 中的异常，以及 Callable 执行时未被 get() 拿走的 ExecutionException 原因）。这是捕获“静默失败”的黄金位置。
常见上报方式：
- 记录结构化日志：包含任务类型、线程名、堆栈、提交时间（可结合 MDC 补充上下文）；
-
推送至告警通道：如异常类型为
SQLException或TimeoutException，触发企业微信/钉钉通知； - 聚合统计：按异常类名 + 方法签名维度计数，接入 Prometheus 监控。
注意：t 在 Runnable 场景下直接是异常；在 Callable 场景下，若你调用了 future.get() 并吞掉了异常，则 t 为 null —— 所以务必避免在业务层无意识地“吃掉”异常。
实战注意事项与避坑点
几个容易踩的坑，直接影响功能稳定性和可观测性：
- 不要在钩子里阻塞或耗时操作：比如同步发 HTTP 日志、写磁盘。应异步落库或投递到内存队列（如 Disruptor、BlockingQueue + 单独消费线程）；
-
确保 ThreadLocal 正确清理：尤其在线程复用场景下，忘记
remove()会导致内存泄漏和跨任务时间错乱； -
区分任务类型做差异化处理：可通过
r instanceof MyTask或反射获取任务元信息（如注解标记的业务域），避免一刀切； - 慎用 this 引用：钩子方法中不要把当前线程池实例传给异步任务，易引发生命周期问题。
不复杂但容易忽略：一次配置，长期受益。只要线程池是你系统的核心执行载体，afterExecute 就是最轻量、最可靠的可观测性入口之一。
