Java記憶體洩漏與野指標問題
四種引用型別的介紹
強引用(StrongReference):JVM 寧可丟擲 OOM ,也不會讓 GC 回收具有強引用的物件;
軟引用(SoftReference):只有在記憶體空間不足時,才會被回的物件;
弱引用(WeakReference):在 GC 時,一旦發現了只具有弱引用的物件,不管當前記憶體空間足夠與否,都會回收它的記憶體;
虛引用(PhantomReference):任何時候都可以被GC回收,當垃圾回收器準備回收一個物件時,如果發現它還有虛引用,就會在回收物件的記憶體之前,把這個虛引用加入到與之關聯的引用佇列中。程式可以通過判斷引用佇列中是否存在該物件的虛引用,來了解這個物件是否將要被回收。可以用來作為GC回收Object的標誌。
我們常說的記憶體洩漏是指new出來的Object無法被GC回收,即為強引用:
什麼是Java中的記憶體洩露
對於C++來說,記憶體洩漏就是new出來的物件沒有delete,俗稱野指標;對於Java來說,就是new出來的Object 放在Heap上無法被GC回收;
在Java中,記憶體洩漏就是存在一些被分配的物件,這些物件有下面兩個特點,首先,這些物件是可達的,即在有向圖中,存在通路可以與其相連;其次,這些物件是無用的,即程式以後不會再使用這些物件。如果物件滿足這兩個條件,這些物件就可以判定為Java中的記憶體洩漏,這些物件不會被GC所回收,然而它卻佔用記憶體。
在C++中,記憶體洩漏的範圍更大一些。有些物件被分配了記憶體空間,然後卻不可達,由於C++中沒有GC,這些記憶體將永遠收不回來。在Java中,這些不可達的物件都由GC負責回收,因此程式設計師不需要考慮這部分的記憶體洩露。
通過分析,我們得知,對於C++,程式設計師需要自己管理邊和頂點,而對於Java程式設計師只需要管理邊就可以了(不需要管理頂點的釋放)。通過這種方式,Java提高了程式設計的效率。
因此,通過以上分析,我們知道在Java中也有記憶體洩漏,但範圍比C++要小一些。因為Java從語言上保證,任何物件都是可達的,所有的不可達物件都由GC管理。
對於程式設計師來說,GC基本是透明的,不可見的。雖然,我們只有幾個函式可以訪問GC,例如執行GC的函式System.gc(),但是根據Java語言規範定義, 該函式不保證JVM的垃圾收集器一定會執行。因為,不同的JVM實現者可能使用不同的演算法管理GC。通常,GC的執行緒的優先級別較低。JVM呼叫GC的策略也有很多種,有的是記憶體使用到達一定程度時,GC才開始工作,也有定時執行的,有的是平緩執行GC,有的是中斷式執行GC。但通常來說,我們不需要關心這些。除非在一些特定的場合,GC的執行影響應用程式的效能,例如對於基於Web的實時系統,如網路遊戲等,使用者不希望GC突然中斷應用程式執行而進行垃圾回收,那麼我們需要調整GC的引數,讓GC能夠通過平緩的方式釋放記憶體,例如將垃圾回收分解為一系列的小步驟執行,Sun提供的HotSpot JVM就支援這一特性。
同樣給出一個 Java 記憶體洩漏的典型例子,
Vector v = new Vector(10);
for (int i = 1; i < 100; i++) {
Object o = new Object();
v.add(o);
o = null;
}
在這個例子中,我們迴圈申請Object物件,並將所申請的物件放入一個 Vector 中,如果我們僅僅釋放引用本身,那麼 Vector 仍然引用該物件,所以這個物件對 GC 來說是不可回收的。因此,如果物件加入到Vector 後,還必須從 Vector 中刪除,最簡單的方法就是將 Vector 物件設定為 null。
Android中常見的記憶體洩漏彙總
什麼是記憶體溢位:(Out Of Memory,簡稱 OOM),通俗理解就是記憶體不夠,即記憶體佔用超出記憶體的空間大小;基本上會造成程式奔潰。解決:找到報錯的程式碼並解決。
什麼是記憶體洩露:記憶體洩漏(Memory Leak),簡單理解就是記憶體使用完畢之後本該垃圾回收卻未被回收。(佔著茅坑不拉屎)--記憶體無法回收又沒起作用。
推理!!!
1.看物件的大小;
2.深入使用MAT進行物件細節的分析
3.前後對比。
懷疑某一段程式碼會造成記憶體溢位。可以先註冊掉該段程式碼生成一個xxx.hroph檔案,然後在解開這段程式碼再生成一個yyy.hroph檔案
通過MAT工具對比他們的記憶體消耗情況---甚至可以精確到每一個物件消耗記憶體的情況。
在 Android 中,洩露 Context 物件的問題尤其嚴重,特別像 Activity 這樣的 Context 物件會引用大量很佔用記憶體的物件,如果 Context 物件發生了記憶體洩漏,那它所引用的所有物件都被洩漏了。Activity 是非常重量級的物件,所以我們應該極力避免妨礙系統對其進行回收,然而實際情況是有多種方式會無意間就洩露了Activity 物件。
case 0.靜態變數造成的記憶體洩漏
最簡單的洩漏 Activity 就是在 Activity 類中定義一個 static 變數,並將其指向一個執行中的 Activity 例項。如果在 Activity 的生命週期結束之前,沒有清除這個引用,那它就會洩漏。由於 Activity 的類物件是靜態的,一旦載入,就會在 APP 執行時一直常駐記憶體,如果類物件不解除安裝,其靜態成員就不會被垃圾回收。
儘量避免使用 static 成員變數:
這裡修復的方法是:
不要在類初始時初始化靜態成員。可以考慮lazy初始化。
case 1. 單例造成的記憶體洩露
單例的靜態特性導致其生命週期同應用一樣長
另一種類似的情況是對經常啟動的 Activity 實現一個單例模式,讓其常駐記憶體可以使它能夠快速恢復狀態。
如我們有一個建立起來非常耗時的 View,在同一個 Activity 不同的生命週期中都保持不變呢,就為它實現一個單例模式。一旦 View 被載入到介面中,它就會持有 Context 的強引用,也就是我們的 Activity 物件。
由於我們是通過一個靜態成員引用了這個 View,所以我們也就引用了 Activity,因此 Activity 就發生了洩漏。所以一定不要把載入的 View 賦值給靜態變數,如果你真的需要,那一定要確保在 Activity 銷燬之前將其從 View 層級中移除。
解決方案:
將該屬性的引用方式改為弱引用;
如果傳入Context,使用ApplicationContext;
case 2. InnerClass匿名內部類
我們經常在 Activity 內部定義一個內部類,這樣做可以增加封裝性和可讀性。但是如果當我們建立了一個內部類的物件,並通過靜態變數持有了 Activity 的引用,那也會可能發生 Activity 洩漏。
在Java中,非靜態內部類 和 匿名類 都會潛在的引用它們所屬的外部類,但是,靜態內部類卻不會。如果這個非靜態內部類例項做了一些耗時的操作,就會造成外圍物件不會被回收,從而導致記憶體洩漏。
解決方案:
將內部類變成靜態內部類;
靜態內部類中使用弱引用來引用外部類的成員變數;
如果有強引用Activity中的屬性,則將該屬性的引用方式改為弱引用;
在業務允許的情況下,當Activity執行onDestory時,結束這些耗時任務;
case 3. 執行緒造成的記憶體洩漏
在 Activity 內定義了一個匿名的 AsyncTask 物件,就有可能發生記憶體洩漏。如果 Activity 被銷燬之後 AsyncTask 仍然在執行,那就會阻止垃圾回收器回收Activity 物件,進而導致記憶體洩漏,直到執行結束才能回收 Activity。
同樣的,使用 Thread 和 TimerTask 也可能導致 Activity 洩漏。只要它們是通過匿名類建立的,儘管它們在單獨的執行緒被執行,它們也會持有對 Activity 的強引用,進而導致記憶體洩漏。
在Android裡面執行緒最容易造成記憶體洩露。執行緒產生記憶體洩露的主要原因在於執行緒生命週期的不可控
2.執行緒問題的改進方式主要有:
1)將執行緒的內部類,改為靜態內部類。
2)在程式中儘量採用弱引用儲存Context。
case 4. Activity Context 的不正確使用
在Android應用程式中通常可以使用兩種Context物件:Activity和Application。當類或方法需要Context物件的時候常見的做法是使用第一個作為Context引數。這樣就意味著View物件對整個Activity保持引用,因此也就保持對Activty的所有的引用。
假設一個場景,當應用程式有個比較大的Bitmap型別的圖片,每次旋轉是都重新載入圖片所用的時間較多。為了提高螢幕旋轉是Activity的建立速度,最簡單的方法時將這個Bitmap物件使用Static修飾。 當一個Drawable繫結在View上,實際上這個View物件就會成為這份Drawable的一個Callback成員變數。而靜態變數的生命週期要長於Activity。導致了當旋轉螢幕時,Activity無法被回收,而造成記憶體洩露。
解決方案:
使用ApplicationContext代替ActivityContext,因為ApplicationContext會隨著應用程式的存在而存在,而不依賴於activity的生命週期;
對Context的引用不要超過它本身的生命週期,慎重的對Context使用“static”關鍵字。Context裡如果有執行緒,一定要在onDestroy()裡及時停掉。
case 5. Handler引起的記憶體洩漏
定義一個匿名的 Runnable 物件並將其提交到 Handler 上也可能導致 Activity 洩漏。Runnable 物件間接地引用了定義它的 Activity 物件,而它會被提交到Handler 的 MessageQueue 中,如果它在 Activity 銷燬時還沒有被處理,就會導致 Activity 洩漏。
當Handler中有延遲的的任務或是等待執行的任務佇列過長,由於訊息持有對Handler的引用,而Handler又持有對其外部類的潛在引用,這條引用關係會一直保持到訊息得到處理,而導致了Activity無法被垃圾回收器回收,而導致了記憶體洩露。
修復方法:在 Activity 中避免使用非靜態內部類,比如上面我們將 Handler 宣告為靜態的,則其存活期跟 Activity 的生命週期就無關了。同時通過弱引用的方式引入 Activity,避免直接將 Activity 作為 context 傳進去,見下面程式碼:
Handler 的持有的引用物件最好使用弱引用,資源釋放時也可以清空 Handler 裡面的訊息。比如在 Activity onStop 或者 onDestroy 的時候,取消掉該 Handler 物件的 Message和 Runnable.
綜述,即推薦使用靜態內部類 + WeakReference 這種方式。每次使用前注意判空。
解決方案:
可以把Handler類放在單獨的類檔案中,或者使用靜態內部類便可以避免洩露;
如果想在Handler內部去呼叫所在的Activity,那麼可以在handler內部使用弱引用的方式去指向所在Activity.使用Static + WeakReference的方式來達到斷開Handler與Activity之間存在引用關係的目的。
case 6. 註冊監聽器的洩漏(資源未關閉造成的記憶體洩漏)
如系統服務可以通過 context.getSystemService 獲取,它們負責執行某些後臺任務,或者為硬體訪問提供介面。如果 Context 物件想要在服務內部的事件發生時被通知,那就需要把自己註冊到服務的監聽器中。然而,這會讓服務持有 Activity 的引用,如果開發者忘記在 Activity 銷燬時取消註冊,也會導致 Activity洩漏
系統服務可以通過Context.getSystemService 獲取,它們負責執行某些後臺任務,或者為硬體訪問提供介面。如果Context 物件想要在服務內部的事件發生時被通知,那就需要把自己註冊到服務的監聽器中。然而,這會讓服務持有Activity 的引用,如果在Activity onDestory時沒有釋放掉引用就會記憶體洩漏。
解決方案:
使用ApplicationContext代替ActivityContext;
在Activity執行onDestory時,呼叫反註冊;
case 7. Cursor,Stream沒有close,View沒有recyle
資源性物件比如(Cursor,File檔案等)往往都用了一些緩衝,我們在不使用的時候,應該及時關閉它們,以便它們的緩衝及時回收記憶體。它們的緩衝不僅存在於 java虛擬機器內,還存在於java虛擬機器外。如果我們僅僅是把它的引用設定為null,而不關閉它們,往往會造成記憶體洩漏。因為有些資源性物件,比如SQLiteCursor(在解構函式finalize(),如果我們沒有關閉它,它自己會調close()關閉),如果我們沒有關閉它,系統在回收它時也會關閉它,但是這樣的效率太低了。因此對於資源性物件在不使用的時候,應該呼叫它的close()函式,將其關閉掉,然後才置為null. 在我們的程式退出時一定要確保我們的資源性物件已經關閉。
對於使用了BraodcastReceiver,ContentObserver,File,遊標 Cursor,Stream,Bitmap等資源的使用,應該在Activity銷燬時及時關閉或者登出,否則這些資源將不會被回收,造成記憶體洩漏。
Solution:
呼叫onRecycled()
case 8. 集合中物件沒清理造成的記憶體洩漏
我們通常把一些物件的引用加入到了集合容器(比如ArrayList)中,當我們不需要該物件時,並沒有把它的引用從集合中清理掉,這樣這個集合就會越來越大。如果這個集合是static的話,那情況就更嚴重了。
所以要在退出程式之前,將集合裡的東西clear,然後置為null,再退出程式。
解決方案:
在Activity退出之前,將集合裡的東西clear,然後置為null,再退出程式。
Solution
private List
public void onDestory() {
if (data != null) {
data.clear();
data = null;
}
}
case 9. WebView造成的洩露
當我們不要使用WebView物件時,應該呼叫它的destory()函式來銷燬它,並釋放其佔用的記憶體,否則其佔用的記憶體長期也不能被回收,從而造成記憶體洩露。
解決方案:
為webView開啟另外一個程序,通過AIDL與主執行緒進行通訊,WebView所在的程序可以根據業務的需要選擇合適的時機進行銷燬,從而達到記憶體的完整釋放。
case 10. 構造Adapter時,沒有使用快取的ConvertView
初始時ListView會從Adapter中根據當前的屏幕布局例項化一定數量的View物件,同時ListView會將這些View物件 快取起來。
當向上滾動ListView時,原先位於最上面的List Item的View物件會被回收,然後被用來構造新出現的最下面的List Item。
這個構造過程就是由getView()方法完成的,getView()的第二個形參View ConvertView就是被快取起來的List Item的View物件(初始化時快取中沒有View物件則ConvertView是null)。
case 11.動畫
在屬性動畫中有一類無限迴圈動畫,如果在Activity中播放這類動畫並且在onDestroy中去停止動畫,那麼這個動畫將會一直播放下去,這時候Activity會被View所持有,從而導致Activity無法被釋放。解決此類問題則是需要早Activity中onDestroy去去呼叫objectAnimator.cancel()來停止動畫
case 12.第三方庫使用不當
對於EventBus,RxJava等一些第三開源框架的使用,若是在Activity銷燬之前沒有進行解除訂閱將會導致記憶體洩漏。
綜上所述,要避免記憶體洩露或者記憶體溢位,主要要遵循以下幾點:
第一:不要為Context長期儲存引用(要引用Context就要使得引用物件和它本身的生命週期保持一致,即對activity的引用應該控制在activity的生命週期之內)。
第二:如果要使用到Context,儘量使用ApplicationContext去代替Context,因為ApplicationContext的生命週期較長,引用情況下不會造成記憶體洩露問題
第三:在你不控制物件的生命週期的情況下避免在你的Activity中使用static變數。儘量使用WeakReference去代替一個static。
第四:垃圾回收器並不保證能準確回收記憶體,這樣在使用自己需要的內容時,主要生命週期和及時釋放掉不需要的物件。儘量在Activity的生命週期結束時,在onDestroy中把我們做引用的其他物件做資源釋放,比如:cursor.close()。如清空對圖片等資源有直接引用或者間接引用的陣列(使用array.clear();array = null);
第五:儘量不要在Activity中使用非靜態內部類,因為非靜態內部類會隱式持有外部類例項的引用。如果使用靜態內部類,將外部例項引用作為弱引用持有。
(靜態的內部類不會持有外部類的一個隱式引用)
在 Java 的實現過程中,也要考慮其物件釋放,最好的方法是在不使用某物件時,顯式地將此物件賦值為 null,比如使用完Bitmap 後先呼叫 recycle(),再賦為null,清空對圖片等資源有直接引用或者間接引用的陣列(使用 array.clear() ; array = null)等,最好遵循誰建立誰釋放的原則。
正確關閉資源,對於使用了BraodcastReceiver,ContentObserver,File,遊標 Cursor,Stream,Bitmap等資源的使用,應該在Activity銷燬時及時關閉或者登出。
保持對物件生命週期的敏感,特別注意單例、靜態物件、全域性性集合等的生命週期。
程式出現停止執行狀態或者致命崩潰現象可能如下原因導致:
1.在while死迴圈裡面或軟體操作非常頻繁的程式碼塊中進行new物件產生強引用物件,
導致jvm不能及時回收記憶體,從而產生記憶體消耗暴增,讓軟體出現停止執行的致命崩潰現象
2.程式碼報錯未捕捉異常造成
3.程式在主執行緒耗時過長,或者在廣播中的耗時超過6s
new出來的物件不用時回收原則;
1.在哪建立就在哪及時釋放,
2.誰引用,誰就負責釋放
能做到C/C++對於程式的“誰建立,誰釋放”原則,那我們對於記憶體的把握,並不比Java或Android本身的GC機制差,而且更好的控制記憶體,能使我們的手機執行得更流暢
java沒有絕對的強制垃圾回收的方法,不過可以這樣去做:
- 對於不再引用的物件,及時把它的引用賦為null。 obj = null;
- 如果記憶體確實很緊張,呼叫System.gc() 方法來建議垃圾回收器開始回收垃圾