JVM內存結構

我們都知道，Java代碼是要運行在虛擬機上的，而虛擬機在執行Java程序的過程中會把所管理的內存劃分為若干個不同的數據區域，這些區域都有各自的用途。其中有些區域隨著虛擬機進程的啟動而存在，而有些區域則依賴用戶線程的啟動和結束而建立和銷毀。在《Java虛擬機規范（Java SE 8）》中描述了JVM運行時內存區域結構如下：

1、以上是Java虛擬機規范，不同的虛擬機實現會各有不同，但是一般會遵守規范。

2、規范中定義的方法區，只是一種概念上的區域，并說明了其應該具有什么功能。但是并沒有規定這個區域到底應該處于何處。所以，對于不同的虛擬機實現來說，是由一定的自由度的。

3、不同版本的方法區所處位置不同，上圖中劃分的是邏輯區域，并不是絕對意義上的物理區域。因為某些版本的JDK中方法區其實是在堆中實現的。

4、運行時常量池用于存放編譯期生成的各種字面量和符號應用。但是，Java語言并不要求常量只有在編譯期才能產生。比如在運行期，String.intern也會把新的常量放入池中。

5、除了以上介紹的JVM運行時內存外，還有一塊內存區域可供使用，那就是直接內存。Java虛擬機規范并沒有定義這塊內存區域，所以他并不由JVM管理，是利用本地方法庫直接在堆外申請的內存區域。

6、堆和棧的數據劃分也不是絕對的，如HotSpot的JIT會針對對象分配做相應的優化。

如上，做個總結，JVM內存結構，由Java虛擬機規范定義。描述的是Java程序執行過程中，由JVM管理的不同數據區域。各個區域有其特定的功能。

Java虛擬機規范中定義了Java內存模型（Java Memory Model，JMM），用于屏蔽掉各種硬件和操作系統的內存訪問差異，以實現讓Java程序在各種平臺下都能達到一致的并發效果，JMM規范了Java虛擬機與計算機內存是如何協同工作的：規定了一個線程如何和何時可以看到由其他線程修改過后的共享變量的值，以及在必須時如何同步的訪問共享變量。

原始的Java內存模型存在一些不足，因此Java內存模型在Java1.5時被重新修訂。這個版本的Java內存模型在Java8中仍然在使用。

Java內存模型（不僅僅是JVM內存分區）

Java內存模型即Java Memory Model，簡稱JMM。JMM定義了Java 虛擬機(JVM)在計算機內存(RAM)中的工作方式。JVM是整個計算機虛擬模型，所以JMM是隸屬于JVM的。

Java內存模型定義了多線程之間共享變量的可見性以及如何在需要的時候對共享變量進行同步。原始的Java內存模型效率并不是很理想，因此Java1.5版本對其進行了重構，現在的Java8仍沿用了Java1.5的版本。

一個本地變量可能是原始類型，在這種情況下，它總是“呆在”線程棧上。一個本地變量也可能是指向一個對象的一個引用。在這種情況下，引用（這個本地變量）存放在線程棧上，但是對象本身存放在堆上。一個對象可能包含方法，這些方法可能包含本地變量。這些本地變量仍然存放在線程棧上，即使這些方法所屬的對象存放在堆上。一個對象的成員變量可能隨著這個對象自身存放在堆上。不管這個成員變量是原始類型還是引用類型。靜態成員變量跟隨著類定義一起也存放在堆上。 存放在堆上的對象可以被所有持有對這個對象引用的線程訪問。當一個線程可以訪問一個對象時，它也可以訪問這個對象的成員變量。如果兩個線程同時調用同一個對象上的同一個方法，它們將會都訪問這個對象的成員變量，但是每一個線程都擁有這個成員變量的私有拷貝。

• 關于并發編程
  在并發編程領域，有兩個關鍵問題：線程之間的通信和同步。

