用jstack定位高CPU线程需先通过top -Hp获取高占用LWP ID，转为16进制后在jstack输出中搜索nid；注意容器环境用HostPid、RUNNABLE不等于真占CPU、GC线程高占用需结合jstat和jmap排查根本原因。
怎么用 jstack 抓到高 CPU 线程的堆栈
直接用 jstack 本身抓不到“哪个线程正在吃 CPU”，它只输出所有线程快照，但配合 top -H 或 ps H 就能定位。关键步骤是：先找 PID，再找高 CPU 的 LWP（轻量级进程 ID），最后转成 16 进制去堆栈里对号入座。
-
top -Hp <pid></pid>查看该 Java 进程下所有线程的 CPU 占用，记下 %CPU 最高的那个 LWP ID -
printf "%x\n" <lwp_id></lwp_id>把它转成小写十六进制（比如 12345 →3039） -
jstack <pid> > thread.log</pid>保存全量堆栈，然后grep -A 10 -B 10 "nid=0x3039"搜索对应线程块 - 注意：JDK 8+ 默认开启
-XX:+UseContainerSupport，在容器里看到的 PID 可能被 cgroup 限制，jstack要用宿主机视角的 PID（即docker inspect里的HostPid）
jtop 是什么？它真能替代 jstack 吗
jtop 不是 JDK 自带工具，而是第三方命令行实时监控器（GitHub 上开源），它把 jstack + jstat + top 逻辑做了聚合，能动态刷新线程 CPU 排名。但它依赖 JVM 的 Attach API，在某些安全加固环境（如 -XX:+DisableAttachMechanism）会直接失败。
- 启动前确认目标 JVM 没加
-XX:+DisableAttachMechanism，否则报错：Unable to open socket file: target process not responding or HotSpot VM not loaded - 它显示的“CPU%”是采样估算值，不是精确瞬时值；和
top -H的结果可能有 5–10% 偏差 - 不支持 JDK 17+ 的默认强封装（需额外加
--add-opens java.base/jdk.internal.misc=ALL-UNNAMED）
线程状态为 RUNNABLE 就一定在跑 CPU 吗
不一定。RUNNABLE 表示线程处于 JVM 就绪或运行态，但操作系统层面它可能正被调度、也可能刚从阻塞中唤醒还没真正执行。真正要怀疑的是那些长期卡在 java.util.concurrent 或 Unsafe.park 外围的 RUNNABLE 线程——它们大概率在自旋或忙等。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 典型陷阱：
AtomicInteger.incrementAndGet()在高争用下反复 CAS 失败，线程持续RUNNABLE但没做有效工作 - 另一个常见点：
Thread.sleep(0)或空while(true)循环，堆栈里看不到 I/O 或锁等待，只有纯 Java 方法调用链 - 区分方法：用
perf record -e cycles:u -p <pid></pid>看用户态指令热点，比堆栈更准
为什么 dump 出来全是 GC 相关线程，但 CPU 还是高
说明问题不在业务线程，而在 GC 本身——尤其是 CMS 或 G1 在并发阶段频繁触发、或元空间/直接内存泄漏导致 GC 压力陡增。这时候 jstack 看到的 GCTaskThread、VM Thread 高占用是结果，不是原因。
立即学习“Java免费学习笔记（深入）”；
- 先用
jstat -gc <pid> 1000</pid>看 GC 频率和耗时，重点关注GCTimeRatio和FGC次数 - 如果
Metaspace使用量持续上涨，检查是否动态生成类（如 CGLIB、Groovy、JSP 编译）没释放 -
jmap -histo:live <pid></pid>可能看不出问题，得用jmap -dump:format=b,file=heap.hprof <pid></pid>配合mat查 dominator tree
线程堆栈只是入口，真正卡点往往藏在内存分配模式、JNI 调用、或外部资源争用里。别盯着 nid 找太久，先确认是不是 GC、锁竞争、或 native 层问题更省时间。
