日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
Java中七個潛在的內(nèi)存泄露風(fēng)險，你知道幾個？

 雖然Java程序員不用像C/C++程序員那樣時刻關(guān)注內(nèi)存的使用情況，JVM會幫我們處理好這些，但并不是說有了GC就可以高枕無憂，內(nèi)存泄露相關(guān)的問題一般在測試的時候很難發(fā)現(xiàn)，一旦上線流量起來可能馬上就是一個詭異的線上故障。

10年積累的成都做網(wǎng)站、成都網(wǎng)站制作、成都外貿(mào)網(wǎng)站建設(shè)經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識你，你也不認(rèn)識我。但先網(wǎng)站設(shè)計制作后付款的網(wǎng)站建設(shè)流程，更有靈臺免費網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

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)閉資源類的代碼，因此最好按照下面的做法處理資源類

 
 
 
 
      
  
  
  
  1. public void handleResource() { 
    2.   
  
  
  
  2.     try { 
    3.   
  
  
  
  3.         // open connection 
    4.   
  
  
  
  4.         // handle business 
    5.   
  
  
  
  5.     } catch (Throwable t) { 
    6.   
  
  
  
  6.         // log stack 
    7.   
  
  
  
  7.     } finally { 
    8.   
  
  
  
  8.         // close connection 
    9.   
  
  
  
  9.     } 
    10.   
  
  
  
  10. } 
    11.

3. 未正確實現(xiàn)equals()和hashCode()

假如有下面的這個類

 
 
 
 
      
  
  
  
  1. public class Person { 
    2.   
  
  
  
  2.     public String name; 
    3.   
  
  
  
  3.      
    4.   
  
  
  
  4.     public Person(String name) { 
    5.   
  
  
  
  5.         this.name = name; 
    6.   
  
  
  
  6.     } 
    7.   
  
  
  
  7. } 
    8.

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

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

可以預(yù)見，這個單元測試并不能通過，原因是Person類沒有實現(xiàn)equals方法，因此使用Object的equals方法，直接比較實體對象的地址，所以map.size() == 100

如果我們改寫Person類的代碼如下所示：

 
 
 
 
      
  
  
  
  1. public class Person { 
    2.   
  
  
  
  2.     public String name; 
    3.   
  
  
  
  3.      
    4.   
  
  
  
  4.     public Person(String name) { 
    5.   
  
  
  
  5.         this.name = name; 
    6.   
  
  
  
  6.     } 
    7.   
  
  
  
  7.      
    8.   
  
  
  
  8.     @Override 
    9.   
  
  
  
  9.     public boolean equals(Object o) { 
    10.   
  
  
  
  10.         if (o == this) return true; 
    11.   
  
  
  
  11.         if (!(o instanceof Person)) { 
    12.   
  
  
  
  12.             return false; 
    13.   
  
  
  
  13.         } 
    14.   
  
  
  
  14.         Person person = (Person) o; 
    15.   
  
  
  
  15.         return person.name.equals(name); 
    16.   
  
  
  
  16.     } 
    17.   
  
  
  
  17.      
    18.   
  
  
  
  18.     @Override 
    19.   
  
  
  
  19.     public int hashCode() { 
    20.   
  
  
  
  20.         int result = 17; 
    21.   
  
  
  
  21.         result = 31 * result + name.hashCode(); 
    22.   
  
  
  
  22.         return result; 
    23.   
  
  
  
  23.     } 
    24.   
  
  
  
  24. } 
    25.

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

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

