JVM記憶體結構闡述

記憶體結構

程式計數器

• 作用，是記住下一條jvm指令的執行地址

• 是執行緒私有的

• 在執行緒背景關系切換的程序中需要記錄到下一條要執行的指令的地址，等到執行緒再次被調度到執行的時候，還是根據該執行緒的程式計數器，來找到下一條要執行的指令的地址

• 每個執行緒都有自己獨有的程式計數器

• 唯一一個記憶體不會溢位的

• 隨著執行緒創建而創建，隨著執行緒銷毀而銷毀

堆疊

堆疊可以說是虛擬機堆疊中的區域變數表

區域變數表中存放了編譯期可知的各種基本資料型別，物件參考（不等于物件本身，可能是一個指向物件起始地址的參考指標，也可能是指向一個代表物件的句柄或其他與此物件相關的位置）和returnAddress型別（指向了一條位元組碼指令的地址），

• 執行緒運行需要的記憶體空間

• 堆疊幀（引數，區域變數，回傳地址）：每個方法運行時需要的記憶體

• 一個堆疊由多個堆疊幀組成

• 堆疊先入后出

堆疊的演示

主方法呼叫method1，method1呼叫method2

method2堆疊幀在堆疊的頂部

method1在堆疊的中間

主方法在堆疊的底部

區域變數，引數在method2堆疊幀內占用記憶體

方法結束完后一步步從頂至下彈出，占用的記憶體也會被釋放掉

問題辨析

1. 垃圾回收是否涉及堆疊記憶體：不需要，堆疊記憶體是一次次方法呼叫產生的堆疊幀記憶體，而每一次方法呼叫后都會被彈出堆疊，自動被回收掉，不需要垃圾回收來涉及堆疊記憶體

2. 堆疊記憶體分配越大越好嗎：堆疊記憶體過大會導致執行緒數變少，物理記憶體大小是有限的,假設物理記憶體為500M，如果堆疊記憶體為250M，能運行的執行緒就只有倆個

3. 方法內的區域變數是否執行緒安全：區域變數是執行緒私有的，不會受到其他執行緒干擾，是執行緒安全的，但是給區域變數加上static修飾，就會有執行緒安全問題了！如果方法內區域變數沒有逃離方法的作用范圍，它就是執行緒安全的，如果區域變數參考了物件，并逃離方法的作用范圍，需要考慮執行緒安全，

三個方法 m1執行緒安全，m2，m3執行緒安全需要考慮

m2中StringBuilder作為引數（逃離了方法的作用范圍）可能被別的執行緒訪問到，需要改成Stringbuffer才能保證執行緒安全

m3中把sb回傳（逃離了方法的作用范圍）可能導致被別的執行緒訪問到

堆疊記憶體溢位

1. 堆疊幀過多導致堆疊記憶體溢位（stackOverFlowError）（遞回沒有退出條件）

2. 堆疊幀過大導致堆疊記憶體溢位

執行緒運行診斷

• 用top（linux命令）定位哪個行程對cpu占用過高

•  ps H -eo pid，%cpu | grep 行程id

  （用ps命令進一步定位是哪個執行緒引起的cpu占用過高）

• jstack行程id （根據執行緒id找到有問題的執行緒）

本地方法堆疊

java中有時候不能與作業系統直接互動，需要本地方法介面（c，c++撰寫的）與作業系統更底層的api來實作互動

堆

堆：通過new關鍵字，創建物件都會使用堆記憶體，是java虛擬機所管理的記憶體中最大的一塊，此記憶體區域唯一目的就是存放物件實體，幾乎所有的物件實體都在這里分配記憶體，堆是垃圾收集器管理的主要區域

• 它是執行緒共享的，堆中物件都要考慮執行緒安全

• 有垃圾回識訓制

堆記憶體溢位（java.lang.OutofMemoryError：java heap space）

堆記憶體診斷（idea Terminal中輸入命令）

• jps：查看當前系統有哪些java行程

• jmap -heap （行程id） 檢查java堆記憶體占用

• jconsole 圖形化界面監視和管理控制臺

• jvisualvm 可視化虛擬機

方法區

隨著虛擬機啟動時創建

方法區與堆一樣是各個java虛擬機執行緒共享的一塊區域

它存盤了跟類的結構相關的一些資訊

