Android 內存洩漏總結
內存管理的目的就是讓我們在開發中怎麼有效的避免我們的應用出現內存洩漏的問題。內存洩漏大家都不陌生了，簡單粗俗的講，就是該被釋放的對像沒有釋放，一直被某個或某些實例所持有卻不再被使用導致GC 不能回收。最近自己閱讀了大量相關的文檔資料，打算做個總結沉澱下來跟大家一起分享和學習，也給自己一個警示，以後coding 時怎麼避免這些情況，提高應用的體驗和質量。
我會從java 內存洩漏的基礎知識開始，並通過具體例子來說明Android 引起內存洩漏的各種原因，以及如何利用工具來分析應用內存洩漏，最後再做總結。
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。
詳細Java中的內存洩漏
1.Java內存回收機制
不論哪種語言的內存分配方式，都需要返回所分配內存的真實地址，也就是返回一個指針到內存塊的首地址。 Java中對像是採用new或者反射的方法創建的，這些對象的創建都是在堆（Heap）中分配的，所有對象的回收都是由Java虛擬機通過垃圾回收機製完成的。 GC為了能夠正確釋放對象，會監控每個對象的運行狀況，對他們的申請、引用、被引用、賦值等狀況進行監控，Java會使用有向圖的方法進行管理內存，實時監控對像是否可以達到，如果不可到達，則就將其回收，這樣也可以消除引用循環的問題。在Java語言中，判斷一個內存空間是否符合垃圾收集標準有兩個：一個是給對象賦予了空值null，以下再沒有調用過，另一個是給對象賦予了新值，這樣重新分配了內存空間。
2.Java內存洩漏引起的原因
內存洩漏是指無用對象（不再使用的對象）持續佔有內存或無用對象的內存得不到及時釋放，從而造成內存空間的浪費稱為內存洩漏。內存洩露有時不嚴重且不易察覺，這樣開發者就不知道存在內存洩露，但有時也會很嚴重，會提示你Out of memory。
Java內存洩漏的根本原因是什麼呢？長生命週期的對象持有短生命週期對象的引用就很可能發生內存洩漏，儘管短生命週期對像已經不再需要，但是因為長生命週期持有它的引用而導致不能被回收，這就是Java中內存洩漏的發生場景。具體主要有如下幾大類：
1、靜態集合類引起內存洩漏：
像HashMap、Vector等的使用最容易出現內存洩露，這些靜態變量的生命週期和應用程序一致，他們所引用的所有的對象Object也不能被釋放，因為他們也將一直被Vector等引用著。
例如
Static Vector v = new Vector(10);for (int i = 1; i<100; i++){Object o = new Object();v.add(o);o = null;}在這個例子中，循環申請Object 對象，並將所申請的對象放入一個Vector 中，如果僅僅釋放引用本身（o=null），那麼Vector 仍然引用該對象，所以這個對像對GC 來說是不可回收的。因此，如果對象加入到Vector 後，還必須從Vector 中刪除，最簡單的方法就是將Vector對象設置為null。
2、當集合裡面的對象屬性被修改後，再調用remove()方法時不起作用。
例如：
public static void main(String[] args){Set<Person> set = new HashSet<Person>();Person p1 = new Person("唐僧","pwd1",25);Person p2 = new Person("孫悟空","pwd2",26);Person p3 = new Person("豬八戒","pwd3",27);set.add(p1);set.add(p2);set.add(p3);System.out.println("總共有:"+set.size()+" 個元素!"); //結果：總共有:3 個元素!p3.setAge(2); //修改p3的年齡,此時p3元素對應的hashcode值發生改變set.remove(p3); //此時remove不掉，造成內存洩漏set.add(p3); //重新添加，居然添加成功System.out.println("總共有:"+set.size()+" 個元素!"); //結果：總共有:4 個元素!for (Person person : set){System.out.println(person);}}3、監聽器
在java 編程中，我們都需要和監聽器打交道，通常一個應用當中會用到很多監聽器，我們會調用一個控件的諸如addXXXListener()等方法來增加監聽器，但往往在釋放對象的時候卻沒有記住去刪除這些監聽器，從而增加了內存洩漏的機會。
4、各種連接
比如數據庫連接（dataSourse.getConnection()），網絡連接(socket)和io連接，除非其顯式的調用了其close（）方法將其連接關閉，否則是不會自動被GC 回收的。對於Resultset 和Statement 對象可以不進行顯式回收，但Connection 一定要顯式回收，因為Connection 在任何時候都無法自動回收，而Connection一旦回收，Resultset 和Statement 對象就會立即為NULL。但是如果使用連接池，情況就不一樣了，除了要顯式地關閉連接，還必須顯式地關閉Resultset Statement 對象（關閉其中一個，另外一個也會關閉），否則就會造成大量的Statement 對象無法釋放，從而引起內存洩漏。這種情況下一般都會在try裡面去的連接，在finally裡面釋放連接。
5、內部類和外部模塊的引用
內部類的引用是比較容易遺忘的一種，而且一旦沒釋放可能導致一系列的後繼類對像沒有釋放。此外程序員還要小心外部模塊不經意的引用，例如程序員A 負責A 模塊，調用了B 模塊的一個方法如：
public void registerMsg(Object b);
這種調用就要非常小心了，傳入了一個對象，很可能模塊B就保持了對該對象的引用，這時候就需要注意模塊B 是否提供相應的操作去除引用。
6、單例模式
不正確使用單例模式是引起內存洩漏的一個常見問題，單例對像在初始化後將在JVM的整個生命週期中存在（以靜態變量的方式），如果單例對象持有外部的引用，那麼這個對象將不能被JVM正常回收，導致內存洩漏，考慮下面的例子：
class A{public A(){B.getInstance().setA(this);}....}//B類採用單例模式class B{private A a;private static B instance=new B();public B(){}public static B getInstance(){return instance;}public void setA(A a){this.a=a;}//getter...}顯然B採用singleton模式，它持有一個A對象的引用，而這個A類的對象將不能被回收。想像下如果A是個比較複雜的對像或者集合類型會發生什麼情況
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();// 使用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;@Overrideprotected 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() {@Overridepublic 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() {@Overridepublic void handleMessage(Message msg) {// ...}}@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);// Post a message and delay its execution for 10 minutes.mLeakyHandler.postDelayed(new Runnable() {@Overridepublic 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<SampleActivity> mActivity;public MyHandler(SampleActivity activity) {mActivity = new WeakReference<SampleActivity>(activity);}@Overridepublic 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() {@Overridepublic void run() { /* ... */ }};@Overrideprotected 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異常。這時，我們可以考慮使用軟/弱引用技術來避免這個問題發生。以下就是高速緩衝器的雛形：
首先定義一個HashMap，保存軟引用對象。
private Map <String, SoftReference<Bitmap>> imageCache = new HashMap <String, SoftReference<Bitmap>> ();
再來定義一個方法，保存Bitmap的軟引用到HashMap。
使用軟引用以後，在OutOfMemory異常發生之前，這些緩存的圖片資源的內存空間可以被釋放掉的，從而避免內存達到上限，避免Crash發生。
如果只是想避免OutOfMemory異常的發生，則可以使用軟引用。如果對於應用的性能更在意，想盡快回收一些佔用內存比較大的對象，則可以使用弱引用。
另外可以根據對像是否經常使用來判斷選擇軟引用還是弱引用。如果該對象可能會經常使用的，就盡量用軟引用。如果該對像不被使用的可能性更大些，就可以用弱引用。
ok，繼續回到主題。前面所說的，創建一個靜態Handler內部類，然後對Handler 持有的對象使用弱引用，這樣在回收時也可以回收Handler 持有的對象，但是這樣做雖然避免了Activity 洩漏，不過Looper 線程的消息隊列中還是可能會有待處理的消息，所以我們在Activity 的Destroy 時或者Stop 時應該移除消息隊列MessageQueue 中的消息。
下面幾個方法都可以移除Message：
public final void removeCallbacks(Runnable r);public final void removeCallbacks(Runnable r, Object token);public final void removeCallbacksAndMessages(Object token);public final void removeMessages(int what);public final void removeMessages(int what, Object object);
盡量避免使用static 成員變量
如果成員變量被聲明為static，那我們都知道其生命週期將與整個app進程生命週期一樣。
這會導致一系列問題，如果你的app進程設計上是長駐內存的，那即使app切到後台，這部分內存也不會被釋放。按照現在手機app內存管理機制，佔內存較大的後台進程將優先回收，yi'wei如果此app做過進程互保保活，那會造成app在後台頻繁重啟。當手機安裝了你參與開發的app以後一夜時間手機被消耗空了電量、流量，你的app不得不被用戶卸載或者靜默。
這裡修復的方法是：
不要在類初始時初始化靜態成員。可以考慮lazy初始化。
架構設計上要思考是否真的有必要這樣做，盡量避免。如果架構需要這麼設計，那麼此對象的生命週期你有責任管理起來。
避免override finalize()
1、finalize 方法被執行的時間不確定，不能依賴與它來釋放緊缺的資源。時間不確定的原因是：
虛擬機調用GC的時間不確定
Finalize daemon線程被調度到的時間不確定
2、finalize 方法只會被執行一次，即使對像被復活，如果已經執行過了finalize 方法，再次被GC 時也不會再執行了，原因是：
含有finalize 方法的object 是在new 的時候由虛擬機生成了一個finalize reference 在來引用到該Object的，而在finalize 方法執行的時候，該object 所對應的finalize Reference 會被釋放掉，即使在這個時候把該object 復活(即用強引用引用住該object )，再第二次被GC 的時候由於沒有了finalize reference 與之對應，所以finalize 方法不會再執行。
3、含有Finalize方法的object需要至少經過兩輪GC才有可能被釋放。
資源未關閉造成的內存洩漏
對於使用了BraodcastReceiver，ContentObserver，File，游標Cursor，Stream，Bitmap等資源的使用，應該在Activity銷毀時及時關閉或者註銷，否則這些資源將不會被回收，造成內存洩漏。
一些不良代碼造成的內存壓力
有些代碼並不造成內存洩露，但是它們，或是對沒使用的內存沒進行有效及時的釋放，或是沒有有效的利用已有的對象而是頻繁的申請新內存。
比如：
Bitmap 沒調用recycle()方法，對於Bitmap 對像在不使用時,我們應該先調用recycle() 釋放內存，然後才它設置為null. 因為加載Bitmap 對象的內存空間，一部分是java 的，一部分C 的（因為Bitmap 分配的底層是通過JNI 調用的)。 而這個recyle() 就是針對C 部分的內存釋放。
構造Adapter 時，沒有使用緩存的convertView ,每次都在創建新的converView。這裡推薦使用ViewHolder。
總結
對Activity 等組件的引用應該控制在Activity 的生命週期之內； 如果不能就考慮使用getApplicationContext 或者getApplication，以避免Activity 被外部長生命週期的對象引用而洩露。
盡量不要在靜態變量或者靜態內部類中使用非靜態外部成員變量（包括context )，即使要使用，也要考慮適時把外部成員變量置空；也可以在內部類中使用弱引用來引用外部類的變量。
對於生命週期比Activity長的內部類對象，並且內部類中使用了外部類的成員變量，可以這樣做避免內存洩漏：
將內部類改為靜態內部類
靜態內部類中使用弱引用來引用外部類的成員變量
Handler 的持有的引用對象最好使用弱引用，資源釋放時也可以清空Handler 裡面的消息。比如在Activity onStop 或者onDestroy 的時候，取消掉該Handler 對象的Message和Runnable.
在Java 的實現過程中，也要考慮其對象釋放，最好的方法是在不使用某對象時，顯式地將此對象賦值為null，比如使用完Bitmap 後先調用recycle()，再賦為null,清空對圖片等資源有直接引用或者間接引用的數組（使用array.clear() ; array = null）等，最好遵循誰創建誰釋放的原則。
正確關閉資源，對於使用了BraodcastReceiver，ContentObserver，File，游標Cursor，Stream，Bitmap等資源的使用，應該在Activity銷毀時及時關閉或者註銷。
保持對對像生命週期的敏感，特別注意單例、靜態對象、全局性集合等的生命週期。
以上所述是小編給大家介紹的Java中關於內存洩漏出現的原因匯總及如何避免內存洩漏（超詳細版），希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復大家的。在此也非常感謝大家對武林網網站的支持！