Java記憶體機制

1. 虛擬機器執行時資料區

基本概念

虛擬機器
模擬某種計算機體系結構，執行特定指令集的軟體。包括程序虛擬機器和系統虛擬機器（VMWare）

• 程序虛擬機器：JVM、Adobe Flash Player、FC模擬器
  • 高階語言虛擬機器：JVM、.NET CLR、P-Code
    • Java語言虛擬機器：JVM、Apache Harmony
      • Java(TM)虛擬機器
        Java(TM)虛擬機器並不是只能執行Java程式
        三大商用JVM：Oracle Hotspot、Oracle JRockit Vm、IBM J9 VM
        • Oracle HotSpot虛擬機器
          Oracle JDK自帶的虛擬機器。HotSpot命名來自它的“熱點程式碼探測”技術。
          每一個Java程式都對應一個Java虛擬機器例項。

公有設計，私有實現
《Java虛擬機器規範》（JVMS）定義了概念模型，不約束虛擬機器的具體實現。
Java虛擬機器執行時資料區
在《Java虛擬機器規範》中定義了若干種程式執行期間會使用到的儲存不同型別資料的區域。
有一些區域是全域性共享的，隨著虛擬機器啟動而建立，隨著虛擬機器退出而銷燬。有一些區域是執行緒私有的，隨著執行緒開始和結束而建立和銷燬。
是所有Java虛擬機器共同的記憶體區域概念模型。

既然虛擬機器作為一個虛擬的計算機， 來執行我們的程式， 那麼在執行的過程中， 必然要有地方存放我們的程式碼（class檔案）； 在執行的過程中， 總會建立很多物件， 必須有地方存放這些物件； 在執行的過程中， 還需要儲存一些執行的狀態， 比如， 將要執行哪個方法， 當前方法執行完成之後， 要返回到哪個方法等資訊， 所以， 必須有一個地方來保持執行的狀態。 上面的描述中， “地方”指的當然就是記憶體區域， 程式執行起來之後， 就是一個動態的過程， 必須合理的劃分記憶體區域， 來存放各種資料。 所以， 在本文中， 將會詳細介紹JVM的執行時資料區。

執行時資料區的劃分

分為程式計數器、Java堆、Java虛擬機器棧、本地方法棧、方法區

• 執行緒私有的資料區包含程式計數器、虛擬機器棧、本地方法棧。
• 全域性共享的是Java堆、方法區（包括常量池）和直接記憶體
• 需要自動記憶體管理（GC）的區域：Java堆、方法區（不規定但實現了GC）、直接記憶體
• 可能出現OOM的區域：Java堆、Java虛擬機器棧、本地方法棧、方法區、直接記憶體
• 可能出現StackOverFlow的區域：Java虛擬機器棧和本地方法棧

程式計數器

這是一塊較小的記憶體空間，它的作用可以看作是當前執行緒所執行的位元組碼的行號指示器。
如果當前執行緒正在執行Java方法，指數器記錄的是正在執行的虛擬機器位元組碼指令的地址；如果是native方法，指數器為空。
這是唯一一個沒有OOM規定的區域。

Java虛擬機器棧

虛擬機器棧描述的是Java方法執行的記憶體模型：每個方法(不包括native方法)在執行時都會建立一個棧幀，用於儲存區域性變數，運算元棧，動態連結，方法出口等資訊。每一個方法從呼叫到執行結束的過程，就對應著一個棧幀在虛擬機器棧中入棧到出棧的過程。

在Java虛擬機器規範中，對該區域記憶體規定了兩種異常狀況:

• StackOverFlowError：當執行緒請求棧深度超出虛擬機器棧所允許的深度時丟擲
• OutOfMemoryError：當Java虛擬機器動態擴充套件到無法申請足夠記憶體時丟擲

本地方法棧

本地方法棧則為虛擬機器使用到的Native方法提供記憶體空間。有些虛擬機器的實現直接把本地方法棧和虛擬機器棧合二為一，比如非常典型的Sun HotSpot虛擬機器。

