Java內存你們都知道，但你知道要怎麼管理Java內存嗎？

前言

深刻研究Java內存管理，將加強你對堆如何工做、引用類型和垃圾回收的認識。

你可能會思考，若是你使用Java編程，關於內存如何工做你須要瞭解哪些哪些信息?Java能夠進行自動內存管理，並且有一個很好的、安靜的垃圾回收器，它在後臺工做，清理那些未使用的對象並釋放一些內存。

所以，做爲一名Java程序員，你不須要再爲銷燬無用對象這樣的問題而煩惱了。可是，雖然這個過程在Java中是自動的，它也不能保證任何事情。因爲不知道垃圾回收器和Java內存是如何設計的，有些對象即便你再也不使用了，卻也不符合垃圾回收的條件。

所以，瞭解Java中內存實際是如何工做的很是重要，由於它爲你編寫高性能和優化的應用程序提供了幫助，這些應用程序永遠不會因內存不足而崩潰。另外一方面，當你發現本身處於糟糕的境地時，你將可以很快發現內存的漏洞。

首先，讓咱們看看內存在Java中一般是如何組織的：

一般，內存分爲兩大部分：堆棧和堆。請記住，內存類型在上圖中的大小與實際內存大小不成比例。與堆棧相比，堆是一個巨大數量的內存。

堆棧

堆棧內存負責保存對堆對象的引用和存儲值類型（在Java中也稱爲基元類型），值類型保存值自己而不保存對堆中對象的引用。

此外，堆棧上的變量具備必定的可見性，也稱爲做用域。只有活躍做用域內的對象才能被使用。例如，假設咱們沒有任何全局做用域變量(字段)，只有局部變量，若是編譯器執行方法的主體，它只能訪問方法主體內堆棧中的對象。它不能訪問其它局部變量，由於這些變量超出了做用域。一旦方法完成並返回，堆棧頂部就會溢出，活躍做用域也會發生變化。

或許你注意到了在上圖中顯示的多個堆棧內存，這是由於Java中的堆棧內存是按線程分配的。所以，每次一個線程被建立和啓動時，它都有本身的堆棧內存，而且不能訪問另外一個線程的堆棧內存。

堆

堆內存將實際對象存儲在內存中。這些對象被堆棧中的變量引用。例如，讓咱們分析下面一行代碼發生了什麼:

StringBuilder builder = new StringBuilder();

「new」關鍵字負責確保堆上有足夠的可用空間，在內存中建立一個StringBuilder類型的對象，並經過堆棧中的「builder」引用它。

每一個正在運行的JVM進程只有一個堆內存。所以，不管運行多少線程，這都是內存中的一個共享部分。實際上，堆結構與上圖中顯示的略有不一樣。堆自己被分紅幾個部分，這有助於垃圾回收進程。

最大堆棧和堆大小都沒有預約義 - 這取決於正在運行的計算機。 然而，在後文中，咱們將研究一些JVM配置，這些配置容許咱們爲正在運行的應用程序明確設定它們的大小

引用類型

若是仔細觀察內存結構圖片，你或許會注意到，表明對堆中對象引用的箭頭的樣式實際是不一樣的。這是由於，在Java編程語言中，咱們有不一樣類型的引用:強引用、弱引用、軟引用和虛引用。引用類型之間的區別在於它們所引用堆上的對象在不一樣的條件下能夠被做爲垃圾回收。讓咱們來仔細認識一下每一種引用類型。

1. 強引用>>>

這種引用類型是咱們都習慣而且最受歡迎的引用類型。在上面的StringBuilder示例中，咱們實際上使用了對堆中對象的強引用。當有一個強引用指向堆上的對象時，或者經過一系列強引用能夠強訪問該對象，則該對象不會被做爲垃圾回收。

2. 弱引用>>

簡單來講，在下一個垃圾回收進程以後，對堆中對象的弱引用極可能不會繼續存在了。弱引用的建立示例以下:

WeakReference<StringBuilder> reference = new WeakReference<>(new StringBuilder());

弱引用的一個很好的用例是緩存方案。假設你檢索了一些數據，而且還但願將其存儲在內存中—這樣一樣的數據能夠被再次請求。另外一方面，你不肯定什麼時候或者是否會再次請求這些數據。所以，你能夠保留對它的弱引用，萬一垃圾回收器運行，它可能會破壞堆中的對象。所以，過了一下子，若是你想要檢索你引用的對象，你可能會忽然獲得一個空的返回值。緩存方案的一個很好的使用是回收WeakHashMap。若是咱們在Java API中打開WeakHashMap類，咱們會看到它的條目實際上擴展了WeakReference類，並使用它的引用字段做爲映射的關鍵字:

private static class Entry<K,V> extends WeakReference<Object> implements Map.Entry<K,V> 
{ 
V value;
......
}