• 線程之間的通信
  線程的通信是指線程之間以何種機制來交換信息。在命令式編程中，線程之間的通信機制有兩種共享內存和消息傳遞。

  在共享內存的并發模型里，線程之間共享程序的公共狀態，線程之間通過寫-讀內存中的公共狀態來隱式進行通信，典型的共享內存通信方式就是通過共享對象進行通信。

  在消息傳遞的并發模型里，線程之間沒有公共狀態，線程之間必須通過明確的發送消息來顯式進行通信，在java中典型的消息傳遞方式就是wait()和notify()。

• 線程之間的同步
  同步是指程序用于控制不同線程之間操作發生相對順序的機制。

  在共享內存并發模型里，同步是顯式進行的。程序員必須顯式指定某個方法或某段代碼需要在線程之間互斥執行。

  在消息傳遞的并發模型里，由于消息的發送必須在消息的接收之前，因此同步是隱式進行的。

• Java的并發采用的是共享內存模型

  Java線程之間的通信總是隱式進行，整個通信過程對程序員完全透明。如果編寫多線程程序的Java程序員不理解隱式進行的線程之間通信的工作機制，很可能會遇到各種奇怪的內存可見性問題。

CPU

• 多CPU：一個現代計算機通常由兩個或者多個CPU。其中一些CPU還有多核。從這一點可以看出，在一個有兩個或者多個CPU的現代計算機上同時運行多個線程是可能的。每個CPU在某一時刻運行一個線程是沒有問題的。這意味著，如果你的Java程序是多線程的，在你的Java程序中每個CPU上一個線程可能同時（并發）執行。

• CPU寄存器：每個CPU都包含一系列的寄存器，它們是CPU內內存的基礎。CPU在寄存器上執行操作的速度遠大于在主存上執行的速度。這是因為CPU訪問寄存器的速度遠大于主存。
  高速緩存cache：由于計算機的存儲設備與處理器的運算速度之間有著幾個數量級的差距，所以現代計算機系統都不得不加入一層讀寫速度盡可能接近處理器運算速度的高速緩存（Cache）來作為內存與處理器之間的緩沖：將運算需要使用到的數據復制到緩存中，讓運算能快速進行，當運算結束后再從緩存同步回內存之中，這樣處理器就無須等待緩慢的內存讀寫了。CPU訪問緩存層的速度快于訪問主存的速度，但通常比訪問內部寄存器的速度還要慢一點。每個CPU可能有一個CPU緩存層，一些CPU還有多層緩存。在某一時刻，一個或者多個緩存行（cache lines）可能被讀到緩存，一個或者多個緩存行可能再被刷新回主存。

• 內存：一個計算機還包含一個主存。所有的CPU都可以訪問主存。主存通常比CPU中的緩存大得多。
  運作原理：通常情況下，當一個CPU需要讀取主存時，它會將主存的部分讀到CPU緩存中。它甚至可能將緩存中的部分內容讀到它的內部寄存器中，然后在寄存器中執行操作。當CPU需要將結果寫回到主存中去時，它會將內部寄存器的值刷新到緩存中，然后在某個時間點將值刷新回主存。

  問題

  • 緩存一致性問題：
    在多處理器系統中，每個處理器都有自己的高速緩存，而它們又共享同一主內存（MainMemory）。基于高速緩存的存儲交互很好地解決了處理器與內存的速度矛盾，但是也引入了新的問題：緩存一致性（CacheCoherence）。當多個處理器的運算任務都涉及同一塊主內存區域時，將可能導致各自的緩存數據不一致的情況，如果真的發生這種情況，那同步回到主內存時以誰的緩存數據為準呢？為了解決一致性的問題，需要各個處理器訪問緩存時都遵循一些協議，在讀寫時要根據協議來進行操作，這類協議有MSI、MESI（IllinoisProtocol）、MOSI、Synapse、Firefly及DragonProtocol，等等：

  • 指令重排序問題：
    為了使得處理器內部的運算單元能盡量被充分利用，處理器可能會對輸入代碼進行亂序執行（Out-Of-Order Execution）優化，處理器會在計算之后將亂序執行的結果重組，保證該結果與順序執行的結果是一致的，但并不保證程序中各個語句計算的先后順序與輸入代碼中的順序一致。因此，如果存在一個計算任務依賴另一個計算任務的中間結果，那么其順序性并不能靠代碼的先后順序來保證。與處理器的亂序執行優化類似，Java虛擬機的即時編譯器中也有類似的指令重排序（Instruction Reorder）優化

