淺談JVM specification的實現及其原理
JVM主要包括兩個子系統和兩個組件。兩個子系統分別是Class loader子系統和Execution engine(執行引擎) 子系統；兩個組件分別是Runtime data area (運行時數據區域)組件和Native interface(本地接口)組件。
Class loader子系統的作用：根據給定的全限定名類名(如 java.lang.Object)來裝載class文件的內容到 Runtime data area中的method area(方法區域)。Java程序員可以extends java.lang.ClassLoader類來寫自己的Class loader。
Execution engine子系統的作用：執行classes中的指令。任何JVM specification實現(JDK)的核心都是Execution engine，不同的JDK（JVM specification）例如Sun 的JDK 和IBM的JDK好壞主要就取決于他們各自實現的Execution engine的好壞。
Native interface組件：與native libraries交互，是其它編程語言交互的接口。當調用native方法的時候，就進入了一個全新的并且不再受虛擬機限制的世界，所以也很容易出現JVM無法控制的native heap OutOfMemory。
Runtime Data Area組件：這就是我們常說的JVM的內存了。它主要分為五個部分——
1、Heap (堆)：一個Java虛擬實例中只存在一個堆空間
2、Method Area(方法區域)：被裝載的class的信息存儲在Method area的內存中。當虛擬機裝載某個類型時，它使用類裝載器定位相應的class文件，然后讀入這個class文件內容并把它傳輸到虛擬機中。
3、Java Stack(java的棧)：虛擬機只會直接對Java stack執行兩種操作：以幀為單位的壓棧或出棧
4、Program Counter(程序計數器)：每一個線程都有它自己的PC寄存器，也是該線程啟動時創建的。PC寄存器的內容總是指向下一條將被執行指令的餓地址，這里的地址可以是一個本地指針，也可以是在方法區中相對應于該方法起始指令的偏移量。
5、Native method stack(本地方法棧)：保存native方法進入區域的地址
以上五部分只有Heap 和Method Area是被所有線程的共享使用的；而Java stack, Program counter 和Native method stack是以線程為粒度的，每個線程獨自擁有自己的部分。
了解JVM的系統結構，再來看看JVM內存回收問題了——
Sun的JVM Generational Collecting(垃圾回收)原理是這樣的：把對象分為年青代(Young)、年老代(Tenured)、持久代(Perm)，對不同生命周期的對象使用不同的算法。(基于對對象生命周期分析)
Java堆中的各代分布。
1. Young（年輕代）
年輕代分三個區。一個Eden區，兩個Survivor區。大部分對象在Eden區中生成。當Eden區滿時，還存活的對象將被復制到Survivor區（兩個中的一個），當這個Survivor區滿時，此區的存活對象將被復制到另外一個Survivor區，當這個Survivor去也滿了的時候，從第一個Survivor區復制過來的并且此時還存活的對象，將被復制年老區(Tenured。需要注意，Survivor的兩個區是對稱的，沒先后關系，所以同一個區中可能同時存在從Eden復制過來 對象，和從前一個Survivor復制過來的對象，而復制到年老區的只有從第一個Survivor去過來的對象。而且，Survivor區總有一個是空的。
2. Tenured（年老代）
年老代存放從年輕代存活的對象。一般來說年老代存放的都是生命期較長的對象。
3. Perm（持久代）
用于存放靜態文件，如今Java類、方法等。持久代對垃圾回收沒有顯著影響，但是有些應用可能動態生成或者調用一些class，例如Hibernate等，在這種時候需要設置一個比較大的持久代空間來存放這些運行過程中新增的類。持久代大小通過-XX:MaxPermSize=進行設置。
舉個例子：當在程序中生成對象時，正常對象會在年輕代中分配空間，如果是過大的對象也可能會直接在年老代生成（據觀測在運行某程序時候每次會生成一個十兆的空間用收發消息，這部分內存就會直接在年老代分配）。年輕代在空間被分配完的時候就會發起內存回收，大部分內存會被回收，一部分幸存的內存會被拷貝至Survivor的from區，經過多次回收以后如果from區內存也分配完畢，就會也發生內存回收然后將剩余的對象拷貝至to區。等到to區也滿的時候，就會再次發生內存回收然后把幸存的對象拷貝至年老區。
通常我們說的JVM內存回收總是在指堆內存回收，確實只有堆中的內容是動態申請分配的，所以以上對象的年輕代和年老代都是指的JVM的Heap空間，而持久代則是之前提到的Method Area，不屬于Heap。
了解完這些之后，以下的轉載一熱衷于鉆研技術的哥們Richen Wang關于內存管理的一些建議——
1、手動將生成的無用對象，中間對象置為null，加快內存回收。
2、對象池技術 如果生成的對象是可重用的對象，只是其中的屬性不同時，可以考慮采用對象池來較少對象的生成。如果有空閑的對象就從對象池中取出使用，沒有再生成新的對象，大大提高了對象的復用率。
3、JVM調優 通過配置JVM的參數來提高垃圾回收的速度，如果在沒有出現內存泄露且上面兩種辦法都不能保證內存的回收時，可以考慮采用JVM調優的方式來解決，不過一定要經過實體機的長期測試，因為不同的參數可能引起不同的效果。如-Xnoclassgc參數等。
推薦的兩款內存檢測工具
1、jconsole JDK自帶的內存監測工具，路徑jdk bin目錄下jconsole.exe，雙擊可運行。連接方式有兩種，第一種是本地方式如調試時運行的進程可以直接連，第二種是遠程方式，可以連接以服務形式啟動的進程。遠程連接方式是：在目標進程的jvm啟動參數中添加-Dcom.sun.management.jmxremote.port=1090 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false 1090是監聽的端口號具體使用時要進行修改，然后使用IP加端口號連接即可。通過該工具可以監測到當時內存的大小，CPU的使用量以及類的加載，還提供了手動gc的功能。優點是效率高，速度快，在不影響進行運行的情況下監測產品的運行。缺點是無法看到類或者對象之類的具體信息。使用方式很簡單點擊幾下就可以知道功能如何了，確實有不明白之處可以上網查詢文檔。
2、JProfiler 收費的工具，但是到處都有破解辦法。安裝好以后按照配置調試的方式配置好一個本地的session即可運行。可以監測當時的內存、CPU、線程等，能具體的列出內存的占用情況，還可以就某個類進行分析。優點很多，缺點太影響速度，而且有的類可能無法被織入方法，例如我使用jprofiler時一直沒有備份成功過，總會有一些類的錯誤。
JVM specification的實現及其原理就介紹到這里。
【編輯推薦】
【責任編輯：彭凡 TEL：（010）68476606】
