Java自上世紀90年代問世以來，以其優良的特性，逐漸佔據了企業級開發的主流位置，並且日益強大的語言生態，更加鞏固了它在編程語言排行榜上的地位。
Java的快速發展，得益於支撐它運行的底層平臺：JVM，這個由C++編寫的虛擬機，有着一個抽象化的虛擬機體系結構，讓我們的Java程序得以“一次編寫，到處運行”，並且開發人員並不需要關心資源問題，JVM爲我們獨挑大樑。但是，正如周志明老師在《深入理解Java虛擬機》中所說：“Java與C++之間有一堵由內存動態分配和垃圾收集技術所圍成的「高牆」，牆外面的人想進去，牆裏面的人卻想出來”，技術總是讓你得到你想得到的，但你卻不得不丟棄一些東西。是的，在Java的道路上，“入之愈深，其進愈難，而其見愈奇”，當你在手舞足蹈地慶祝Java帶給你的便利的同時，你也可能苦惱於內存泄漏和溢出的問題，有道是人在JVM，身不由己。
枕邊的那本第一版《深入理解Java虛擬機》是我在大學時期買的，現在基本快翻爛了，記得剛畢業的時候，上下班兩個小時地鐵的通勤時間，總喜歡捧着它結合白天系統的問題尋找答案，那段時光，是我畢業之後最美好的回憶。依稀還記得技術生涯當中處理的第一個JVM問題，當時我的應用程序構建於JDK1.6，基於POI做了一個Excel報表導出的功能，第一次部署的時候使用的默認JVM參數，但是測試人員在點擊了一次導出之後，其他功能就疑似掛掉了，過了一會後才能正常使用；再點擊導出，又出現這個問題，查看堆棧發現錯誤信息：java.lang.OutOfmemoryError: PermGen Space，由於當時剛畢業，對於這種疑難問題沒有經驗，一時間慌了神，後面我猛然想起《深入理解Java虛擬機》中提到過類似的場景，在JDK1.6以及之前的版本中，常量池分配在永久代內，而導出Excel報表這個功能是會產生大量的字符串的，而字符串分配在字符串常量池，原來是一次導出產生的字符串撐爆了永久代！按照書裏的提示，我只需要將永久代設置大一些，就不會出現這種現象。隨即設置了XX:PermSize和XX:MaxPermSize的值，完美解決了這個問題。至今想起這個事件，仍然很慶幸當時買了《深入理解Java虛擬機》，從此以後，我就將它放在枕頭下了。
如今，畢業參加工作已有好幾年了，也會時常翻閱《深入理解Java虛擬機》，爭取對每個細節做到知根知底。從新生代到老年代，從YGC到FGC，從CMS到G1，無不是Java開發者老生常談的話題。從2017年到2019年，兩年時間Oracle發佈了Java9到Java13，似乎感覺快跟不上技術發展的腳步了，好像Java8的Lambda還沒學透，Java9的模塊化就來了，Java10的var變量類型推斷就來了，Java11的ZGC就來了…再一次地，我想起了跟隨《深入理解Java虛擬機》的腳步，得知第三版已枕戈待旦，相比老版新增內容多到50%，JDK12和JDK13 EA等特性解讀應有盡有，值得期待！