一、JVM內存的構

java虛擬機會將內存分為幾個不同的管理區，這些區域各自有各自的用途，根據不同的特點，承擔不同的任務以及在垃圾回收時運用不同的算法?？傮w分為下面幾個部分：

程序計數器（PRogram Counter Register）、JVM虛擬機棧（JVM Stacks）、本地方法棧（Native Method Stacks）、堆（Heap）、方法區（Method Area）

如下圖：

1、程序計數器（Program Counter Register）

這 是一塊比較小的內存，不在Ram上，而是直接劃分在CPU上的，程序員無法直接操作它，它的作用是：JVM在解釋字節碼文件（.class）時，存儲當前線程所執行的字節碼的行號，只是一種概念模型，各種JVM所采用的方式不同，字節碼解釋器工作時，就是通過改變程序計數器的值來選取下一條要執行的指令， 分支、循環、跳轉、等基礎功能都是依賴此技術區完成的。還有一種情況，就是我們常說的Java多線程方面的，多線程就是通過線程輪流切換而達到的，同一時刻，一個內核只能執行一個指令，所以，對于每一個程序來說，必須有一個計數器來記錄程序的執行進度，這樣，當線程恢復執行的時候，才能從正確的地方開始， 所以，每個線程都必須有一個獨立的程序計數器，這類計數器為線程私有的內存。如果一個線程正在執行一個Java方法，則計數器記錄的是字節碼的指令的地址，如果執行的一個Native方法，則計數器的記錄為空，此內存區是唯一一個在Java規范中沒有任何OutOfMemoryError情況的區域。

2、JVM虛擬機棧（JVM Stacks）

JVM虛擬機棧就是我們常說的堆棧的棧（我們常常把內存粗略分為堆和棧），和程序計數器一樣，也是線程私有的，生命周期和線程一樣，每個方法被執行的時候會產生一個棧幀， 用于存儲局部變量表、動態鏈接、操作數、方法出口等信息。方法的執行過程就是棧幀在JVM中出棧和入棧的過程。局部變量表中存放的是各種基本數據類型，如 boolean、byte、char、等8種，及引用類型（存放的是指向各個對象的內存地址），因此，它有一個特點：內存空間可以在編譯期間就確定，運行期不在改變。這個內存區域會有兩種可能的Java異常：StackOverFlowError和OutOfMemoryError。

3、本地方法棧（Native Method Stacks）

從名字即可看出，本地方法棧就是用來處理Java中的本地方法的，Java類的祖先類Object中有眾多Native方法，如hashCode()、 wait()等，他們的執行很多時候是借助于操作系統，但是JVM需要對他們做一些規范，來處理他們的執行過程。此區域，可以有不同的實現方法，像我們常用的Sun的JVM就是本地方法棧和JVM虛擬機棧是同一個。

4、堆（Heap）

堆內存是內存中最重要的一塊，也是最有必要進行深究的一部分。因為Java性能的優化，主要就是針對這部分內存的。所有的對象實例及數組都是在堆上面分配的（隨著JIT技術的逐漸成熟，這句話似乎有些絕對，不過至少目前還基本是這樣的），可通過-Xmx和-Xms來控制堆的大小。JIT 技術的發展產生了新的技術，如棧上分配和標量替換，也許在不久的幾年里，即時編譯會誕生及成熟，那個時候，“所有的對象實例及數組都是在堆上面分配的”這句話就應該稍微改改了。堆內存是垃圾回收的主要區域，所以在下文垃圾回收板塊會重點介紹，此處只做概念方面的解釋。在32位系統上最大為2G，64位系統上無限制?？赏ㄟ^-Xms和-Xmx控制，-Xms為JVM啟動時申請的最小Heap內存，-Xmx為JVM可申請的最大Heap內存。

5、方法區（Method Area）

