本篇文章給大家分享的是有關(guān)Java中有哪些潛在的內(nèi)存泄露風(fēng)險，小編覺得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

創(chuàng)新互聯(lián)公司主營漢川網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,成都app軟件開發(fā),漢川h5小程序設(shè)計搭建,漢川網(wǎng)站營銷推廣歡迎漢川等地區(qū)企業(yè)咨詢

1. 內(nèi)存泄露的定義

如果GC無法回收內(nèi)存中不再使用的對象，則定義為內(nèi)存有泄露

2. 未關(guān)閉的資源類

當(dāng)我們在程序中打開一個新的流或者是新建一個網(wǎng)絡(luò)連接的時候，JVM都會為這些資源類分配內(nèi)存做緩存，常見的資源類有網(wǎng)絡(luò)連接，數(shù)據(jù)庫連接以及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()

假如有下面的這個類

public class Person {     public String name;          public Person(String name) {         this.name = name;     } }

并且如果在程序中有下面的操作

@Test public void givenMapWhenEqualsAndHashCodeNotOverriddenThenMemoryLeak() {     Map map = new HashMap<>();     for(int i=0; i<100; i++) {         map.put(new Person("jon"), 1);     }     Assert.assertFalse(map.size() == 1); }

可以預(yù)見，這個單元測試并不能通過，原因是Person類沒有實(shí)現(xiàn)equals方法，因此使用Object的equals方法，直接比較實(shí)體對象的地址，所以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;     } }

則上文中的單元測試就可以順利通過了，需要注意的是這個場景比較隱蔽，一定要在平時的代碼中注意。

4. 非靜態(tài)內(nèi)部類

要知道，所有的非靜態(tài)類別類都持有外部類的引用，因此某些情況如果引用內(nèi)部類可能延長外部類的生命周期，甚至持續(xù)到進(jìn)程結(jié)束都不能回收外部類的空間，這類內(nèi)存溢出一般在Android程序中比較多，只要MyAsyncTask處于運(yùn)行狀態(tài)MainActivity的內(nèi)存就釋放不了，很多時候安卓開發(fā)者這樣做只是為了在內(nèi)部類中拿到外部類的屬性，殊不知，此時內(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)行下面的這個例子，則最終程序會因?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對重寫了finalize()的類的處理稍微不同，首先會針對這個類創(chuàng)建一個java.lang.ref.Finalizer類，并讓java.lang.ref.Finalizer持有這個類的引用，在上文中的例子中，因?yàn)镕inalizer類的引用被java.lang.ref.Finalizer持有，所以他的實(shí)例并不能被Young  GC清理，反而會轉(zhuǎn)入到老年代。在老年代中，JVM  GC的時候會發(fā)現(xiàn)Finalizer類只被java.lang.ref.Finalizer引用，因此將其標(biāo)記為可GC狀態(tài)，并放入到j(luò)ava.lang.ref.Finalizer.ReferenceQueue這個隊列中。等到所有的Finalizer類都加到隊列之后，JVM會起一個后臺線程去清理java.lang.ref.Finalizer.ReferenceQueue中的對象，之后這個后臺線程就專門負(fù)責(zé)清理java.lang.ref.Finalizer.ReferenceQueue中的對象了。這個設(shè)計看起來是沒什么問題的，但其實(shí)有個坑，那就是負(fù)責(zé)清理java.lang.ref.Finalizer.ReferenceQueue的后臺線程優(yōu)先級是比較低的，并且系統(tǒng)沒有提供可以調(diào)節(jié)這個線程優(yōu)先級的接口或者配置。因此當(dāng)我們在使用使用重寫finalize()方法的對象時，千萬不要瞬間產(chǎn)生大量的對象，要時刻謹(jǐn)記，JVM對此類對象的處理有特殊邏輯。

6. 針對長字符串調(diào)用String.intern()

如果提前在src/test/resources/large.txt中寫入大量字符串，并且在Java  1.6及以下的版本運(yùn)行下面程序，也將得到一個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)行期間不會GC，因此產(chǎn)生了OOM。在Java  1.7以及之后字符串常量池轉(zhuǎn)移到了HeapSpace此類問題也就無需再關(guān)注了

7. ThreadLocal的誤用

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

@Test public void testThreadLocalMemoryLeaks() {     ThreadLocal> localCache = new ThreadLocal<>();    List cacheInstance = new ArrayList<>(10000);     localCache.set(cacheInstance);     localCache = new ThreadLocal<>(); }

當(dāng)localCache的值被重置之后cacheInstance被ThreadLocalMap中的value引用，無法被GC，但是其key對ThreadLocal實(shí)例的引用是一個弱引用，本來ThreadLocal的實(shí)例被localCache和ThreadLocalMap的key同時引用，但是當(dāng)localCache的引用被重置之后，則ThreadLocal的實(shí)例只有ThreadLocalMap的key這樣一個弱引用了，此時這個實(shí)例在GC的時候能夠被清理。

img

其實(shí)看過ThreadLocal源碼的同學(xué)會知道，ThreadLocal本身對于key為null的Entity有自清理的過程，但是這個過程是依賴于后續(xù)對ThreadLocal的繼續(xù)使用，假如上面的這段代碼是處于一個秒殺場景下，會有一個瞬間的流量峰值，這個流量峰值也會將集群的內(nèi)存打到高位(或者運(yùn)氣不好的話直接將集群內(nèi)存打滿導(dǎo)致故障)，后面由于峰值流量已過，對ThreadLocal的調(diào)用也下降，會使得ThreadLocal的自清理能力下降，造成內(nèi)存泄露。ThreadLocal的自清理實(shí)現(xiàn)是錦上添花，千萬不要指望它雪中送碳。

8. 類的靜態(tài)變量

Tomcat對在網(wǎng)絡(luò)容器中使用ThreadLocal引起的內(nèi)存泄露做了一個總結(jié)，詳見：https://cwiki.apache.org/confluence/display/tomcat/MemoryLeakProtection，這里我們列舉其中的一個例子。

熟悉Tomcat的同學(xué)知道，Tomcat中的web應(yīng)用由webapp classloader這個類加載器的，并且webapp  classloader是破壞雙親委派機(jī)制實(shí)現(xiàn)的，即所有的web應(yīng)用先由webapp  classloader加載，這樣的好處就是可以讓同一個容器中的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 { }  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();  } }

需要注意這個例子中的兩個非常關(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)用啟動，MyThreadLocal類也會被webapp  classloader加載，如果此時web應(yīng)用下線，而線程的生命周期未結(jié)束(比如為LeakingServlet提供服務(wù)的線程是一個線程池中的線程)，那會導(dǎo)致myThreadLocal的實(shí)例仍然被這個線程引用，而不能被GC，期初看來這個帶來的問題也不大，因?yàn)閙yThreadLocal所引用的對象占用的內(nèi)存空間不太多，問題在于myThreadLocal間接持有加載web應(yīng)用的webapp  classloader的引用(通過myThreadLocal.getClass().getClassLoader()可以引用到)，而加載web應(yīng)用的webapp  classloader有持有它加載的所有類的引用，這就引起了classloader泄露，它泄露的內(nèi)存就非?？捎^了。

以上就是Java中有哪些潛在的內(nèi)存泄露風(fēng)險，小編相信有部分知識點(diǎn)可能是我們?nèi)粘９ぷ鲿姷交蛴玫降?。希望你能通過這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。