靜態變數的生命週期，起始於類的載入，終止於類的釋放。
什麼時候類會載入呢?
我們知道，在app開啟時，會建立一個程序，然後初始化一個dvm的例項，負責類的載入釋放 和 垃圾回收等。
換句話說，在程序建立之後，就會載入類，靜態變數誕生了。
那何時釋放?
當然是在類解除安裝的時候。同上面。在程序結束之前，靜態變數就壽終正寢。
我們知道，Android中，你是不知道何時程序會被Kill。所以
1.不能保證靜態變數會一直存在.(程序可能被Kill掉)
2.每次開啟app時靜態變數的值都是初始值(程序沒有被kill掉所以靜態變數儲存的還是上次的值)。
而且，靜態變數是不會被垃圾回收的，其物件一直保持引用，及ARC不可能是0。
所以要自己釋放靜態變數。

網上查到的相關連結

1

單例模式討論篇：單例模式與垃圾回收

Jvm的垃圾回收機制到底會不會回收掉長時間不用的單例模式物件，這的確是一個比較有爭議性的問題。將這一部分內容單獨成篇的目的也是為了與廣大博友廣泛的討論一下這個問題。為了能讓更多的人看到這篇文章，請各位博友看完文章之後，點一下“頂”，讓本篇文章排名儘量的靠前。筆者在此謝過。
討論命題：當一個單例的物件長久不用時，會不會被jvm的垃圾收集機制回收。
首先說一下為什麼會產生這一疑問，筆者本人再此之前從來沒有考慮過垃圾回收對單例模式的影響，直到去年讀了一本書，《設計模式之禪》秦小波著。在書中提到在j2ee應用中，jvm垃圾回收機制會把長久不用的單例類物件當作垃圾，並在cpu空閒的時候對其進行回收。之前讀過的幾本設計模式的書，包括《java與模式》，書中都沒有提到jvm垃圾回收機制對單例的影響。並且在工作過程中，也沒有過單例物件被回收的經歷，加上工作中很多前輩曾經告誡過筆者：儘量不要宣告太多的靜態屬性，因為這些靜態屬性被載入後不會被釋放。因此對jvm垃圾收集會回收單例物件這一說法持懷疑態度。漸漸地，發現在同事中和網上的技術人員中，對這一問題也基本上是鮮明的對立兩派。那麼到底jvm會不會回收長久不用的單例物件呢。
對這一問題，**筆者本人的觀點是：不會回收**。
下面給出本人的測試程式碼
[java] view plaincopy
class Singleton {

private byte[] a = new byte[6*1024*1024];

private static Singleton singleton = new Singleton();

private Singleton(){}

1
2
3

public static Singleton getInstance(){  
    return singleton;  
}  

}

class Obj {

private byte[] a = new byte[3*1024*1024];

}

public class Client{

public static void main(String[] args) throws Exception{

Singleton.getInstance();

while(true){

new Obj();

}

}

}

