JVM是虛擬機器，也是一種規範，他遵循著馮·諾依曼體系結構的設計原理。馮·諾依曼體系結構中，指出計算機處理的資料和指令都是二進位制數，採用儲存程式方式不加區分的儲存在同一個儲存器裡，並且順序執行，指令由操作碼和地址碼組成，操作碼決定了操作型別和所操作的數的數字型別，地址碼則指出地址碼和運算元。從dos到window8，從unix到ubuntu和CentOS，還有MAC OS等等，不同的作業系統指令集以及資料結構都有著差異，而JVM通過在作業系統上建立虛擬機器，自己定義出來的一套統一的資料結構和操作指令，把同一套語言翻譯給各大主流的作業系統，實現了跨平臺執行，可以說JVM是java的核心，是java可以一次編譯到處執行的本質所在。
一、JVM的組成和執行原理。
JVM的畢竟是個虛擬機器，是一種規範，雖說符合馮諾依曼的計算機設計理念，但是他並不是實體計算機，所以他的組成也不是什麼儲存器，控制器，運算器，輸入輸出裝置。在我看來，JVM放在執行在真實的作業系統中表現的更像應用或者說是程式，他的組成可以理解為JVM這個程式有哪些功能模組，而這些功能模組的運作可以看做是JVM的執行原理。JVM有多種實現，例如Oracle的JVM，HP的JVM和IBM的JVM等，而在本文中研究學習的則是使用最廣泛的Oracle的HotSpot JVM。
1.JVM在JDK中的位置。
JDK是java開發的必備工具箱，JDK其中有一部分是JRE，JRE是JAVA執行環境，JVM則是JRE最核心的部分。我從oracle.com擷取了一張關於JDK Standard Edtion的組成圖，
從最底層的位置可以看出來JVM有多重要，而實際專案中JAVA應用的效能優化，OOM等異常的處理最終都得從JVM這兒來解決。HotSpot是Oracle關於JVM的商標，區別於IBM，HP等廠商開發的JVM。Java HotSpot Client VM和Java HotSpot Server VM是JDK關於JVM的兩種不同的實現，前者可以減少啟動時間和記憶體佔用，而後者則提供更加優秀的程式執行速度（參考自：http://docs.oracle.com/ javase/8/docs/technotes/ guides/vm/index.html ，該文件有關於各個版本的JVM的介紹）。在命令列，通過java -version可以檢視關於當前機器JVM的資訊，下面是我在Win8系統上執行命令的截圖，
可以看出我裝的是build 20.13-b02版本，HotSpot 型別Server模式的JVM。
2.JVM的組成
JVM由4大部分組成：ClassLoader，Runtime Data Area， Execution Engine，Native Interface。
我從CSDN找了一張描述JVM大致結構的圖：
2.1.ClassLoader是負責載入class檔案，class檔案在檔案開頭有特定的檔案標示，並且ClassLoader只負責class檔案的載入，至於它是否可以執行，則由Execution Engine決定。
2.2.Native Interface是負責呼叫本地介面的。他的作用是呼叫不同語言的介面給JAVA用，他會在Native Method Stack中記錄對應的本地方法，然後呼叫該方法時就通過Execution Engine載入對應的本地lib。原本多於用一些專業領域，如JAVA驅動，地圖製作引擎等，現在關於這種本地方法介面的呼叫已經被類似於Socket通訊，WebService等方式取代。
2.3.Execution Engine是執行引擎，也叫Interpreter。Class檔案被載入後，會把指令和資料資訊放入記憶體中，Execution Engine則負責把這些命令解釋給作業系統。
2.4.Runtime Data Area則是存放資料的，分為五部分：Stack，Heap，Method Area，PC Register，Native Method Stack。幾乎所有的關於java記憶體方面的問題，都是集中在這塊。下圖是javapapers.com上關於Run-time Data Areas的描述：
可以看出它把Method Area化為了Heap的一部分，javapapers.com中認為Method Area是Heap的邏輯區域，但這取決於JVM的實現者，而HotSpot JVM中把Method Area劃分為非堆記憶體，顯然是不包含在Heap中的。下圖是javacodegeeks.com中，2014年9月刊出的一片博文中關於Runtime Data Area的劃分，其中指出，NonHeap包含PermGen和Code Cache，PermGen包含Method Area,而且PermGen在JAVA SE 8中已經不再用了。查閱資料（https://abhirockzz.wordpress.com/ 2014/ 03/18/ java-se-8-is -knocking-are-you-there/）得知，java8中PermGen已經從JVM中移除並被MetaSpace取代，java8中也不會見到OOM:PermGen Space的異常。目前Runtime Data Area可以用下圖描述它的組成：
2.4.1.Stack是java棧記憶體，它等價於C語言中的棧，棧的記憶體地址是不連續的，每個執行緒都擁有自己的棧。棧裡面儲存著的是StackFrame，在《JVM Specification》中文版中被譯作java虛擬機器框架，也叫做棧幀。StackFrame包含三類資訊：區域性變數，執行環境，運算元棧。區域性變數用來儲存一個類的方法中所用到的區域性變數。執行環境用於儲存解析器對於java位元組碼進行解釋過程中需要的資訊，包括：上次呼叫的方法、區域性變數指標和運算元棧的棧頂和棧底指標。運算元棧用於儲存運算所需要的運算元和結果。StackFrame在方法被呼叫時建立，在某個執行緒中，某個時間點上，只有一個框架是活躍的，該框架被稱為Current Frame，而框架中的方法被稱為Current Method，其中定義的類為Current Class。區域性變數和運算元棧上的操作總是引用當前框架。當Stack Frame中方法被執行完之後，或者呼叫別的StackFrame中的方法時，則當前棧變為另外一個StackFrame。Stack的大小是由兩種型別，固定和動態的，動態型別的棧可以按照執行緒的需要分配。 下面兩張圖是關於棧之間關係以及棧和非堆記憶體的關係基本描述（來自http://www.programering.com/ a/MzM3QzNwATA.html）：
2.4.2.Heap是用來存放物件資訊的，和Stack不同，Stack代表著一種執行時的狀態。換句話說，棧是執行時單位，解決程式該如何執行的問題，而堆是儲存的單位，解決資料儲存的問題。Heap是伴隨著JVM的啟動而建立，負責儲存所有物件例項和陣列的。堆的儲存空間和棧一樣是不需要連續的，它分為Young Generation和Old Generation（也叫Tenured Generation）兩大部分。Young Generation分為Eden和Survivor，Survivor又分為From Space和 ToSpace。
和Heap經常一起提及的概念是PermanentSpace，它是用來載入類物件的專門的記憶體區，是非堆記憶體，和Heap一起組成JAVA記憶體，它包含MethodArea區（在沒有CodeCache的HotSpotJVM實現裡，則MethodArea就相當於GenerationSpace）。在JVM初始化的時候，我們可以通過引數來分別指定，PermanentSpace的大小、堆的大小、以及Young Generation和Old Generation的比值、Eden區和From Space的比值，從而來細粒度的適應不同JAVA應用的記憶體需求。
2.4.3.PC Register是程式計數暫存器，每個JAVA執行緒都有一個單獨的PC Register，他是一個指標，由Execution Engine讀取下一條指令。如果該執行緒正在執行java方法，則PC Register儲存的是 正在被執行的指令的地址，如果是本地方法，PC Register的值沒有定義。PC暫存器非常小，只佔用一個字寬，可以持有一個returnAdress或者特定平臺的一個指標。
2.4.4.Method Area在HotSpot JVM的實現中屬於非堆區，非堆區包括兩部分：Permanet Generation和Code Cache，而Method Area屬於Permanert Generation的一部分。Permanent Generation用來儲存類資訊，比如說：class definitions，structures，methods， field， method (data and code) 和 constants。Code Cache用來儲存Compiled Code，即編譯好的原生程式碼，在HotSpot JVM中通過JIT(Just In Time) Compiler生成，JIT是即時編譯器，他是為了提高指令的執行效率，把位元組碼檔案編譯成本地機器程式碼，如下圖：
引用一個經典的案例來理解Stack，Heap和Method Area的劃分，就是Sring a="xx"； Stirng b="xx"，問是否a==b? 首先==符號是用來判斷兩個物件的引用地址是否相同，而在上面的題目中，a和b按理來說申請的是Stack中不同的地址，但是他們指向Method Area中Runtime Constant Pool的同一個地址，按照網上的解釋，在a賦值為“xx”時，會在Runtime Contant Pool中生成一個String Constant，當b也賦值為“xx”時，那麼會在常量池中檢視是否存在值為“xx”的常量，存在的話，則把b的指標也指向“xx”的地址，而不是新生成一個String Constant。我查閱了網路上大家關於String Constant的儲存的說說法，存在略微差別的是，它儲存在哪裡，有人說Heap中會分配出一個常量池，用來儲存常量，所有執行緒共享它。而有人說常量池是Method Area的一部分，而Method Area屬於非堆記憶體，那怎麼能說常量池存在於堆中？
我認為，其實兩種理解都沒錯。Method Area的確從邏輯上講可以是Heap的一部分，在某些JVM實現裡從堆上開闢一塊儲存空間來記錄常量是符合JVM常量池設計目的的，所以前一種說法沒問題。對於後一種說法，HotSpot JVM的實現中的確是把方法區劃分為了非堆記憶體，意思就是它不在堆上。我在HotSpot JVM做了個簡單的實驗，定義多個常量之後，程式丟擲OOM：PermGen Space異常，印證了JVM實現中常量池是在Permanent Space中的說法。但是，我的JDK版本是1.6的。查閱資料，JDK1.7中InternedStrings已經不再儲存在PermanentSpace中，而是放到了Heap中；JDK8中PermanentSpace已經被完全移除，InternedStrings也被放到了MetaSpace中（如果出現記憶體溢位，會報OOM:MetaSpace，這裡有個關於兩者效能對比的文章：http://blog.csdn.net/zhyhang /article/details/17246223）。所以，仁者見仁，智者見智，一個饅頭足以引發血案，就算是同一個商家的JVM，畢竟JDK版本在更新，或許正如StackOverFlow上大神們所說，對於理解JVM Runtime Data Area這一部分的劃分邏輯，還是去看對應版本的JDK原始碼比較靠譜，或者是參考不同的版本JVM Specification進群617434785可以免費獲取文中知識點免費視訊
2.4.5.Native Method Stack是供本地方法（非java）使用的棧。每個執行緒持有一個Native Method Stack。
3.JVM的執行原理簡介
Java程式被javac工具編譯為.class位元組碼檔案之後，我們執行java命令，該class檔案便被JVM的Class Loader載入，可以看出JVM的啟動是通過JAVA Path下的java.exe或者java進行的。JVM的初始化、執行到結束大概包括這麼幾步：
呼叫作業系統API判斷系統的CPU架構，根據對應CPU型別尋找位於JRE目錄下的/lib/jvm.cfg檔案，然後通過該配置檔案找到對應的jvm.dll檔案（如果我們引數中有-server或者-client， 則載入對應引數所指定的jvm.dll，啟動指定型別的JVM），初始化jvm.dll並且掛接到JNIENV結構的例項上，之後就可以通過JNIENV例項裝載並且處理class檔案了。class檔案是位元組碼檔案，它按照JVM的規範，定義了變數，方法等的詳細資訊，JVM管理並且分配對應的記憶體來執行程式，同時管理垃圾回收。直到程式結束，一種情況是JVM的所有非守護執行緒停止，一種情況是程式呼叫System.exit()，JVM的生命週期也結束。
關於JVM如何管理分配記憶體，我通過class檔案和垃圾回收兩部分進行了學習。
二、JVM的記憶體管理和垃圾回收
JVM中的記憶體管理主要是指JVM對於Heap的管理，這是因為Stack，PC Register和Native Method Stack都是和執行緒一樣的生命週期，線上程結束時自然可以被再次使用。雖然說，Stack的管理不是重點，但是也不是完全不講究的。
1.棧的管理
JVM允許棧的大小是固定的或者是動態變化的。在Oracle的關於引數設定的官方文件中有關於Stack的設定（http://docs.oracle.com/cd/E13150_01/ jrockit_jvm/jrockit/jrdocs / refman/optionX.html#wp1024112），是通過-Xss來設定其大小。關於Stack的預設大小對於不同機器有不同的大小，並且不同廠商或者版本號的jvm的實現其大小也不同，如下表是HotSpot的預設大小：
我們一般通過減少常量，引數的個數來減少棧的增長，在程式設計時，我們把一些常量定義到一個物件中，然後來引用他們可以體現這一點。另外，少用遞迴呼叫也可以減少棧的佔用。
棧是不需要垃圾回收的，儘管說垃圾回收是java記憶體管理的一個很熱的話題，棧中的物件如果用垃圾回收的觀點來看，他永遠是live狀態，是可以reachable的，所以也不需要回收，他佔有的空間隨著Thread的結束而釋放。（參考自：http://stackoverflow.com/ questions/20030120/java -default-stack-size）
關於棧一般會發生以下兩種異常：
1.當執行緒中的計算所需要的棧超過所允許大小時，會丟擲StackOverflowError。
2.當Java棧試圖擴充套件時，沒有足夠的儲存器來實現擴充套件，JVM會報OutOfMemoryError。
我針對棧進行了實驗，由於遞迴的呼叫可以致使棧的引用增加，導致溢位，所以設計程式碼如下：
我的機器是x86_64系統，所以Stack的預設大小是128KB，上述程式在執行時會報錯：
而當我在eclipse中調整了-Xss引數到3M之後，該異常消失。
另外棧上有一點得注意的是，對於原生程式碼呼叫，可能會在棧中申請記憶體，比如C呼叫malloc()，而這種情況下，GC是管不著的，需要我們在程式中，手動管理棧記憶體，使用free()方法釋放記憶體。
2.堆的管理
堆的管理要比棧管理複雜的多，我通過堆的各部分的作用、設定，以及各部分可能發生的異常，以及如何避免各部分異常進行了學習。
上圖是 Heap和PermanentSapce的組合圖，其中Eden區裡面存著是新生的物件，From Space和To Space中存放著是每次垃圾回收後存活下來的物件 ，所以每次垃圾回收後，Eden區會被清空。存活下來的物件先是放到From Space，當From Space滿了之後移動到To Space。當To Space滿了之後移動到Old Space。Survivor的兩個區是對稱的，沒先後關係，所以同一個區中可能同時存在從Eden複製過來 物件，和從前一個Survivor複製過來的物件，而複製到年老區的只有從第一個Survivor複製過來的物件。而且，Survivor區總有一個是空的。同時，根據程式需要，Survivor區是可以配置為多個的（多於兩個），這樣可以增加物件在年輕代中的存在時間，減少被放到年老代的可能。
Old Space中則存放生命週期比較長的物件，而且有些比較大的新生物件也放在Old Space中。
堆的大小通過-Xms和-Xmx來指定最小值和最大值，通過-Xmn來指定Young Generation的大小（一些老版本也用-XX:NewSize指定）， 即上圖中的Eden加FromSpace和ToSpace的總大小。然後通過-XX:NewRatio來指定Eden區的大小，在Xms和Xmx相等的情況下，該引數不需要設定。通過-XX：SurvivorRatio來設定Eden和一個Survivor區的比值。（參考自博文：http://www.cnblogs.com/redcreen /archive/ 2011/05/04/2037057.html）
堆異常分為兩種，一種是Out of Memory(OOM)，一種是Memory Leak(ML)。Memory Leak最終將導致OOM。實際應用中表現為：從Console看，記憶體監控曲線一直在頂部，程式響應慢，從執行緒看，大部分的執行緒在進行GC，佔用比較多的CPU，最終程式異常終止，報OOM。OOM發生的時間不定，有短的一個小時，有長的10天一個月的。關於異常的處理，確定OOM/ML異常後，一定要注意保護現場，可以dump heap，如果沒有現場則開啟GCFlag收集垃圾回收日誌，然後進行分析，確定問題所在。如果問題不是ML的話，一般通過增加Heap，增加實體記憶體來解決問題，是的話，就修改程式邏輯。
3.垃圾回收
JVM中會在以下情況觸發回收：物件沒有被引用，作用域發生未捕捉異常，程式正常執行完畢，程式執行了System.exit()，程式發生意外終止。
JVM中標記垃圾使用的演算法是一種根搜尋演算法。簡單的說，就是從一個叫GC Roots的物件開始，向下搜尋，如果一個物件不能達到GC Roots物件的時候，說明它可以被回收了。這種演算法比一種叫做引用計數法的垃圾標記演算法要好，因為它避免了當兩個物件啊互相引用時無法被回收的現象。
JVM中對於被標記為垃圾的物件進行回收時又分為了一下3種演算法：
1.標記清除演算法，該演算法是從根集合掃描整個空間，標記存活的物件，然後在掃描整個空間對沒有被標記的物件進行回收，這種演算法在存活物件較多時比較高效，但會產生記憶體碎片。
2.複製演算法，該演算法是從根集合掃描，並將存活的物件複製到新的空間，這種演算法在存活物件少時比較高效。
3.標記整理演算法，標記整理演算法和標記清除演算法一樣都會掃描並標記存活物件，在回收未標記物件的同時會整理被標記的物件，解決了記憶體碎片的問題。
JVM中，不同的 記憶體區域作用和性質不一樣，使用的垃圾回收演算法也不一樣，所以JVM中又定義了幾種不同的垃圾回收器（圖中連線代表兩個回收器可以同時使用）：
1.Serial GC。從名字上看，序列GC意味著是一種單執行緒的，所以它要求收集的時候所有的執行緒暫停。這對於高效能的應用是不合理的，所以序列GC一般用於Client模式的JVM中。
2.ParNew GC。是在SerialGC的基礎上，增加了多執行緒機制。但是如果機器是單CPU的，這種收集器是比SerialGC效率低的。
3.Parrallel Scavenge GC。這種收集器又叫吞吐量優先收集器，而吞吐量=程式執行時間/(JVM執行回收的時間+程式執行時間),假設程式執行了100分鐘，JVM的垃圾回收佔用1分鐘，那麼吞吐量就是99%。Parallel Scavenge GC由於可以提供比較不錯的吞吐量，所以被作為了server模式JVM的預設配置。
4.ParallelOld是老生代並行收集器的一種，使用了標記整理演算法，是JDK1.6中引進的，在之前老生代只能使用序列回收收集器。
5.Serial Old是老生代client模式下的預設收集器，單執行緒執行，同時也作為CMS收集器失敗後的備用收集器。
6.CMS又稱響應時間優先回收器，使用標記清除演算法。他的回收執行緒數為(CPU核心數+3)/4，所以當CPU核心數為2時比較高效些。CMS分為4個過程：初始標記、併發標記、重新標記、併發清除。
7.GarbageFirst（G1）。比較特殊的是G1回收器既可以回收Young Generation，也可以回收Tenured Generation。它是在JDK6的某個版本中才引入的，效能比較高，同時注意了吞吐量和響應時間。進群617434785可以免費獲取文中知識點免費視訊
對於垃圾收集器的組合使用可以通過下表中的引數指定：
（MarsYOungNote:圖中第三個寫錯了。UseConeMarkSweepGC）
預設的GC種類可以通過jvm.cfg或者通過jmap dump出heap來檢視，一般我們通過jstat -gcutil [pid] 1000可以檢視每秒gc的大體情況，或者可以在啟動引數中加入：-verbose:gc -XX: +PrintGCTimeStamps -XX: +PrintGCDetails -Xloggc:./gc.log來記錄GC日誌。
GC中有一種情況叫做Full GC，以下幾種情況會觸發Full GC也叫MajorGC：
1.Tenured Space空間不足以建立打的物件或者陣列，會執行FullGC，並且當FullGC之後空間如果還不夠，那麼會OOM:java heap space。
2.Permanet Generation的大小不足，存放了太多的類資訊，在非CMS情況下回觸發FullGC。如果之後空間還不夠，會OOM:PermGen space。
3.CMS GC時出現promotion failed和concurrent mode failure時，也會觸發FullGC。promotion failed是在進行Minor GC時，survivor space放不下、物件只能放入舊生代，而此時舊生代也放不下造成的；concurrent mode failure是在執行CMS GC的過程中同時有物件要放入舊生代，而此時舊生代空間不足造成的。
4.判斷MinorGC後，要晉升到TenuredSpace的物件大小大於TenuredSpace的大小，也會觸發FullGC。
可以看出，當FullGC頻繁發生時，一定是記憶體出問題了。
三、JVM的資料格式規範和Class檔案
1.資料型別規範
依據馮諾依曼的計算機理論，計算機最後處理的都是二進位制的數，而JVM是怎麼把java檔案最後轉化成了各個平臺都可以識別的二進位制呢？JVM自己定義了一個抽象的儲存資料單位，叫做Word。一個字足夠大以持有byte、char、short、int、float、reference或者returnAdress的一個值，兩個字則足夠持有更大的型別long、double。它通常是主機平臺一個指標的大小，如32位的平臺上，字是32位。
同時JVM中定義了它所支援的基本資料型別，包括兩部分：數值型別和returnAddress型別。數值型別分為整形和浮點型。
整形：
浮點：
returnAddress型別的值是Java虛擬機器指令的操作碼的指標。
對比java的基本資料型別，jvm的規範中沒有boolean型別。這是因為jvm中堆boolean的操作是通過int型別來進行處理的，而boolean陣列則是通過byte陣列來進行處理。
至於String，我們知道它儲存在常量池中，但他不是基本資料型別，之所以可以存在常量池中，是因為這是JVM的一種規定。如果檢視String原始碼，我們就會發現，String其實就是一個基於基本資料型別char的陣列。如圖：
2.位元組碼檔案
通過位元組碼檔案的格式我們可以看出jvm是如何規範資料型別的。下面是ClassFile的結構：
關於各個欄位的定義（參考自JVM Specification 和 博文：http://www.cnblogs.com/ zhuYears /archive/2012/02/07 /2340347.html），
magic：
魔數，魔數的唯一作用是確定這個檔案是否為一個能被虛擬機器所接受的Class檔案。魔數值固定為0xCAFEBABE，不會改變。
minor_version、 major_version：
分別為Class檔案的副版本和主版本。它們共同構成了Class檔案的格式版本號。不同版本的虛擬機器實現支援的Class檔案版本號也相應不同，高版本號的虛擬機器可以支援低版本的Class檔案，反之則不成立。
constant_pool_count：
常量池計數器，constant_pool_count的值等於constant_pool表中的成員數加1。
constant_pool[]：
常量池，constant_pool是一種表結構，它包含Class檔案結構及其子結構中引用的所有字串常量、類或介面名、欄位名和其它常量。常量池不同於其他，索引從1開始到constant_pool_count -1。
access_flags：
訪問標誌，access_flags是一種掩碼標誌，用於表示某個類或者介面的訪問許可權及基礎屬性。access_flags的取值範圍和相應含義見下表：
this_class：
類索引，this_class的值必須是對constant_pool表中專案的一個有效索引值。constant_pool表在這個索引處的項必須為CONSTANT_Class_info型別常量，表示這個Class檔案所定義的類或介面。
super_class：
父類索引，對於類來說，super_class的值必須為0或者是對constant_pool表中專案的一個有效索引值。如果它的值不為0，那constant_pool表在這個索引處的項必須為CONSTANT_Class_info型別常量，表示這個Class檔案所定義的類的直接父類。當然，如果某個類super_class的值是0，那麼它必定是java.lang.Object類，因為只有它是沒有父類的。
interfaces_count：
介面計數器，interfaces_count的值表示當前類或介面的直接父介面數量。
interfaces[]：
介面表，interfaces[]陣列中的每個成員的值必須是一個對constant_pool表中專案的一個有效索引值，它的長度為interfaces_count。每個成員interfaces[i] 必須為CONSTANT_Class_info型別常量。
fields_count：
欄位計數器，fields_count的值表示當前Class檔案fields[]陣列的成員個數。
fields[]：
欄位表，fields[]陣列中的每個成員都必須是一個fields_info結構的資料項，用於表示當前類或介面中某個欄位的完整描述。
methods_count：
方法計數器，methods_count的值表示當前Class檔案methods[]陣列的成員個數。
methods[]：
方法表，methods[]陣列中的每個成員都必須是一個method_info結構的資料項，用於表示當前類或介面中某個方法的完整描述。
attributes_count：
屬性計數器，attributes_count的值表示當前Class檔案attributes表的成員個數。
attributes[]：
屬性表，attributes表的每個項的值必須是attribute_info結構。
四、一個java類的例項分析
為了瞭解JVM的資料型別規範和記憶體分配的大體情況，我新建了MemeryTest.java：
編譯為MemeryTest.class後，通過WinHex檢視該檔案，對應位元組碼檔案各個部分不同的定義，我瞭解了下面16進位制數值的具體含義，儘管不清楚ClassLoader的具體實現邏輯，但是可以想象這樣一個嚴謹格式的檔案給JVM對於記憶體管理和執行程式提供了多大的幫助。
執行程式後，我在windows資源管理器中找到對應的程式ID.
並且在控制檯通過jmap -heap 10016檢視堆記憶體的使用情況：
輸出結果中表示當前java程式啟動的JVM是通過4個執行緒進行Parallel GC，堆的最小FreeRatio是40%，堆的最大FreeRatio是70%，堆的大小是4090M，新物件佔用1.5M，Young Generation可以擴充套件到最大是1363M， Tenured Generation的大小是254.5M，以及NewRadio和SurvivorRadio中，下面更是具體給出了目前Young Generation中1.5M的劃分情況，Eden佔用1.0M，使用了5.4%，Space佔了0.5M,使用了93%，To Space佔了0.5M,使用了0%。
下面我們通過jmap dump把heap的內容列印打檔案中：
使用Eclipse的MAT外掛開啟對應的檔案：
選擇第一項記憶體洩露分析報告開啟test.bin檔案，展示出來的是MAT關於記憶體可能洩露的分析。
從結果來看，有3個地方可能存在記憶體洩露，他們佔據了Heap的22.10%，13.78%，14.69%，如果記憶體洩露，這裡一般會有一個比值非常高的物件。開啟第一個Probem Suspect，結果如下：
ShallowHeap是物件本身佔用的堆大小，不包含引用，RetainedHeap是物件所持有的Shallowheap的大小，包括自己ShallowHeap和可以引用的物件的ShallowHeap。垃圾回收的時候，如果一個物件不再引用後被回收，那麼他的RetainedHeap是能回收的記憶體總和。通過上圖可以看出程式中並沒有什麼記憶體洩露，可以放心了。如果還有什麼不太確定的物件，則可以通過多個時間點的HeapDumpFile來研究某個物件的變化情況。
五、小結
以上便是我最近幾天對JVM相關資料的整理，主要圍繞他的基本組成和執行原理等，記憶體管理，基本資料型別和位元組碼檔案。JVM是一個非常優秀的JAVA程式，也是個不錯的規範，這次整理學習讓我對他有了更加清晰的認知，對Java語言的理解也更加加深。
這次學習過程，堅定了我對程式設計師發展的認知。知識一定要精，下一步我將邊工作邊仔細閱讀Oracle的3個版本的《JVM Specification》，並且結合實踐讓自己的Java基礎素養更上一個層次。