三言兩語說透設(shè)計模式的藝術(shù)-簡單工廠模式
一、寫在前面工廠模式是最常見的一種創(chuàng)建型設(shè)計模式，通常說的工廠模式指的是工廠方法模式，是使用頻率最高的工廠模式。簡單工廠模式又稱為靜態(tài)工廠方法模式，不屬于GoF 23種設(shè)計
好久沒寫技術(shù)文章了，今天下班“早”，簡單叨叨一篇。
早下班的原因說起來也有點搞笑，是因為健身時候杠鈴把手上砸了個口子。砸傷當時我看了一眼，雖然很痛但骨頭沒事，竟然心中還有一絲慶幸。縫針吧，有點夸張，不處理吧，還挺深。于是，我在從醫(yī)院處理完傷口后，有了這篇文章。
好了，言歸正傳。
市面上通常對于 CPU 問題排查的案例面試比較少，基本上都在講：如果 CPU 升到 100% 怎么辦？
這確實是個高頻問題，必須需要流利回答。之前也寫過一篇文章，可以參考：
圖片
重點問題！CPU利用率過高排查思路｜原創(chuàng)
這是一個今天發(fā)生的真實案例（相關(guān)信息已脫敏處理，不影響案例本質(zhì)）。
問題如下：這是一個比較大項目改動，改造的過程中涉及到了相當多下游接口的改動和相當多的依賴包。今天在上線發(fā)布后經(jīng)過接口和功能驗證，需求發(fā)布成功。
但是接著，我發(fā)布完成后才發(fā)現(xiàn)機器的平均 CPU 負載升高，平均 CPU 負載幾乎升高了有 5-8 %，最高負載更是超過了 CPU 安全水位線。如此多的改動，到底是什么導(dǎo)致了 CPU 負載的上升？
我自己用 python 花了張圖，大概下面這個樣子
圖片
問題出現(xiàn)，CPU 升高
快速處理： 我先快速對比了一下 CPU 負載升高的時間點，和發(fā)布時間基本對應(yīng)，基本可以判斷是本次發(fā)布引起的。雖然并沒有影響到業(yè)務(wù)，但是發(fā)現(xiàn)問題后，我還是第一時間做了回滾處理。
注意：發(fā)布過程中出現(xiàn)任何問題不要想排查問題原因，直接回滾，血淚教訓的鐵律
我排查問題的思路如下：
問題引入的依賴有很多，到底是哪個依賴引入的？我難道一個個下掉去排查嗎？
排除法，這也確實是一種辦法，只不過是太辛苦了，事倍功半。更不用說還需要下掉相關(guān)代碼，還得不斷去耗時發(fā)布，實在是繁瑣。
怎么辦呢？不賣關(guān)子了，直接上 Arthas。
Arthas 使用 async-profiler 生成 CPU/內(nèi)存火焰圖進行性能分析，彌補了之前內(nèi)存分析的不足。
async-profiler 是一款開源的 Java 性能分析工具，原理是基于 HotSpot 的 API，以微乎其微的性能開銷收集程序運行中的堆棧信息、內(nèi)存分配等信息進行分析。
官網(wǎng)：https://github.com/async-profiler/async-profiler
我們常用的是 CPU 性能分析和 Heap 內(nèi)存分配分析。在進行 CPU 性能分析時，僅需要非常低的性能開銷就可以進行分析。
在進行 Heap 分配分析時，async-profiler 工具會收集內(nèi)存分配信息，而不是去檢測占用 CPU 的代碼。async-profiler 不使用侵入性的技術(shù)，例如字節(jié)碼檢測工具或者探針檢測等，這也說明 async-profiler 的內(nèi)存分配分析像 CPU 性能分析一樣，不會產(chǎn)生太大的性能開銷，同時也不用寫出龐大的堆棧文件再去進行進一步處理，。
async-profiler 工具在采樣后可以生成采樣結(jié)果的日志報告，也可以生成 SVG 格式的火焰圖。
圖片
具體使用大家直接去官網(wǎng)看文檔吧，有不懂留言。我這里直接說使用
進入測試服務(wù)器控制臺，使用 JPS 命令查看 PID 信息。
? develop jps2800 Jps528 TestCode2450 Launcher假設(shè)運行程序的名是 TestCode，可以看到對應(yīng)的 PID 是 528。
使用下面命令：
./profiler.sh -d 20 -f 528.svg 528對 528 號進程采樣20秒，然后得到生成的 528.svg 文件，然后我們使用瀏覽器打開這個文件，可以看到 CPU 的使用火焰圖，如下（這里用網(wǎng)絡(luò)圖片代替）：
圖片
關(guān)于火焰圖怎么看，一言以蔽之：火焰圖里，橫條越長，代表使用的越多，從下到上是調(diào)用堆棧信息。 在這個圖里可以看到 main 方法上面的調(diào)用中 hotmethod3 方法的 CPU 使用是最多的，點擊這個方法。還可能看到更詳細的信息。
那么我們現(xiàn)在只需要查找 hotmethod3 使用的地方在哪里，就可以定位到問題代碼。
當然，上面的是個代替 case，告訴你怎么看這個火焰圖。真實的 case 要比這個更難排查。如下圖，問題代碼是個線程，是由某個類調(diào)用的：
圖片
問題代碼是一個 Thread 的 run 方法引起的，那么是誰調(diào)用的他呢？這個類的信息我打碼了，假設(shè)為 ClassA。
但是排查代碼，ClassA 根本沒有被項目代碼直接的調(diào)用，于是我找到了這個 CalssA 所屬的依賴包 dep-demoA，看他是誰引入的。
./gradlew :項目名:dependencyInsight --dependency dep-demoA這個命令會打出一個項目的依賴樹，結(jié)果如下：
+--- com.ali:dep-demoA:1.0.0 (*)/--- com.ali:dep-demoB:1.0.0 /--- com.ali:dep-demoC:1.0.0如上結(jié)果，項目中我是用的是 dep-demoC，結(jié)果他同時引入了 dep-demoB，我看了下這個 demoB，他很可能會跟 arthas 類似，通過 Java Agent技術(shù)和字節(jié)碼增強技術(shù)以實現(xiàn)一定的功能，這對程序是非常有損耗的。（所以線上不能開 arthas）
嘗試排除 demoB，代碼如下：
all*.exclude group: "com.ali", module: "dep-demoB"然后重啟項目，CPU 負載下降，回歸到正常水平，問題解決。
圖片
本文鏈接：http://www.www897cc.com/showinfo-26-92746-0.html大廠真實案例，CPU 升高問題如何排查？五分鐘掌握
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 避免刪庫跑路的辦法，你知道嗎？
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號