我们在生产中有一个Java应用程序，其中某个线程正在停止/备份。线程正在读取队列，我们测量插入任务的处理时间。调试根本原因的最佳方法是什么。每分钟左右采用peroidic线程转储（通过脚本）提供更多信息？其他人做了什么来调试这种情况。
答案 0 :(得分：1)
在我工作的系统中，我们监控任务执行所需的时间。如果此时间超过X时间，我们会触发一个线程转储（以编程方式，从我们测量时间的点开始，所以不是外部脚本），然后在几秒钟之后再进行另一次线程转储。这个阈值X应该是一个相对较大的数字，在我们的例子中它是5分钟。如果发生这种情况，我们可以假设系统不是“慢”，而是发生了一些不好的事情，比如死锁或极长的阻塞呼叫。
所以，回答部分问题：是的，定期的线程转储可能会有所帮助，但前提是转储是在您要查找的事件的确切时刻发生的。如果你每10秒钟只生成一次线程转储，找到正确的转储可能会很痛苦......除非你正在寻找死锁，否则工具可以帮助解决这个问题。我无法回答你问题的表现部分。
答案 1 :(得分：1)
假设你的线程正在从一个简单的并发队列实现中拉出任务，我首先要检查垃圾收集是否是罪魁祸首。如果您还没有这样做，则需要添加命令行选项以打开GC日志记录：
-XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCDateStamps -Xloggc:<some-file>
如果您确定它不是垃圾收集，那么您可以考虑使用jHiccup之类的东西来监控停顿，特别是如果您的应用程序在虚拟化环境中运行。
答案 2 :(得分：0)
在生产中定期进行线程转储肯定是一项昂贵的操作。因为您要向JVM提供额外的任务来打印由JVM生成的所有线程的所有当前执行堆栈。
如果您可以访问代码，我建议您使用其他日志记录来打印性能日志和计时数据。
如果您无法访问代码，我建议您使用APM工具，例如dynatrace，appdynamics或任何可用于调试时间方法或第三方调用的内容。
希望这有帮助！
此致 Eby J