和虛擬機器棧一樣，本地方法棧區域也會丟擲StackOverflowError和OutOfMemoryError異常。

棧幀

棧幀(Stack Frame)是用於支援虛擬機器進行方法呼叫和方法執行的資料結構，它是虛擬機器執行時資料區的虛擬機器棧(Virtual Machine Stack)的棧元素。

它被用於儲存資料和部分過程結果的資料結構，同時也被用來處理動態連結、方法返回值和異常分派。

在編譯程式碼的時候，棧幀中需要多大的區域性變量表，多深的運算元棧都已經完全確定了，並且寫入到了方法表的Code屬性中，因此一個棧幀需要分配多少記憶體，不會受到程式執行期變數資料的影響，而僅僅取決於具體虛擬機器的實現。

對於執行引擎來講，活動執行緒中，只有虛擬機器棧頂的棧幀才是有效的，稱為當前棧幀(Current Stack Frame)，這個棧幀所關聯的方法稱為當前方法(Current Method)。執行引用所執行的所有位元組碼指令都只針對當前棧幀進行操作。

一個完整的棧幀包括：區域性變量表、運算元棧、動態連線資訊、方法正常完成和異常完成資訊

• 區域性變量表
  是一組變數值儲存空間，用於存放方法引數和方法內部定義的區域性變數。其大小以slot為最小單位(32位)。在Java程式編譯為Class檔案時，就在方法表的Code屬性的max_locals資料項中確定了該方法需要分配的最大區域性變量表的容量。它存放了編譯期可知的各種基本資料型別(boolean，byte,char,short,int,float,long,double)，物件引用，以及returnAddress型別(指向了一條位元組碼指令地址)
  區域性變量表用於方法間引數傳遞，以及方法執行過程中儲存基礎資料型別的值和物件的引用。
• 運算元棧
  運算元棧也常被稱為操作棧，它是一個後入先出棧，由若干個Entry組成。同區域性變量表一樣，運算元棧的最大深度也是編譯的時候被寫入到方法表的Code屬性的max_stacks資料項中。
  在方法執行過程中，棧幀用於儲存計算引數和計算結果；在方法呼叫時，運算元棧也用來準備呼叫方法的引數以及接收方法返回結果。

舉例

Java堆

1. 全域性共享
2. 通常是Java虛擬機器中最大的一片記憶體區域
3. 是Java物件的儲存區域
4. 需要實現自動記憶體管理，即GC，但不限制實現方式
5. 可能出現OOM異常

Java堆、棧的關聯過程：兩種方式

方式一的優點是訪問速度更快，因為方式二需要兩次指標定位。方式二的優點是，Java堆中的物件經常會變化（GC），此時只需要修改控制代碼池中的引用即可，比較方便。目前第一種方式比較流行。

方法區和執行時常量池

1. 全域性共享
2. 作用是儲存類的結構資訊
3. JVMS不要求進行記憶體管理，但商用Java虛擬機器都實現了自動記憶體管理
4. 執行時常量區是方法區的一部分，作用是儲存Java類檔案常量池中的符號資訊
5. 可能出現OOM異常

直接記憶體

1. 並非JVMS定義的標準記憶體區域
2. 隨JDK1.4加入的NIO引入，目的是避免在Java堆和Native堆中來回複製資料帶來的效能損耗
3. 全域性共享
4. 能被自動管理，但檢測手段比較簡陋
5. 可能出現OOM異常

2. 物件判定和回收演算法

可回收物件的判定方法

1. 引用計數演算法
給物件新增一個引用計數器，每當有一個地方引用它時，引用計數器的值加1；引用失效時，值減1；計數器為0的物件可以被回收。

缺點：迴圈引用
OC語言的解決方式：強引用和弱引用。弱引用不會增加引用計數。
2. 可達性分析演算法
由於引用計數演算法的缺陷，Java虛擬機器通常使用這種判定方法。

通過一系列稱為“GC Root”的物件作為起始點，從這些起點向下搜尋，搜尋路線稱為“引用鏈”，如果一個物件到GC Roots沒有任何引用鏈，則判定不可用。

