企业官网建设流程全解析

排查Java服务“响应不过来”时，我每次都提醒团队先去抓一份线程Dump，而不是凭经验和日志猜。原因很简单：Dump是一次完整的快照，把那一秒JVM里每个线程在干什么清清楚楚地摊开。尤其是用VisualVM这种带图形界面的工具，连“怎么看Dump”这一步都可以直接在界面上完成，不用背命令，也不用求运维给权限。

这篇文章适合遇到这类场景的人：系统偶尔卡顿但日志正常、CPU无故冲高、某个功能点了没反应、线程池被打满，甚至怀疑死锁但不知道从哪入手。如果你只会jstack但又不想每次切换终端，VisualVM完全可以作为日常主力的分析入口。我在这里把从生成Dump到读Dump、再到定位故障的所有过程拆开讲清楚，最后附上我踩过坑之后总结下来的排查节奏。

1. 线程Dump能回答什么问题：先把症状对号入座

1.1 三种典型故障信号的快速判断

线程Dump解决的问题不是“系统为什么会变慢”，而是“慢的那一刻，每个线程在做什么”。同一个“卡住”现象，背后可能差别很大。

第一种是CPU异常冲高。应用还能响应，但CPU使用率已经顶到接近核心数上限，日志里又没有明显的异常输出。这时候最想知道的其实是“哪个线程在用CPU”。Dump会显示每个线程当时的状态和调用栈，如果一堆线程都停在同一段循环代码上，基本就是热点位置。

第二种是功能偶发卡死。页面转圈，服务本身还在，其他请求可能正常，也可能全部排队。这时候问题多数出在线程等待：等锁、等网络、等数据库连接、等队列里的任务。Dump里WAITING、BLOCKED状态大面积出现，就能顺着锁信息找到谁在“挡路”。

第三种是全员僵死。不是某一个功能，而是整个进程完全无响应。这种情况除了看线程，还要配合GC、内存来确认，但Dump依然能提供第一手证据：是线程都在等同一把锁，还是线程池线程全部耗尽，还是GC线程异常导致的停顿。

1.2 相比jstack，VisualVM实际解决了什么

命令行工具jstack和jcmd也能生成文本Dump，但VisualVM的优势在于它把“抓取、展示、对比、回放”放在了一个界面里。对于不熟悉命令的同事，给一个按钮和给一串参数，学习成本完全不同。

实际工作中我很少只依赖一种。应急时先用jstack拉一版，防止进程假死连不上；稳定复现时用VisualVM，因为它能看到线程状态的时间线，还能顺便用抽样器把CPU占用率最高的方法抓出来。这些信息配合Dump一起看，定位速度会快很多。

2. 用VisualVM生成线程Dump：连接、按钮、文件保存全流程

2.1 连接目标进程的两种常见方式

VisualVM通常随JDK一起安装，路径在JDK安装目录的bin/jvisualvm下。Linux服务器上如果没有图形界面，我一般先在本地启动VisualVM，再配置远程JMX连接目标JVM。如果是本地开发机，启动后左侧“应用程序”树里会直接列出本机所有Java进程，双击即可进入监控页。

远程连接前，目标JVM需要带上JMX参数启动。我常用的最小参数组合是这样：

-Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=19000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

这里要提醒一句：authenticate=false只建议在完全可信的内网环境临时使用，否则端口裸奔风险很大。配置好之后，在VisualVM里右键“远程”，添加远程主机，再添加JMX连接，输入端口就能进去。

2.2 Threads标签页里的核心按钮

连接上进程后，点进“Threads”标签页，能看到一张实时变化的线程状态时间线，横轴是时间，纵轴是各个线程，不同颜色代表不同状态。我一般会先在这里观察十几秒，确认问题正在发生的窗口期，然后再点右上角的“线程Dump”按钮。

点按钮的瞬间，VisualVM会新开一个标签页，内容就是当前线程Dump的完整文本。这一步千万注意：Dump捕捉的是点击那一刻的状态，不是持续趋势。如果不清楚当前是不是故障窗口，宁可多等一会儿，也别在正常时段抓一堆没有价值的快照。

抓完之后我很建议立刻点标签页下方的“保存”按钮，把内容保存成文件。推荐的文件名格式是“进程名_日期_时分秒.tdump”。这样后续复盘时能精确对应到当时的操作。

2.3 保存、打开与历史文件回放

VisualVM保存的线程Dump文件，之后可以直接通过“文件”菜单里的“打开”再次查看。这个能力是我最常用的：线上问题当时没来得及细看，先把Dump存下来，等找到安静环境再逐行分析，完全不打扰现场。

另外，VisualVM也支持直接打开纯文本格式的Dump文件。换句话说，哪怕某一次是用jstack生成的文本，只要按照约定保存下来，也能在VisualVM里统一归档。我实际的项目复盘文件往往包含线程Dump、GC日志、CPU采样结果三样东西，放在同一个目录，每次排查看起来效率极高。

