問題
無限回圈的while會導致CPU使用率飆升嗎？
經常使用Young GC會導致CPU占用率飆升嗎？
具有大量執行緒的應用程式的CPU使用率是否較高？
CPU使用率高的應用程式的執行緒數是多少？
處于BLOCKED狀態的執行緒會導致CPU使用率飆升嗎？
分時作業系統中的CPU是消耗us還是sy？
思路
1.如何計算CPU使用率？
CPU％= 1 - idleTime / sysTime * 100
復制代碼- idleTime：CPU空閑的時間
- sysTime：CPU處于用戶模式和內核模式的時間總和
2.與CPU使用率有關的是什么？
人們常說，計算密集型程式的CPU密集程度更高，
那么，JAVA應用程式中的哪些操作更加CPU密集？
以下列出了常見的CPU密集型操作：
- 頻繁的GC; 如果訪問量很高，可能會導致頻繁的GC甚至FGC，當呼叫量很大時，記憶體分配將如此之快以至于GC執行緒將連續執行，這將導致CPU飆升，
- 序列化和反序列化，稍后將給出一個示例：當程式執行xml決議時，呼叫量會增加，從而導致CPU變滿，
- 序列化和反序列化;
- 正則運算式， 我遇到了正則運算式使CPU充滿的情況; 原因可能是Java正則運算式使用的引擎實作是NFA自動機，它將在字符匹配期間執行回溯，我寫了一篇文章“ 正則運算式中的隱藏陷阱 ”來詳細解釋原因，
- 執行緒背景關系切換; 有許多已啟動的執行緒，這些執行緒的狀態在Blocked（鎖定等待，IO等待等）和Running之間發生變化，當鎖爭用激烈時，這種情況很容易發生，
- 有些執行緒正在執行非阻塞操作，例如while (true)陳述句，如果在程式中計算需要很長時間，則可以使執行緒休眠，
3. CPU是否與行程和執行緒相關？
現在，分時作業系統使用回圈方式為行程調度分配時間片，如果行程正在等待或阻塞，那么它將不會使用CPU資源，執行緒稱為輕量級行程，并共享行程資源，因此，執行緒調度在CPU中也是分時的，但在Java中，我們使用JVM進行執行緒調度，因此，通常，執行緒調度有兩種模式：時間共享調度和搶占式調度，
答案
1. while的無限回圈會導致CPU使用率飆升嗎？
是，
首先，無限回圈將呼叫CPU暫存器進行計數，此操作將占用CPU資源，那么，如果執行緒始終處于無限回圈狀態，CPU是否會切換執行緒？
除非作業系統時間片到期，否則無限回圈不會放棄占用的CPU資源，并且無限回圈將繼續向系統請求時間片，直到系統沒有空閑時間來執行任何其他操作，
2.頻繁的Young GC會導致CPU占用率飆升嗎？
是，
Young GC本身就是JVM用于垃圾收集的操作，它需要計算記憶體和呼叫暫存器，因此，頻繁的Young GC必須占用CPU資源，
讓我們來看一個現實世界的案例，for回圈從資料庫中查詢資料集合，然后再次封裝新的資料集合，如果記憶體不足以存盤，JVM將回收不再使用的資料，因此，如果所需的存盤空間很大，您可能會收到CPU使用率警報，
3.具有大量執行緒的應用程式的CPU使用率是否較高？
不時，
如果通過jstack檢查系統執行緒狀態時執行緒總數很大，但處于Runnable和Running狀態的執行緒數不多，則CPU使用率不一定很高，
我遇到過這樣一種情況：系統執行緒的數量是1000+，其中超過900個執行緒處于BLOCKED和WAITING狀態，該執行緒占用很少的CPU，
但是大多數情況下，如果執行緒數很大，那么常見的原因是大量執行緒處于BLOCKED和WAITING狀態，
4.對于CPU占用率高的應用程式，執行緒數是否較大？
不是，
高CPU使用率的關鍵因素是計算密集型操作，如果一個執行緒中有大量計算，則CPU使用率也可能很高，這也是資料腳本任務需要在大規模集群上運行的原因，
5.處于BLOCKED狀態的執行緒是否會導致CPU占用率飆升？
不會，
CPU使用率的飆升更多是由于背景關系切換或過多的可運行狀態執行緒，處于阻塞狀態的執行緒不一定會導致CPU使用率上升，
6.如果分時作業系統中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使用率飆升，
看完三件事??
如果你覺得這篇內容對你還蠻有幫助，我想邀請你幫我三個小忙：
-
點贊，轉發，有你們的 『點贊和評論』，才是我創造的動力，
-
關注公眾號 『 java爛豬皮 』，不定期分享原創知識，
-
同時可以期待后續文章ing??
出處：club.perfma.com/article/186…
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/182749.html
標籤：其他