類的成員變數，常量，靜態變數，方法資料，以及成員方法，構造器方法，特殊方法的代碼部分等資料，雖然java虛擬機規范把方法區描述為堆的一個邏輯部分，但是它有一個別名叫做Non-Heap（非堆），目的應該是與java堆區分開來

永久代：hotspot虛擬機1.8以前對方法區的稱呼

方法區記憶體溢位：

• 1.8以前導致永久代溢位

• 1.8以后會導致元空間溢位

場景：

• spring

• mybatis

• 動態代理

  在運行時生成類導致記憶體溢位

運行時常量池

常量池：就是一張表，虛擬機指令可以根據這張表找到要執行的類名，方法名，引數型別，字面量等資訊

運行時常量池：運行時常量池是方法區的一部分，Class檔案中除了有類的版本，欄位，方法，介面等描述資訊外，還有一項資訊是常量池，用于存放編譯期生成的各種字面量和符號參考，這部分內容將在類加載后進入方法區的運行時常量池中存放，并把里面的符號變為真實地址

JDK1.8 StringTable（字串常量池(運行時常量池的一部分)）是存在堆中的

jdk1.6即以下版本 StringTable是在永久代中

最重要一點，StringTable中存盤的并不是String型別的物件，儲存的而是指向String物件的索引，真實物件還是儲存在堆中，

s1+s2是變數，在運行中可能參考的值被修改，結果不能確定，所以必須在運行期間動態的用StringBuilder進行字串拼接，而s5是常量在編譯期就已經能確定好，不需要StringBuilder方式拼接

字串是延遲稱為物件的，即執行到哪一行才會在字串常量池中放入那一行

了解字串常量池StringTable案例

String.intern()是一個Native方法，它的作用：如果字串常量池中已經包含一個等于此String物件的字串，則回傳代表池中這個物件的String物件，否則將此String物件包含的字串添加到常量池中，并且回傳此String物件的參考

這里一開始將x放入了字串常量池，然后new了一個s放在了堆中

s.intern將s放入串池，但是串池中已經有了“ab” 則不會放入串池，只會回傳串池中的物件 所以s2 == x（true） 因為s2是串池中回傳的物件 與常量池中的ab相等，s==x為false 常量池已經有了“ab”所以沒把s放入串池中，還是存在堆中 (jdk1.8).

s2==x（true）

s== x（true） 因為s.intern（）方法將s放入了字串常量池(串池中沒有“ab”)

如果是jdk1.6是將s拷貝，結果又會不同了，這里就不進行詳細闡述了

x1 == x2 為false 因為常量池已有cd x2.intern（）沒有將x2放入常量池成功，x2.intern（）的回傳物件才會與 x1 相同

StringTable調優

調整 -XX:StringTableSize=桶個數

考慮將字串物件是否入池

如果字串很多 可考慮入池

直接記憶體

直接記憶體并不是虛擬機運行時資料區的一部分，也不是Java虛擬機規范中定義的記憶體區域，但是這部分記憶體頻繁地被使用，而且也可能導致OutOfMemoryError例外出現，所以我們放到這里進行講解

在JDK1.4中新加入了NIO（New Input/Output）類，引入了一種基于通道（Channle）與緩沖區（Buffer）的的I/O方式，它可以使用Native函式庫直接分配堆外記憶體，然后通過一個存盤在Java堆中的DirectByteBuffer物件作為這塊記憶體的參考進行操作，避免了在Java堆中和Native堆中來回復制資料

顯然，本機直接記憶體的分配不會受到Java堆大小的限制，但是會受到本機總記憶體以及處理器尋址空間的限制，服務器管理員在配置虛擬機引數時，會根據實際記憶體設定 -Xmx等引數資訊，但經常忽略直接記憶體，使得各個記憶體區域綜合大于物理記憶體限制，從而導致動態擴展時OutOfMemoryError例外，

• 常見于NIO操作，用于資料緩沖區

• 分配回收成本高，但讀寫性能高

• 不受jvm記憶體回收管理

分配和回收原理：

• 使用了Unsafe物件完成直接記憶體的分配回收，并且回收需要主動呼叫freeMemory方法

• ByteBuffer的實作類內部，使用了Cleaner（虛參考）來檢測ByteBuffer物件，一旦ByteBuffer物件被垃圾回收，那么就會由ReferenceHandler執行緒通過Cleaner的clean方法呼叫freeMemory來釋放記憶體