摘要：JVM是一種用于計算裝置的規範，是一個虛構出來的計算機，通過在實際的計算機上仿真模拟各種計算機功能來實作的。
本文分享自華為雲社群《[雲駐共創]JVM記憶體模型的探知之旅》，作者：多米諾的古牌。
JVM是Java Virtual Machine（Java虛拟機）的簡稱，是一種用于計算裝置的規範，是一個虛構出來的計算機，通過在實際的計算機上仿真模拟各種計算機功能來實作的。
JVM可以讓java程式，一次編寫，導出運作。讓底層代碼和運作環境分離開，編寫好一份代碼後，不用再次修改内容，隻用通過安裝不同的JVM環境自動進行轉換即可運作，在各種系統中無縫連接配接。
在Java誕生之時，C和C++稱霸天下，但是這兩種語言中沒有記憶體管理機制，是通過手動操作來進行的管理，非常麻煩和繁瑣。
此時Java應運而生,為了處理記憶體管理這個方面，專門設計了垃圾回收機制，來自動進行記憶體的管理。極大的優化了操作，讓程式員們不用正在噼裡啪啦在碼代的海洋中遨遊時，還要操心記憶體會不會溢出這些“影響我方輸出”的問題，頓時獲得了成噸的好評。
在Java誕生之時，還有個讓當時C和C++大佬頭疼的問題是，數組下标越界是沒有檢查機制的，這還了得，又是一個影響“我方暴力輸出”的罪魁禍首，是以JVM繼續抱着暖男的思想，又來了個愛的抱抱。
JVM又一次看見了大佬們的煩惱，果斷提供了數組下标越界的自動檢查機制，在檢測到數組下标出現越界後，會在運作時自動抛出“java.lang.ArrayIndexOutOfBoundsException”這個異常，在當時可是感動了很多業界大佬（我猜的）。
JVM還有一個多态功能，是通過相同接口，不同的執行個體進行實作，完成不同的業務操作，比如：定義了一個動物接口（裡面有一個吃的方法），我們就可以通過這個動物創造小貓（吃魚），再創造一個狗狗（吃肉），再創造一個小助手（吃零食，O(∩_∩)O哈哈~）。
仔細想想，對我們有啥影響呢，那好處老多了，比如：
（1）消除類型之間的耦合關系；
（2）可替換性；
（3）可擴充性；
（4）接口性；
（5）靈活性；
（6）簡化性；
JVM是Java Virtual Machine的簡稱，是Java虛拟機，是一種模拟出來的虛拟計算機，它通過在不同的計算機環境當中模拟實作計算功能來實作的。
引入Java虛拟機後，Java語言在不同平台上運作時就不需要重新編譯。在其中，Java虛拟機屏蔽了與具體平台的相關資訊，使得Java源程式在編譯完成之後即可在不同的平台運作，達到“一次編譯，到處運作”的目的，Java語言重要的特點之一跨平台，也即與平台的無關性，其關鍵點就是JVM。
JRE是Java Runtime Environment的簡稱，是Java運作環境，是讓作業系統運作Java應用程式的環境，其内部包含JVM，也就是說JRE隻負責對已經存在的Java源程式進行運作的操作，它不包含開發工具JDK，對JDK内部的編譯器、調試器和其它工具均不包含。
JDK是Java Development Kit的簡稱，是Java開發工具包，是整個Java程式開發的核心。其主要包含了JRE、Java的系統類庫以及對Java程式進行編譯以及運作的工具，例如：javac.exe和java.exe指令工具等。
Oracle（Hotspot、Jrockit）、BEA（LiquidVM）、IBM（J9）、taobaoVM（淘寶專用，對Hotspot進行了深度定制）、zing（垃圾回收機制非常快，到達1毫秒左右）。
當Java程式編譯完成為.class檔案==》類加載器（ClassLoader）==》将位元組碼檔案加載進JVM中；
方法區中儲存的主要是類的資訊（類的屬性、成員變量、構造函數等）、堆（建立的對象）。
堆中的對象調用方法時，方法會運作在虛拟機棧、程式計數器、本地方法棧中。
執行方法中代碼時，代碼通過執行引擎執行中的“解釋器”執行；方法中經常調用的代碼，即熱點代碼，通過“即時編譯器”執行，其執行速度非常快。
GC是針對堆記憶體中沒有引用的對象進行回收，可以手動也可以自動。
因為JVM不能直接調用作業系統的功能，隻能通過本地方法接口來調用作業系統的功能。
Program Counter Register即程式計數器（寄存器），用于記錄下一條Jvm指令的執行位址。
javap主要用于操作JVM，javap -c 是對java代碼進行反彙編操作。下圖為通過先編譯demo.java後，再執行javap -c demo的輸出結果：
其中第一列為二進制位元組碼，即JVM指令，第二列為java源代碼。第一列中的序号為JVM指令的執行位址。
JVM會通過程式計數器記錄下一條需要執行的JVM指令的位址（比如第一行的0），然後交給解釋器解析為機器碼，最後交給cpu（隻能識别機器碼），完成一行的執行。
想要執行下一行，繼續讓JVM的程式計數器記錄下一條位址（比如第二行的3），再交給解釋器解析後給cpu，以此類推執行結束。
虛拟機棧是每個線程運作所需要的記憶體空間，每個棧中由多個棧幀組成，每個線程中隻能有一個活動棧幀（對應目前正在執行的方法），所有棧幀都遵循後進先出，先進後出的原則。
棧幀是每次調用方法時所占用的記憶體，在棧幀中儲存的内容參數、局部變量、傳回位址。
注1：垃圾回收不涉及棧記憶體，因為棧記憶體是由方法調用産生的，當方法調用結束後會彈出棧。
注2：棧記憶體不是配置設定的越大越好，因為實體記憶體是一定的，棧記憶體越大，可以支援更多的遞歸調用，但是可執行的線程數會越來越少。
注3：方法的局部變量，當其沒有逃離方法的作用範圍時，是線程安全的；如果其引用了對象（比如靜态變量，即共享變量，用對象作為參數的方法，傳回值為對象的方法），并且逃離出了方法的作用範圍，就需要考慮線程安全的問題了。
（1）虛拟機棧中，棧幀過多（無限遞歸），如圖1棧幀過多；
（2）每個棧幀所占用過大，如圖2 棧幀過大。
無限遞歸調用（棧幀過多）的小實驗，method1()方法在主方法中無限調用自己，那麼會發生什麼情況呢？
答案很明顯，程式崩潰了，産生了棧記憶體溢出錯誤，如下圖所示：
-Xss:該參數規定了每個線程虛拟機棧的大小；
接着我們通過設定一個虛拟機棧的大小是256k試試會發生什麼？
我們發現當我們調整了虛拟機棧的大小後執行了4315次方法後記憶體就溢出了，而調整虛拟機棧之前，我們是23268次，很明顯我們可以通過-Xss參數調整虛拟機棧的大小來控制記憶體的溢出情況。
想象中的場景，大佬在瘋狂輸出，突然CPU爆表了，顯示CPU占用過多，如何去定位哪行代碼的問題，是的是哪行（大佬都很忙的好嗎，當然要精确了，一分鐘幾千萬上下的，O(∩_∩)O哈哈~）？
Linux環境下：
在背景運作Stack_6這個java位元組碼（.class）檔案：
注：無論是否将nohup指令的輸出重定向到終端,輸出都将附加到目前目錄的 nohup.out 檔案中。
（1）通過top指令，檢視程序（相當于任務管理器），發現了一個占用CPU達到100%的可疑家夥，這還了得，趕緊瞅瞅具體發生了什麼，還有沒有王法，這讓其他小夥伴還怎麼愉快的玩耍，秒速糾錯ING。。。
注：top指令，檢視哪個程序占用CPU過高，傳回程序号。
（2） 通過ps H -eo pid,tid ,%cpu | grep 指令過濾任務管理器中的内容。
注：ps H -eo pid,tid,%cpu |grep，是通過ps指令檢視哪個線程占用CPU過高，傳回程序id，其中pid為程序id，tid為線程id，%cpu為CPU占用情況；
發現了罪魁禍首，這一串串心驚肉跳的紅色。。。
（3） 通過jstack 程序id檢視，20389這個有問題的程序中具體的情況。
注：jstack 程序id，是通過jstack 指令定位具體哪段代碼出現占用CPU過高，注意jstack指令查找的線程id是16進制的，需要轉換；
發現裡面有一堆執行的代碼，那麼我們怎麼找到具體是哪個家夥搞事情的呢？上圖我們可以發現搞事情的線程是20441，那麼我們通過電腦将20441轉換為16進制的4FD9再去試試，真相隻有一個。
通過對比nid（線程id）4fd9，我們發現這個叫thread1的線程一直在運作（RUNNABLE狀态），并且檢視到位置是位于Stack_6.java檔案的第11行出現的問題。。。
現在我們回到源碼中，在Stack_6檔案的第11行，我們發現原來這裡一直在執行死循環，終于找到你，還好我沒放棄，奈斯~
由于Java本身有時候是無法直接和作業系統底層互動的，但有時候需要Java調用本地的C或C++方法，是以此時本地方法棧應運而生，它們是一類帶有native關鍵字的方法。
Heap堆：是通過new關鍵字建立的對象存放在堆中
堆中存放的對象都是線程共享的，是以都是需要考慮線程安全問題的。
因為堆中存放的對象存放了大量的對象，是以給他配了個小助手——垃圾回收機制（可以調自動擋和手動擋哦~）。
繼續幻想一個場景，當一個大佬開發完一個段代碼的時候（當然一般大佬都是很自信的，我寫的代碼怎麼可能有問題，不存在的。。。），但是測試可跑不了，穩妥起見咱們還是默默得搞測試試試嘛，安全第一。但是機器的記憶體就這麼大，大佬肯定跑了很多次了，都沒出現問題的，這不是找茬嘛。。。還是默默改下機子參數再試試吧（想去怼大佬，一定要拿出證據嘛~）。
-Xmx：JVM調優參數之一，該參數表示java堆可以擴充到的最大值。下面上案例：
在執行了26次之後，果斷的背景報了堆記憶體溢出錯誤。
下面通過-Xmx JVM調優參數将堆記憶體調小至8m，再試試會發生什麼呢？
操作基本和棧記憶體溢出的時候的案例一樣，次數明顯變小了，隻調用了17次就出現了堆記憶體溢出錯誤了。
jps工具:檢視目前系統中有哪些java程序
jmap工具：檢視堆記憶體的占用情況jmap -heap 程序id
jconsole工具：圖形化的工具，擁有多功能的監測功能，可以連續監測。
下面我們通過運作代碼後通過jconsole可視化圖形工具，來檢視堆記憶體的使用情況。
上圖我們可以看到，在我們建立10mb的數組對象時，記憶體使用有一定上升；然後在我們手動調用垃圾回收機制後，記憶體又得到了很大的釋放。
Java虛拟機中有一個被所有jvm線程共享的方法區。方法區有點類似于傳統程式設計語言中的編譯代碼塊或者作業系統層面的代碼段。它存儲着每個類的構造資訊，譬如運作時的常量池，字段，方法資料，以及方法和構造方法的代碼，包括一些在類和執行個體初始化和接口初始化時候使用的特殊方法。
方法區有個别稱non-heap(非堆)，可以看作是一塊獨立于堆的記憶體空間，是JVM規範中定義的一個概念，用于存儲類資訊、常量池、靜态變量，JIT編譯後的代碼等資料，具體放在哪裡，不同的實作可以放在不同的地方。
（1）方法區與java堆一樣，是各個線程共享的記憶體區域；
（2）方法區在JVM啟動的時候被建立；
（3）方法區的大小，跟堆空間一樣，可以選擇固定大小或擴充；
（4）方法區的大小決定了系統可以儲存多少個類，如果系統定義了太多的類，導緻方法區溢出，虛拟機同樣會抛出溢出錯誤OutOfMemoryError；
（5）關閉JVM就會釋放這個區域的記憶體。
在JVM記憶體結構1.6的時候，方法區儲存在記憶體結構中，叫做永久代，裡面存儲了運作時的常量池（包含串池StringTable）、類的資訊、類加載器；
在JVM記憶體結構1.8的時候，方法區做為一個概念，儲存在本地記憶體中，叫做元空間，裡面存儲了運作時的常量池、類的資訊、類加載器，此時串池（StringTable）儲存在堆之中。
點選關注，第一時間了解華為雲新鮮技術~