java中统计异步任务真实耗时需将计时逻辑下沉至执行线程：通过asyncconfigurer定制线程池，在beforeexecute/afterexecute钩子中记录起止时间；结合@asynctimetrack注解与aop包装任务，封装计时及mdc上下文透传，确保耗时准确、日志可追溯、超时可告警。
Java中用线程池配合AOP统计异步任务真实耗时，关键在于解决“调用即返回、执行在后台”的时间错位问题。单纯在方法入口打点、出口算差值会严重失真——因为@Async方法返回的是代理结果，实际逻辑还在线程池里跑。必须把计时逻辑下沉到真正执行任务的线程上下文中。
异步任务耗时统计的核心难点
传统同步方法的AOP计时（比如@Around）在@Async上直接失效：切面拦截的是提交动作，不是执行动作。任务提交后立刻返回，而System.currentTimeMillis()记录的时间只反映“排队耗时”，不包含“运行耗时”。要拿到真实执行时间，必须让计时发生在目标线程内，且能关联原始请求上下文（如traceId、方法签名）。
基于AsyncConfigurer定制线程池+任务包装
不依赖默认线程池，而是通过实现AsyncConfigurer自定义线程池，并在提交任务前做一层包装，把计时逻辑注入实际执行体：
- 重写getAsyncExecutor()，返回自定义ThreadPoolTaskExecutor
- 在线程池的beforeExecute()钩子中记录开始时间戳，并存入ThreadLocal或MDC
- 在afterExecute()钩子中读取开始时间，计算差值并输出日志
- 确保异常情况也能触发afterExecute，避免耗时漏统计
用AOP环绕通知+自定义注解标记异步方法
仅靠线程池钩子还不够——需要知道哪些方法是“值得关注的异步任务”。这时结合自定义注解（如@AsyncTimeTrack）和AOP更清晰：
- 定义注解@AsyncTimeTrack，保留策略为RUNTIME，作用于METHOD
- 切面类使用@Around("@annotation(asyncTimeTrack)"），但不直接计时，而是将方法元信息（类名、方法名、参数摘要）封装进一个RunnableWrapper对象
- Wrapper内部持有计时逻辑：构造时记录startNano，run()执行前再校准一次（防线程复用导致时间漂移），run()结束后打印耗时
- 最终调用taskExecutor.submit(wrapper)而非原始Runnable
保障上下文传递与日志可追溯
异步任务跨线程后，MDC中的traceId、用户ID等会丢失，导致日志无法串联。需主动透传：
- 在提交任务前，从当前线程MDC中提取关键字段，存入Wrapper对象
- Wrapper的run()方法开头，将这些字段重新put进新线程的MDC
- 日志模板统一包含%X{traceId} %X{userId}，确保每条耗时日志可定位到具体请求和用户
- 对超时任务（如>5s）额外打WARN级别日志，并附带堆栈快照（用Thread.getAllStackTraces()筛选目标线程）
这个方案绕开了@Async代理层的干扰，把计时锚点牢牢钉在任务真实执行的位置，同时保持业务代码零修改。只要在异步方法上加个注解，就能自动获得准确、带上下文、可告警的耗时数据。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
