GC那些事兒--Android記憶體優化第一彈

anly_jun發表於2016-10-14

引言

App優化之記憶體優化(序), 作為App優化系列中記憶體優化的一個小部分.

由於記憶體相關知識比較生澀, 記憶體優化中使用到的相關工具, 也有很多專有名詞. 對Java記憶體管理, GC, Android記憶體管理, Dalvik/ART等知識有一個理論的認識, 可以讓我們更好的使用這些工具, 分析記憶體問題.

據此, 我們就先從理論入手, 聊聊GC那些事兒.

1, 何為GC

GC 是 garbage collection 的縮寫, 垃圾回收的意思. 也可以是 Garbage Collector, 也就是垃圾回收器.

1.1 垃圾回收器

我們先來解釋下Garbage Collector(垃圾回收器).

記憶體管理, 一直是程式設計中的一個大的問題. 在較老的語言中, 例如C++語言中, 記憶體管理是顯式的, 也就是說使用者自己申請記憶體使用, 自己釋放記憶體. 這就是為什麼C++語言中除了建構函式, 還有解構函式. 我們在建立物件的時候呼叫建構函式建立, 系統會在物件結束其作用域的時候呼叫解構函式, 我們需要做的就是在解構函式中釋放掉我們申請的相關資源, 以便釋放記憶體地址.

顯然, 這種顯式的由程式設計人員自己控制釋放記憶體的方式很容易出問題, 忘了, 漏了, 都可能導致記憶體問題. 也不符合程式設計師要懶的特徵.

故而, Java語言中引入了自動記憶體管理的機制, 也就是垃圾回收器. 大部分的現代面嚮物件語言, 也都是採用自動記憶體管理機制.

記憶體自動管理回收機制可以解決大部分, 但不是所有的記憶體問題, 這也是為什麼我們要討論記憶體洩露.

垃圾回收器的職責

垃圾回收器有三大職責:

  1. 分配記憶體;
  2. 確保任何被引用的物件保留在記憶體中;
  3. 回收不能通過引用關係找到的物件的記憶體.

垃圾回收的一般流程

GC那些事兒--Android記憶體優化第一彈
Slice 1

1.2 相關概念

垃圾回收(GC)

垃圾回收器中有一個程式來做上面的這些事情, 這個程式查詢我們的物件引用的關係並釋放其記憶體, 這個程式就是garbage collection(垃圾回收), 也就是我們常說的GC.

Heap和Stack

簡單說下:

  • Heap記憶體是指java執行環境用來分配給物件和JRE類的記憶體. 是應用的記憶體空間.
  • Stack記憶體是相對於執行緒Thread而言的, 它儲存執行緒中方法中短期存在的變數值和對Heap中物件的引用等.
  • Stack記憶體, 顧名思義, 是類Stack方式, 總是後進先出(LIFO)的.
  • 我們通常說的GC的針對Heap記憶體的. 因為Stack記憶體相當於是隨用隨銷的.

GC那些事兒--Android記憶體優化第一彈

GC Root

直譯GC根, 我們姑且不譯了吧.
所謂GC Root我們可以理解為是一個Heap記憶體之外的物件, 通常包括但不僅限於如下幾種:

  • System Class 系統Class Loader載入的類. 例如java執行環境中rt.jar中類, 比如java.util.* package中的類.
  • Thread 執行中的執行緒
  • JNI 中的本地/全域性變數, 使用者自定義的JNI程式碼或是JVM內部的.
  • Busy Monitor 任何呼叫了wait()或notify()方法, 或是同步化的(synchronized)的東西. 可以理解為同步監控器.
  • Java本地例項, 還在執行的Thread的stack中的方法建立的物件.

活物件/垃圾

如果這個物件是引用可達的, 則稱之為活的(live), 反之, 如果這個物件引用不可達, 則稱之為死的(dead), 也可以稱之為垃圾(garbage).

這個引用可達與不可達就是相對於GC Root來說的:

GC那些事兒--Android記憶體優化第一彈