一旦WeakHashMap中的一個關鍵字被進行了垃圾回收，整個條目就會從映射中移除。

3. 軟引用>>>

這種引用類型用於對內存更敏感的方案，由於只有當應用程序內存不足時，所引用的對象纔會被做爲垃圾回收。所以，只要沒有迫切須要釋放出一些內存空間，垃圾回收器就不會去回收軟引用的對象。Java保證在拋出OutOfMemoryError以前清除全部軟引用的對象。Javadocs代表：「在虛擬機拋出OutOfMemoryError以前，全部對可軟訪問對象的軟引用都會確保被清除。」 與弱引用相似，軟引用的建立示例以下:

SoftReference<StringBuilder> reference = new SoftReference<>(new StringBuilder());
......
}

4. 虛引用>>>

用於算法檢查後的清理操做，由於咱們知道有些對象不須要再存在。僅與引用隊列一塊兒使用，由於此類引用的.get（）方法將始終返回空值。這些引用類型被認爲是優於終結器的。

如何引用字符串

Java中對字符串類型的處理略有不一樣。字符串是不可變的，這意味着每次使用字符串執行操做時，實際上都會在堆上建立另外一個對象。對於字符串，Java在內存中進行字符串池管理。這意味着Java會盡量地存儲和重用字符串。對於字符串文字，更是這樣。例如：

String localPrefix = "297"; //1
String prefix = "297";      //2
if (prefix == localPrefix)
{
    System.out.println("Strings are equal" );
}
else
{
    System.out.println("Strings are different");
}

運行時，將輸出如下內容：

Strings are equal

所以，能夠看出在比較了字符串類型的兩個引用以後，它們實際上指向了堆中的相同對象。可是，這對於被計算的字符串無效。假設咱們對上述代碼的//1行進行如下更改

String localPrefix = new Integer(297).toString(); //1

輸出：

Strings are different

在這種狀況下，咱們實際上看到堆上有兩個不一樣的對象。若是咱們考慮到計算出的字符串會被常用，咱們能夠強制JVM經過在計算的字符串末尾添加.intern（）方法將計算的字符串添加到字符串池當中：

String localPrefix = new Integer(297).toString().intern(); //1

進行上述更改後輸出以下：

Strings are equal

垃圾回收進程

正如前面所討論的，根據堆棧中的變量對堆中對象的引用類型，在某個肯定的時間點，該對象符合垃圾回收器的條件。

比方說，全部紅色的對象都符合被垃圾回收器的條件。 你可能會注意到堆上有一個對象，它對同一堆上的其它對象進行了強引用（例如，多是引用了本身項的列表，或者是具備兩個引用類型字段的對象）。可是，因爲堆棧中的引用丟失，這個對象就沒法再被訪問，所以它也成了垃圾。

爲了更深刻地瞭解細節，咱們先提出如下幾點：

1.這個過程是由Java自動觸發的，什麼時候啓動以及是否啓動此過程取決於Java。

2.實際上這個進程是昂貴的。當垃圾回收器運行時，應用程序中的全部線程都會暫停(取決於GC類型，稍後將對此進行討論)。

3.這其實是一個比垃圾回收和釋放內存更復雜的進程。

儘管由Java決定什麼時候運行垃圾回收器，你也能夠直接調用System.gc( )並指望垃圾回收器在執行這行代碼時運行，對吧？

這是一個錯誤的假設。

你只須要讓Java運行垃圾回收器，可是是否運行垃圾回收器仍然取決於Java。不管如何，不建議直接調用System.gc( )。

因爲這是一個很是複雜的過程，而且它可能會影響你程序的表現，它須要以一個智能的方式實現。 一個被稱做「標記和掃描」的進程來完成此任務。Java分析堆棧中的變量並「標記」全部保持活躍的對象，而後清除全部不會使用的對象。

實際上，Java並無回收任何垃圾。事實上，垃圾越多，標記爲活躍的對象就越少，進程也就越快。爲了使這個進程更加優化，堆內存實際由多個部分組成。咱們能夠經過JVisualVM（Java JDK附帶的工具）可視化內存使用狀況和其它一些有用的東西。您惟一須要作的就是安裝一個名爲Visual GC的插件，它容許您查看內存的實際結構。讓咱們放大一點，分解大局：

當一個對象被建立時，它被分配到Eden(1)區。由於Eden區的空間沒有那麼大，它很快就滿了。垃圾回收器在Eden區運行，並標記出活躍的對象。

一旦一個對象在一次垃圾回收進程中存活，它就會被移動到所謂的倖存者區S0(2)中。 垃圾器第回收二次在Eden區上運行時，它會將全部倖存的對象移動到S1(3)區中。此外，當前在S0(2)區上的全部內容都將被移動到S1(3)區中。

