動輒就是閱讀Spring源碼或者jvm調優？

本回答參考了幾個網頁的案例。

不知道您有沒有聽過扁鵲三兄弟的故事，故事是這樣的：魏文王問扁鵲：你們三兄弟都精通醫術，誰是醫術最好的呢？扁鵲回答：大哥最好，二哥次之，我最差。魏文王不解的問：為什么這樣說呢？扁鵲答：大哥治病是在病人發作之前，那時候病人自己不覺得有病，但大哥就下藥鏟除了病根，使他的醫術難以被人認可，所以沒有名氣；二哥治病是在病起之初，癥狀尚不十分明顯，病人也沒有覺得痛苦，二哥就能藥到病除，所以大家的印象就是小病找二哥；我治病是在病人危急時刻，病人痛苦萬分，家人心急如焚，他們看到我治病時在經脈上扎針穿刺，或以毒試毒，或動大手續使病人減輕痛苦直至痊愈，所以我聞名天下。魏文王大悟。

為什么要講這個故事呢？因為JVM調優跟這個故事很像。

對應的JVM調優，也有這三個階段：

1.在項目部署到線上之前，基于可能的并發量進行預估調優。

2.在項目運行過程中，部署監控收集性能數據，平時分析日志進行調優。

3.線上出現OOM(out of memory)，進行問題排查與調優。

綜合起來說，遇到以下情況，就需要考慮進行JVM調優了：

Heap內存（老年代）持續上漲達到設置的最大內存值；Full GC 次數頻繁；GC 停頓時間過長（超過1秒）；應用出現OutOfMemory 等內存異常；應用中有使用本地緩存且占用大量內存空間；系統吞吐量與響應性能不高或下降。

簡單總結一下JVM調優的三個最主要目標：

一、防止出現OOM

即在系統部署之前，根據一些關鍵數據進行預估不同內存區域需要給多少內存合適

二、解決OOM

即線上出現了OOM，應該如何調優以保證程序能正常運行

二、減少full gc出現的頻率

這個主要是堆區，如果設置的不合理就會頻繁full gc，導致系統運行一陣暫停一陣，導致體驗下降。

所以對于一個項目的架構師來說，比方說一個電商系統，一個電子政務系統，一個企業ero系統，根據其業務運行模式的不同，就有不同的調優目標。

而對于一個項目的架構師來說，JVM調優是一個手段，但并不一定所有問題都可以通過JVM進行調優解決，因此，在進行JVM調優時，我們要遵循一些原則：

大多數的Java應用不需要進行JVM優化；大多數導致GC問題的原因是代碼層面的問題導致的（代碼層面）；上線之前，應先考慮將機器的JVM參數設置到最優；減少創建對象的數量（代碼層面）；減少使用全局變量和大對象（代碼層面）；優先架構調優和代碼調優，JVM優化是不得已的手段（代碼、架構層面）；分析GC情況優化代碼比優化JVM參數更好（代碼層面）；

通過以上原則，我們發現，其實最有效的優化手段是架構和代碼層面的優化，而JVM優化則是最后不得已的手段，也可以說是對服務器配置的最后一次“壓榨”。