內(nèi)存泄漏的原因

JVM 虛擬機(jī)是使用引用計(jì)數(shù)法和可達(dá)性分析來(lái)判斷對(duì)象是否可回收，本質(zhì)是判斷一個(gè)對(duì)象是否還被引用，如果沒(méi)有引用則回收。

在開發(fā)的過(guò)程中，由于代碼的實(shí)現(xiàn)不同就會(huì)出現(xiàn)很多種內(nèi)存泄漏問(wèn)題，讓gc 系統(tǒng)誤以為此對(duì)象還在引用中，無(wú)法回收，造成內(nèi)存泄漏。

內(nèi)存泄漏的危害

• 長(zhǎng)時(shí)間運(yùn)行，程序變卡，性能嚴(yán)重下降
• 程序莫名其妙掛掉
• OutOfMemoryError錯(cuò)誤
• 亂七八糟的錯(cuò)誤，還不易排查

內(nèi)存泄漏有哪些情況

內(nèi)存泄漏原因很多，因此這里給出最常見的幾種。

1.資源未關(guān)閉造成的內(nèi)存泄漏

各種連接，比如數(shù)據(jù)庫(kù)連接、網(wǎng)絡(luò)連接和IO連接等。

在對(duì)數(shù)據(jù)庫(kù)進(jìn)行操作的過(guò)程中，首先需要建立與數(shù)據(jù)庫(kù)的連接，當(dāng)不再使用時(shí)，需要調(diào)用close方法來(lái)釋放與數(shù)據(jù)庫(kù)的連接。

只有連接被關(guān)閉后，垃圾回收器才會(huì)回收對(duì)應(yīng)的對(duì)象。否則，如果在訪問(wèn)數(shù)據(jù)庫(kù)的過(guò)程中，對(duì)Connection、Statement或ResultSet不顯性地關(guān)閉，將會(huì)造成大量的對(duì)象無(wú)法被回收，從而引起內(nèi)存泄漏，因此最好按照下面的做法處理資源類，偽代碼如下：

publicvoidhandleResource {
try {
// open connection
// handle business
} catch (Throwable t) {
// log stack
} finally {
// close connection
}}

2.靜態(tài)集合類

如HashMap、LinkedList等等，如果這些容器為靜態(tài)的，那么它們的生命周期與程序一致，則容器中的對(duì)象在程序結(jié)束之前將不能被釋放，從而造成內(nèi)存泄漏。

生命周期長(zhǎng)的對(duì)象持有短生命周期對(duì)象的引用，盡管短生命周期的對(duì)象不再使用，但是因?yàn)殚L(zhǎng)生命周期對(duì)象持有它的引用而導(dǎo)致不能被回收。

3.ThreadLocal的誤用

ThreadLocal一定要列在Java內(nèi)存泄露的榜首，總能在不知不覺(jué)中將內(nèi)存泄露掉，一個(gè)常見的例子是：

publicvoidtestThreadLocalMemoryLeaks {
ThreadLocal<List<Integer>> localCache = new ThreadLocal<>;
List<Integer> cacheInstance = new ArrayList<>(10000);
localCache.set(cacheInstance);localCache = new ThreadLocal<>;
}

當(dāng)localCache的值被重置之后cacheInstance被ThreadLocalMap中的value引用，無(wú)法被GC。

但是其key對(duì)ThreadLocal實(shí)例的引用是一個(gè)弱引用，本來(lái)ThreadLocal的實(shí)例被localCache和ThreadLocalMap的key同時(shí)引用，但是當(dāng)localCache的引用被重置之后。

則ThreadLocal的實(shí)例只有ThreadLocalMap的key這樣一個(gè)弱引用了，此時(shí)這個(gè)實(shí)例在GC的時(shí)候能夠被清理。

上面這張圖詳細(xì)地揭示了ThreadLocal和Thread以及ThreadLocalMap三者的關(guān)系。

1)Thread中有一個(gè)map，就是ThreadLocalMap

2)ThreadLocalMap的key是ThreadLocal，值是我們自己設(shè)定的。

3)ThreadLocal是一個(gè)弱引用，當(dāng)為null時(shí)，會(huì)被當(dāng)成垃圾回收