3. 线程状态的信号含义：RUNNABLE、WAITING、BLOCKED到底在说什么

3.1 先看懂单条线程记录的字段

一份典型的线程Dump记录长这样，用VisualVM打开后看到的文本和这个格式基本一致：

"batch-worker-3" #17 prio=5 os_prio=0 cpu=98012.41ms elapsed=3600.08s tid=0x00007f... java.lang.Thread.State: RUNNABLE at java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:458) at com.example.batch.MessagePump.drain(MessagePump.java:77) at com.example.batch.MessagePump.run(MessagePump.java:42)

开头双引号里是线程名，#17是JVM内部的线程编号。如果线程名是子线程池自己定的，比如batch-worker-3，通常直接能从名字看出用途；如果是http-nio-8080-exec-10，说明是Tomcat的请求处理线程；如果是main，那就是主线程。

cpu=字段在某些版本里会显示该线程累计占用的CPU时间，单位毫秒。这个值非常有参考价值：一个线程Dump里RUNNABLE线程不少，但只有cpu时间特别高的那几个才可能是真正的计算热点。

接下来是一个java.lang.Thread.State字段，它代表线程此刻的执行状态。再往下是从当前栈顶到栈底的调用顺序，顶部是线程正在执行的方法，底部是入口。分析时我优先看栈顶两三层，热点通常就在那里。

3.2 四种状态的判断逻辑

Java线程状态和操作系统的线程状态不完全是一回事，但Dump里的状态对判断问题已经足够。

RUNNABLE表示线程正在JVM层面“可运行”。它不代表一定在消耗CPU，也许正阻塞在socket读上。判断依据是栈顶方法：如果栈顶是SocketInputStream.socketRead0或FileDispatcher.read0，即使状态是RUNNABLE，其实是在等待I/O。

WAITING表示线程无限期等待另一个线程的动作，典型场景是Object.wait()、Thread.join()、LockSupport.park()。线程池里大部分空闲线程就是这种状态，这是正常的。但如果当时业务线程本应该执行任务，却大面积停在WAITING，就需要找等待条件。

TIMED_WAITING和WAITING的区别是带超时时间，常见于sleep、带超时的wait、parkNanos等。看到大量TIMED_WAITING不一定是坏事，很多轮询和定时任务就是这样设计的。

BLOCKED表示线程想进入synchronized同步块，但锁被其他线程持有，只好卡在锁外。这是排查锁竞争最直接的状态标志。一个进程里偶尔一两个BLOCKED正常，如果几十个线程全部BLOCKED在同一个对象上，基本可以断定是锁热点。

3.3 锁信息与死锁识别

VisualVM的Dump文本中，锁相关的信息通常有两类。一类是synchronized监视器，文本里会出现locked、waiting to lock这样的标记；另一类是Locked ownable synchronizers，对应ReentrantLock、CountDownLatch这类基于AQS的锁。

我在看锁信息时，不会去记对象内存地址，而是把重点放在两处：谁持有锁，以及锁对应的业务代码在哪。比如一个线程栈里有waiting to lock <0x000000...>，接下来就要去整份Dump里查找谁持有这个地址的锁。一旦找到，阻塞链条就连起来了。

死锁更极端，是两个线程各自持有一把锁，又互相等待对方手里的锁。VisualVM在打开线程Dump后会自动检测，并在文本开头显示类似“Found one Java-level deadlock”的段落。如果看不到这句话，说明当前Dump里没有严格意义的Java死锁，但也别放松，可能是等待链条更长的资源竞争。

4. 从Dump推断故障现场的三个排查实例

4.1 CPU冲高：忙等待自旋，而不是真的在计算

有一回我负责的批处理模块CPU使用率持续超过80%，日志里一切正常。现场抓了第一份Dump，发现大量线程处于RUNNABLE，而且栈顶全部停在同一个队列的poll方法上：

"batch-worker-3" #17 prio=5 os_prio=0 cpu=98012.41ms elapsed=3600.08s ... java.lang.Thread.State: RUNNABLE at java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:458) at com.example.batch.MessagePump.drain(MessagePump.java:77)

如果是正常处理消息，栈顶方法应该是业务处理入口，而不是poll。这里的问题很明显：线程在无限循环里反复拉动空队列，拉一次返回null，又立刻拉下一次，形成自旋。虽然状态写RUNNABLE，但这实际上是一种CPU空转。

我用VisualVM的抽样器同时抓了一份CPU采样，热点方法同样指向MessagePump.drain。双重证据下，修复方案就是给循环加上等待条件，队列为空时让线程休眠或使用阻塞式take。修完再抓Dump，同样的线程状态变成了TIMED_WAITING，CPU掉下来了。

这里想强调一个经验：**RUNNABLE不等于在干活，也可能是空转。**只看状态不看栈顶，很容易把忙等待当成正常计算。

4.2 偶发全员卡住：不是死锁，而是一把锁排队

