要统计单任务在队列中的真实排队耗时，需在提交时用 system.nanotime() 记录入队时间戳并封装进任务对象，如 timedrunnable，执行时计算差值；不可依赖 threadlocal 或 execute() 内部打点，因线程不一致或可能直行。
Java 线程池本身不提供任务入队时间戳或上下文绑定机制，要统计“单任务在队列中的真实排队耗时”，核心思路是：在任务提交时打上入队时间戳，并让任务执行时能安全读取该时间戳——关键在于把时间戳作为上下文随任务一起传递，而非依赖线程局部变量（ThreadLocal）或共享状态。
用包装任务封装入队时间
最直接可靠的方式是自定义 Runnable/Callable 包装器，在提交任务时记录 `System.nanoTime()`（高精度、不受系统时间调整影响），并在执行时计算与当前时间的差值：
- 创建一个 `TimedRunnable` 类，持有一个 `long enqueueNanos` 字段和原始 `Runnable`
- 在构造时调用 `System.nanoTime()` 记录入队时刻（注意：必须在 `execute()` 或 `submit()` 调用前完成，即在主线程中打点）
- 重写 `run()` 方法：先计算 `System.nanoTime() - enqueueNanos`，再调用原任务逻辑；可将结果通过日志、Metrics 或回调上报
- 提交时不要直接传原始任务，而是传 `new TimedRunnable(original, System.nanoTime())` ——但注意：`System.nanoTime()` 必须在真正进入队列前获取，因此推荐在 `execute()` 之前立即获取，例如：`executor.execute(new TimedRunnable(r, System.nanoTime()));`
利用 ThreadPoolExecutor 的 beforeExecute 钩子（需配合任务标识）
如果无法修改任务提交侧代码，可借助 `ThreadPoolExecutor` 的 `beforeExecute(Thread, Runnable)` 钩子。但该钩子只在任务即将执行（已出队、即将 run）时触发，此时已无入队时间信息。所以必须提前把时间戳存到任务对象中：
- 要求所有任务实现某个标记接口（如 `EnqueueTimed`），带 `setEnqueueTime(long)` 和 `getEnqueueTime()` 方法
- 提交前由调用方设置时间戳（同上，`task.setEnqueueTime(System.nanoTime())`）
- 在 `beforeExecute` 中检查任务是否实现了该接口，若实现则读取时间戳并计算排队耗时
- 注意：不能依赖 `ThreadLocal` 存储时间戳，因为 `beforeExecute` 和任务提交不在同一线程，且多个任务共用线程池线程
避免常见陷阱
以下做法看似简洁，但不可靠：
- 用 ThreadLocal 存时间戳：提交线程和执行线程不同，`ThreadLocal` 不跨线程传递，会丢失
- 在 execute() 内部打点（如重写 execute 方法）：`ThreadPoolExecutor.execute()` 是 public 方法，但其内部可能直接运行（如线程数
- 用 System.currentTimeMillis()：精度低（毫秒级），且受系统时钟回拨影响，导致排队耗时为负或失真；务必用 `System.nanoTime()`
进阶：统一接入 Metrics（如 Micrometer）
若项目已集成 Micrometer，可将排队耗时作为 DistributionSummary 上报：
- 在 `TimedRunnable.run()` 中计算耗时后，调用 `distributionSummary.record(nanos / 1_000_000.0)`（转为毫秒）
- 添加 tag 如 `pool.name=xxx`, `task.type=xxx`，便于多维度下钻
- 注意单位一致性：`nanoTime` 差值是纳秒，建议转为毫秒或微秒后上报，避免数值过大
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
