編輯：關於Android編程
內存管理的目的就是讓我們在開發中怎麼有效的避免我們的應用出現內存洩漏的問題。內存洩漏大家都不陌生了，簡單粗俗的講，就是該被釋放的對象沒有釋放，一直被某個或某些實例所持有卻不再被使用導致 GC 不能回收。最近自己閱讀了大量相關的文檔資料，打算做個總結沉澱下來跟大家一起分享和學習，也給自己一個警示，以後 coding 時怎麼避免這些情況，提高應用的體驗和質量。
我會從 java 內存洩漏的基礎知識開始，並通過具體例子來說明 Android 引起內存洩漏的各種原因，以及如何利用工具來分析應用內存洩漏，最後再做總結。
篇幅有些長，大家可以分幾節來看！
手機內存是指手機的RAM(Random Access Memory),即隨機存儲器，在工作狀態時可以隨機讀寫數據，斷電以後會丟失數據。可分為以下幾個部分：
寄存器（Registers）：速度最快的存儲場所，位於處理器內部，在程序中無法控制。 棧（Stack）：存放基本類型的數據和對象的引用，但對象本身不存放在棧中，而存放在堆中。 堆（Heap）：用來存放對象和數組，在堆中分配的內存，由Java虛擬機的垃圾回收器（GC）來管理。 靜態存儲區（Static Field）：指在固定的位置存放應用程序運行時一直存在的數據，Java在內存中專門劃分了一個靜態存儲區來管理一些特殊的數據變量 如靜態的數據變量。 常量池（Constant Pool）：JVM虛擬機必須為每一個被裝載的類維護一個常量池。常量池就是該類所用到的常量的一個有序集合，包括直接常量（基本類型，String）和對其他類、字段和方法的符號引用。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，而它自己存在於棧中。
結論：
了解了 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中的內存洩漏，這些對象不會被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。
集合類如果僅僅有添加元素的方法，而沒有相應的刪除機制，導致內存被占用。如果這個集合類是全局性的變量 (比如類中的靜態屬性，全局性的 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();// 使用Application 的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 的使用造成的內存洩漏問題應該說是最為常見了，很多時候我們為了避免 ANR 而不在主線程進行耗時操作，在處理網絡任務或者封裝一些請求回調等api都借助Handler來處理，但 Handler 不是萬能的，對於 andler 的使用代碼編寫一不規范即有可能造成內存洩漏。另外，我們知道 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 傳進去，見下面代碼：
public class SampleActivity extends Activity {
/**
* Instances of static inner classes do not hold an implicit
* reference to their outer class.
*/
private static class MyHandler extends Handler {
private final WeakReference mActivity;
public MyHandler(SampleActivity activity) {
mActivity = new WeakReference(activity);
}
@Override
public void handleMessage(Message msg) {
SampleActivity activity = mActivity.get();
if (activity != null) {
// ...
}
}
}
private final MyHandler mHandler = new MyHandler(this);
/**
* Instances of anonymous classes do not hold an implicit
* reference to their outer class when they are "static".
*/
private static final Runnable sRunnable = new Runnable() {
@Override
public void run() { /* ... */ }
};
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// Post a message and delay its execution for 10 minutes.
mHandler.postDelayed(sRunnable, 1000 * 60 * 10);
// Go back to the previous Activity.
finish();
}
}
綜述，即推薦使用靜態內部類 + WeakReference 這種方式。每次使用前注意判空。
前面提到了 WeakReference，所以這裡就簡單的說一下 Java 對象的幾種引用類型。
Java對引用的分類有 Strong reference, SoftReference, WeakReference, PhatomReference四種。
在Android應用的開發中，為了防止內存溢出，在處理一些占用內存大而且聲明周期較長的對象時候，可以盡量應用軟引用和弱引用技術。
軟/弱引用可以和一個引用隊列（ReferenceQueue）聯合使用，如果軟引用所引用的對象被垃圾回收器回收，Java虛擬機就會把這個軟引用加入到與之關聯的引用隊列中。利用這個隊列可以得知被回收的軟/弱引用的對象列表，從而為緩沖器清除已失效的軟/弱引用。
假設我們的應用會用到大量的默認圖片，比如應用中有默認的頭像，默認游戲圖標等等，這些圖片很多地方會用到。如果每次都去讀取圖片，由於讀取文件需要硬件操作，速度較慢，會導致性能較低。所以我們考慮將圖片緩存起來，需要的時候直接從內存中讀取。但是，由於圖片占用內存空間比較大，緩存很多圖片需要很多的內存，就可能比較容易發生OutOfMemory異常。這時，我們可以考慮使用軟/弱引用技術來避免這個問題發生。以下就是高速緩沖器的雛形：
首先定義一個ashMap，保存軟引用對象。