方法區是所有線程共享的內存區域，用于存儲已經被JVM加載的類信息、常量、靜態變量等數據，一般來說，方法區屬于持久代（關于持久代，會在GC部分詳細介紹，除了持久代，還有新生代和舊生代），也難怪Java規范將方法區描述為堆的一個邏輯部分，但是它不是堆。方法區的垃圾回收比較棘手，就算是Sun的 HotSpot VM在這方面也沒有做得多么完美。此處引入方法區中一個重要的概念：運行時常量池。主要用于存放在編譯過程中產生的字面量（字面量簡單理解就是常量）和引用。一般情況，常量的內存分配在編譯期間就能確定，但不一定全是，有一些可能就是運行時也可將常量放入常量池中，如String類中有個Native方法 intern()。

此處補充一個在JVM內存管理之外的一個內存區：直接內存。在JDK1.4中新加入類NIO類，引入了一種基于通道與緩沖區的I/O方式，它可以使用Native函數庫直接分配堆外內存，即我們所說的直接內存，這樣在某些場景中會提高程序的性能。

二、垃圾回收

有句話說的好：Java和C++之間有一堵有內存分配和垃圾回收技術圍成的墻，墻外的人想進去，墻里的人想出去！這句話的意思，請讀者自己去琢磨。總的來說，C、C++程序員有時苦于內存泄露，內存管理是件令人頭痛的事兒，但是Java程序員呢，又羨慕C++程序員，自己可以控制一切，這樣就不會在內存管理方面顯得束手無策，的確如此，作為Java程序員我們很難去控制JVM的內存回收，只能根據它的原理去適應，盡量提高程序的性能。下面開始講解Java垃圾回收，即Garbage Collection，GC。從以下四個方面進行：

1、為什么要進行垃圾回收？

隨著程序的運行，內存中存在的實例對象、變量等信息占據的內存越來越多，如果不及時進行垃圾回收，必然會帶來程序性能的下降，甚至會因為可用內存不足造成一些不必要的系統異常。

2、哪些“垃圾”需要回收？

在我們上面介紹的五大區中，有三個是不需要進行垃圾回收的：程序計數器、JVM棧、本地方法棧。因為它們的生命周期是和線程同步的，隨著線程的銷毀，它們占用的內存會自動釋放，所以只有方法區和堆需要進行GC。具體到哪些對象的話，簡單概況一句話：如果某個對象已經不存在任何引用，那么它可以被回收。通俗解釋一下就是說，如果一個對象，已經沒有什么作用了，就可以被當廢棄物被回收了。

3、什么時候進行垃圾回收？

根據一個經典的引用計數算法，每個對象添加一個引用計數器，每被引用一次，計數器加1，失去引用，計數器減1，當計數器在一段時間內保持為0時，該對象就認為是可以被回收得了。但是，這個算法有明顯的缺陷：當兩個對象相互引用，但是二者已經沒有作用時，按照常規，應該對其進行垃圾回收，但是其相互引用，又不符合垃圾回收的條件，因此無法完美處理這塊內存清理，因此Sun的JVM并沒有采用引用計數算法來進行垃圾回收。而是采用一個叫：根搜索算法，如下圖：

基本思想就是：從一個叫GC Roots的對象開始，向下搜索，如果一個對象不能到達GC Roots對象的時候，說明它已經不再被引用， 即可被進行垃圾回收（此處暫且這樣理解，其實事實還有一些不同，當一個對象不再被引用時，并沒有完全“死亡”，如果類重寫了finalize()方法，且沒有被系統調用過，那么系統會調用一次finalize()方法，以完成最后的工作，在這期間，如果可以將對象重新與任何一個和GC Roots有引用的對象相關聯，則該對象可以“重生”，如果不可以，那么就說明徹底可以被回收了），如上圖中的Object5、Object6、 Object7，雖然它們3個依然可能相互引用，但是總體來說，它們已經沒有作用了，這樣就解決了引用計數算法無法解決的問題。

補充引用的概念：JDK 1.2之后，對引用進行了擴充，引入了強、軟、若、虛四種引用，被標記為這四種引用的對象，在GC時分別有不同的意義：

