- 无限循环的while会致使CPU使用率飙升吗?
- 常用Young GC会致使CPU占用率飙升吗?
- 具备大量线程的应用程序的CPU使用率是否较高?
- CPU使用率高的应用程序的线程数是多少?
- 处于BLOCKED状态的线程会致使CPU使用率飙升吗?
- 分时操做系统中的CPU是消耗
us
仍是sy
?
CPU%= 1 - idleTime / sysTime * 100java
人们常说,计算密集型程序的CPU密集程度更高。正则表达式
那么,JAVA应用程序中的哪些操做更加CPU密集?数据库
如下列出了常见的CPU密集型操做:segmentfault
while (true)
语句。若是在程序中计算须要很长时间,则可使线程休眠。如今,分时操做系统使用循环方式为进程调度分配时间片。若是进程正在等待或阻塞,那么它将不会使用CPU资源。线程称为轻量级进程,并共享进程资源。所以,线程调度在CPU中也是分时的。但在Java中,咱们使用JVM进行线程调度。所以,一般,线程调度有两种模式:时间共享调度和抢占式调度。服务器
是。工具
首先,无限循环将调用CPU寄存器进行计数,此操做将占用CPU资源。那么,若是线程始终处于无限循环状态,CPU是否会切换线程?oop
除非操做系统时间片到期,不然无限循环不会放弃占用的CPU资源,而且无限循环将继续向系统请求时间片,直到系统没有空闲时间来执行任何其余操做。spa
stackoverflow中也提出了这个问题:为何无心的无限循环增长了CPU的使用?操作系统
是。
Young GC自己就是JVM用于垃圾收集的操做,它须要计算内存和调用寄存器。所以,频繁的Young GC必须占用CPU资源。
让咱们来看一个现实世界的案例。for循环从数据库中查询数据集合,而后再次封装新的数据集合。若是内存不足以存储,JVM将回收再也不使用的数据。所以,若是所需的存储空间很大,您可能会收到CPU使用率警报。
不时。
若是经过jstack检查系统线程状态时线程总数很大,但处于Runnable和Running状态的线程数很少,则CPU使用率不必定很高。
我遇到过这样一种状况:系统线程的数量是1000+,其中超过900个线程处于BLOCKED和WAITING状态。该线程占用不多的CPU。
可是大多数状况下,若是线程数很大,那么常见的缘由是大量线程处于BLOCKED和WAITING状态。
不是。
高CPU使用率的关键因素是计算密集型操做。若是一个线程中有大量计算,则CPU使用率也可能很高。这也是数据脚本任务须要在大规模集群上运行的缘由。
不会。
CPU使用率的飙升更可能是因为上下文切换或过多的可运行状态线程。处于阻塞状态的线程不必定会致使CPU使用率上升。
us
或sy
值很高,这意味着什么?您可使用命令查找CPU的值us
和sy
值top
,如如下示例所示:
us
:用户空间占用CPU的百分比。简单来讲,高咱们是由程序引发的。经过分析线程堆栈很容易找到有问题的线程。sy
:内核空间占用CPU的百分比。当sy为高时,若是它是由程序引发的,那么它基本上是因为线程上下文切换。
如何找出CPU使用率高的缘由?下面简要描述分析过程。
若是发现应用程序服务器的CPU使用率很高,请首先检查线程数,JVM,系统负载等参数,而后使用这些参数来证实问题的缘由。其次,使用jstack打印堆栈信息并使用工具分析线程使用状况(建议使用fastThread,一个在线线程分析工具)。
如下是一个真实案例:
一天晚上,我忽然收到一条消息,说CPU使用率达到了100%。而后我用jstack导出了线程栈信息。
进一步检查日志:
onsumer_ODC_L_nn_jmq919_1543834242875 - priority:10 - threadid:0x00007fbf7011e000 - nativeid:0x2f093 - state:RUNNABLE stackTrace: java.lang.Thread.State:RUNNABLE at java.lang.Object.hashCode(Native Method) at java.util.HashMap.hash(HashMap.java:362) at java.util.HashMap.getEntry(HashMap.java:462) at java.util.HashMap.containsKey(HashMap.java:449) at com.project.order.odc.util.XmlSerializableTool.deSerializeXML(XMLSerializableTool.java:100) at com.project.plugin.service.message.resolver.impl.OrderFinishMessageResolver.parseMessage(OrderFinishMessageResolver.java:55) at com.project.plugin.service.message.resolver.impl.OrderFinishMessageResolver.parseMessage(OrderFinishMessageResolver.java:21) at com.project.plugin.service.message.resolver.impl.AbstractResolver.resolve(AbstractResolver.java:28) at com.project.plugin.service.jmq.AbstractListener.onMessage(AbstractListener.java:44)
如今经过这个日志找到了问题:用于反序列化MQ消息实体的方法致使CPU使用率飙升。