要知道，所有的非靜態(tài)類別類都持有外部類的引用，因此某些情況如果引用內(nèi)部類可能延長外部類的生命周期，甚至持續(xù)到進程結(jié)束都不能回收外部類的空間，這類內(nèi)存溢出一般在Android程序中比較多，只要MyAsyncTask處于運行狀態(tài)MainActivity的內(nèi)存就釋放不了，很多時候安卓開發(fā)者這樣做只是為了在內(nèi)部類中拿到外部類的屬性，殊不知，此時內(nèi)存已經(jīng)泄露了。

 
 
 
 
      
  
  
  
  1. public class MainActivity extends Activity { 
    2.   
  
  
  
  2.     @Override 
    3.   
  
  
  
  3.     protected void onCreate(Bundle savedInstanceState) { 
    4.   
  
  
  
  4.         super.onCreate(savedInstanceState); 
    5.   
  
  
  
  5.         setContentView(R.layout.main); 
    6.   
  
  
  
  6.         new MyAsyncTask().execute(); 
    7.   
  
  
  
  7.     } 
    8.   
  
  
  
  8.  
    9.   
  
  
  
  9.     private class MyAsyncTask extends AsyncTask { 
    10.   
  
  
  
  10.         @Override 
    11.   
  
  
  
  11.         protected Object doInBackground(Object[] params) { 
    12.   
  
  
  
  12.             return doSomeStuff(); 
    13.   
  
  
  
  13.         } 
    14.   
  
  
  
  14.         private Object doSomeStuff() { 
    15.   
  
  
  
  15.             //do something to get result 
    16.   
  
  
  
  16.             return new MyObject(); 
    17.   
  
  
  
  17.         } 
    18.   
  
  
  
  18.     } 
    19.   
  
  
  
  19. } 
    20.

5. 重寫了finalize()的類

如果運行下面的這個例子，則最終程序會因為OOM的原因崩潰

 
 
 
 
      
  
  
  
  1. public class Finalizer { 
    2.   
  
  
  
  2.     @Override 
    3.   
  
  
  
  3.     protected void finalize() throws Throwable { 
    4.   
  
  
  
  4.     while (true) { 
    5.   
  
  
  
  5.            Thread.yield(); 
    6.   
  
  
  
  6.       } 
    7.   
  
  
  
  7.   } 
    8.   
  
  
  
  8.  
    9.   
  
  
  
  9. public static void main(String str[]) { 
    10.   
  
  
  
  10.   while (true) { 
    11.   
  
  
  
  11.         for (int i = 0; i < 100000; i++) { 
    12.   
  
  
  
  12.             Finalizer force = new Finalizer(); 
    13.   
  
  
  
  13.         } 
    14.   
  
  
  
  14.    } 
    15.   
  
  
  
  15.  } 
    16.   
  
  
  
  16. } 
    17.

