java应用cpu飙升100%时，需用top -hp查高负载lwp线程id，转十六进制后在jstack输出中匹配，定位runnable状态下的高频计算方法及变量误用问题。
当 Java 应用 CPU 使用率突然飙到 100%，最常见原因是某个或某几个线程陷入高频计算、死循环、过度对象创建或锁竞争。单纯看线程数或堆内存往往找不到根因，需将操作系统级线程与 JVM 线程精准关联——top -Hp 查出高负载的本地线程 ID（LWP），再用 jstack 转换为十六进制匹配线程栈，就能定位到具体 Java 方法和变量操作。
用 top -Hp 找出最忙的线程 PID
在问题发生时执行：
top -Hp <java_pid></java_pid>
按 P（大写）按 CPU 使用率降序，观察 %CPU 列最高的那几行。记下对应 LWP 列的数字（即线程 ID，十进制）。这个 ID 是 Linux 内核调度的轻量级进程号，和 JVM 线程一一对应。
将 LWP 转成十六进制，用于 jstack 匹配
JVM 线程栈中显示的是线程 ID 的十六进制形式，需手动转换：
- Linux 下可用命令快速转：
printf "%x\n" <lwp_id></lwp_id> - 例如 LWP 是 28723 →
printf "%x\n" 28723输出7033 - 注意：jstack 输出里
"nid=0x7033"中的0x前缀可忽略，直接搜7033即可
用 jstack 抓栈并定位问题代码
执行：
jstack <java_pid> > jstack.out</java_pid>
打开 jstack.out，搜索刚才得到的十六进制 ID（如 7033），找到对应线程块。重点关注：
- 线程状态是否为
RUNNABLE（而非 BLOCKED/WAITING） - 栈顶方法是否在做密集计算：比如
String::hashCode、HashMap::put、自定义循环、JSON 序列化/反序列化、正则反复匹配 - 是否有明显可疑变量：如未加界限制的 while 循环、空 busy-wait、递归无出口、BigDecimal 高精度除法未设 scale
结合代码确认变量级根源
找到方法后，回看源码，特别检查该方法中参与计算的变量：
- 集合类是否被反复遍历且 size 持续增长（如日志拼接时不断往 List.add）
- 字符串拼接是否在循环里用
+（触发大量 StringBuilder 创建） - 缓存 key 是否含时间戳或随机数，导致缓存失效+重复计算
- 数值计算是否用了低效算法（如斐波那契递归、未优化的矩阵乘法）
这类问题往往不是“功能错误”，而是“性能误用”——变量生命周期、复用方式或计算路径没对齐实际负载。