a> 強引用(Strong Reference).就是為剛被new出來的對象所加的引用，它的特點就是，永遠不會被回收。

b> 軟引用(Soft Reference).聲明為軟引用的類，是可被回收的對象，如果JVM內存并不緊張，這類對象可以不被回收，如果內存緊張，則會被回收。此處有一個問題，既然被引用為軟引用的對象可以回收，為什么不去回收呢？其實我們知道，Java中是存在緩存機制的，就拿字面量緩存來說，有些時候，緩存的對象就是當前可有可無的，只是留在內存中如果還有需要，則不需要重新分配內存即可使用，因此，這些對象即可被引用為軟引用，方便使用，提高程序性能。

c> 弱引用(Weak Reference).弱引用的對象就是一定需要進行垃圾回收的，不管內存是否緊張，當進行GC時，標記為弱引用的對象一定會被清理回收。

d> 虛引用(Phantom Reference).虛引用弱的可以忽略不計，JVM完全不會在乎虛引用，其唯一作用就是做一些跟蹤記錄，輔助finalize函數的使用。

最后總結，什么樣的類需要回收呢？無用的類，何為無用的類？需滿足如下要求：

1> 該類的所有實例對象都已經被回收。

2> 加載該類的ClassLoader已經被回收。

3> 該類對應的反射類java.lang.Class對象沒有被任何地方引用。

4、如何進行垃圾回收？

本塊內容以介紹垃圾回收算法為主，因為我們前面有介紹，內存主要被分為三塊，新生代、舊生代、持久代。三代的特點不同，造就了他們所用的GC算法不同，新生代適合那些生命周期較短，頻繁創建及銷毀的對象，舊生代適合生命周期相對較長的對象，持久代在Sun HotSpot中就是指方法區（有些JVM中根本就沒有持久代這中說法）。首先介紹下新生代、舊生代、持久代的概念及特點：

新生代：New Generation或者Young Generation。上面大致分為Eden區和Survivor區，Survivor區又分為大小相同的兩部分：FromSpace 和ToSpace。新建的對象都是用新生代分配內存，Eden空間不足的時候，會把存活的對象轉移到Survivor中，新生代的大小可以由-Xmn來控制，也可以用-XX:SurvivorRatio來控制Eden和Survivor的比例.舊生代：Old Generation。用于存放新生代中經過多次垃圾回收仍然存活的對象，例如緩存對象。舊生代占用大小為-Xmx值減去-Xmn對應的值。

持久代：Permanent Generation。在Sun的JVM中就是方法區的意思，盡管有些JVM大多沒有這一代。主要存放常量及類的一些信息默認最小值為16MB，最大值為64MB，可通過-XX:PermSize及-XX:MaxPermSize來設置最小值和最大值。

常見的GC算法：

標記-清除算法（Mark-Sweep）

最基礎的GC算法，將需要進行回收的對象做標記，之后掃描，有標記的進行回收，這樣就產生兩個步驟：標記和清除。這個算法效率不高，而且在清理完成后會產生內存碎片，這樣，如果有大對象需要連續的內存空間時，還需要進行碎片整理，所以，此算法需要改進。

復制算法（Copying）

前面我們談過，新生代內存分為了三份，Eden區和2塊Survivor區，一般Sun的JVM會將Eden區和Survivor區的比例調為8:1，保證有一塊Survivor區是空閑的，這樣，在垃圾回收的時候，將不需要進行回收的對象放在空閑的Survivor區，然后將Eden區和第一塊Survivor區進行完全清理，這樣有一個問題，就是如果第二塊Survivor區的空間不夠大怎么辦？這個時候，就需要當Survivor區不夠用的時候，暫時借持久代的內存用一下。此算法適用于新生代。

標記-整理（或叫壓縮）算法（Mark-Compact）