JMM和硬件內存架構之間的橋接

Java內存模型與硬件內存架構之間存在差異。硬件內存架構沒有區分線程棧和堆。對于硬件，所有的線程棧和堆都分布在主內存中。部分線程棧和堆可能有時候會出現在CPU緩存中和CPU內部的寄存器中。如下圖所示：

從抽象的角度來看，JMM定義了線程和主內存之間的抽象關系：

• 線程之間的共享變量存儲在主內存（Main Memory）中
• 每個線程都有一個私有的本地內存（Local Memory），本地內存是JMM的一個抽象概念，并不真實存在，它涵蓋了緩存、寫緩沖區、寄存器以及其他的硬件和編譯器優化。本地內存中存儲了該線程以讀/寫共享變量的拷貝副本。
• 從更低的層次來說，主內存就是硬件的內存，而為了獲取更好的運行速度，虛擬機及硬件系統可能會讓工作內存優先存儲于寄存器和高速緩存中。
• Java內存模型中的線程的工作內存（working memory）是cpu的寄存器和高速緩存的抽象描述。而JVM的靜態內存儲模型（JVM內存模型）只是一種對內存的物理劃分而已，它只局限在內存，而且只局限在JVM的內存。

JMM模型下的線程間通信：

JMM決定一個線程對共享變量的寫入何時對另一個線程可見。從抽象的角度來看，JMM定義了線程和主內存之間的抽象關系：線程之間的共享變量存儲在主內存（main memory）中，每個線程都有一個私有的本地內存（local memory），本地內存中存儲了該線程以讀/寫共享變量的副本。本地內存是JMM的一個抽象概念，并不真實存在。它涵蓋了緩存，寫緩沖區，寄存器以及其他的硬件和編譯器優化。

線程間通信必須要經過主內存。

如下，如果線程A與線程B之間要通信的話，必須要經歷下面2個步驟：

1）線程A把本地內存A中更新過的共享變量刷新到主內存中去。

2）線程B到主內存中去讀取線程A之前已更新過的共享變量。

關于主內存與工作內存之間的具體交互協議，即一個變量如何從主內存拷貝到工作內存、如何從工作內存同步到主內存之間的實現細節，Java內存模型定義了以下八種操作來完成：

• lock（鎖定）：作用于主內存的變量，把一個變量標識為一條線程獨占狀態。
• unlock（解鎖）：作用于主內存變量，把一個處于鎖定狀態的變量釋放出來，釋放后的變量才可以被其他線程鎖定。
• read（讀取）：作用于主內存變量，把一個變量值從主內存傳輸到線程的工作內存中，以便隨后的load動作使用
• load（載入）：作用于工作內存的變量，它把read操作從主內存中得到的變量值放入工作內存的變量副本中。
• use（使用）：作用于工作內存的變量，把工作內存中的一個變量值傳遞給執行引擎，每當虛擬機遇到一個需要使用變量的值的字節碼指令時將會執行這個操作。
• assign（賦值）：作用于工作內存的變量，它把一個從執行引擎接收到的值賦值給工作內存的變量，每當虛擬機遇到一個給變量賦值的字節碼指令時執行這個操作。
• store（存儲）：作用于工作內存的變量，把工作內存中的一個變量的值傳送到主內存中，以便隨后的write的操作。
• write（寫入）：作用于主內存的變量，它把store操作從工作內存中一個變量的值傳送到主內存的變量中。

Java內存模型還規定了在執行上述八種基本操作時，必須滿足如下規則：

