threadmxbean.getthreadcputime() 返回线程自启动以来的累计cpu纳秒数，非单次操作耗时；需双采样求差值，并确保线程处于运行态、已启用cpu时间支持，且避免i/o、sleep等阻塞操作。
ThreadMXBean.getThreadCpuTime() 本身不用于“精确计算变量线程耗时”，它返回的是指定线程自启动以来在 CPU 上执行的总纳秒数（即真正占用 CPU 的时间），属于累计值，不是针对某段代码块或某个变量操作的独立耗时。要实现对一段逻辑（比如某次变量赋值、对象构造、方法调用）的 CPU 时间测量，必须配合两次采集做差，并确保线程上下文一致、采样时机合理。
getThreadCpuTime 是累计值，不是区间计时器
该方法返回的是线程整个生命周期内消耗的 CPU 时间总和，单位为纳秒。它不会自动重置，也不能直接绑定到某行 Java 代码。例如：
- 调用 threadMXBean.getThreadCpuTime(tid) 一次，只能拿到当前累计值；
- 想得到“某段 for 循环的 CPU 耗时”，必须在循环前取一次、循环后取一次，再相减；
- 若中间线程被调度出去、休眠、阻塞或等待锁，这部分时间不计入 getThreadCpuTime，这正是它比 System.currentTimeMillis() 更贴近“真实运算开销”的原因。
正确使用方式：双采样 + 差值计算
要评估某段逻辑的真实 CPU 占用，推荐以下步骤：
- 启用 CPU 时间采集：threadMXBean.setThreadCpuTimeEnabled(true)（首次需检查
isThreadCpuTimeSupported()）； - 获取目标线程 ID（如当前线程用
Thread.currentThread().getId()）； - 在待测逻辑前调用
getThreadCpuTime(tid)记为startCpuNs； - 执行目标逻辑（避免 sleep / wait / I/O，否则 CPU 时间几乎为 0）；
- 立即再次调用
getThreadCpuTime(tid)记为endCpuNs； - 差值
endCpuNs - startCpuNs即为该逻辑实际消耗的 CPU 时间（纳秒级）。
注意：两次调用之间应尽量减少干扰操作；若逻辑过短（如单次 int 赋值），可能因精度限制返回 0 —— 这不代表没开销，而是低于 JVM 或 OS 的时间计量粒度。
它不反映阻塞/等待，但可辅助识别热点
getThreadCpuTime 只统计运行态（Running）中真正执行字节码的时间。它无法告诉你线程是否在等锁（BLOCKED）、等 notify（WAITING）、或读文件（TIMED_WAITING）。若想全面分析线程行为，需结合：
- ThreadInfo.getLockedSynchronizers() 判断锁竞争；
- ThreadInfo.getWaitedTime() 和 getBlockedTime() 获取等待/阻塞累计毫秒；
- 对比
getThreadUserTime()（用户态 CPU 时间）与getThreadCpuTime()（含内核态），判断是否存在系统调用开销。
实际场景中的典型误用
常见错误包括：
- 用它替代
System.nanoTime()测量含 sleep 的逻辑 → 结果接近 0，造成误判； - 跨线程调用 getThreadCpuTime 但未确认线程仍存活 → 返回 -1；
- 未启用 CPU 时间支持（
setThreadCpuTimeEnabled(true)）就直接调用 → 持续返回 -1； - 在多核环境下，把单个线程 CPU 时间直接等同于“系统 CPU 使用率” → 忽略了并行性与归一化处理（需除以采样时长 × CPU 核数）。