和標記-清除算法前半段一樣，只是在標記了不需要進行回收的對象后，將標記過的對象移動到一起，使得內存連續，這樣，只要將標記邊界以外的內存清理就行了。此算法適用于持久代。

常見的垃圾收集器：

根據上面說的諸多算法，每天JVM都有不同的實現，我們先來看看常見的一些垃圾收集器：

首先介紹三種實際的垃圾回收器：串行GC（SerialGC）、并行回收GC（Parallel Scavenge）和并行GC（ParNew）。

1、Serial GC。是最基本、最古老的收集器，但是現在依然被廣泛使用，是一種單線程垃圾回收機制，而且不僅如此，它最大的特點就是在進行垃圾回收的時候，需要將所有正在執行的線程暫停（Stop The World），對于有些應用這是難以接受的，但是我們可以這樣想，只要我們能夠做到將它所停頓的時間控制在N個毫秒范圍內，大多數應用我們還是可以接受的，而且事實是它并沒有讓我們失望，幾十毫米的停頓我們作為客戶機（Client）是完全可以接受的，該收集器適用于單CPU、新生代空間較小及對暫停時間要求不是非常高的應用上，是client級別默認的GC方式，可以通過-XX:+UseSerialGC來強制指定。

2、ParNew GC?；竞蚐erial GC一樣，但本質區別是加入了多線程機制，提高了效率，這樣它就可以被用在服務器端（Server）上，同時它可以與CMS GC配合，所以，更加有理由將它置于Server端。

3、Parallel Scavenge GC。在整個掃描和復制過程采用多線程的方式來進行，適用于多CPU、對暫停時間要求較短的應用上，是server級別默認采用的GC方式，可用-XX:+UseParallelGC來強制指定，用-XX:ParallelGCThreads=4來指定線程數。以下給出幾組使用組合：

4、CMS (Concurrent Mark Sweep)收集器。該收集器目標就是解決Serial GC 的停頓問題，以達到最短回收時間。常見的B/S架構的應用就適合用這種收集器，因為其高并發、高響應的特點。CMS收集器是基于“標記-清除”算法實現的，整個收集過程大致分為4個步驟：

初始標記(CMS initial mark)、并發標記(CMS concurrent mark)、重新標記(CMS remark)、并發清除(CMS concurrent sweep)。

其中初始標記、重新標記這兩個步驟任然需要停頓其他用戶線程。初始標記僅僅只是標記出GC ROOTS能直接關聯到的對象，速度很快，并發標記階段是進行GC ROOTS 根搜索算法階段，會判定對象是否存活。而重新標記階段則是為了修正并發標記期間，因用戶程序繼續運行而導致標記產生變動的那一部分對象的標記記錄，這個階段的停頓時間會被初始標記階段稍長，但比并發標記階段要短。由于整個過程中耗時最長的并發標記和并發清除過程中，收集器線程都可以與用戶線程一起工作，所以整體來說，CMS收集器的內存回收過程是與用戶線程一起并發執行的。

CMS收集器的優點：并發收集、低停頓，但是CMS還遠遠達不到完美。

CMS收集器主要有三個顯著缺點：

a>.CMS收集器對CPU資源非常敏感。在并發階段，雖然不會導致用戶線程停頓，但是會占用CPU資源而導致引用程序變慢，總吞吐量下降。CMS默認啟動的回收線程數是：(CPU數量+3) / 4。