如果要把一個變量從主內存中復制到工作內存，就需要按順尋地執行read和load操作， 如果把變量從工作內存中同步回主內存中，就要按順序地執行store和write操作。但Java內存模型只要求上述操作必須按順序執行，而沒有保證必須是連續執行。

• 不允許read和load、store和write操作之一單獨出現
• 不允許一個線程丟棄它的最近assign的操作，即變量在工作內存中改變了之后必須同步到主內存中。
• 不允許一個線程無原因地（沒有發生過任何assign操作）把數據從工作內存同步回主內存中。
• 一個新的變量只能在主內存中誕生，不允許在工作內存中直接使用一個未被初始化（load或assign）的變量。即就是對一個變量實施use和store操作之前，必須先執行過了assign和load操作。
• 一個變量在同一時刻只允許一條線程對其進行lock操作，但lock操作可以被同一條線程重復執行多次，多次執行lock后，只有執行相同次數的unlock操作，變量才會被解鎖。lock和unlock必須成對出現
• 如果對一個變量執行lock操作，將會清空工作內存中此變量的值，在執行引擎使用這個變量前需要重新執行load或assign操作初始化變量的值
• 如果一個變量事先沒有被lock操作鎖定，則不允許對它執行unlock操作；也不允許去unlock一個被其他線程鎖定的變量。
• 對一個變量執行unlock操作之前，必須先把此變量同步到主內存中（執行store和write操作）。

JMM可見性問題

可見性（共享對象可見性）：線程對共享變量修改的可見性。當一個線程修改了共享變量的值，其他線程能夠立刻得知這個修改

線程緩存導致的可見性問題：

如果兩個或者更多的線程在沒有正確的使用volatile聲明或者同步的情況下共享一個對象，一個線程更新這個共享對象可能對其它線程來說是不可見的：共享對象被初始化在主存中。跑在CPU上的一個線程將這個共享對象讀到CPU緩存中，然后修改了這個對象。只要CPU緩存沒有被刷新會主存，對象修改后的版本對跑在其它CPU上的線程都是不可見的。這種方式可能導致每個線程擁有這個共享對象的私有拷貝，每個拷貝停留在不同的CPU緩存中。

解決這個內存可見性問題你可以使用：

• Java中的volatile關鍵字：volatile關鍵字可以保證直接從主存中讀取一個變量，如果這個變量被修改后，總是會被寫回到主存中去。Java內存模型是通過在變量修改后將新值同步回主內存，在變量讀取前從主內存刷新變量值這種依賴主內存作為傳遞媒介的方式來實現可見性的，無論是普通變量還是volatile變量都是如此，普通變量與volatile變量的區別是：volatile的特殊規則保證了新值能立即同步到主內存，以及每個線程在每次使用volatile變量前都立即從主內存刷新。因此我們可以說volatile保證了多線程操作時變量的可見性，而普通變量則不能保證這一點。
• Java中的synchronized關鍵字：同步快的可見性是由“如果對一個變量執行lock操作，將會清空工作內存中此變量的值，在執行引擎使用這個變量前需要重新執行load或assign操作初始化變量的值”、“對一個變量執行unlock操作之前，必須先把此變量同步回主內存中（執行store和write操作）”這兩條規則獲得的。
• Java中的final關鍵字：final關鍵字的可見性是指，被final修飾的字段在構造器中一旦被初始化完成，并且構造器沒有把“this”的引用傳遞出去（this引用逃逸是一件很危險的事情，其他線程有可能通過這個引用訪問到“初始化了一半”的對象），那么在其他線程就能看見final字段的值（無須同步）

重排序導致的可見性問題：

Java程序中天然的有序性可以總結為一句話：如果在本地線程內觀察，所有操作都是有序的（“線程內表現為串行”(Within-Thread As-If-Serial Semantics)）；如果在一個線程中觀察另一個線程，所有操作都是無序的（“指令重排序”現象和“線程工作內存與主內存同步延遲”現象）。

Java語言提供了volatile和synchronized兩個關鍵字來保證線程之間操作的有序性：

