将Java进程转移到“解剖台”之前，法医都干了什么？(2)

jstack将会获取当时的执行栈。一般都会多次取值，我们这里取一次即可。这些信息非常有用，能够还原你的java进程中线程情况。

top -Hp $PID -b -n 1 -c > $DUMP_DIR/top-$PID.dump 2>&1 

为了能够得到更加精细的信息，我们使用top命令，来获取进程中所有线程的cpu信息。这样，就可以看到资源到底是耗费在什么地方。

5、高级替补

kill -3 $PID 

有时候，jstack并不能够运行。有很多原因，比如java进程几乎不响应了。我们会尝试向进程发送kill -3信号。这个信号是java进程享有的，将会打印jstack的trace信息到日志文件中。是jstack的一个替补方案。

gcore -o $DUMP_DIR/core $PID 

对于jmap无法执行的问题，也有替补，那就是GDB组件中的gcore。将会生成一个core文件。我们可以使用如下的命令去生成dump

${JDK_BIN}jhsdb jmap --exe ${JDK}java --core $DUMP_DIR/core --binaryheap 

瞬时态和历史态

xjjdog这里创建两个名词。瞬时态是指当时发生的，快照类型的元素;历史态是指按照频率抓取的，有固定监控项的资源变动图。

上面有很多信息，比如CPU，比如系统内存等，瞬时态的价值就不如历史态来的直观一些，因为它还存在一个基线问题。所以如果有监控系统一类的工具，将美好的多。

但对于lsof，heap等，这种没有时间序列概念的混杂信息，无法进入监控系统，产生有用价值，就只能够通过瞬时态进行分析。这种情况下，瞬时态的价值反而更大一些。

我已经把上面的过程，写成了一个shell脚本。你可以在github上找到它。点击左下角的查看原文，也能和它见面。

https://github.com/sayhiai/shell

但值得注意的是，分布式环境的故障原因，往往会出乎意料，你的这份单机证据，可能就只是一个表象。它没有说谎，但它背后的意义，往往对问题本质进行了错误的引导。

（编辑：ASP站长网）