若是一個對象在X輪垃圾回收中存活了下來(取決於JVM的實現，在個人例子中是8輪)，那麼它極可能會永遠存活下來，並被移入到Old(4)區。

結合目前爲止所說的一切，若是你看一下圖中標號(6)的垃圾回收器，它每次運行時，你均可以看到對象切換到倖存者空間，而且Eden區的空間增大了。如此反覆。老一代也能夠被做爲垃圾回收，但因爲它在內存中空間是比Eden區更大的部分，所以這種狀況不會常常發生。Metaspace(5)用於在JVM中存儲已加載類的元數據。

所呈現的圖片其實是一個Java 8的應用程序。在Java 8以前的版本，內存的結構有點不一樣。元空間實際上稱爲PermGen. 區。例如，在Java 6中，此空間還爲字符串池存儲了內存。所以，若是Java 6應用程序中有太多字符串，則它可能會崩潰。歡迎你們關注個人公種浩【程序員追風】，文章都會在裏面更新，整理的資料也會放在裏面。

垃圾回收器類型

實際上，JVM有三種類型的垃圾回收器，程序員能夠選擇應該使用哪一種垃圾回收器。默認狀況下，Java根據底層硬件選擇要使用的垃圾回收器類型。

1.串行垃圾回收器 - 一個單線程回收器。 主要適用於數據使用量較小的小型應用程序。 能夠經過指定命令行選項來啓用：-XX：+ UseSerialGC

2.並行垃圾回收器 - 從命名能夠看出，串行垃圾回收器和並行垃圾回收器之間的區別在於並行垃圾回收器使用多個線程來執行垃圾回收進行。並行垃圾回收器也被稱做吞吐量回收器。能夠經過直接指定選項來啓用它：-XX：+ UseParallelGC

3.主要併發標記垃圾回收器 - 若是你還記得，在本文前面提到垃圾回收過程實際上至關昂貴，而且當它運行時，全部線程都被暫停。可是，咱們有這種大多數併發GC類型，它聲明它與應用程序併發工做。可是，它有「大多數」併發的緣由。它不能100％同時應用於應用程序。線程暫停一段時間。儘管如此，暫停時間儘量短，以實現最佳的GC性能。實際上，有兩種類型的大多數併發GC：

3.1垃圾優先 - 應用程序合理暫停時間內的高吞吐量。 經過如下選項啓用：-XX：+ UseG1GC

3.2併發標記掃描 - 應用程序暫停時間保持最短。能夠經過指定選項來啓用：-XX：+ UseConcMarkSweepGC。從JDK 9開始，這個垃圾回收器類型不推薦使用。。

提示和技巧

1.爲了最小化內存的佔用，請儘量限制變量的做用域。請記住，每次堆棧中的頂級做用域溢出時，來自該做用域的引用都會丟失，這可能會致使相應的對象被做爲垃圾回收。

2.直接對空的、廢棄對象的引用，這會致使被引用的對象被做爲垃圾回收。

3.避免成爲終結者。 它們放慢了進程，不保證任何事情， 更喜歡進行對虛引用的清理工做。

4.當弱引用或軟引用適用時，請不要使用強引用。最多見的內存缺陷是緩存方案，即便數據可能不須要，也會被保存在內存中。

5.JVisualVM還具備在某一點時間點進行堆轉儲的功能，所以你能夠分析每一類所佔用的內存量。

6.根據你的應用程序需求來配置JVM。運行應用程序時，明確指定JVM的堆大小。內存分配進程是寶貴的，所以要爲堆分配一個合理的初始最大內存空間。若是你知道一開始使用較小的初始堆空間是沒有意義的，JVM將擴展這個內存空間。 根據如下命令來明確內存空間：

（1）初始堆大小 -Xms512m 將初始堆大小設置爲512 mb。

（2）最大堆大小 -Xmx1024m 將最大堆大小設置爲1024 mb。

（3）線程堆棧大小 -Xss128m 將線程堆棧大小設置爲128mb。

（4）新生代堆大小 -Xmn256m 將新生代堆大小設置爲256mb。

7.若是Java應用程序崩潰並出現OutOfMemoryError，你須要一些額外的信息來檢測漏洞，運行如下進程：-XX：HeapDumpOnOutOfMemory，它將在下次發生此錯誤時建立堆轉儲文件。

8.使用-verbose：gc選項獲取垃圾回收輸出。 每次進行垃圾回收時，都會生成一個輸出

總結

從內存資源的角度看，瞭解內存是如何組織的，會爲你編寫良好、優化的代碼提供優點。這樣作的好處是，你能夠經過提供最適合你所運行應用程序的不一樣配置，來優化你正在運行的JVM。若是使用正確的工具，發現和修復內存漏洞只是一件容易的事情。

最後

歡迎你們一塊兒交流，喜歡文章記得點個贊喲，感謝支持！