• volatile關鍵字本身就包含了禁止指令重排序的語義
• synchronized則是由“一個變量在同一個時刻只允許一條線程對其進行lock操作”這條規則獲得的，這個規則決定了持有同一個鎖的兩個同步塊只能串行地進入

一、Java內存分配

Java虛擬機在執行Java程序的過程中會把它所管理的內存劃分為若干個不同的數據區域。這些區域存儲不同類型的數據，這些區域的內存分配和銷毀的時間也不同，有的區域隨著虛擬機進程的啟動而存在，有些區域則是依賴用戶線程的啟動和結束而建立和銷毀。根據《Java虛擬機規范（第2版）》的規定，Java虛擬機管理的內存包括五個運行時數據區域，如下圖所示：

1、方法區

方法區（Method Area）是各個線程共享的內存區域，它用于存儲已被虛擬機加載的類信息（包括類的名稱、方法信息、成員變量信息）、常量、靜態變量、以及編譯器編譯后的代碼等數據。當方法區無法滿足內存分配需求時，將拋出OutOfMemeryError異常。
? ??運行時常量池（Runtime Constant Pool）是方法區的一部分,此區域會在兩種情況下存儲數據。

（1）class文件的常量池中的數據

class文件中的常量池用于存放編譯期生成的各種字面值和常量，這部分內容在類被加載后存放到方法區的運行時常量池中。

字面值：private String name=“zhangSan”；private int age = 23+3；

常量：private final String TAG = “MainActivity”；private final int age = 26;

（2）運行期間生成的常量

運行時常量池相對于class文件常量池的另外一個重要特征是具備動態性，Java語言并不要求常量一定只能在編譯期產生，也就是并非預置入class文件中常量池的內容才能進入方法區運行時常量池，運行期間也可能將新的常量放入池中，這種特性被開發人員利用得比較多的便是String類的intern()方法。String str = “abc”.intern();當運行時常量池中存在字符串"abc時，將該字符串的引用返回，賦值給str，否則創建字符串"abc"，加入運行時常量池中，并返回引用賦值給str。既然運行時常量池是方法區的一部分，自然會受到方法區內存的限制，當常量池無法再申請到內存時會拋出OutOfMemoryError異常。

2、虛擬機棧

虛擬機棧是線程私有的內存空間，每個線程都有一個線程棧，每個方法被執行時都會創建一個棧幀，方法執行完成，棧幀彈出，線程運行結束，線程棧被回收。虛擬機棧就是Java中的方法執行的內存模型，每個方法在執行的同時都會創建一個棧幀，這個棧幀用于存儲局部變量表、操作數棧、指向當前方法所屬的類的運行時常量池的引用、方法返回地址等信息，每個方法從調用直至執行完成的過程，就對應著一個棧幀在虛擬機棧中入棧到出棧的過程。局部變量表用來存儲方法中的局部變量，包括方法中聲明的變量以及函數形參。對于基本數據類型的變量，則直接存儲它的值，對于引用類型的變量，則存的是指向對象的引用。局部變量表的大小在編譯器就可以確定其大小，并且在程序執行期間局部變量表的大小是不會改變的。程序中的所有計算過程都是在借助于操作數棧來完成的。指向運行時常量池的引用，因為在方法執行的過程中有可能需要用到類中的常量，所以必須要有一個引用指向當前方法所屬的類的運行時常量池。方法返回地址，當一個方法執行完畢之后，要返回之前調用它的地方，因此在棧幀中必須保存一個方法返回地址。

在Java虛擬機規范中，對這個區域規定了兩種異常狀況：如果線程請求的棧深度大于虛擬機所允許的深度，將拋出StackOverflowError異常；如果虛擬機?？梢詣討B擴展（當前大部分的Java虛擬機都可動態擴展，只不過Java虛擬機規范中也允許固定長度的虛擬機棧），當擴展時無法申請到足夠的內存時會拋出OutOfMemoryError異常。

3、本地方法棧

