java应用程序中的高CPU利用率-为什么？
我有一个Java应用程序（基于web），它有时会在几个小时内显示非常高的CPU利用率（几乎90%）。Linux的TOP命令显示了这一点。重新启动应用程序时，问题就会消失。
所以要调查：
我使用线程转储来查找线程正在执行的操作。有几个线程处于“可运行”状态，一些线程处于其他一些状态。在重复执行线程转储时，我确实看到一些线程总是处于“可运行”状态。因此，他们似乎是罪魁祸首。
但我无法确定，哪个线程占用了CPU或进入了无限循环（从而导致CPU使用率高）。
日志不一定有用，因为有问题的代码可能没有记录任何内容。
如何调查-应用程序的哪个部分或哪个线程导致CPU利用率高？-还有其他想法吗？
共有3个答案
在线程转储中，您可以找到行号，如下所示。
对于当前正在运行的主线程。。。
"main" #1 prio=5 os_prio=0 tid=0x0000000002120800 nid=0x13f4 runnable [0x0000000001d9f000]
java.lang.Thread.State: **RUNNABLE**
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:313)
at com.rana.samples.**HighCPUUtilization.main(HighCPUUtilization.java:17)**
您可能是垃圾回收机制问题的受害者。
当您的应用程序需要内存并且配置为使用的内存越来越少时，垃圾收集器将经常运行，这会消耗大量CPU周期。如果它不能收集任何东西，你的内存就会一直很低，所以它会一次又一次地运行。当您重新部署应用程序时，内存将被清除，垃圾收集不会超出需要，因此CPU利用率将保持较低，直到再次满为止。
您应该检查应用程序中是否没有可能的内存泄漏，以及它是否已针对内存进行了良好的配置（检查参数-Xmx，请参见Java选项-Xmx代表什么？）
另外，您使用什么作为web框架？JSF非常依赖会话并消耗大量内存，最多考虑无状态！
如果分析器在您的设置中不适用，您可以尝试在这篇文章中识别以下步骤的线程。
基本上有三个步骤：
- 运行top-H，获得CPU最高的线程的PID
- 将PID转换为十六进制
- 在线程转储中查找具有匹配十六进制PID的线程
-
问题内容： 我有一个Java应用程序（基于Web），有时显示几个小时的CPU使用率很高（几乎90％）。Linux 命令显示了这一点。重新启动应用程序后，问题消失了。 因此要调查 ： 我使用线程转储来查找线程在做什么。发现多个线程处于状态，一些处于其他状态。在进行重复的线程转储时，我确实看到了一些始终处于状态的线程。因此，他们似乎是罪魁祸首。 但是我无法确定是哪个线程正在占用CPU或进入了无限循环（
-
我有一个基于java的应用程序要在ubuntu上运行，为了从服务器开始并保持它的活力，我编写了一个upstart脚本。 问题是启动了upstart服务，它消耗了100%的cpu，这个应用程序有很多线程，只有一个线程很高。 请注意，从命令行启动java应用程序不会出现此问题。 非常感谢。
-
我正在使用mod安全规则https://github.com/SpiderLabs/owasp-modsecurity-crs清理用户输入数据。在将用户输入与mod security rule正则表达式匹配时，我面临着cpu激增和延迟。总的来说，它包含500个正则表达式来检查不同类型的攻击（xss、badrobots、generic和sql）。对于每个请求，我检查所有参数并对照所有这500个正则表
-
谁能解释一下这两种方法的真正区别 vm。GetTotalizationofCPU（CloudSim.clock（））； 和 cloudlet.get利用OfCpu（CloudSim.clock（））； 提前感谢
-
我对wowza中的cpu使用有问题。 这是可疑的线程。这个线程被占用了高CPU。 这个线程占用了大量cpu。这是jdk bug还是其他？ 这是我的环境。 CentOS 5.4版（最终版） WowzaMediaServer-3.1.2 java版本1.6.0_23 java（TM）SE Runtime Environment（构建1.6.0_23-b05）java HotSpot（TM）64位服务器
-
问题内容： 在Linux中是否有命令或任何其他方式来获取当前或平均 CPU使用率 （对于多处理器环境）？ 我在小型系统中使用嵌入式Linux。基本上，我需要确定CPU利用率，以便在CPU利用率很高的情况下，可以将新进程转移到系统中的另一个控制器，而不是在可能忙于执行更重要进程的主处理器上执行。 这个问题不仅仅在于对进程进行优先级排序，另一个控制器可以充分处理新进程，只是当主处理器不忙时，我希望它来