Android 內存泄漏總結
內存管理的目的就是讓我們在開發中怎麼有效的避免我們的應用出現內存泄漏的問 題。內存泄漏大家都不陌生了，簡單粗俗的講，就是該被釋放的對象沒有釋放，一 直被某個或某些實例所持有卻不再被使用導致 GC 不能回收 我會從 java 內存泄漏的基礎知識開始，並通過具體例子來說明 Android 引起內存泄 漏的各種原因，以及如何利用工具來分析應用內存泄漏，最後再做總結。 篇幅有些長，大家可以分幾節來看！
（順手留下GitHub鏈接，需要獲取相關面試等內容的可以自己去找）
https://github.com/xiangjiana/Android-MS
更多完整項目下載。未完待續。源碼。圖文知識後續上傳github。
可以點擊關於我聯繫我獲取
Java 內存分配策略
Java 程序運行時的內存分配策略有三種,分別是靜態分配,棧式分配,和堆式分配，對 應的，三種存儲策略使用的內存空間主要分別是靜態存儲區（也稱方法區）、棧區 和堆區。
- 靜態存儲區（方法區）： 主要存放靜態數據、全局 static 數據和常量。這塊內 存在程序編譯時就已經分配好，並且在程序整個運行期間都存在。
- **棧區 ：**當方法被執行時，方法體內的局部變量都在棧上創建，並在方法執行結 束時這些局部變量所持有的內存將會自動被釋放。因爲棧內存分配運算內置於 處理器的指令集中，效率很高，但是分配的內存容量有限。
- 堆區 ： 又稱動態內存分配，通常就是指在程序運行時直接 new 出來的內存。 這部分內存在不使用時將會由 Java 垃圾回收器來負責回收。
棧與堆的區別：
在方法體內定義的（局部變量）一些基本類型的變量和對象的引用變量都是在方法 的棧內存中分配的。當在一段方法塊中定義一個變量時，Java 就會在棧中爲該變量 分配內存空間，當超過該變量的作用域後，該變量也就無效了，分配給它的內存空 間也將被釋放掉，該內存空間可以被重新使用。
堆內存用來存放所有由 new 創建的對象（包括該對象其中的所有成員變量）和數 組。在堆中分配的內存，將由 Java 垃圾回收器來自動管理。在堆中產生了一個數 組或者對象後，還可以在棧中定義一個特殊的變量，這個變量的取值等於數組或者對象在堆內存中的首地址，這個特殊的變量就是我們上面說的引用變量。我們可以 通過這個引用變量來訪問堆中的對象或者數組。
舉個例子:
public class Sample() {
int s1 = 0;
Sample mSample1 = new Sample();
public void method() {
int s2 = 1;
Sample mSample2 = new Sample();
}
}
Sample mSample3 = new Sample();
Sample 類的局部變量 s2 和引用變量 mSample2 都是存在於棧中，但 mSample2 指向的對象是存在於堆上的。 mSample3 指向的對象實體存放在堆上，包括這個對 象的所有成員變量 s1 和 mSample1，而它自己存在於棧中。
結論：
局部變量的基本數據類型和引用存儲於棧中，引用的對象實體存儲於堆中。—— 因 爲它們屬於方法中的變量，生命週期隨方法而結束。
成員變量全部存儲於堆中（包括基本數據類型，引用和引用的對象實體）—— 因爲 它們屬於類，類對象終究是要被new出來使用的。
瞭解了 Java 的內存分配之後，我們再來看看 Java 是怎麼管理內存的。
Java是如何管理內存
Java的內存管理就是對象的分配和釋放問題。在 Java 中，程序員需要通過關鍵字 new 爲每個對象申請內存空間 (基本類型除外)，所有的對象都在堆 (Heap)中分配空 間。另外，對象的釋放是由 GC 決定和執行的。在 Java 中，內存的分配是由程序 完成的，而內存的釋放是由 GC 完成的，這種收支兩條線的方法確實簡化了程序員的工作。但同時，它也加重了JVM的工作。這也是 Java 程序運行速度較慢的原因 之一。因爲，GC 爲了能夠正確釋放對象，GC 必須監控每一個對象的運行狀態， 包括對象的申請、引用、被引用、賦值等，GC 都需要進行監控。
監視對象狀態是爲了更加準確地、及時地釋放對象，而釋放對象的根本原則就是該 對象不再被引用。
爲了更好理解 GC 的工作原理，我們可以將對象考慮爲有向圖的頂點，將引用關係 考慮爲圖的有向邊，有向邊從引用者指向被引對象。另外，每個線程對象可以作爲 一個圖的起始頂點，例如大多程序從 main 進程開始執行，那麼該圖就是以 main 進程頂點開始的一棵根樹。在這個有向圖中，根頂點可達的對象都是有效對象， GC將不回收這些對象。如果某個對象 (連通子圖)與這個根頂點不可達(注意，該圖 爲有向圖)，那麼我們認爲這個(這些)對象不再被引用，可以被 GC 回收。 以下，我 們舉一個例子說明如何用有向圖表示內存管理。對於程序的每一個時刻，我們都有 一個有向圖表示JVM的內存分配情況。以下右圖，就是左邊程序運行到第6行的示 意圖。
Java使用有向圖的方式進行內存管理，可以消除引用循環的問題，例如有三個對 象，相互引用，只要它們和根進程不可達的，那麼GC也是可以回收它們的。這種 方式的優點是管理內存的精度很高，但是效率較低。另外一種常用的內存管理技術 是使用計數器，例如COM模型採用計數器方式管理構件，它與有向圖相比，精度行 低(很難處理循環引用的問題)，但執行效率很高。
什麼是Java中的內存泄露
在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中常見的內存泄漏彙總
- 集合類泄漏
集合類如果僅僅有添加元素的方法，而沒有相應的刪除機制，導致內存被佔 用。如果這個集合類是全局性的變量 (比如類中的靜態屬性，全局性的 map 等 即有靜態引用或 final 一直指向它)，那麼沒有相應的刪除機制，很可能導致集 合所佔用的內存只增不減。比如上面的典型例子就是其中一種情況，當然實際 上我們在項目中肯定不會寫這麼 2B 的代碼，但稍不注意還是很容易出現這種 情況，比如我們都喜歡通過 HashMap 做一些緩存之類的事，這種情況就要多 留一些心眼。 - 單例造成的內存泄漏
由於單例的靜態特性使得其生命週期跟應用的生命週期一樣長，所以如果使用 不恰當的話，很容易造成內存泄漏。比如下面一個典型的例子，
public class AppManager {
private static AppManager instance;
private Context context;
private AppManager(Context context) {
this.context = context;
}
public static AppManager getInstance(Context context) {
if (instance == null) {
instance = new AppManager(context);
}
return instance;
}
}
這是一個普通的單例模式，當創建這個單例的時候，由於需要傳入一個Context， 所以這個Context的生命週期的長短至關重要：
1、 如果此時傳入的是 Application 的 Context，因爲 Application 的生命週期就是整 個應用的生命週期，所以這將沒有任何問題。
2、 如果此時傳入的是 Activity 的 Context，當這個 Context 所對應的 Activity 退出 時，由於該 Context 的引用被單例對象所持有，其生命週期等於整個應用程序的生 命週期，所以當前Activity 退出時它的內存並不會被回收，這就造成泄漏了。
正確的方式應該改爲下面這種方式：
public class AppManager {
private static AppManager instance;
private Context context;
private AppManager(Context context) {
this.context = context.getApplicationContext();// 使用Applica tion 的context
}
public static AppManager getInstance(Context context) {
if (instance == null) {
instance = new AppManager(context); }return instance;
}
}
或者這樣寫，連 Context 都不用傳進來了：
在你的 Application 中添加一個靜態方法，getContext() 返回 Application 的 context，
...
context = getApplicationContext();
...
/**
* 獲取全局的context
* @return 返回全局context對象
*/
public static Context getContext(){
return context;
}
public class AppManager {
private static AppManager instance;
private Context context;
private AppManager() {
this.context = MyApplication.getContext();// 使用Application 的context
}
public static AppManager getInstance() {
if (instance == null) {
instance = new AppManager();
}
return instance;
}
}
-
匿名內部類/非靜態內部類和異步線程
- 非靜態內部類創建靜態實例造成的內存泄漏
有的時候我們可能會在啓動頻繁的Activity中，爲了避免重複創建相同的數 據資源，可能會出現這種寫法：
public class MainActivity extends AppCompatActivity {
private static TestResource mResource = null;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
if(mManager == null){
mManager = new TestResource();
}
//...
}
class TestResource {
//...
}
}
這樣就在Activity內部創建了一個非靜態內部類的單例，每次啓動Activity時都會使用 該單例的數據，這樣雖然避免了資源的重複創建，不過這種寫法卻會造成內存泄 漏，因爲非靜態內部類默認會持有外部類的引用，而該非靜態內部類又創建了一個 靜態的實例，該實例的生命週期和應用的一樣長，這就導致了該靜態實例一直會持 有該Activity的引用，導致Activity的內存資源不能正常回收。
正確的做法爲：
將該內部類設爲靜態內部類或將該內部類抽取出來封裝成一個單例，如果需要使用 Context，請按照上面推薦的使用Application 的 Context。當然，Application 的 context 不是萬能的，所以也不能隨便亂用，對於有些地方則必須使用 Activity 的 Context，對於Application，Service，Activity三者的Context的應用場景如下：
其中： NO1表示 Application 和 Service 可以啓動一個 Activity，不過需要創建一個 新的 task 任務隊列。而對於 Dialog 而言，只有在 Activity 中才能創建
- 匿名內部類
android開發經常會繼承實現Activity/Fragment/View，此時如果你使用了匿名 類，並被異步線程持有了，那要小心了，如果沒有任何措施這樣一定會導致泄 露
public class MainActivity extends Activity {
...
Runnable ref1 = new MyRunable();
Runnable ref2 = new Runnable() {
@Override
public void run() {
}
};
...
}
ref1和ref2的區別是，ref2使用了匿名內部類。我們來看看運行時這兩個引用的內 存：
可以看到，ref1沒什麼特別的。 但ref2這個匿名類的實現對象裏面多了一個引用：
this$0這個引用指向MainActivity.this，也就是說當前的MainActivity實例會被ref2持 有，如果將這個引用再傳入一個異步線程，此線程和此Acitivity生命週期不一致的時 候，就造成了Activity的泄露。
- Handler 造成的內存泄漏
Handler 的使用造成的內存泄漏問題應該說是最爲常見了，很多時候我們爲了 避免 ANR 而不在主線程進行耗時操作，在處理網絡任務或者封裝一些請求回 調等api都藉助Handler來處理，但 Handler不是萬能的，對於 Handler 的使用 代碼編寫一不規範即有可能造成內存泄漏。另外我們知道 Handler、 Message 和MessageQueue都是相互關聯在一起的，萬一 Handler 發送的 Message 尚未被處理，則該 Message 及發送它的 Handler 對象將被線程MessageQueue一直持有。 由於 Handler 屬於TLS(Thread Local Storage) 變 量, 生命週期和 Activity 是不一致的。因此這種實現方式一般很難保證跟 View 或者 Activity 的生命週期保持一致，故很容易導致無法正確釋放。
舉個例子：
public class SampleActivity extends Activity {
private final Handler mLeakyHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
// ...
}
}
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// Post a message and delay its execution for 10 minutes.
mLeakyHandler.postDelayed(new Runnable() {
@Override
public void run() { /* ... */ }
}, 1000 * 60 * 10);
// Go back to the previous Activity.
finish();
}
}
在該 SampleActivity中聲明瞭一個延遲10分鐘執行的消息 Message， mLeakyHandler 將其 push 進了消息隊列 MessageQueue 裏。當該 Activity 被 finish() 掉時，延遲執行任務的 Message 還會繼續存在於主線程中，它持有該 Activity 的 Handler 引用，所以此時 finish() 掉的 Activity 就不會被回收了從而造成 內存泄漏（因 Handler 爲非靜態內部類，它會持有外部類的引用，在這裏就是指 SampleActivity）。
修復方法： 在 Activity 中避免使用非靜態內部類，比如上面我們將 Handler 聲明爲 靜態的，則其存活期跟 Activity 的生命週期就無關了。同時通過弱引用的方式引入 Activity，避免直接將 Activity 作爲 context 傳進去,代碼省略…
綜述，即推薦使用靜態內部類 + WeakReference 這種方式。每次使用前注意判 空。前面提到了 WeakReference，所以這裏就簡單的說一下 Java 對象的幾種引用類 型。Java對引用的分類有 Strong reference,SoftReference, WeakReference, PhatomReference 四種。
未完待續…
（順手留下GitHub鏈接，需要獲取相關面試等內容的可以自己去找）
https://github.com/xiangjiana/Android-MS
更多完整項目下載。未完待續。源碼。圖文知識後續上傳github。
可以點擊關於我聯繫我獲取