本地方法棧也是線程私有的內存空間，本地方法棧與Java棧所發揮的作用是非常相似的，它們之間的區別不過是Java棧執行Java方法，本地方法棧執行的是本地方法，有的虛擬機直接把本地方法棧和虛擬機棧合二為一。

4、堆

Java堆是Java虛擬機所管理的內存中最大的一塊，在虛擬機啟動時創建，此內存區域的目的就是存放對象實例，幾乎所有的對象實例都在這里分配內存。從內存分配的角度來看，線程共享的Java堆中可能劃分出多個線程私有的分配緩沖區(TLAB)。Java堆可以處于物理上不連續的內存空間，只要邏輯上連續即可，在實現上，既可以實現固定大小的，也可以是擴展的。如果堆中沒有足夠的內存分配給實例，并且堆也無法再拓展時，將會拋出OutOfMemeryError異常。

堆是運行時動態分配內存，對象在沒有引用變量指向它的時候，才變成垃圾，但是仍然占著內存，在程序空閑的時候（沒有工作線程運行，GC線程優先級最低）或者堆內存不足的時候（GC線程被觸發），被垃圾回收器釋放掉，由于要在運行時動態分配內存，存取速度較慢。

5、程序計數器

程序計數器的作用可以看做是當前線程所執行的字節碼的行號指示。字節碼解釋器工作時就是通過改變這個計數器的值來選取下一條需要執行的字節碼指令，分支、循環、跳轉、異常處理、線程恢復等基礎功能都需要依賴這個計數器來完成。由于Java虛擬機的多線程是通過線程輪流切換并分配處理器執行時間的方式來實現的，在任何一個確定的時刻，一個處理器（對于多核處理器來說是一個內核）只會執行一條線程中的指令。因此，為了線程切換后能恢復到正確的執行位置，每條線程都需要有一個獨立的程序計數器，各條線程之間的計數器互不影響，獨立存儲，我們稱這類內存區域為線程私有的內存。如果線程正在執行的是一個Java方法，這個計數器記錄的是正在執行的虛擬機字節碼指令的地址；如果正在執行的是Natvie方法，這個計數器值則為空。

Java內存回收

對于虛擬機?？臻g，當方法調用結束后，基本類型變量、引用類型變量、形參占據的空間會被自動釋放，但引用類型指向的對象在堆中，堆中的無用內存由垃圾回收線程回收，GC線程優先級最低，只有當沒有工作線程存在時GC線程才會執行，或者堆空間不足時會自動觸發GC線程工作。除了回收內存，GC線程還負責整理堆中的碎片。

四種引用類型

Java中的對象引用分為四種，強引用類型、軟引用類型、弱引用類型、虛引用類型。Java中提供這四種引用類型主要有兩個目的：第一是可以讓程序員通過代碼的方式決定某些對象的生命周期；第二是有利于JVM進行垃圾回收。使用軟引用和弱引用可以有效的避免oom。軟引用關聯的對象，只有軟引用關聯時，才可回收，如果有強引用同時關聯，不會回收對象占用的內存，弱引用也如此。

（1）強引用

強引用是使用最普遍的引用，類似Object obj = new Object()、String str = “hello”。如果一個對象具有強引用，那垃圾回收器絕不會回收它。當內存空間不足，Java虛擬機寧愿拋出OutOfMemoryError錯誤，使程序異常終止，也不會靠隨意回收具有強引用的對象來解決內存不足的問題。
（2）軟引用（SoftReference）

軟引用是用來描述一些有用但并不是必需的對象，在Java中用java.lang.ref.SoftReference類來表示，如果內存空間足夠，垃圾回收器就不會回收它；如果內存空間不足了，就會回收這些對象的內存。只要垃圾回收器沒有回收它，該對象就可以被程序使用。軟引用通常用于網頁緩存、圖片緩存，防止內存溢出，在內存充足的時候，緩存對象會一直存在，在內存不足的時候，緩存對象占用的內存會被垃圾收集器回收。使用示例：