本段程式的目的是模擬j2ee容器，首先例項化單例類，這個單例類佔6M記憶體，然後程式進入死迴圈，不斷的建立物件，逼迫jvm進行垃圾回收，然後觀察垃圾收集資訊，如果進行垃圾收集後，記憶體仍然大於6M，則說明垃圾回收不會回收單例物件。
執行本程式使用的虛擬機器是hotspot虛擬機器，也就是我們使用的最多的java官方提供的虛擬機器，俗稱jdk，版本是jdk1.6.0_12
執行時vm arguments引數為：-verbose:gc -Xms20M -Xmx20M，意思是每次jvm進行垃圾回收時顯示記憶體資訊，jvm的記憶體設為固定20M。
執行結果：
……
[Full GC 18566K->6278K(20352K), 0.0101066 secs]
[GC 18567K->18566K(20352K), 0.0001978 secs]
[Full GC 18566K->6278K(20352K), 0.0088229 secs]
……
從執行結果中可以看到總有6M空間沒有被收集。因此，筆者認為，至少在hotspot虛擬機器中，垃圾回收是不會回收單例物件的。
後來查閱了一些相關的資料，hotspot虛擬機器的垃圾收集演算法使用根搜尋演算法。這個演算法的基本思路是：對任何“活”的物件，一定能最終追溯到其存活在堆疊或靜態儲存區之中的引用。通過一系列名為根（GC Roots）的引用作為起點，從這些根開始搜尋，經過一系列的路徑，如果可以到達java堆中的物件，那麼這個物件就是“活”的，是不可回收的。可以作為根的物件有：
虛擬機器棧（棧楨中的本地變量表）中的引用的物件。
方法區中的類靜態屬性引用的物件。
方法區中的常量引用的物件。
本地方法棧中JNI的引用的物件。
方法區是jvm的一塊記憶體區域，用來存放類相關的資訊。很明顯，java中單例模式建立的物件被自己類中的靜態屬性所引用，符合第二條，因此，單例物件不會被jvm垃圾收集。
雖然jvm堆中的單例物件不會被垃圾收集，但是單例類本身如果長時間不用會不會被收集呢？因為jvm對方法區也是有垃圾收集機制的。如果單例類被收集，那麼堆中的物件就會失去到根的路徑，必然會被垃圾收集掉。對此，筆者查閱了hotspot虛擬機器對方法區的垃圾收集方法，jvm解除安裝類的判定條件如下：
該類所有的例項都已經被回收，也就是java堆中不存在該類的任何例項。
載入該類的ClassLoader已經被回收。
該類對應的java.lang.Class物件沒有任何地方被引用，無法在任何地方通過反射訪問該類的方法。
只有三個條件都滿足，jvm才會在垃圾收集的時候解除安裝類。顯然，單例的類不滿足條件一，因此單例類也不會被解除安裝。也就是說，只要單例類中的靜態引用指向jvm堆中的單例物件，那麼單例類和單例物件都不會被垃圾收集，依據根搜尋演算法，物件是否會被垃圾收集與未被使用時間長短無關，僅僅在於這個物件是不是“活”的。假如一個物件長久未使用而被回收，那麼收集演算法應該是最近最長未使用演算法，最近最長未使用演算法一般用在作業系統的內外存交換中，如果用在虛擬機器垃圾回收中，豈不是太不安全了？以上是筆者的觀點。

二(轉載)Android靜態變數的生命週期

Android是用Java開發，其靜態變數的生命週期遵守Java的設計。我們知道靜態變數是在類被load的時候分配記憶體的，並且存在於方法區。當類被解除安裝的時候，靜態變數被銷燬。在PC機的客戶端程式中，一個類被載入和解除安裝，可簡單的等同於jvm程序的啟動和結束。那麼在Android中呢？用的Dalvik vm也是一樣的。不過Android不太突出的程序概念，所以對靜態變數的生命週期就會感覺模糊，這種模糊對於值型別是無所謂的，如果是靜態的物件引用，則與記憶體回收、記憶體洩漏這些問題有關，有必要加深研究和理解。

一、靜態變數在類被載入的時候分配記憶體。

類在什麼時候被載入？

當我們啟動一個app的時候，系統會建立一個程序，此程序會載入一個Dalvik VM的例項，然後程式碼就執行在DVM之上，類的載入和解除安裝，垃圾回收等事情都由DVM負責。也就是說在程序啟動的時候，類被載入，靜態變數被分配記憶體。

二、靜態變數在類被解除安裝的時候銷燬。

類在什麼時候被解除安裝？

在程序結束的時候。

說明：一般情況下，所有的類都是預設的ClassLoader載入的，只要ClassLoader存在，類就不會被解除安裝，而預設的ClassLoader生命週期是與程序一致的，本文討論一般情況。

三、Android中的程序什麼時候結束

這個是Android對程序和記憶體管理不同於PC的核心——如果資源足夠，Android不會殺掉任何程序，另一個意思就是程序隨時可能會被殺掉。而Android會在資源夠的時候，重啟被殺掉的程序。也就是說靜態變數的值，如果不做處理，是不可靠的，可以說記憶體中的一切都不可靠。如果要可靠，還是得儲存到Nand或SD卡中去，在重啟的時候恢復回來。

另一種情況就是不能把退出所有Activity等同於程序的退出，所以在使用者點選圖示啟動應用的時候，以前存放於靜態變數中的值，有可能還存在，因此要視具體情況給予清空操作。

四、Application也是一樣不可靠

Application其實是一個單例物件，也是放在記憶體中的，當程序被殺掉，就全清空了，只不過Android系統會幫重建Application，而我們存放在Application的資料自然就沒有了，還是得自己處理。

五、靜態引用的物件不會被垃圾回收

只要靜態變數沒有被銷燬也沒有置null，其物件一直被保持引用，也即引用計數不可能是0，因此不會被垃圾回收。因此，單例物件在執行時不會被回收。