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

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

為什麼要講這個故事呢？因為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最佳化則是最後不得已的手段，也可以說是對伺服器配置的最後一次“壓榨”。

前輩啊！冒昧問一句用的是delphi？

那個真是當年ms系統開發的大熱工具！

都知道BAT的工資高啊，所以都有這樣的心儀目標企業也是可以理解的！當然還算是一般的企業多！

第二 即使去不成大廠，為了自己的前途也是需要不斷進修的！

同時作為程式設計師，必須理解目標企業的喜好和需求啊！不是有那句話麼？

“選擇比努力更重要”

大廠喜歡什麼，那就按照他們的喜好來安排自己的學習計劃和學習路徑！好比備考的押題和體育的有針對性訓練一個道理！

第三 普通企業和小廠基本都是抄襲或者模仿大廠的規範和標準來招人的！因為很多HR根本就不專業，你讓他們按照自己企業的實際情況去寫招聘要求和對應憑著進行相關面試，他們哪有那個實力和耐心？