我正在分析进行线程转储的方法之间的差异。以下是我正在研究的其中几个
定义一个 jmx bean,它在单击声明的 bean 操作时通过 Runtime.exec() 触发 jstack。
在预定义的时间间隔后重复执行“ManagementFactory.getThreadMXBean().dumpAllThreads(true, true)”的守护线程。
比较两者之间的线程转储输出,我发现方法 2 存在以下缺点
- 使用方法 2 记录的线程转储无法被 TDA 等开源线程转储分析器解析
- 输出不包括在分析高 CPU 问题时可能有用的 native 线程 ID(对吗?)
- 还有吗?
我希望得到有关方面的建议/意见
在生产代码中通过 Runtime.exec() 执行 jstack 有什么缺点吗?各种操作系统(windows、linux)上的兼容性问题?
还有其他方法来进行线程转储吗?
谢谢。
编辑 -
1 和 2 的组合方法似乎是要走的路。我们可以在后台运行一个专用线程,并以线程转储分析器可以理解的格式在日志文件中打印线程转储。 如果需要任何仅由 jstack 输出记录的额外信息(比如可能是 native 线程 id),我们会根据需要手动执行。
最佳答案
你可以使用
jstack {pid} > stack-trace.log
以用户身份在进程运行的盒子上运行。
如果您多次运行此程序,您可以使用 diff
更轻松地查看哪些线程处于 Activity 状态。
为了分析堆栈跟踪,我在专用线程中定期使用以下采样。</p>
Map<Thread, StackTraceElement[]> allStackTraces = Thread.getAllStackTraces();
使用此信息,您可以获得线程的 id、运行状态并比较堆栈跟踪。
关于java - 在生产中进行线程转储,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/14118385/