我正在使用VisualVM监视我的JBoss实例。我附上了它的截图。
问题是我重新启动JBoss实例后，操作系统上的CPU开始变高。负载可以高达40，顶级命令中的JAVA进程显示高达300％的使用率。
然后继续减慢前端的应用程序。
VisualVM显示CPU很高，并且线程数也在增加。
我怎样才能进一步找到根本原因？
答案 0 :(得分：1)
一个好的起点是生成堆转储，并使用堆转储分析器工具查看引擎盖下发生的事情，并使用VisualVM浏览它
一些免费的替代方案是Eclipse MAT或IBM HeapAnalyzer
答案 1 :(得分：1)
当涉及高CPU使用率时，我通常会寻找两件事：
要进一步诊断＃1，启用GC Logging可能是最好的方法。但是，您也可以使用jstat：
jstat -gc PID 60s
上述命令将每隔60秒从JVM收集内存使用情况和垃圾收集详细信息。在调试环境中，60s应该没问题，但在生产环境中3600s就足够了。 jstat重量很轻，不会产生任何不良影响。输出将帮助您了解是否存在频繁的GC（主要/次要）。频繁的主要集合肯定是一个问题（它会暂停应用程序），但是，非常频繁的次要集合也可能导致高CPU（应用程序过于频繁地创建过多的垃圾）。如果是这种情况，可能您需要一个头转储，您需要了解应用程序的内存使用情况详细信息，但在此之前不需要。请记住，捕获堆转储可能会“挂起”您的应用程序（我不建议它在生产中，除非您可以在捕获数据后立即重新启动应用程序）。
要诊断＃2，“top”提供一个选项（“H”）来检查各个线程消耗的CPU。这将指向（实时）消耗CPU的应用程序线程。另外（正如其他人所建议的那样），以10秒的间隔捕获5/6个线程转储。在RUNNABLE状态下查找线程。这些是正在工作并因此占用CPU的线程。在多个转储中，相同（一组）线程是否在Runnable状态中停留？可能你有问题。
希望这会有所帮助。祝你好运！
答案 2 :(得分：0)
了解增加的线程数非常容易。捕获几个theaddumps并比较创建的新线程。
对于高CPU利用率，您必须使用Visual VM（如果此信息可用）或本机系统监视工具检测导致此问题的线程。您应该能够将线程ID映射到threaddump中的stacktrace以查看真正的原因。
答案 3 :(得分：0)
是的，但由于2个问题，我们很难从线程转储中找到。 1. CPU利用率在15-20分钟内迅速从20％增加到90％。我们无法在其他环境中这样做。 2.当我们接受线程转储时，可能导致问题的实际线程完成，我们找到正在等待资源的其他线程。
是否有其他方法可以在服务器端配置或检查？
