7種可能會(huì)導(dǎo)致內(nèi)存泄漏的場(chǎng)景！
雖然Java程序員不用像C/C++程序員那樣時(shí)刻關(guān)注內(nèi)存的使用情況，JVM會(huì)幫我們處理好這些，但并不是說有了GC就可以高枕無憂，內(nèi)存泄露相關(guān)的問題一般在測(cè)試的時(shí)候很難發(fā)現(xiàn)，一旦上線流量起來可能馬上就是一個(gè)詭異的線上故障。
1. 內(nèi)存泄露的定義
如果GC無法回收內(nèi)存中不再使用的對(duì)象，則定義為內(nèi)存有泄露
2. 未關(guān)閉的資源類
當(dāng)我們?cè)诔绦蛑写蜷_一個(gè)新的流或者是新建一個(gè)網(wǎng)絡(luò)連接的時(shí)候，JVM都會(huì)為這些資源類分配內(nèi)存做緩存，常見的資源類有網(wǎng)絡(luò)連接，數(shù)據(jù)庫(kù)連接以及IO流。值得注意的是，如果在業(yè)務(wù)處理中異常，則有可能導(dǎo)致程序不能執(zhí)行關(guān)閉資源類的代碼，因此最好按照下面的做法處理資源類
public void handleResource() {
try {
// open connection
// handle business
} catch (Throwable t) {
// log stack
} finally {
// close connection
}
}
3. 未正確實(shí)現(xiàn)equals()和hashCode()
假如有下面的這個(gè)類
public class Person {
public String name;
public Person(String name) {
this.name = name;
}
}
并且如果在程序中有下面的操作
@Test
public void givenMapWhenEqualsAndHashCodeNotOverriddenThenMemoryLeak() {
Map<Person, Integer> map = new HashMap<>();
for(int i=0; i<100; i++) {
map.put(new Person("jon"), 1);
}
Assert.assertFalse(map.size() == 1);
}
可以預(yù)見，這個(gè)單元測(cè)試并不能通過，原因是Person類沒有實(shí)現(xiàn)equals方法，因此使用Object的equals方法，直接比較實(shí)體對(duì)象的地址，所以map.size() == 100
如果我們改寫Person類的代碼如下所示：
public class Person {
public String name;
public Person(String name) {
this.name = name;
}
@Override
public boolean equals(Object o) {
if (o == this) return true;
if (!(o instanceof Person)) {
return false;
}
Person person = (Person) o;
return person.name.equals(name);
}
@Override
public int hashCode() {
int result = 17;
result = 31 * result + name.hashCode();
return result;
}
}
則上文中的單元測(cè)試就可以順利通過了，需要注意的是這個(gè)場(chǎng)景比較隱蔽，一定要在平時(shí)的代碼中注意。
4. 非靜態(tài)內(nèi)部類
要知道，所有的非靜態(tài)類別類都持有外部類的引用，因此某些情況如果引用內(nèi)部類可能延長(zhǎng)外部類的生命周期，甚至持續(xù)到進(jìn)程結(jié)束都不能回收外部類的空間，這類內(nèi)存溢出一般在Android程序中比較多，只要MyAsyncTask處于運(yùn)行狀態(tài)MainActivity的內(nèi)存就釋放不了，很多時(shí)候安卓開發(fā)者這樣做只是為了在內(nèi)部類中拿到外部類的屬性，殊不知，此時(shí)內(nèi)存已經(jīng)泄露了。
public class MainActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
new MyAsyncTask().execute();
}
private class MyAsyncTask extends AsyncTask {
@Override
protected Object doInBackground(Object[] params) {
return doSomeStuff();
}
private Object doSomeStuff() {
//do something to get result
return new MyObject();
}
}
}
5. 重寫了finalize()的類
如果運(yùn)行下面的這個(gè)例子，則最終程序會(huì)因?yàn)镺OM的原因崩潰
public class Finalizer {
@Override
protected void finalize() throws Throwable {
while (true) {
Thread.yield();
}
}
public static void main(String str[]) {
while (true) {
for (int i = 0; i < 100000; i++) {
Finalizer force = new Finalizer();
}
}
}
}
JVM對(duì)重寫了finalize()的類的處理稍微不同，首先會(huì)針對(duì)這個(gè)類創(chuàng)建一個(gè)java.lang.ref.Finalizer類，并讓java.lang.ref.Finalizer持有這個(gè)類的引用，在上文中的例子中，因?yàn)?code style="overflow-wrap: break-word;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(30, 107, 184);background-color: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;">Finalizer類的引用被java.lang.ref.Finalizer持有，所以他的實(shí)例并不能被Young GC清理，反而會(huì)轉(zhuǎn)入到老年代。在老年代中，JVM GC的時(shí)候會(huì)發(fā)現(xiàn)Finalizer類只被java.lang.ref.Finalizer引用，因此將其標(biāo)記為可GC狀態(tài)，并放入到java.lang.ref.Finalizer.ReferenceQueue這個(gè)隊(duì)列中。等到所有的Finalizer類都加到隊(duì)列之后，JVM會(huì)起一個(gè)后臺(tái)線程去清理java.lang.ref.Finalizer.ReferenceQueue中的對(duì)象，之后這個(gè)后臺(tái)線程就專門負(fù)責(zé)清理java.lang.ref.Finalizer.ReferenceQueue中的對(duì)象了。這個(gè)設(shè)計(jì)看起來是沒什么問題的，但其實(shí)有個(gè)坑，那就是負(fù)責(zé)清理java.lang.ref.Finalizer.ReferenceQueue的后臺(tái)線程優(yōu)先級(jí)是比較低的，并且系統(tǒng)沒有提供可以調(diào)節(jié)這個(gè)線程優(yōu)先級(jí)的接口或者配置。因此當(dāng)我們?cè)谑褂檬褂弥貙?code style="overflow-wrap: break-word;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(30, 107, 184);background-color: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;">finalize()方法的對(duì)象時(shí)，千萬不要瞬間產(chǎn)生大量的對(duì)象，要時(shí)刻謹(jǐn)記，JVM對(duì)此類對(duì)象的處理有特殊邏輯。
6. 針對(duì)長(zhǎng)字符串調(diào)用String.intern()
如果提前在src/test/resources/large.txt中寫入大量字符串，并且在Java 1.6及以下的版本運(yùn)行下面程序，也將得到一個(gè)OOM
@Test
public void givenLengthString_whenIntern_thenOutOfMemory()
throws IOException, InterruptedException {
String str
= new Scanner(new File("src/test/resources/large.txt"), "UTF-8")
.useDelimiter("\\A").next();
str.intern();
System.gc();
Thread.sleep(15000);
}
原因是在Java 1.6及以下，字符串常量池是處于JVM的PermGen區(qū)的，并且在程序運(yùn)行期間不會(huì)GC，因此產(chǎn)生了OOM。在Java 1.7以及之后字符串常量池轉(zhuǎn)移到了HeapSpace此類問題也就無需再關(guān)注了
7. ThreadLocal的誤用
ThreadLocal一定要列在Java內(nèi)存泄露的榜首，總能在不知不覺中將內(nèi)存泄露掉，一個(gè)常見的例子是：
@Test
public void testThreadLocalMemoryLeaks() {
ThreadLocal<List<Integer>> localCache = new ThreadLocal<>();
List<Integer> cacheInstance = new ArrayList<>(10000);
localCache.set(cacheInstance);
localCache = new ThreadLocal<>();
}
當(dāng)localCache的值被重置之后cacheInstance被ThreadLocalMap中的value引用，無法被GC，但是其key對(duì)ThreadLocal實(shí)例的引用是一個(gè)弱引用，本來ThreadLocal的實(shí)例被localCache和ThreadLocalMap的key同時(shí)引用，但是當(dāng)localCache的引用被重置之后，則ThreadLocal的實(shí)例只有ThreadLocalMap的key這樣一個(gè)弱引用了，此時(shí)這個(gè)實(shí)例在GC的時(shí)候能夠被清理。
其實(shí)看過ThreadLocal源碼的同學(xué)會(huì)知道，ThreadLocal本身對(duì)于key為null的Entity有自清理的過程，但是這個(gè)過程是依賴于后續(xù)對(duì)ThreadLocal的繼續(xù)使用，假如上面的這段代碼是處于一個(gè)秒殺場(chǎng)景下，會(huì)有一個(gè)瞬間的流量峰值，這個(gè)流量峰值也會(huì)將集群的內(nèi)存打到高位(或者運(yùn)氣不好的話直接將集群內(nèi)存打滿導(dǎo)致故障)，后面由于峰值流量已過，對(duì)ThreadLocal的調(diào)用也下降，會(huì)使得ThreadLocal的自清理能力下降，造成內(nèi)存泄露。ThreadLocal的自清理實(shí)現(xiàn)是錦上添花，千萬不要指望它雪中送碳。
8. 類的靜態(tài)變量
Tomcat對(duì)在網(wǎng)絡(luò)容器中使用ThreadLocal引起的內(nèi)存泄露做了一個(gè)總結(jié)，詳見：https://cwiki.apache.org/confluence/display/tomcat/MemoryLeakProtection，這里我們列舉其中的一個(gè)例子。
熟悉Tomcat的同學(xué)知道，Tomcat中的web應(yīng)用由webapp classloader這個(gè)類加載器的，并且webapp classloader是破壞雙親委派機(jī)制實(shí)現(xiàn)的，即所有的web應(yīng)用先由webapp classloader加載，這樣的好處就是可以讓同一個(gè)容器中的web應(yīng)用以及依賴隔離。
下面我們看具體的內(nèi)存泄露的例子：
public class MyCounter {
private int count = 0;
public void increment() {
count++;
}
public int getCount() {
return count;
}
}
public class MyThreadLocal extends ThreadLocal<MyCounter> {
}
public class LeakingServlet extends HttpServlet {
private static MyThreadLocal myThreadLocal = new MyThreadLocal();
protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {
MyCounter counter = myThreadLocal.get();
if (counter == null) {
counter = new MyCounter();
myThreadLocal.set(counter);
}
response.getWriter().println(
"The current thread served this servlet " + counter.getCount()
+ " times");
counter.increment();
}
}
需要注意這個(gè)例子中的兩個(gè)非常關(guān)鍵的點(diǎn)：
MyCounter以及MyThreadLocal必須放到web應(yīng)用的路徑中，保被webapp classloader加載ThreadLocal類一定得是ThreadLocal的繼承類，比如例子中的MyThreadLocal，因?yàn)門hreadLocal本來被 common classloader加載，其生命周期與tomcat容器一致。ThreadLocal的繼承類包括比較常見的NamedThreadLocal，注意不要踩坑。
假如LeakingServlet所在的web應(yīng)用啟動(dòng)，MyThreadLocal類也會(huì)被webapp classloader加載，如果此時(shí)web應(yīng)用下線，而線程的生命周期未結(jié)束(比如為LeakingServlet提供服務(wù)的線程是一個(gè)線程池中的線程)，那會(huì)導(dǎo)致myThreadLocal的實(shí)例仍然被這個(gè)線程引用，而不能被GC，期初看來這個(gè)帶來的問題也不大，因?yàn)?code style="overflow-wrap: break-word;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(30, 107, 184);background-color: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;">myThreadLocal所引用的對(duì)象占用的內(nèi)存空間不太多，問題在于myThreadLocal間接持有加載web應(yīng)用的webapp classloader的引用（通過myThreadLocal.getClass().getClassLoader()可以引用到），而加載web應(yīng)用的webapp classloader有持有它加載的所有類的引用，這就引起了classloader泄露，它泄露的內(nèi)存就非常可觀了。
https://www.baeldung.com/java-memory-leaks https://cwiki.apache.org/confluence/display/tomcat/MemoryLeakProtection
-END-