2, Java的記憶體管理機制

2.1 關於JVM

我們平常在檢視我們的java版本時, 你會發現:

$ java -version
java version "1.8.0_74"
Java(TM) SE Runtime Environment (build 1.8.0_74-b02)
Java HotSpot(TM) 64-Bit Server VM (build 25.74-b02, mixed mode)複製程式碼

其中有個HotSpot VM的東西, 那麼這個是什麼呢? 和JVM有什麼關係呢?

在此簡單說下, 以便行文:

  • JVM, Java虛擬機器, 可以簡單理解為一種技術思想, 虛擬技術理念.
  • HotSpot VM是JVM的一種實現, 包含了伺服器版和桌面應用程式版, 現時由Oracle維護併發布.

我們當前使用的sun(oracle)的java版本(應該是1.3以上)都是內建的HotSpot VM實現. 所以接下來的分析也都是基於HotSpot VM的, 但是還是簡稱JVM.

2.2 JVM記憶體區域

JVM使用分代式的記憶體管理方式, 將Heap分成三代 --- 新生代, 老一代, 持久代.

GC那些事兒--Android記憶體優化第一彈

  • Young Generation

    • 新生代.
    • 所有new的物件.
    • 該區域的記憶體管理使用minor garbage collection(小GC).
    • 更進一步分成Eden space, Survivor 0 和 Survivor 1 三個部分.
  • Old Generation

    • 老年區.
    • 新生代中執行小粒度的GC倖存下來的"老"物件.
    • 該區域的記憶體管理使用major garbage collection(大GC).
  • Permanent Generation

    • 持久代.
    • 包含應用的類/方法資訊, 以及JRE庫的類和方法資訊.

小GC執行非常頻繁, 而且速度特別快.
大GC一般會比小GC慢十倍以上.
大小GC都會發出"Stop the World"事件, 也就是說中斷程式執行, 直至GC完成. 這也是我們在App優化之消除卡頓中為什麼說頻繁GC會造成使用者感知卡頓.

3, GC的流程

瞭解了記憶體Heap的幾個區域, 我們再來看下垃圾收集器是怎麼利用這幾個區域來管理記憶體和回收垃圾的.

1. 建立新的物件

每當我們使用new建立一個物件時, 這個物件會被分配到新生代Eden區域:

GC那些事兒--Android記憶體優化第一彈

2. 當Eden區域滿時
當Eden區域記憶體被分配完時, 小GC程式被觸發:

GC那些事兒--Android記憶體優化第一彈

引用可達的物件會移到Survivor(倖存者)區域--S0, 然後清空Eden區域, 此時引用不可達的物件會直接刪除, 記憶體回收, 如下:

GC那些事兒--Android記憶體優化第一彈

3. Eden再次滿時
當Eden區域再次分配完後, 小GC執行, 引用可達的物件會移到Survivor(倖存者)區域, 而引用不可達的物件會跟隨Eden的清空而刪除回收.

需要注意的是, 這次引用可達的物件移動到的是S1的倖存者區.
而且, S0區域也會執行小GC, 將其中還引用可達的物件移動到S1區, 且年齡+1. 然後清空S0, 回收其中引用不可達的物件.

此時, 所有引用可達的物件都在S1區, 且S1區的物件存在不同的年齡. 如下:

GC那些事兒--Android記憶體優化第一彈

當Eden第三次滿時, S0和S1的角色互換了:

GC那些事兒--Android記憶體優化第一彈

依此迴圈.

4. 當Survivor區的物件年齡達到"老年線"時
上面1~3迴圈, Survivor區的物件年齡也會持續增長, 當其中某些物件年齡達到"老年線", 例如8歲時, 它們會"晉升"到老年區.

GC那些事兒--Android記憶體優化第一彈

如此1~4步重複, 大體流程是這樣的

GC那些事兒--Android記憶體優化第一彈

參考


轉載請註明出處, 歡迎大家分享到朋友圈, 微博~

相關文章