Find N3入網：最高支持16+1TB
OPPO將于近期登場的Find N3折疊屏目前已經正式入網，型號為PHN110。本次Find N3在外觀方面相比前兩代有很大的變化，不再是小號的橫向折疊屏，而是跟別的廠商一樣采用了較為常見的
在實際工作中，可能每個開發都寫過死循環的代碼。
死循環有兩種：
這兩種情況，程序會不停地運行，使用寄存器保存循環次數或者遞歸深度，一直占用 cpu，導致 cpu 使用率飆升。
在使用 JDK1.7 時，還有些死循環比如多線程的環境下，往 HashMap 中 put 數據，可能會導致鏈表出現死循環。
就會導致cpu不斷飆高。
我之前參與過餐飲相關的業務系統開發，當時我所在的團隊是菜品的下游業務。
當時菜品系統有菜品的更新，會發kafka消息，我們系統訂閱該topic，就能獲取到最近更新的菜品數據。
同步菜品數據的功能，上線了一年多的時候，沒有出現過什么問題。
但在某一天下午，我們收到了大量 CPU100% 的報警郵件。
追查原因之后發現，菜品系統出現了 bug，我們每次獲取到的都是全量的菜品數據，并非增量的數據。
一次性獲取的數據太多。
菜品修改還是比較頻繁的，也就是說我們系統，會頻繁地讀取和解析大量的數據，導致 CPU 不斷飆升。
其根本原因是頻繁的full gc。
有時候，我們的業務系統需要實時計算數據，比如：電商系統中需要實時計算優惠后的最終價格。
或者需要在代碼中，從一堆數據中，統計匯總出我們所需要的數據。
如果這個實時計算或者實時統計的場景，是一個非常耗時的操作，并且該場景的請求并發量還不小，就可能會導致 cpu 飆高。
因為實時計算需要消耗 cpu 資源，如果一直計算，就會一直消耗 cpu 資源。
為了防止并發場景中，多個線程修改公共資源，導致的數據異常問題，很多時候我們會在代碼中使用synchronized或者Lock加鎖。
這樣多個線程進入臨界方法或者代碼段時，需要競爭某個對象或者類的鎖，只有搶到相應的鎖，才能訪問臨界資源。其他的線程，則需要等待，擁有鎖的線程釋放鎖，下一次可以繼續競爭那把鎖。
有些業務場景中，某段代碼需要線程獲取多把鎖，才能完成業務邏輯。
但由于代碼的 bug，或者釋放鎖的順序不正確，可能會引起死鎖的問題。
例如：
"pool-4-thread-1" prio=10 tid=0x00007f27bc11a000 nid=0x2ae9 waiting on condition [0x00007f2768ef9000]java.lang.Thread.State: WAITING (parking)at sun.misc.Unsafe.park(Native Method)- parking to wait for <0x0000000090e1d048> (a java.util.concurrent.locks.ReentrantLock$FairSync)at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)比如線程 a 擁有鎖 c，需要獲取鎖 d，才能完成業務邏輯。
而剛好此時線程 b 擁有鎖 d，需要獲取鎖 c，才能完成業務邏輯。
線程 a 等待線程 b 釋放鎖，而線程 b 等待線程 a 釋放鎖，兩個線程都持有對方需要的鎖，無法主動釋放，就會出現死鎖問題。
死鎖會導致 CPU 使用率飆升。
首先，使用top命令確認是不是Java進程是罪魁禍首。Java進程要么是個后臺任務，要么是個jar包，比如一個Spring Boot服務。
圖片
假設發現占用CPU 99.7%的線程是Java進程，進程PID為13731。
接下來，還是用top命令，只不過加一個參數-Hp，就是下面這樣：
top -Hp 13731H參數表示要顯示線程級別的信息，p則表示指定的pid，也就是進程ID。執行之后，這個Java進程中占用線程占用CPU的情況就列出來了。假設占用CPU最高的那個線程PID為13756。
圖片
這就要用到JDK默認提供的一個工具——jstack。jstack用于生成Java進程的線程快照（thread dump）。線程快照是一個關于Java進程中所有線程當前狀態的快照，包括每個線程的堆棧信息。通過分析線程快照，可以了解Java進程中各個線程的運行狀態、鎖信息等。
我們用jstack的目的是將那個占用CPU最高的線程的堆棧信息搞下來，然后進一步分析。使用命令jstack pid > out.log將某個進程的堆棧信息輸出到out.log文件中。
jstack 13731 > thread_stack.log將13756轉換為16進制，可以用在線進制轉換工具直接轉換，比如這個。轉換結果為0x35bc。
然后在線程棧中，也就是上一步保存的那個thread_stack.log文件，查找這個16進制的線程ID（0x35bc）。
這樣，我們就能看到需要的線程名稱、線程狀態，哪個方法的哪一行代碼消耗了最多的CPU都很清楚了。
圖片
Arthas是阿里開源的一款線上監控診斷產品，通過全局視角實時查看應用load、內存、GC、線程的狀態信息，并能在不修改應用代碼的情況下，對業務問題進行診斷，包括查看方法調用的入參、異常，監測方法執行耗時，類加載信息等，大大提升線上問題排查效率。
要使用Arthas，你需要先把它安裝到你的目標服務器上。
curl -O https://arthas.aliyun.com/arthas-boot.jarjava -jar arthas-boot.jar啟動之后，會列出當前這臺服務器上的所有Java進程，選擇你要排查的那個服務即可。出現arthas@之后表示已經啟動，并成功attach到目標進程上。
圖片
可以輸入命令dashboard看一下實時面板，默認5秒刷新一次，在這個面板上能夠看到線程、內存堆棧、GC和Runtime的基本信息。如果你用過VisualVM的話，操作界面與之類似。
執行thread命令，這個命令會顯示所有線程的信息，并且把CPU使用率高的線程排在前面。
這樣，一眼就看出來了，第一個線程的CPU使用率高達99%。
圖片
使用thread ID獲取堆棧信息，其實就是jstack pid相同的作用。通過前一步看到這個線程的ID是18，然后執行：
thread 18
圖片
直接就看出來了出現問題的位置，比如TestController.java文件的high方法的第23行。然后可以進入代碼查看具體問題。
面試官：“你碰到過CPU 100%的情況嗎？你是怎么處理的？”
生產環境如果cpu已經被打滿了，不要一上來就說什么top，jstack，記住，真實的生產環境如果CPU已經要被打爆了的話
第一選擇肯定是重啟，并且如果你近段時間有發布的話，還要考慮是否可以回滾，保障生產環境的穩定性是最重要的
還有就是，如果CPU已經被打爆了，不管arthas還是jstack大概率也是執行不了的，jvm無法響應
我：“之前碰到過CPU被打滿的情況，我們線上第一時間做了重啟，在重啟的過程中，我們去查了服務在那段時間的日志、鏈路、指標，沒有發現特殊的異常。”
有時候CPU100&會伴隨非常明顯的日志、鏈路或者指標異常。例如：通過gc的指標發現，發現full gc的次數激增，或者發現內存的使用率很高，這個時候大概率是因為gc導致的cpu 100%。這個時候就不要再去jstack了，應該第一次時間查看堆dump文件，確認是哪個對象占用了大量內存
我：“當服務重啟完成后，我們開始排查具體的原因。我們通過定期執行top命令，發現java進程的CPU的使用率確實在慢慢增加”
我：“接著，我通過top -Hp以及jstack命令拿到了應用里cpu使用率最高的那個線程的堆棧，通過分析堆棧最終定位到了具體的代碼，是因為代碼觸發了一個臨界值，進入了死循環”
下面這段代碼是我實際工作碰到一個導致線上CPU 100%的代碼：
public ShortUrlRandomSeed getAvailableSeed() { MachineInfo machineInfo = UrlConverUtil.getMachineInfo(); for (; ; ) { // 獲取種子 ShortUrlRandomSeed seed = shortUrlSeedService.getAvailableSeed(machineInfo); if (seed != null) { int influenceNum = shortUrlSeedService.updateSeedStatus(seed.getId()); if (influenceNum > 0) { return seed; } } }}這段代碼的作用是為了獲取一個種子用于短鏈的生成，在項目上線之初預生成了接近21w個種子，這個代碼在線上跑了3年了一直沒有問題，直到去年的某一天，21w個種子用光了，seed一直為null，開始死循環，最終導致CPU 100%
本文鏈接：http://m.www897cc.com/showinfo-26-91012-0.html美團一面，你碰到過CPU 100%的情況嗎？你是怎么處理的？
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 機械師 10 周年：科技致敬時光，旗艦 mini GTX 上市熱銷
下一篇： 分布式一致性必備：一文讀懂Raft算法
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號