JVM對重寫了finalize()的類的處理稍微不同，首先會針對這個類創(chuàng)建一個java.lang.ref.Finalizer類，并讓java.lang.ref.Finalizer持有這個類的引用，在上文中的例子中，因為Finalizer類的引用被java.lang.ref.Finalizer持有，所以他的實例并不能被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è)計看起來是沒什么問題的，但其實有個坑，那就是負(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及以下的版本運行下面程序，也將得到一個OOM

 
 
 
 
      
  
  
  
  1. @Test 
    2.   
  
  
  
  2. public void givenLengthString_whenIntern_thenOutOfMemory() 
    3.   
  
  
  
  3.   throws IOException, InterruptedException { 
    4.   
  
  
  
  4.     String str  
    5.   
  
  
  
  5.       = new Scanner(new File("src/test/resources/large.txt"), "UTF-8") 
    6.   
  
  
  
  6.       .useDelimiter("\\A").next(); 
    7.   
  
  
  
  7.     str.intern(); 
    8.   
  
  
  
  8.      
    9.   
  
  
  
  9.     System.gc();  
    10.   
  
  
  
  10.     Thread.sleep(15000); 
    11.   
  
  
  
  11. } 
    12.

原因是在Java 1.6及以下，字符串常量池是處于JVM的PermGen區(qū)的，并且在程序運行期間不會GC，因此產(chǎn)生了OOM。在Java 1.7以及之后字符串常量池轉(zhuǎn)移到了HeapSpace此類問題也就無需再關(guān)注了

7. ThreadLocal的誤用

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

 
 
 
 
      
  
  
  
  1. @Test 
    2.   
  
  
  
  2. public void testThreadLocalMemoryLeaks() { 
    3.   
  
  
  
  3.     ThreadLocal> localCache = new ThreadLocal<>(); 
    4.   
  
  
  
  4.    List cacheInstance = new ArrayList<>(10000); 
    5.   
  
  
  
  5.     localCache.set(cacheInstance); 
    6.   
  
  
  
  6.     localCache = new ThreadLocal<>(); 
    7.   
  
  
  
  7. } 
    8.

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

img

其實看過ThreadLocal源碼的同學(xué)會知道，ThreadLocal本身對于key為null的Entity有自清理的過程，但是這個過程是依賴于后續(xù)對ThreadLocal的繼續(xù)使用，假如上面的這段代碼是處于一個秒殺場景下，會有一個瞬間的流量峰值，這個流量峰值也會將集群的內(nèi)存打到高位(或者運氣不好的話直接將集群內(nèi)存打滿導(dǎo)致故障)，后面由于峰值流量已過，對ThreadLocal的調(diào)用也下降，會使得ThreadLocal的自清理能力下降，造成內(nèi)存泄露。ThreadLocal的自清理實現(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是破壞雙親委派機制實現(xiàn)的，即所有的web應(yīng)用先由webapp classloader加載，這樣的好處就是可以讓同一個容器中的web應(yīng)用以及依賴隔離。

下面我們看具體的內(nèi)存泄露的例子：

 
 
 
 
      
  
  
  
  1. public class MyCounter { 
    2.   
  
  
  
  2.  private int count = 0; 
    3.   
  
  
  
  3.  
    4.   
  
  
  
  4.  public void increment() { 
    5.   
  
  
  
  5.   count++; 
    6.   
  
  
  
  6.  } 
    7.   
  
  
  
  7.  
    8.   
  
  
  
  8.  public int getCount() { 
    9.   
  
  
  
  9.   return count; 
    10.   
  
  
  
  10.  } 
    11.   
  
  
  
  11. } 
    12.   
  
  
  
  12.  
    13.   
  
  
  
  13. public class MyThreadLocal extends ThreadLocal { 
    14.   
  
  
  
  14. } 
    15.   
  
  
  
  15.  
    16.   
  
  
  
  16. public class LeakingServlet extends HttpServlet { 
    17.   
  
  
  
  17.  private static MyThreadLocal myThreadLocal = new MyThreadLocal(); 
    18.   
  
  
  
  18.  
    19.   
  
  
  
  19.  protected void doGet(HttpServletRequest request, 
    20.   
  
  
  
  20.    HttpServletResponse response) throws ServletException, IOException { 
    21.   
  
  
  
  21.  
    22.   
  
  
  
  22.   MyCounter counter = myThreadLocal.get(); 
    23.   
  
  
  
  23.   if (counter == null) { 
    24.   
  
  
  
  24.    counter = new MyCounter(); 
    25.   
  
  
  
  25.    myThreadLocal.set(counter); 
    26.   
  
  
  
  26.   } 
    27.   
  
  
  
  27.  
    28.   
  
  
  
  28.   response.getWriter().println( 
    29.   
  
  
  
  29.     "The current thread served this servlet " + counter.getCount() 
    30.   
  
  
  
  30.       + " times"); 
    31.   
  
  
  
  31.   counter.increment(); 
    32.   
  
  
  
  32.  } 
    33.   
  
  
  
  33. } 
    34.

需要注意這個例子中的兩個非常關(guān)鍵的點：

  • MyCounter以及MyThreadLocal必須放到web應(yīng)用的路徑中，保被webapp classloader加載
  • ThreadLocal類一定得是ThreadLocal的繼承類，比如例子中的MyThreadLocal，因為ThreadLocal本來被common classloader加載，其生命周期與tomcat容器一致。ThreadLocal的繼承類包括比較常見的NamedThreadLocal，注意不要踩坑。

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


網(wǎng)站欄目：Java中七個潛在的內(nèi)存泄露風(fēng)險，你知道幾個？
當(dāng)前URL：http://www.dlmjj.cn/article/djhhscd.html