Java中GC Roots：

1. 虛擬機器棧中（本地變量表中）引用的物件
2. 方法區的類靜態屬性引用的物件
3. 方法區中的常量引用的物件
4. 本地方法棧中JNI引用的物件

垃圾收集演算法

1. 標記-清除演算法
首先標記出所有需要回收的物件，標記完成後統一清除。
缺陷：產生大量不連續的記憶體碎片

2. 複製演算法
將可用記憶體分為相等的兩塊，每次只使用其中一塊，當一塊記憶體用完了，就將還活著的物件複製到另一塊記憶體中，再把這塊記憶體中的所有物件清除掉。
缺陷：將記憶體縮小了一半、複製開銷
改進：不一定需要分為大小相等的兩塊，可以適當提高可用記憶體比例。

3. 標記-整理演算法
標記過程與“標記-清理演算法”一樣，然後讓所有存活物件向一端移動，最後清理掉邊界以外的物件。
缺陷：系統停頓時間更長（移動消耗）

4. 分代演算法
當今商用Java虛擬機器共同採用的演算法。

根據物件存活週期的不同將記憶體劃分為幾塊。一般把Java堆分為新生代和老年代，然後在不同記憶體區域採用不同的垃圾收集演算法。比如新生代，會產生大量垃圾物件，適合採用複製演算法（需要複製的物件較少），而老年代可以採用標記-清理或者標記-整理演算法。

HotPot虛擬機器的演算法實現

GC Roots列舉

安全點和安全區

Android記憶體優化

1. Android記憶體管理機制

Android系統記憶體分配和回收

• 一個APP通常就是一個程序對應一個虛擬機器
• GC只有在Heap剩餘空間不夠時才觸發垃圾回收
• GC觸發時，所有執行緒都會被暫停（可能導致記憶體抖動）

APP記憶體限制機制

• 不同裝置分配的記憶體限制不同
• 吃記憶體大戶：圖片

切換應用時後臺APP清理機制

• APP切換的LRU cache：最近使用的APP最不可能被清理
• onTrimMemory()回撥

監控記憶體的方法

• Android方法
• AS monitor工具

2. Android記憶體優化方法

資料結構優化

1. 字串拼接使用StringBuilder：時間和空間效能都極大優於String
2. ArrayMap、SparseMap替換HashMap：時間和空間優化
3. 記憶體抖動：重複大量申請物件
   
4. 再小的class會耗費0.5kb
5. HashMap一個entry需要額外佔用32b

物件複用

1. 複用系統自帶的資源
2. listview、GridView複用
   3.避免在onDraw中建立物件（因為onDraw經常會呼叫，如果建立物件耗時、耗記憶體，會造成卡頓）

避免記憶體洩漏
記憶體洩漏會導致可用記憶體越來越少，頻繁造成GC

1. 單例模式使用了Activity的context（單例物件常駐記憶體），應該使用Application的context
2. 靜態變數引用Activity、view等物件沒有及時釋放（靜態變數常駐記憶體）
3. 非靜態內部類和匿名內部類會持有外部類（Activity）物件，因此內部類裡不能有靜態引用或耗時任務。否則不能用這兩種內部類。
4. Handler：message可能等待很長時間，在處理之前，message都持有handler引用，而handler持有Activity引用。導致洩漏。解決方式是將handler宣告為靜態，並將Activity的弱引用傳給它。或者在Activity結束時同時移除message。
5. 資源未關閉造成的記憶體洩漏
   對於使用了BraodcastReceiver，ContentObserver，File，遊標 Cursor，Stream，Bitmap等資源的使用，應該在Activity銷燬時及時關閉或者登出，否則這些資源將不會被回收，造成記憶體洩漏。參考http://waylenw.github.io/Android/android-bitmap-memory-yh/

3. OOM優化

當APP申請的記憶體空間大於系統為APP分配的空間時會出現OOM

1. 調整影象大小後再放入記憶體
2. 採用強引用＋軟引用2級快取，提高載入效能
3. 及時回收影象
4. 不要建立過多的靜態變數

參考文章