另一个场景是Web应用每过一段时间就会出现一次几十秒的停顿，之后自动恢复。我抓了两份Dump：第一份在卡顿时抓，第二份在五秒后抓。两次结果里都有大量http-worker线程处于BLOCKED，等待的锁地址是同一个。

顺着锁地址去找持有者，发现是一个正在执行远程调用的线程。它的栈顶停在网络读取上，而且没有超时。也就是说，这个线程持有锁后，在等一个迟迟不回应的外部服务，其余几十个请求线程全部被锁挡住排队。外部服务一旦恢复，调用返回，锁释放，卡顿瞬间消失。

这也是线程Dump最有价值的地方：把“随机卡顿”和“锁等待”绑定到了一起。如果没有Dump，单看日志只会发现外部服务偶发超时，完全想不到它和内部锁的关系。后续的修复思路也很明确：给远程调用加超时，同时对锁保护的范围做瘦身，不让网络调用发生在持锁期间。

4.3 池耗尽：业务线程全去等待连接

还有一种情况很常见：进程没死，但新请求进不来，页面一直转圈。抓Dump后看到一堆业务线程堆栈长这样：

"api-call-12" #48 prio=5 ... java.lang.Thread.State: WAITING (parking) at jdk.internal.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:... at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(...) at com.example.pool.ConnectionPool.borrow(ConnectionPool.java:...

这些线程并不是忙等，而是全部停在连接池队列里等一个空闲连接。单独看任何一条栈都正常，但把几十条栈放在一起，模式立刻清楚：连接池被占满，而持有连接的那些线程在干什么呢？它们大部分停在数据库查询或外部API等待上。

连接池耗尽往往不是池太小，而是被慢调用拖住了。排查时除了看Dump，还要同步看连接池监控。修复方向是缩短调用超时、限制并发依赖、必要时拆分独立的线程池隔离。这一案例的结论同样来自多份Dump的横向对比，单看一条线程Dump永远看不出“池耗尽”这个整体局面。

5. 排错经验：多抓几次、横向对比、别死守单份快照

5.1 一次Dump永远不够，至少间隔抓三份

线程Dump是瞬时快照，只能说明按钮按下那一刻的情况。一个线程停在同一方法上，可能是因为它本来就该等在那里，也可能是因为已经卡死了。要区分这两者很简单：隔几秒再抓一次。

我常用的节奏是“故障发生时立刻抓一份，5秒后再抓一份，如果进程还能撑住，30秒后再抓一份”。三份Dump放在一起，重点看两个指标：第一，卡住的线程是否始终停在同一位置；第二，状态分布是否基本一致。如果两次Dump内容高度雷同，说明是持续性的阻塞；如果每次都不一样，那更可能是瞬间波动。

实际操作中，VisualVM的Threads时间线页面就能看到这种趋势。抓Dump之前先观察时间线五分钟，比盲目点按钮有价值得多。真正稳定的复现窗口，时间线上往往有明确特征：整段颜色集中在BLOCKED或WAITING，很少跳动。

5.2 抓完Dump之后最容易犯的三个错误

第一个错误是只盯着STATE字段。前面说了RUNNABLE可能是在等I/O，WAITING可能是线程池正常空闲。不看栈顶、不看CPU时间，只看状态就下结论，最容易误判。

第二个错误是忽略日志时间线。Dump只能告诉你线程在哪，不能告诉你它为什么在那。做判断时，一定要把GC日志、慢日志、外部依赖的响应时间线拉出来对齐。比如Dump里大量WAITING在Object.wait，如果同一时间点GC日志显示young GC频繁，那结论就完全不同。

第三个错误是现场被快速回收。真正常用的做法是保存Dump后把进程保留一段时间，不要立刻重启。很多信息需要后续二次抽取，比如再抓一次GC、再用VisualVM的堆转储功能看一下内存对象。一旦重启，现场证据就没了。

5.3 围绕VisualVM的一点点长期主义

如果团队经常要用线程Dump排查问题，我建议把线程名统一规范。线程池初始化时给核心线程、业务线程、异步任务分别起有业务含义的前缀，而不是任由默认的pool-1-thread-1出现。好的线程名在Dump文本里的价值不亚于日志打印，一句话就能告诉你这个线程属于哪个环节。

另外，VisualVM的“Sampler”里还有个CPU抽样功能，可以统计每个方法的自用时间。它和线程Dump是互补关系：Dump告诉你线程堆栈结构，抽样器告诉你在这些堆栈里CPU时间花在哪个方法。回看案例一，我就是靠Dump发现停在poll，再靠CPU采样确认了自旋占用，才敢放心改代码。

以我自己的习惯来说，每次排完问题都会把当时的VisualVM线程Dump、CPU采样结果和一份简要的排查记录放同一个目录。排查记录里只写三句话：现象、第一个可疑线程栈、结论与操作。回头再做容量评估或代码Review时，这批文件就是最好的依据。线程Dump不是万能的，但它是把模糊的“系统卡了”变成可核实证据的最短路径，值得花半小时把流程练熟。