程式員必須掌握的性能調優 X Y Z

性能調優，是從開發崗躍遷至架構崗的攔路虎。升級思維的過程是痛苦的，尤其是在背負壓力下的被動升級，跳出原先的舒適區，進入更大的舒適區，這樣才能站上新平面。記得當時老兵哥我還有不少負面情緒，回顧過往才懂得要感謝當時的領導給我這份壓力，逼迫我高強度學習並突破了舊的思維，機會和挑戰是並存的。 ...

熱評博文：《如何設計出優美的Web API？》，現閱讀量超 2500，小伙伴們不要錯過哦！

2003 ~ 2008 年，這五年老兵哥我在通信行業做實習生和開發崗，主要用 C / C++ / MFC 開發嵌入式 / 伺服器 / 桌面等應用程式，期間做過大量代碼重構優化，但很少涉及性能調優，要麼我負責的局部無需考慮併發訪問和海量數據，要麼網管平臺僅供客戶內部人員使用，不存在併發訪問和海量數據。2008 年底，老兵哥我跳槽到了移動互聯網做技術經理，隨後五年主要用 Java / C++ 開發 Web / 伺服器等互聯網應用。

當時，架構師這個崗位在業界還是很罕見的，不懂預估併發用戶、業務數據等規模，自然就預見不到後續併發訪問和海量數據會帶來巨大的性能挑戰。我們趕著工期把功能需求實現、業務流程跑通，然後就上線了，但移動互聯網爆發的那些年業務增長非常快，系統上線不久就遇到性能問題了，其現象就是原來耗時很短的操作現在動不動就超時，或者界面刷不出來數據等等，巨大的壓力跟著客戶投訴一起擺到了我面前。

性能調優任務不像普通開發任務，它需要背負業務、時間和難度等多種壓力。羅馬不是一天建成的，導致性能問題的原因錯綜複雜，當時老兵哥我也不知道從何處下手，找不到解決問題的切入點。好性能不是調優出來的，更多是設計出來的。只有經歷過性能調優，才能體會這句話的真諦。性能調優，其實就是對承載業務的現網系統做重構優化，就像是邊開車邊換輪胎，它所需要的技能跟代碼重構完全不在一個層級上。

現在老兵哥我知道，性能是系統性問題，性能調優離不開架構視角。不識廬山真面目，只緣身在此山中。當你陷在具體的、局部的問題當中，你是無法找到解決問題的思路的。你必須從實現細節跳脫出來，從更加巨集觀全局的視角來梳理業務流程，就像文末鏈接的系列文章《圖解 Spring Cloud：HTTP 請求的處理流程與機制》的剖析過程類似，然後以業務流程為線索分析每個環節存在的性能瓶頸原因，這樣你就不再困惑了。

當每個環節潛在問題梳理出來之後，根據資源、時間等外部限制，按照帕累托二八原則，你可以決定優先解決哪些問題，從而有條不紊地化解性能壓力了。隨著在性能調優上的經驗不斷豐富，你就越來越有信心掌控更大規模的系統了。更值得高興的是，當你費老牛勁把這些自己挖的巨坑填上後，你就記得下次不要再給自己挖坑了，也就懂得怎樣設計一個高性能的互聯網系統了，這不就是從開發躍遷至架構的契機嗎？

性能調優，是從開發崗躍遷至架構崗的攔路虎。升級思維的過程是痛苦的，尤其是在背負壓力下的被動升級，跳出原先的舒適區，進入更大的舒適區，這樣才能站上新平面。記得當時老兵哥我還有不少負面情緒，回顧過往才懂得要感謝當時的領導給我這份壓力，逼迫我高強度學習並突破了舊的思維，機會和挑戰是並存的。性能優化是一個不斷迭代、持續進行的過程，涉及軟體開發生命周期的所有階段，對於某款採用 Hibernate 作為持久層框架的 Java EE 典型應用程式，性能優化會涉及以下幾個方面：

性能調優

業務規則調優，包括業務流程、交互設計等
應用容器調優，包括啟動參數、連接數和線程數等
Spring 調優，包括事務管理、二級緩存等
Hibernate 調優，包括批量操作、抓取策略和緩存等
資料庫調優，包括索引、SQL 語句和配置等
JVM 調優，包括記憶體、垃圾回收 GC等
底層系統調優，包括操作系統、硬體等

如果對上述性能優化方向做些分類歸併，我們可以採用下列分類維度來看：

X 維度，即業務維度，技術始終是服務業務的，任何技術問題的原點就是業務需求。在啟動技術層面的性能優化之前，我們有必要先審視一下業務流程是否合理，交互設計上有沒有可以優化的空間等。
Y 維度，待業務維度優化完畢，接下來就是審視技術在實現當前業務流程或交互設計的全鏈路上有沒有可優化的地方，即 HTTP 請求處理全流程，從瀏覽器到應用容器，再到 Spring、Hibernate、資料庫等。

維度Y

Z 維度，除了沿著 HTTP 請求的橫向鏈路，我們還要審視支持應用系統的縱向技術棧，從上到下包括 JVM、操作系統和硬體等，這是整套應用系統運行的環境，許多性能問題都跟運行環境存在關係。

維度Z

XYZ 維度分類是從不同層次梳理性能優化方向，有助於幫我們搭建起了性能優化的框架體系，這三個維度跟應用架構也是一一對應的。除了按照層次、縱橫分類之外，我們還可以按性能優化對象的粒度劃分，將優化範圍分為函數、模塊、框架、系統、鏈路和環境等等，從開發崗到架構師，我們就是要練就從小粒度到大粒度優化的能力，跳脫出原來的思維框架，站到更寬廣的視角來選擇優化路線。如果你沒有精心設計優化方案就開始上述調優，這將會是非常耗時的，而且很可能收效甚微。一個好的優化方案必然要為各種調優任務劃分優先順序，任何時候都不可能有足夠的時間和資金做全面優化，優先順序的判斷依據是投入產出比。在確定了優先順序之後，接下來我們就按照帕累托 Pareto 定律（即 80/20 法則）來選取調優任務，集中百分之八十的力量去改善應用程式中最影響性能的百分之二十的問題。

今天先分享到這裡，後續老兵哥我把這些調優經驗和架構視角梳理出來供大家參考。堅持技術寫作不容易，如果你覺得有價值，麻煩動動手指點下文「推薦」按鈕，讓更多小伙伴可以看到，我也會更加有動力堅持分享。另外，老兵哥我後續還會分享職業規劃、應聘面試、技能提升、影響力打造等經驗，歡迎關註本專欄或歪信公主號「 IT老兵哥」！

微信公眾號「 IT老兵哥」

關註「 IT老兵哥 」，賦能程式人生

軟技能-熱點文章：

硬技能-熱點文章：