public void testSoftReference() {Map<String,SoftReference<Bitmap>> imagesCache = new HashMap<String,SoftReference<Bitmap>>();Bitmap bitmap = getBitmap();SoftReference<Bitmap> image1 = new SoftReference<Bitmap>(bitmap);imagesCache.put("image1",image1);SoftReference<Bitmap> result_SoftReference = imagesCache.get("image1");Bitmap result_Bitmap = result_SoftReference .get();}import java.lang.ref.SoftReference;public class Main {public static void main(String[] args) {SoftReference<String> sr = new SoftReference<String>(new String("hello"));System.out.println(sr.get());}}

（3）弱引用（WeakReference）

弱引用也是用來描述非必需對象的，但是它的強度比軟引用更弱一些，在java中用java.lang.ref.WeakReference類來表示。當垃圾收集器工作時，無論當前內存是否足夠，都會回收掉只被弱引用關聯的對象，不過由于垃圾回收器是一個優先級很低的線程，因此不一定會很快發現那些只具有弱引用的對象。弱引用可以用于：單例類持有一個activity引用時，會造成內存泄露，把activity聲明為弱引用，在activity銷毀后，垃圾收集器掃描到activity對象時，會回收activity對象的內存。使用示例：

public class SingleTon1 { private static final SingleTon1 mInstance = null; private WeakReference<Context> mContext;private SingleTon1(WeakReference<Context> context) { mContext = context;} public static SingleTon1 getInstance(WeakReference<Context> context) { if (mInstance == null) { synchronized (SingleTon1.class) { if (mInstance == null) { mInstance = new SingleTon1(context); } } } return mInstance; } } public class MyActivity extents Activity {public void onCreate (Bundle savedInstanceState){super.onCreate(savedInstanceState);setContentView(R.layout.main);SingleTon1 singleTon1 = SingleTon1.getInstance(new WeakReference<Context>(this));}}import java.lang.ref.WeakReference;public class Main {public static void main(String[] args) {WeakReference<String> sr = new WeakReference<String>(new String("hello"));System.out.println(sr.get());System.gc(); //通知JVM的gc進行垃圾回收System.out.println(sr.get());}}

輸出結果：

hello null

第二個輸出結果是null，這說明只要JVM進行垃圾回收，被弱引用關聯的對象必定會被回收掉。不過要注意的是，這里所說的被弱引用關聯的對象是指只有弱引用與之關聯，如果存在強引用同時與之關聯，則進行垃圾回收時也不會回收該對象（軟引用也是如此）。

（4）虛引用

虛引用和軟引用、弱引用不同，它并不影響對象的生命周期，也無法通過虛引用來取得一個對象實例，在java中用java.lang.ref.PhantomReference類表示。如果一個對象與虛引用關聯，則跟沒有引用與之關聯一樣，在任何時候都可能被垃圾回收器回收。虛引用必須和引用隊列（ReferenceQueue）聯合使用，如下：

import java.lang.ref.PhantomReference;import java.lang.ref.ReferenceQueue;public class Main {public static void main(String[] args) {ReferenceQueue<String> queue = new ReferenceQueue<String>();PhantomReference<String> pr = new PhantomReference<String>(new String("hello"), queue);System.out.println(pr.get());}}

2、垃圾回收算法

（1）標記-清除（Mark-Sweep）

標記-清除（Mark-Sweep）算法，分為標記和清除兩個階段：首先標記出所有需要回收的對象，在標記完成后統一回收掉所有被標記的對象。

標記-清除算法主要問題是：
1、效率問題，標記和清除過程的效率很低
2、空間問題，標記清除之后會產生大量不連續的內存碎片，空間碎片太多可能會導致，當程序在以后的運行過程中需要分配較大對象時無法找到足夠的連續內存而不得不提前觸發另一次垃圾收集

（2）復制（Copying）算法

復制算法，它將可用內存按容量劃分為大小相等的兩塊，每次只使用其中的一塊。當這一塊的內存用完了，就將還存活著的對象復制到另外一塊上面，然后再把已使用過的內存空間一次清理掉。這樣使得每次都是對其中的一塊進行內存回收，內存分配時也就不用考慮內存碎片等復雜情況，只要移動堆頂指針，按順序分配內存即可，實現簡單，運行高效。

復制算法的主要問題是：
1、復制算法將內存縮小為原來的一半，過于浪費
2、對象存活率較高時就要執行較多的復制操作，造成頻繁GC,效率將會變低

（3）標記-整理（Mark-Compact）

標記-整理算法的標記過程仍然與標記-清除算法一樣，但后續步驟不是直接對可回收對象進行清理，而是讓所有存活的對象都向一端移動，然后直接清理掉端邊界以外的內存，這樣連續的內存空間就比較多了。

? ? 如上圖所示，所有存活的對象依次向左上角移動，（0,4）移動到（0,2），（1,0）移動到（0,3），依次類推，當所有的存活對象移動完成后，把剩余的所有空間清空，也就是清空（1,1）后的所有空間。

（4）分代回收（generational collection）

程序創建的大部分對象的生命周期都很短，只有一小部分對象的生命周期比較長，根據這樣的規律，一般把Java堆分為Young Generation（新生代），Old Generation（老年代）和Permanent Generation（持久代），上面幾種算法是通過分代回收混合在一起的，這樣就可以根據各個年代的特點采用最適當的回收算法。

（1）新生代

在新生代中，有一個叫Eden Space的空間，主要是用來存放新生的對象，還有兩個Survivor Spaces（from、to），?這兩個區域大小相等，相當于copying算法中的兩個區域，它們用來存放每次垃圾回收后存活下來的對象。在新生代中，垃圾回收一般用Copying的算法，速度快。

當新建對象無法放入eden區時，將觸發minor collection（minorGC 是清理新生代的GC線程，eden的清理，from、to的清理都由MinorGC完成），將eden區與from區的存活對象復制到to區，經過一次垃圾回收，eden區和from區清空，to區中則緊密的存放著存活對象；當eden區再次滿時，minor collection將eden區和to區的存活對象復制到from區，eden區和to區被清空，from區存放eden區和to區的存活對象，就這樣from區和to區來回切換。如果進行minor collection的時候，發現to區放不下，則將eden區和from區的部分對象放入成熟代。另一方面，即使to區沒有滿，JVM依然會移動世代足夠久遠的對象到成熟代。

（2）成熟代

在成熟代中主要存放應用程序中生命周期長的內存對象，垃圾回收一般用mark-compact的算法，速度慢些，但減少內存要求。如果成熟代放滿對象，無法從新生代移入新的對象，那么將觸發major collection（major GC清理整合OldGen的內存空間）。
（3）永久代

在永久代中，主要用來放JVM自己的反射對象，比如類對象、方法對象、成員變量對象、構造方法對象等。
? ? 此外，垃圾回收一般是在程序空閑的時候（沒有工作線程，GC線程優先級較低）或者堆內存不足的時候自動觸發，也可以調用System.gc()主動的通知Java虛擬機進行垃圾回收，但這只是個建議，Java虛擬機不一定馬上執行，啟動時機的選擇由JVM決定，并且取決于堆內存中Eden區是否可用。

說明：
from, to: 這兩個區域大小相等，相當于copying算法中的兩個區域，當新建對象無法放入eden區時，將出發minor collection。JVM采用copying算法，將eden區與from區的可到達對象復制到to區。經過一次垃圾回收，eden區和from區清空，to區中則緊密的存放著存活對象。隨后from區成為新的to區， to區成為新的from區。如果進行minor collection的時候，發現to區放不下，則將部分對象放入成熟世代。另一方面，即使to區沒有滿，JVM依然會移動世代足夠久遠的對象到成熟世代。如果成熟世代放滿對象，無法移入新的對象，那么將觸發major collection（Full回收）。

總結

以上是生活随笔為你收集整理的Java内存结构(JVM)与内存模型(JMM)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。