JVM 對 Java 有多重要，對程式設計師面試有多重要，這些不用多說。
如果你還沒意識到學 JVM 的必要性，或者不知道怎麼學 JVM，那麼看完這篇文章，你就能知道答案了。
曾經的我很不屑於學 JVM，但是後來發現不學不行。這就像和媳婦吵架之後我不想道歉一樣，不道歉那是不可能的，道歉是早晚的事兒，逃不掉。
後來我明白了：
認慫越晚，結局越慘。
但是我學的時候才知道：JVM，你太過分了，太難學了！
我的學習過程可以說非常坎坷，不過經歷坎坷之後，我倒是發現學 JVM 的門道很多。
以我的經驗加上和同行們的交流，我認為學 JVM 最好的方法是：
在程式設計師不同的水平段，做精準的學習。
所謂的精準學習，就是學習對自己工作有巨大幫助的知識點。以工作內容帶動學習，等到積累多了，再一舉攻克所有 JVM 知識點，最終熟練掌握 JVM 底層原理。
下面我來說說初級、高階、資深程式設計師，如何循序漸進、分步學習。
初級程式設計師怎麼學
對剛入行的新手程式設計師，工作一般是修復簡單 bug、開發簡單功能。如何編碼少出 bug，是這個階段的核心問題。
對於這個核心問題，JVM 原理必須深入掌握兩個知識點。
1. 類的初始化
類的初始化，要了解的非常深入才可以。否則，一不留神就會往專案裡引入一些有關初始化的 bug。
比如看看下面這段程式碼：
public class ParentClass {
private int parentX;
public ParentClass() {
setX(100);
}
public void setX(int x) {
parentX = x;
}
}
public class ChildClass extends ParentClass{
private int childX = 1;
public ChildClass() {}
@Override
public void setX(int x) {
super.setX(x);
childX = x;
System.out.println("ChildX 被賦值為 " + x);
}
public void printX() {
System.out.println("ChildX = " + childX);
}
}
public class TryInitMain {
public static void main(String[] args) {
ChildClass cc = new ChildClass();
cc.printX();
}
}
有興趣可以執行看看結果，一旦把這種程式碼放到了生產環境裡，排查非常困難。
2. Java 記憶體結構和物件分配
第二個知識點，就是 Java 記憶體結構和物件分配的基礎知識，尤其是 JVM 記憶體中堆的佈局和物件分配的關係。
比如，堆記憶體的佈局
當然，Java7 後，新佈局變了
知道佈局了，就得知道java物件分配的基本原則：
- 物件優先在Eden區分配
- 物件太大直接會分配到老年代
只有知道這些知識，才不會經常寫下底下這種 bug：
// 將全部行數讀取的記憶體中
List<String> lines = FileUtils.readLines(new File("temp/test.txt"), Charset.defaultCharset());
for (String line : lines) {
// pass
}
上面這段程式碼，一旦讀取到了大檔案，很可能把生產環境搞崩。
所以，把上述兩個知識點深入理解了，對新手提升自己的程式碼質量非常非常有用。只有程式碼質量上去了，你才能得到更好的發展。
對於這兩個知識點，我認為通過網路的文章去學習最好。如果直接看書，有兩個最大的缺點：
- 知識積累不足導致學不懂
- 書中冗餘知識點太多，互相交雜，精力耗費過大，價效比不高
故這裡學習推薦根據知識點去搜文章讀，而不是找原理性的書籍看。
高階程式設計師怎麼學
對處於這個階段的朋友，他們已經可以熟練編寫健壯的程式碼了，經常會獨立開發出一個大的功能模組，有的可能還能獨立開發出一個完整的小型專案。
這時候，他們可能會面臨兩種情況：
1. 需要寫一些工具類給全團隊使用
在這種情況下，你很可能就需要 Java 中的語法糖，因為語法糖能讓你寫出非常靈活簡單的程式碼。這包括泛型，自動拆裝箱，可變引數還有遍歷迴圈。
但是，使用這些語法糖的時候，如果你不熟悉他們在 JVM 中的實現原理，就非常容易栽個大跟頭，
比如:
public class GenericPitfall {
public static void main(String[] args) {
List list = new ArrayList();
list.add("123");
List<Integer> list2 = list;
System.out.println(list2.get(0).intValue());
}
}
2. 編寫效能優越的程式碼
什麼時候需要效能優越的程式碼？最常見的就是把以前效能不好的同步實現，轉化成非同步實現。
而這種要求，就需要開發對 Java 的多執行緒開發非常熟悉，並且一定要深入理解多執行緒在 JVM 中的原理實現。
不然，可以看看下面這段程式碼：
class IncompletedSynchronization {
int x;
public int getX() {
return x;
}
public synchronized void setX(int x) {
this.x = x;
}
}
再看看這段：
Object lock = new Object();
synchronized (lock) {
lock = new Object();
}
如果把上面這些程式碼上了生產環境，熬通宵排查問題的命運就註定了……
這裡的知識點，我推薦通過網上的文章看，又因為涉及到了併發知識，我建議就著《Java Performance》第二版的“Chapter 9. Threading and Synchronization Performance”這章一起看。
還有餘力，建議再繼續看周志明的那本《深入理解 JAVA 虛擬機器》第三版中的 12-13 章。周志明這本書講的十分深入，也帶來個缺點：門檻高。此時，如果沒看懂可以放一放。
注意，我這裡說的是併發的原理，不是併發實踐，讀者想學併發程式設計，《JAVA 併發程式設計實踐》我認為是前提條件，故不會贅述。
資深程式設計師怎麼學
這時候的你，已經開始承擔專案開發中很重要的職責了，有些出色的朋友都開始帶團隊了。那這時候，你可能會做下面的事：
1. 合理規劃專案使用資源
合理規劃專案使用資源，前提是對垃圾回收有非常深入的瞭解。
如果說在新手期，已經對 Java 物件的記憶體分配和記憶體使用有了大致的概念，那麼，這個垃圾回收，則是這類知識的進一步擴充。
只有理解了各種垃圾回收的原理，再配合著 Java 記憶體佈局的基礎知識，才能更好地規劃出專案用什麼回收演算法，才能在合適的資源利用度上得到最佳效能。
比如，新生代和老年代之間的合適比例。比如，新生代中 Eden 和 Survivor 區域間的比例。
2. 排查各種線上問題
要排查各種問題，就需要對 JVM 提供的各種故障排查工具非常瞭解。
這些工具又分為兩類：
- 基礎的命令列形式的故障處理工具，比如 jps、jstack 等等
- 第二類是視覺化的故障處理工具，比如 VisualVM
但是，掌握工具的使用還不夠。因為有關垃圾回收的問題，還必須得通過解析 GC 日誌後，再通過工具的使用，才可能能定位到問題的根源。
所以，最好對使用故障排查工具和 GC 日誌都非常熟練。
比如：
2021-05-26T14:45:37.987-0200: 151.126:
[GC (Allocation Failure) 151.126: [DefNew: 629119K->69888K(629120K), 0.0584157 secs] 1619346K->1273247K(2027264K), 0.0585007 secs]
[Times: user=0.06 sys=0.00, real=0.06 secs]
2021-05-26T14:45:59.690-0200: 172.829:
[GC (Allocation Failure) 172.829: [DefNew: 629120K->629120K(629120K), 0.0000372 secs]172.829: [Tenured: 1203359K->755802K(1398144K), 0.1855567 secs] 1832479K->755802K(2027264K), [Metaspace: 6741K->6741K(1056768K)], 0.1856954 secs]
[Times: user=0.18 sys=0.00, real=0.18 secs]
上面這條，應該一眼看出來，垃圾演算法用的是 Serial 收集器，並且年輕代分配出現了問題，大小可能需要調整。
這裡的知識點，強烈反對看網上的文章，網上說的很多細節有問題，疏漏很多。所以，推薦看書。
《Java Performance》第二版裡，“Chapter 5. An Introduction to Garbage Collection”，“Chapter 6. Garbage Collection Algorithms”的知識已經足夠。
有人去看《深入理解 JAVA 虛擬機器》第三版中的第 3 章，講垃圾收集器與記憶體分配策略的。這裡還是老問題，講的太細，我建議繞過 3.4 節，講 HotSpot 演算法細節的那塊兒。
這裡安全點這個知識點挺重要，但是現在這個階段想理解挺難的。我覺得將來做一些底層框架，接觸到崩潰恢復的 checkpoint 相關思想了，再回頭來學習，那才能真正理解和掌握。
技術專家怎麼學
達到這個級別了，那就需要對整套 JVM 要有非常深入的瞭解了，因為你是解決技術問題的最後保障了。有些時候，甚至還需要因為某些問題開發出各種各樣的工具。
曾經，有個專案時不時總是會報錯：
java.lang.OutOfMemoryError: GC overhead limit exceeded
這個問題幾個同事都沒搞定，就來找我。我看了看，突然想起來，以前在官方調優指南《HotSpot Virtual Machine Garbage Collection Tuning Guide》看到過相關介紹。
JVM 本身記憶體不足就會執行 GC，但是如果每次 GC 回收的記憶體不夠，那麼很快就會開始下一次 GC。
JVM 有個預設的保護機制，如果發現在一個統計週期內，98% 的時間都是在執行 GC，記憶體回收卻少於 2% 的時候，就會報這個錯。
怎麼引起的呢？這個問題如果去排查程式碼，那真的是難如登天，首先，沒有任何堆疊錯誤去幫助定位問題。其次，專案程式碼量大了去了，而且是年頭久遠。
這時，就需要通過對 JVM 總體的深入理解，去反推問題了。我當時是這樣推理的：
記憶體溢位，GC 無法回收問題，說明了兩個問題：
- 堆內的記憶體不夠用了
- 佔用記憶體的物件要麼就是該關閉的資源沒有關閉，要麼被大量的暫時放在一起了
那如果我 dump 出記憶體檔案出來，再分析下就知道是哪些物件在佔用記憶體了。
一查發現是大量的字串在佔用記憶體。
綜合我前面的推測，字串不是資料庫連線，肯定沒有該關閉未關閉的問題。那就剩一個可能了，就是被大量的暫時放起來了，導致 GC 回收不了。
那麼新問題來了，能大量放字串的，會是什麼？
首先就去猜快取。根據這條線索，直接去原始碼搜 Cache 關鍵詞，把所有關於 Cache 的程式碼都看了下。一下子就找到問題了。
原來，我們有個功能是解析一個非常大的檔案。檔案的格式如下：
需要把這個檔案的每一行內容按照列去一起存到資料庫裡。
由於寫程式碼的人偷懶，想一次解析完畢後一股腦全塞到資料庫裡。所以，他弄了個 Map，Map 的 Key 是相同的列名，Value是每一行解析過的內容。
而這樣寫程式碼的結果就是，一行對應了一個有三個條目的 HashMap。如果檔案有十幾萬行，就有十幾萬的 HashMap。然後，這些 HashMap 再存到一個列表裡，再把這個列表放到一個叫做 xxxCache 的 HashMap 中。
示意程式碼如下：
public class ParseFile4OOM {
public static void main(String[] args) {
List<Map<String, String>> lst = new ArrayList<>();
for (int i = 0; i < 100000; i++) {
Map<String, String> map = new HashMap<>();
map.put("Column1", "Content1");
map.put("Column2", "Content2");
map.put("Column3", "Content3");
lst.add(map);
}
Map<String, List<Map<String, String>>> contentCache = new HashMap<>();
contentCache.put("contents", lst);
}
}
那對這種情況怎麼辦呢？程式碼還不能大動，只能優化。
那時，我們已經用了 JDK8 了，引入了 String 常量池。同時，Hashmap 在這個業務場景下，容積是固定的，所以，就不應該給它多分配空間，就固定死為 3。
優化後，程式碼如下：
public class ParseFile4OOM {
public static void main(String[] args) {
List<Map<String, String>> lst = new ArrayList<>();
for (int i = 0; i < 100000; i++) {
Map<String, String> map = new HashMap<>(3);
map.put("Column1".intern(), "Content1".intern());
map.put("Column2".intern(), "Content2".intern());
map.put("Column3".intern(), "Content3".intern());
lst.add(map);
}
Map<String, List<Map<String, String>>> contentCache = new HashMap<>();
contentCache.put("contents".intern(), lst);
}
}
把優化後的程式碼上線，錯誤搞定了！
所以，在這個階段就非得把 JVM 吃透不可了。吃透原理就必須靠看書了。
周志明的《深入理解 JAVA 虛擬機器》是必須的了，但是還不夠。
《Oracle JRockit: The Definitive Guide》這本書我也建議讀一讀，雖然老了，但是裡面的很多內容，尤其前四章，對 JVM 原理真的快講透了。對 JVM 是如何彈性伸縮去平衡資源和效能關係的，娓娓道來，讓我醍醐灌頂，程式設計視野一下子開啟了很多。
至此，不同階段的學習方法講完了。
總的來說，JVM 知識廣博複雜，如果想要掌握，不能一蹴而就。而且我們們程式設計師不容易，需要學的知識太多，然而我們們的精力卻是有限的。
所以，對於 JVM 原理來說，假設有些知識點眼前看不懂，用不上，可以先暫時放一放，做到精準學習，把省下來的精力用在別的知識甚至自己的生活上，更有意義。
看完如果覺得有收穫，希望能隨手點個贊。
你好，我是四猿外。
一家上市公司的技術總監，管理的技術團隊一百餘人。
我從一名非計算機專業的畢業生，轉行到程式設計師，一路打拼，一路成長。
我會把自己的成長故事寫成文章，把枯燥的技術文章寫成故事。
歡迎關注我的公眾號。
