標籤:bag 一個棧 申請 方法區 並且 分析 發展 完全 相等
從誕生至今,20多年過去,Java至今仍是使用最為廣泛的語言。這仰賴於Java提供的各種技術和特性,讓開發人員能優雅的編寫高效的程式。今天我們就來說說Java的一項基本但非常重要的技術記憶體管理
瞭解C語言的同學都知道,在C語言中記憶體的開闢和釋放都是由我們自己來管理的,每一個new操作都要對於一個delete操作,否則就會參數記憶體流失和溢出的問題,導致非常槽糕的後果。但在Java開發過程中,則完全不需要擔心這個問題。因為jvm提供了自動記憶體管理的機制。記憶體管理的工作由jvm幫我們完成。這樣我們就不用為了釋放記憶體而頭疼了。
Jvm記憶體淺析
雖然jvm幫我們做了記憶體管理的工作,但是我們仍需要瞭解jvm到底做了什麼,下面我們就一起去看一看
jvm啟動時進行一系列的工作,其中一項就是開闢一塊運行時記憶體。而這一塊記憶體中又分為了五大地區,分別用於不同的功能。
程式計數器
記錄程式啟動並執行下一條指令的地址,這裡的“地址”可以是一個本地指標,也可以是在方法位元組碼中相對於該方法起始指令的位移量。如果該線程正在執行一個本地方法,那麼此時程式計數器的值為”undefined”.在多線程環境下,每一個線程都有自己的程式計數器,在jvm調度線程時,會把當前的線程的程式計數器儲存到快照,以便下次線程擷取執行時間時擷取
VM Stack
虛擬機器棧是Java方法執行的記憶體模型,每個方法執行的時候,會在棧中建立一幀用於儲存局部變數表、運算元棧、動態連結、方法出口。方法開始調用時,會建立棧幀併入棧,方法執行結束時會出棧。每個線程都有自己的棧。
動態連結:是一種在常量池中指向方法的符號引用,需要在運行期確定為直接引用
方法出口:當前執行方法的調用者的程式計數器,或異常處理表的地址
可以通過 -xxs 大小 來配置棧的大小,當嵌套調用使用不當,會導致方法不停的入棧,最終導致棧空間被佔滿產生 StackOverflowError
本地方法棧
Heap
堆是用於存放對象執行個體的地方,幾乎所有對象執行個體在堆中分配。堆是線程共用的,這是多線程時同步機制的原因。
堆是GC管理的主要區域,GC在對堆進行回收前,首先要確定對象是否已死(不可能再被使用的對象)
判斷對象是否存活的演算法有兩種:引用計數演算法、可達性分析演算法
引用計數演算法是為每一個對象添加一個引用計數器,每當有一個引用指向它時,計數器就加一,任何時刻計數器為0的對象就不可能再被使用。這種演算法實現簡單,但是它很難解決對象循環參考的問題(何為循環參考見下方備忘)
可達性分析演算法是Java語言正在使用的演算法。它的基本思想是通過一系統被稱為“GC Root”的對象為起點,從這個起點向下搜尋,搜尋走過的路徑稱為引用鏈,當一個對象不再任何引用鏈上時,則說明這個對象是不可能再被使用的。
在Java語言中,GC Root包括以下幾種對象:
- 虛擬機器棧中引用的對象
- 本地方法棧中JNI引用的對象
- 方法區中類靜態成員變數引用的對象
- 方法區中常量引用的對象
可以看出分析對象是否存活,都與引用有關。在JDK1.2之後,Java對引用的概念進行了擴充,將引用分為 強引用(Strong Reference)、軟引用(Soft Reference)、弱引用(Weak Reference)、虛引用(Phantom Reference)
- 強引用
強引用即為原來意義上的引用,只要強引用存在,被引用的對象就不會被回收
- 軟引用
SoftReference類表示軟引用,對於被軟引用關聯的對象,在系統將要發生記憶體溢出時,會把這些對象列入回收範圍後,進行二次回收
- 弱引用
WeakReference類表示弱引用,對於被弱引用關聯的對象,只能生存到下一次記憶體回收發生之前
- 虛引用
PhantomReference類表示虛引用,虛引用不對關聯的對象的存留時間構成影響,也無法取得對象執行個體,它唯一的作用是在對象被GC回收是收到一條系統通知
堆得大小可以通過-Xmx和-Xms來控制。對於主流的Jvm,GC基本都採用分代收集的演算法。基於這個演算法, Java堆又分為新生代(Young Generation)和老年代(Old Generation),新生代又被進一步劃分為Eden和Survivor區,最後Survivor由FromSpace和ToSpace組成。建立的對象都是用新生代分配記憶體,Eden空間不足的時候,會把存活的對象轉移到Survivor中,新生代大小可以由-Xmn來控制,也可以用-XX:SurvivorRatio來控制Eden和Survivor的比例。老生代用於存放新生代中經過多次記憶體回收(也即Minor GC)仍然存活的對象。
永生代(Permanent Space)為方法區
方法區
方法區也為所以線程所共用,用於存放已載入的類資訊、靜態變數、常量和即時編譯器編譯後的代碼。-XX:MaxPermSize用於設定方法區大小
直接記憶體
直接記憶體不是虛擬機器運行時資料區的一部分。通過Native函數庫直接分配的堆外記憶體,然後通過儲存在Java堆中的DirectByteBuffer對象作為這塊記憶體的引用進行操作
記憶體配置和回收策略
目前為止,jvm已經發展處三種比較成熟的垃圾收集演算法:1.標記-清除演算法;2.複製演算法;3.標記-整理演算法;4.分代收集演算法
1. 標記-清除演算法
這種記憶體回收一次回收分為兩個階段:標記、清除。首先標記所有需要回收的對象,在標記完成後回收所有被標記的對象。這種回收演算法會產生大量不連續的記憶體片段,當要頻繁分配一個大對象時,jvm在新生代中找不到足夠大的連續的記憶體塊,會導致jvm頻繁進行記憶體回收(目前有機制,對大對象,直接分配到老年代中)
2. 複製演算法
這種演算法會將記憶體劃分為兩個相等的塊,每次只使用其中一塊。當這塊記憶體不夠使用時,就將還存活的對象複製到另一塊記憶體中,然後把這塊記憶體一次清理掉。這樣做的效率比較高,也避免了記憶體片段。但是這樣記憶體的可使用空間減半,是個不小的損失。
3. 標記-整理演算法
這是標記-清除演算法的升級版。在完成標記階段後,不是直接對可回收對象進行清理,而是讓存活對象向著一端移動,然後清理掉邊界以外的記憶體
4. 分代收集演算法
當前商業虛擬機器都採用這種演算法。首先根據對象存活周期的不同將記憶體分為幾塊即新生代、老年代,然後根據不同年代的特點,採用不同的收集演算法。在新生代中,每次垃圾收集時都有大量對象死去,只有少量存活,所以選擇了複製演算法。而老年代中因為對象存活率比較高,所以採用標記-整理演算法(或者標記-清除演算法)
GC的執行機制
由於對象進行了分代處理,因此記憶體回收地區、時間也不一樣。GC有兩種類型:Scavenge GC和Full GC。
Minor GC
一般情況下,當新對象產生,並且在Eden申請空間失敗時,就會觸發Minor GC,對Eden地區進行GC,清除非存活對象,並且把尚且存活的對象移動到Survivor區。然後整理Survivor的兩個區。這種方式的GC是對年輕代的Eden區進行,不會影響到年老代。因為大部分對象都是從Eden區開始的,同時Eden區不會分配的很大,所以Eden區的GC會頻繁進行。因而,一般在這裡需要使用速度快、效率高的演算法,使Eden去能儘快空閑出來。
Full GC
對整個堆進行整理,包括Young、Tenured和Perm。Full GC因為需要對整個堆進行回收,所以比Minor GC要慢,因此應該儘可能減少Full GC的次數。在對JVM調優的過程中,很大一部分工作就是對於FullGC的調節。有如下原因可能導致Full GC:
1.年老代(Tenured)被寫滿
2.持久代(Perm)被寫滿
3.System.gc()被顯示調用
4.上一次GC之後Heap的各域分配策略動態變化
Java常見的記憶體流失
- 資料庫連接,網路連接,IO串連等沒有顯示調用close關閉,會導致記憶體泄露
- 監聽器的使用,在釋放對象的同時沒有相應刪除監聽器的時候也可能導致記憶體泄露
JAVA是記憶體回收語言的一種,開發人員無需特意管理記憶體配置。但是JAVA中還是存在著許多記憶體泄露的可能性,如果不好好處理記憶體泄露,會導致APP記憶體單元無法釋放被浪費掉,最終導致記憶體全部佔據堆棧(heap)擠爆進而程式崩潰。
記憶體泄露
說到記憶體泄露,就不得不提到記憶體溢出,這兩個比較容易混淆的概念,我們來分析一下。
大量的記憶體泄露會導致記憶體溢出(oom)。
記憶體
想要瞭解記憶體泄露,對記憶體的瞭解必不可少。
JAVA是在JVM所虛擬出的記憶體環境中啟動並執行,JVM的記憶體可分為三個區:堆(heap)、棧(stack)和方法區(method)。
棧(stack):是簡單的資料結構,但在電腦中使用廣泛。棧最顯著的特徵是:LIFO(Last In, First Out, 後進先出)。比如我們往箱子裡面放衣服,先放入的在最下方,只有拿出後來放入的才能拿到下方的衣服。棧中只存放基本類型和對象的引用(不是對象)。
堆(heap):堆記憶體用於存放由new建立的對象和數組。在堆中分配的記憶體,由java虛擬機器自動記憶體回收行程來管理。JVM只有一個堆區(heap)被所有線程共用,堆中不存放基本類型和對象引用,只存放對象本身。
方法區(method):又叫靜態區,跟堆一樣,被所有的線程共用。方法區包含所有的class和static變數。
記憶體的概念大概理解清楚後,要考慮的問題來了:
到底是哪裡的記憶體會讓我們造成記憶體泄露?
記憶體泄露原因分析
在JAVA中JVM的棧記錄了方法的調用,每個線程擁有一個棧。線上程的運行過程當中,執行到一個新的方法調用,就在棧中增加一個記憶體單元,即幀(frame)。在frame中,儲存有該方法調用的參數、局部變數和返回地址。然而JAVA中的局部變數只能是基本類型變數(int),或者對象的引用。所以在棧中只存放基本類型變數和對象的引用。引用的對象儲存在堆中。
當某方法運行結束時,該方法對應的frame將會從棧中刪除,frame中所有局部變數和參數所佔有的空間也隨之釋放。線程回到原方法繼續執行,當所有的棧都清空的時候,程式也就隨之運行結束。
而對於堆記憶體,堆存放著普通變數。在JAVA中堆記憶體不會隨著方法的結束而清空,所以在方法中定義了局部變數,在方法結束後變數依然存活在堆中。
綜上所述,棧(stack)可以自行清除不用的記憶體空間。但是如果我們不停的建立新對象,堆(heap)的記憶體空間就會被消耗盡。所以JAVA引入了記憶體回收(garbage collection,簡稱GC)去處理堆記憶體的回收,但如果對象一直被引用無法被回收,造成記憶體的浪費,無法再被使用。所以對象無法被GC回收就是造成記憶體泄露的原因!
記憶體回收機制
記憶體回收(garbage collection,簡稱GC)可以自動清空堆中不再使用的對象。在JAVA中對象是通過引用使用的。如果再沒有引用指向該對象,那麼該對象就無從處理或調用該對象,這樣的對象稱為不可到達(unreachable)。記憶體回收用於釋放不可到達的對象所佔據的記憶體。
實現思想:我們將棧定義為root,遍曆棧中所有的對象的引用,再遍曆一遍堆中的對象。因為棧中的對象的引用執行完畢就刪除,所以我們就可以通過棧中的對象的引用,尋找到堆中沒有被指向的對象,這些對象即為不可到達對象,對其進行記憶體回收。
記憶體回收實現思想
如果持有對象的強引用,記憶體回收行程是無法在記憶體中回收這個對象。
參考型別
在JDK 1.2以前的版本中,若一個對象不被任何變數引用,那麼程式就無法再使用這個對象。也就是說,只有對象處於可觸及(reachable)狀態,程式才能使用它。從JDK 1.2版本開始,把對象的引用分為4種層級,從而使程式能更加靈活地控制對象的生命週期。這4種層級由高到低依次為:強引用、軟引用、弱引用和虛引用。
Java/Android參考型別及其流量分析
1. 強引用(Strong reference)
實際編碼中最常見的一種參考型別。常見形式如:A a = new A();等。強引用本身儲存在棧記憶體中,其儲存指向對記憶體中對象的地址。一般情況下,當對記憶體中的對象不再有任何強引用指向它時,記憶體回收機器開始考慮可能要對此記憶體進行的記憶體回收。如當進行編碼:a = null,此時,剛剛在堆中分配地址並建立的a對象沒有其他的任何引用,當系統進行記憶體回收時,堆記憶體將被記憶體回收。
2. 軟引用(Soft Reference)
軟引用的一般使用形式如下:
A a = new A();
SoftReference<A> srA = new SoftReference<A>(a);
軟引用所指示的對象進行記憶體回收需要滿足如下兩個條件:
1.當其指示的對象沒有任何強引用對象指向它;
2.當虛擬機器記憶體不足時。
因此,SoftReference變相的延長了其指示對象佔據堆記憶體的時間,直到虛擬機器記憶體不足時記憶體回收行程才回收此堆記憶體空間。
3. 弱引用(Weak Reference)
同樣的,軟引用的一般使用形式如下:
A a = new A();
WeakReference<A> wrA = new WeakReference<A>(a);
WeakReference不改變原有強引用對象的記憶體回收時機,一旦其指示對象沒有任何強引用對象時,此對象即進入正常的記憶體回收流程。
4. 虛引用(Phantom Reference)
與SoftReference或WeakReference相比,PhantomReference主要差別體現在如下幾點:
1.PhantomReference只有一個建構函式
PhantomReference(T referent, ReferenceQueue<? super T> q)
2.不管有無強引用指向PhantomReference的指示對象,PhantomReference的get()方法返回結果都是null。
因此,PhantomReference使用必須結合ReferenceQueue;
與WeakReference相同,PhantomReference並不會改變其指示對象的記憶體回收時機。
記憶體泄露原因
如果持有對象的強引用,記憶體回收行程是無法在記憶體中回收這個對象。
記憶體泄露的真因是:持有對象的強引用,且沒有及時釋放,進而造成記憶體單元一直被佔用,浪費空間,甚至可能造成記憶體溢出!
其實在Android中會造成記憶體泄露的情景無外乎兩種:
- 全域進程(process-global)的static變數。這個無視應用的狀態,持有Activity的強引用的怪物。
- 活在Activity生命週期之外的線程。沒有清空對Activity的強引用。
檢查一下你的項目中是否有以下幾種情況:
- Static Activities
- Static Views
- Inner Classes
- Anonymous Classes
- Handler
- Threads
- TimerTask
- Sensor Manager
java的GC與記憶體流失