while循环CPU占用率高问题深入分析与解决方案

直接上一个工作中碰到的问题，另外一个系统开启多线程调用我这边的接口，然后我这边会开启多线程批量查询第三方接口并且返回给调用方。使用的是两三年前别人遗留下来的方法，放到线上后发现确实是可以正常取到结果，但是一旦调用，CPU占用就直接100%(部署环境是win server服务器)。因此查看了下相关的老代码并使用JProfiler查看发现是在某个while循环的时候有问题。具体项目代码就不贴了，类似于下面这段代码。

while(flag) {//your code;}

这里的flag可能是true或者是某个需要很长时间才能跳出这个循环的条件。

先放上我的解决方法，上述代码修改如下：

while(flag) {Thread.sleep(1);//your code;}

之后CPU占用率就正常了。其实这里面涉及到的知识点很多，我在网上也查了一些资料，现在分析下这个问题的原因以及相关解决方案。

为什么上述while循环会使得CPU占用率很高呢

这里就涉及到了操作系统的知识：操作系统中，CPU竞争有很多种策略。Unix系统使用的是时间片算法，而Windows则属于抢占式的。
在时间片算法中，所有的进程排成一个队列。操作系统按照他们的顺序，给每个进程分配一段时间，即该进程允许运行的时间。如果在时间片结束时进程还在运行，则CPU将被剥夺并分配给另一个进程。如果进程在时间片结束前阻塞或结束，则CPU当即进行切换。调度程序所要做的就是维护一张就绪进程列表，，当进程用完它的时间片后，它被移到队列的末尾。
所谓抢占式操作系统，就是说如果一个进程得到了 CPU 时间，除非它自己放弃使用 CPU ，否则将完全霸占 CPU 。因此可以看出，在抢占式操作系统中，操作系统假设所有的进程都是“人品很好”的，会主动退出 CPU 。在抢占式操作系统中，假设有若干进程，操作系统会根据他们的优先级、饥饿时间（已经多长时间没有使用过 CPU 了），给他们算出一个总的优先级来。操作系统就会把 CPU 交给总优先级最高的这个进程。当进程执行完毕或者自己主动挂起后，操作系统就会重新计算一次所有进程的总优先级，然后再挑一个优先级最高的把 CPU 控制权交给他。
我们用分蛋糕的场景来描述这两种算法。假设有源源不断的蛋糕（源源不断的时间），一副刀叉（一个CPU），10个等待吃蛋糕的人（10 个进程）。
如果是 Unix操作系统来负责分蛋糕，那么他会这样定规矩：每个人上来吃 1 分钟，时间到了换下一个。最后一个人吃完了就再从头开始。于是，不管这10个人是不是优先级不同、饥饿程度不同、饭量不同，每个人上来的时候都可以吃 1 分钟。当然，如果有人本来不太饿，或者饭量小，吃了30秒钟之后就吃饱了，那么他可以跟操作系统说：我已经吃饱了（挂起）。于是操作系统就会让下一个人接着来。
如果是 Windows 操作系统来负责分蛋糕的，那么场面就很有意思了。他会这样定规矩：我会根据你们的优先级、饥饿程度去给你们每个人计算一个优先级。优先级最高的那个人，可以上来吃蛋糕——吃到你不想吃为止。等这个人吃完了，我再重新根据优先级、饥饿程度来计算每个人的优先级，然后再分给优先级最高的那个人。
这样看来，这个场面就有意思了——可能有些人是PPMM，因此具有高优先级，于是她就可以经常来吃蛋糕。可能另外一个人是个丑男，而去很ws，所以优先级特别低，于是好半天了才轮到他一次（因为随着时间的推移，他会越来越饥饿，因此算出来的总优先级就会越来越高，因此总有一天会轮到他的）。而且，如果一不小心让一个大胖子得到了刀叉，因为他饭量大，可能他会霸占着蛋糕连续吃很久很久，导致旁边的人在那里咽口水。。。
而且，还可能会有这种情况出现：操作系统现在计算出来的结果，5号PPMM总优先级最高，而且高出别人一大截。因此就叫5号来吃蛋糕。5号吃了一小会儿，觉得没那么饿了，于是说“我不吃了”（挂起）。因此操作系统就会重新计算所有人的优先级。因为5号刚刚吃过，因此她的饥饿程度变小了，于是总优先级变小了；而其他人因为多等了一会儿，饥饿程度都变大了，所以总优先级也变大了。不过这时候仍然有可能5号的优先级比别的都高，只不过现在只比其他的高一点点——但她仍然是总优先级最高的啊。因此操作系统就会说：5号mm上来吃蛋糕……（5号mm心里郁闷，这不刚吃过嘛……人家要减肥……谁叫你长那么漂亮，获得了那么高的优先级）。

相关的解决方案及分析：

除了这里使用的Thread.sleep(1)，相关的还有Thread.sleep(0) Thread.yeild()

Thread.Sleep 函数是干吗的呢？还用刚才的分蛋糕的场景来描述。上面的场景里面，5号MM在吃了一次蛋糕之后，觉得已经有8分饱了，她觉得在未来的半个小时之内都不想再来吃蛋糕了，那么她就会跟操作系统说：在未来的半个小时之内不要再叫我上来吃蛋糕了。这样，操作系统在随后的半个小时里面重新计算所有人总优先级的时候，就会忽略5号mm。Sleep函数就是干这事的，他告诉操作系统“在未来的多少毫秒内我不参与CPU竞争”。

现在有两个问题：

1.如果我调用一下 Thread.sleep(1000) ，一秒后，这个线程会不会被唤醒？
2.Thread.sleep(0) 。既然是 sleep 0 毫秒，那么他跟去掉这句代码相比，有什么区别？

对于第一个问题，答案是：不一定。因为你只是告诉操作系统：在未来的1000毫秒内我不想再参与到CPU竞争。那么1000毫秒过去之后，这时候也许另外一个线程正在使用CPU，那么这时候操作系统是不会重新分配CPU的，直到那个线程挂起或结束；况且，即使这个时候恰巧轮到操作系统进行CPU 分配，那么当前线程也不一定就是总优先级最高的那个，CPU还是可能被其他线程抢占去。
与此相似的，Thread有个Resume函数，是用来唤醒挂起的线程的。好像上面所说的一样，这个函数只是“告诉操作系统我从现在起开始参与CPU竞争了”，这个函数的调用并不能马上使得这个线程获得CPU控制权。

对于第二个问题，答案是：有，而且区别很明显。假设我们刚才的分蛋糕场景里面，有另外一个PPMM 7号，她的优先级也非常非常高（因为非常非常漂亮），所以操作系统总是会叫道她来吃蛋糕。而且，7号也非常喜欢吃蛋糕，而且饭量也很大。不过，7号人品很好，她很善良，她没吃几口就会想：如果现在有别人比我更需要吃蛋糕，那么我就让给他。因此，她可以每吃几口就跟操作系统说：我们来重新计算一下所有人的总优先级吧。不过，操作系统不接受这个建议——因为操作系统不提供这个接口。于是7号mm就换了个说法：“在未来的0毫秒之内不要再叫我上来吃蛋糕了”。这个指令操作系统是接受的，于是此时操作系统就会重新计算大家的总优先级——注意这个时候是连7号一起计算的，因为“0毫秒已经过去了”嘛。因此如果没有比7号更需要吃蛋糕的人出现，那么下一次7号还是会被叫上来吃蛋糕。

因此，Thread.Sleep(0)的作用，就是“触发操作系统立刻重新进行一次CPU竞争”。竞争的结果也许是当前线程仍然获得CPU控制权，也许会换成别的线程获得CPU控制权。这也是我们在大循环里面经常会写一句Thread.sleep(0) ，因为这样就给了其他线程比如Paint线程获得CPU控制权的权力，这样界面就不会假死在那里。末了说明一下，虽然上面提到说“除非它自己放弃使用 CPU ，否则将完全霸占 CPU”，但这个行为仍然是受到制约的——操作系统会监控你霸占CPU的情况，如果发现某个线程长时间霸占CPU，会强制使这个线程挂起，因此在实际上不会出现“一个线程一直霸占着 CPU 不放”的情况。至于我们的大循环造成程序假死，并不是因为这个线程一直在霸占着CPU。实际上在这段时间操作系统已经进行过多次CPU竞争了，只不过其他线程在获得CPU控制权之后很短时间内马上就退出了，于是就又轮到了这个线程继续执行循环，于是就又用了很久才被操作系统强制挂起。因此反应到界面上，看起来就好像这个线程一直在霸占着CPU一样。

Thread.Yeild()
Yield 的中文翻译为 “放弃”，这里意思是主动放弃当前线程的时间片，并让操作系统调度其它就绪态的线程使用一个时间片。但是如果调用 Yield，只是把当前线程放入到就绪队列中，而不是阻塞队列。如果没有找到其它就绪态的线程，则当前线程继续运行。

优势：比 Thread.Sleep(0) 速度要快，可以让低于当前优先级的线程得以运行。可以通过返回值判断是否成功调度了其它线程。

劣势：只能调度同一个处理器的线程，不能调度其它处理器的线程。当没有其它就绪的线程，会一直占用 CPU 时间片，造成 CPU 100%占用率

Thread.sleep(0)
　　sleep 的意思是告诉操作系统自己要休息 n 毫秒，这段时间就让给另一个就绪的线程吧。当 n=0 的时候，意思是要放弃自己剩下的时间片，但是仍然是就绪状态，其实意思和 Yield 有点类似。但是 sleep(0) 只允许那些优先级相等或更高的线程使用当前的CPU，其它线程只能等着挨饿了。如果没有合适的线程，那当前线程会重新使用 CPU 时间片。

优势：相比 Yield，可以调度任何处理器的线程使用时间片。
劣势：只能调度优先级相等或更高的线程，意味着优先级低的线程很难获得时间片，很可能永远都调用不到。当没有符合条件的线程，会一直占用 CPU 时间片，造成 CPU 100%占用率。

Thread.sleep(1)
该方法使用 1 作为参数，这会强制当前线程放弃剩下的时间片，并休息 1 毫秒（因为不是实时操作系统，时间无法保证精确，一般可能会滞后几毫秒或一个时间片）。但因此的好处是，所有其它就绪状态的线程都有机会竞争时间片，而不用在乎优先级。

优势：可以调度任何处理器的线程使用时间片。无论有没有符合的线程，都会放弃 CPU 时间，因此 CPU 占用率较低。
劣势：相比 Thread.sleep(0)，因为至少会休息一定时间，所以速度要更慢。

一般我会用Thread.sleep(1)

参考了两篇文章，写得很好，在这里贴出来。

理解Thread.sleep()函数

Thread.Sleep(0) vs Sleep(1) vs Yeild

while循环CPU占用率高问题深入分析与解决方案相关推荐

.net 软件 CPU 占用率高问题处理
.net 软件 CPU 占用率高问题处理一般这种都是因为代码问题导致的,比如最经典的就是死循环,而且循环体内,没有做任何的 CPU 抢占丢弃处理,往往这种代码极易引起 CPU 占用率狂飙. 如何 ...
性能优化之CPU占用率高（一）
文章部分摘于,点击查看原文当我们cpu使用率高的情况下会出现什么情况? 我们访问程序的速度比较慢,运行时间长. 系统崩溃,无法访问程序. 什么情况会导致Java应用程序的CPU使用率飙 ...
IDEA的CPU占用率高问题解决方法
前言:这段时间发现 IDEA 的 CPU 占用率猛涨,时不时就飙升到百分之7.80,使得敲代码的体验感十分不佳,在经过一番查找之后终于解决了问题,在此记录一下 IDEA的CPU占用率高问题解决方法问 ...
如何定位cpu占用率高的java线程
如何定位cpu占用率高的java线程工具: 1 jstack:jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息,如果是在64位机器上,需要指定选项&q ...
win10句柄数比win7多 cpu占用率高_Win10更新再出问题！CPU使用率高+损坏SSD，修复方法来了...
Win10的系统更新,真的是跟拆盲盒一样时刻面临着"惊喜". 毕竟,win10系统的更新出错,都不是一天两天的事情了,完全让人吃不消. 上次win10 2004号称最稳定的版本,乐 ...
Java CPU占用率高分析
首先,通过top命令找出CPU占用率高的进程: 然后,通过ps -o THREAD,tid,time -mp 2066命令找出执行时间最长的线程的TID 将有问题的TID转为16进制格式: print ...
一次服务器CPU占用率高的定位分析
背景通过性能监控发现上线服务器cpu某核占用率已经达到了100%,而且是由我们的某个核心服务导致的.幸亏由于我们的服务进程由多个相同worker(线程)调度承担的,所以除了CPU占用率高之外,并没有 ...
一次简单的服务器 cpu 占用率高的快速排查实战
前两天,朋友遇到一个线上 cpu 占用率很高的问题,我们俩一起快速定位并解决了这个问题.在征求朋友同意后,特发此文分享整个过程.本文以对话的形式展开,加上我的内心独白.文中对话与实际对话略有出入. 友 ...
原创|面试官：线上服务器CPU占用率高如何排查定位问题？
国外开发者平台 HankerRank 发布的 2018 年开发者技能调查报告中有一项关于"雇主最看重哪些核心能力"的调查,结果显示如下: 排名前几的比较受重视的能力分别为:解决问题 ...
netty cpu 占用率高_交换机CPU使用率高问题定位
诊断工具 display工具 log工具报文冲击导致的CPU使用率高问题 CPU使用率高问题信息采集诊断工具 display cpu-usage [ slot x ] display cpu-de ...

while循环CPU占用率高问题深入分析与解决方案

while循环CPU占用率高问题深入分析与解决方案相关推荐

最新文章

热门文章