b>.CMS收集器無法處理浮動垃圾，可能出現“Concurrent Mode Failure“，失敗后而導致另一次Full GC的產生。由于CMS并發清理階段用戶線程還在運行，伴隨程序的運行自熱會有新的垃圾不斷產生，這一部分垃圾出現在標記過程之后，CMS無法在本次收集中處理它們，只好留待下一次GC時將其清理掉。這一部分垃圾稱為“浮動垃圾”。也是由于在垃圾收集階段用戶線程還需要運行，即需要預留足夠的內存空間給用戶線程使用，因此CMS收集器不能像其他收集器那樣等到老年代幾乎完全被填滿了再進行收集，需要預留一部分內存空間提供并發收集時的程序運作使用。在默認設置下，CMS收集器在老年代使用了68%的空間時就會被激活，也可以通過參數-XX:CMSInitiatingOccupancyFraction的值來提供觸發百分比，以降低內存回收次數提高性能。要是CMS運行期間預留的內存無法滿足程序其他線程需要，就會出現“Concurrent Mode Failure”失敗，這時候虛擬機將啟動后備預案：臨時啟用Serial Old收集器來重新進行老年代的垃圾收集，這樣停頓時間就很長了。所以說參數-XX:CMSInitiatingOccupancyFraction設置的過高將會很容易導致“Concurrent Mode Failure”失敗，性能反而降低。

c>.最后一個缺點，CMS是基于“標記-清除”算法實現的收集器，使用“標記-清除”算法收集后，會產生大量碎片。空間碎片太多時，將會給對象分配帶來很多麻煩，比如說大對象，內存空間找不到連續的空間來分配不得不提前觸發一次Full GC。為了解決這個問題，CMS收集器提供了一個-XX:UseCMSCompactAtFullCollection開關參數，用于在Full GC之后增加一個碎片整理過程，還可通過-XX:CMSFullGCBeforeCompaction參數設置執行多少次不壓縮的Full GC之后，跟著來一次碎片整理過程。

5、G1收集器。相比CMS收集器有不少改進，首先基于標記-整理算法，不會產生內存碎片問題，其次，可以比較精確的控制停頓，此處不再詳細介紹。

6、Serial Old。Serial Old是Serial收集器的老年代版本，它同樣使用一個單線程執行收集，使用“標記-整理”算法。主要使用在Client模式下的虛擬機。

7、Parallel Old。Parallel Old是Parallel Scavenge收集器的老年代版本，使用多線程和“標記-整理”算法。

8、RTSJ垃圾收集器，用于Java實時編程，后續會補充介紹。

三、Java程序性能優化

gc()的調用

調用gc方法暗示著Java 虛擬機做了一些努力來回收未用對象，以便能夠快速地重用這些對象當前占用的內存。當控制權從方法調用中返回時，虛擬機已經盡最大努力從所有丟棄的對象中回收了空間，調用System.gc() 等效于調用Runtime.getRuntime().gc()。

finalize()的調用及重寫

gc只能清除在堆上分配的內存(純java語言的所有對象都在堆上使用new分配內存)，而不能清除棧上分配的內存（當使用JNI技術時,可能會在棧上分配內存，例如java調用c程序，而該c程序使用malloc分配內存時）。因此，如果某些對象被分配了棧上的內存區域，那gc就管不著了，對棧上的對象進行內存回收就要靠finalize()。舉個例子來說,當java 調用非java方法時（這種方法可能是c或是c++的）,在非java代碼內部也許調用了c的malloc()函數來分配內存，而且除非調用那個了 free() 否則不會釋放內存(因為free()是c的函數),這個時候要進行釋放內存的工作,gc是不起作用的,因而需要在finalize()內部的一個固有方法調用free()。

優秀的編程習慣

（1）避免在循環體中創建對象，即使該對象占用內存空間不大。（2）盡量及時使對象符合垃圾回收標準。（3）不要采用過深的繼承層次。（4）訪問本地變量優于訪問類中的變量。

四、常見問題

1、內存溢出

就是你要求分配的java虛擬機內存超出了系統能給你的，系統不能滿足需求，于是產生溢出。2、內存泄漏

是指你向系統申請分配內存進行使用(new)，可是使用完了以后卻不歸還(delete)，結果你申請到的那塊內存你自己也不能再訪問,該塊已分配出來的內存也無法再使用，隨著服務器內存的不斷消耗，而無法使用的內存越來越多，系統也不能再次將它分配給需要的程序，產生泄露。一直下去，程序也逐漸無內存使用，就會溢出。

文章出處：http://blog.csdn.net/zhangerqing