重點(diǎn)來(lái)了，突然我們ThreadLocal是null了，也就是要被垃圾回收器回收了，但是此時(shí)我們的ThreadLocalMap生命周期和Thread的一樣，它不會(huì)回收，這時(shí)候就出現(xiàn)了一個(gè)現(xiàn)象。

那就是ThreadLocalMap的key沒(méi)了，但是value還在，這就造成了內(nèi)存泄漏。

解決辦法：使用完ThreadLocal后，執(zhí)行remove操作，避免出現(xiàn)內(nèi)存溢出情況。

4.變量不合理的作用域

一般而言，一個(gè)變量的定義的作用范圍大于其使用范圍，很有可能會(huì)造成內(nèi)存泄漏。另一方面，如果沒(méi)有及時(shí)地把對(duì)象設(shè)置為null，很有可能導(dǎo)致內(nèi)存泄漏的發(fā)生。

public class UsingRandom {
private String msg;
public void receiveMsg(){
readFromNet();// 從網(wǎng)絡(luò)中接受數(shù)據(jù)保存到msg中
saveDB();// 把msg保存到數(shù)據(jù)庫(kù)中
}
}

如上面這個(gè)偽代碼，通過(guò)readFromNet方法把接受的消息保存在變量msg中，然后調(diào)用saveDB方法把msg的內(nèi)容保存到數(shù)據(jù)庫(kù)中，此時(shí)msg已經(jīng)就沒(méi)用了，由于msg的生命周期與對(duì)象的生命周期相同，此時(shí)msg還不能回收，因此造成了內(nèi)存泄漏。

實(shí)際上這個(gè)msg變量可以放在receiveMsg方法內(nèi)部，當(dāng)方法使用完，那么msg的生命周期也就結(jié)束，此時(shí)就可以回收了。還有一種方法，在使用完msg后，把msg設(shè)置為null，這樣垃圾回收器也會(huì)回收msg的內(nèi)存空間。

5.內(nèi)部類持有外部類

如果一個(gè)外部類的實(shí)例對(duì)象的方法返回了一個(gè)內(nèi)部類的實(shí)例對(duì)象，這個(gè)內(nèi)部類對(duì)象被長(zhǎng)期引用了，即使那個(gè)外部類實(shí)例對(duì)象不再被使用，但由于內(nèi)部類持有外部類的實(shí)例對(duì)象，這個(gè)外部類對(duì)象將不會(huì)被垃圾回收，這也會(huì)造成內(nèi)存泄露。

6.堆外內(nèi)存無(wú)法回收

堆外內(nèi)存不受gc的管理，可能因?yàn)榈谌降腷ug出現(xiàn)內(nèi)存泄漏

內(nèi)存泄漏的解決辦法

1.少使用靜態(tài)變量

盡量減少使用靜態(tài)變量，或者使用完及時(shí) 賦值為 null;

2.明確對(duì)象有效作用域

明確內(nèi)存對(duì)象的有效作用域，盡量縮小對(duì)象的作用域，能用局部變量處理的不用成員變量，因?yàn)榫植孔兞繌棗?huì)自動(dòng)回收；

3.注意聲明周期引用

減少長(zhǎng)生命周期的對(duì)象持有短生命周期的引用；

4.注意Sting的使用

使用StringBuilder和StringBuffer進(jìn)行字符串連接，Sting和StringBuilder以及StringBuffer等都可以代表字符串，其中String字符串代表的是不可變的字符串，后兩者表示可變的字符串。

如果使用多個(gè)String對(duì)象進(jìn)行字符串連接運(yùn)算，在運(yùn)行時(shí)可能產(chǎn)生大量臨時(shí)字符串，這些字符串會(huì)保存在內(nèi)存中從而導(dǎo)致程序性能下降。

5.不需要對(duì)象手動(dòng)設(shè)置Null

對(duì)于不需要使用的對(duì)象手動(dòng)設(shè)置null值，不管GC何時(shí)會(huì)開始清理，我們都應(yīng)及時(shí)的將無(wú)用的對(duì)象標(biāo)記為可被清理的對(duì)象；

6.及時(shí)關(guān)閉各種鏈接

各種連接（數(shù)據(jù)庫(kù)連接，網(wǎng)絡(luò)連接，IO連接）操作，務(wù)必顯示調(diào)用close關(guān)閉。