寫一下個人看了些JVM和GC文章之后的認識和總結,目錄如下,
1. Overview
2. JVM架構體系
1) 垃圾回收
- 對象存活性判斷
- 垃圾回收算法
- 垃圾回收器(回收算法的具體實現)
2) 類裝載子系統
- 啟動類加載器
- 擴展類加載器
- 應用程序類加載器
- 自定義類加載器
3) 執行引擎
- 解釋器
- 即時編譯器
4) 運行時數據區
- 堆Heap
- 方法區
- 程序計數器
- 虛擬機棧
- 本地方法棧
3. 垃圾回收器開啟命令
4. Reference
Overview
Java虛擬機Java virtual machine(JVM) 是物理機器的軟件實現。java編譯器javac將源碼文件.java編譯成字節碼文件.class,然后這個字節碼文件.class被放到JVM中,裝載并執行字節碼文件.class。JVM架構圖如下,
JVM架構體系
-
垃圾回收(garbage collection):負責回收堆內存heap中沒有被使用的對象
-
判斷對象是否存活,可達性檢測
- 引用計數算法:給對象添加一個引用計數器,每當有一個地方引用它時,計數器值就加1,當引用失效時,計數器值就減1。任何時刻計數器為0的對象就是不可能再被使用的
-
根搜索算法:通過一系列名為“GC Roots”的對象作為起始點,從這些節點開始向下搜索,搜索所走過的路徑稱為引用鏈,當一個對象到 GC Roots 沒有任何引用鏈相連時,就證明此對象是不可用的
根搜索算法
-
垃圾回收算法
- 標記-清除算法Mark-Sweep:首先標記出所有需要回收的對象,在標記完成后統一回收所有被標記的對象
- 效率問題:標記和清除動作都不是高效動作
- 空間問題:標記清除之后產生大量不連續的內存碎片,碎片太多導致分配較大對象時無法找到足夠的連續內存而不得不提前觸發另一次gc
- 復制算法Copying:它將可用內存按容量劃分為大小相等的兩塊,每次只使用其中的一塊。當這一塊的內存用完了,就將還存活著的對象復制到另外一塊上面,然后再把已使用過的內存空間一次清理掉
- 可用內存縮小為原來的一半
- 每次收集時,所有的標記對象都要被拷貝,從而導致一些生命周期很長的對象被來回拷貝多次,消耗大量的時間 ->分代回收來解決這個問題
- 標記-壓縮算法Mark-Compact:標記過程與MS類似,但后續步驟不是直接對可回收對象進行清理sweep,而是讓所有存活的對象都向一端移動,然后直接清理掉端邊界以外的內存
- 分代回收算法Generational Collecting:根據對象存活周期的不同將內存劃分為幾塊
- 新生代:內存分為一塊較大的Eden空間和兩塊較小的Survivor空間。新建object在Eden,Eden滿時觸發YGC,Eden中存活對象被移動到S0區,清空Eden;等Eden再滿再YGC,Eden和S0中的存活對象被復制到S1(復制算法保證了S1中來自Eden和S0兩部分的存活對象占用連續的內存空間,避免了碎片化);清空Eden和S0。下一輪的時候S0和S1交換角色,如此循環往復。如果對象的復制次數達到15次,該對象就會被送到老年代。
- 老年代:對象存活率高
- 標記-清除算法Mark-Sweep:首先標記出所有需要回收的對象,在標記完成后統一回收所有被標記的對象
-
垃圾回收器(垃圾回收算法的具體實現)
- 并行與并發
- 并行Parallel:指多條垃圾收集線程并行工作,但此時用戶線程仍然處于等待狀態
- 并發Concurrent:指用戶線程與垃圾收集線程同時執行,用戶程序在繼續運行,而垃圾收集程序運行于另一個CPU上
- 新生代minor gc:新生代內存不是很大,miinor gc回收速度一般比較快
- 老年代major gc/ full gc:老年代內存一般比較大,用于緩存大對象,所以回收速度約minor gc的10倍以上
- 吞吐量throughput:JVM總共運行了100分鐘,其中垃圾收集花掉1分鐘,那吞吐量就是99%,即(all-gc)/all(for batch pipeline)
- 停頓時間:垃圾回收器正在運行時,應用程序的暫停時間(for streaming pipeline)
- 回收器類型
- NEW
- serial,單線程
- parNew,serial多線程版
- Parallel Scavenge,復制算法,并行,優先保證吞吐量,不顧及用戶STW感受,吞吐量方面優化的系統,停頓時間長是可以接收的。
- OLD/tenured
- Serial Old,Serial回收器的老年代版本,單線程,標記-整理算法
- Parallel Old,Parallel Scavenge回收器的老年代版本,多線程,標記-整理算法
- Concurrent Mark Sweep, CMS:優先最短回收停頓時間,用戶體驗好,標記-清除算法
- NEW and OLD
- garbage first, G1:它將整個Java堆劃分為多個大小相等的獨立區域(Region),雖然還保留有新生代和老年代的概念,但新生代和老年代不再是物理隔離的了,它們都是一部分Region(不需要連續)的集合。
-
關鍵點:region內存劃分,優先級區域回收方式。優先回收價值最大的region
垃圾回收器分類
-
- garbage first, G1:它將整個Java堆劃分為多個大小相等的獨立區域(Region),雖然還保留有新生代和老年代的概念,但新生代和老年代不再是物理隔離的了,它們都是一部分Region(不需要連續)的集合。
- NEW
- 并行與并發
-
-
類裝載子系統(classloader sub-system):定位和導入二進制class文件,校驗導入類的正確性,為類變量分配并初始化內存,解析符號引用
- 啟動類加載器bootstrap classloader,負責加載JAVA_HOME/lib下的合法類文件
- 擴展類加載器extension classloader,負責加載JAVA_HOME/lib/ext下的合法類文件
- 應用程序類加載器application classloader,負責加載用戶路徑classpath下的合法類文件
- 自定義類加載器user defined classloader,
class MyClassLoader extends ClassLoader
- JVM通過雙親委派模型進行類的加載,先交給其最底層父類去加載,父類無法加載時才自己試著去加載。if(parent != null) parent.loadclass(name) 遞歸recursion,
application classloader -> extension classloader -> bootstrap classloader
-
先看user defined classloader是否緩存了,如果緩存了,就直接返回,如果沒有,委派父classloader去加載,如果父緩存了,就直接返回,否則再委派給父classloader;直到最后的bootstrap classloader,如果其緩存找不到,則在其路徑下找,找到則至二級返回,否則往其子類返回,讓其子類在其路徑下找;最后又回到自定義classloader,如果還找不到就拋異常
classloader sub-system from briblue, 圖上的某個class應該先到UDC
-
執行引擎(execution engine):執行classloader中的方法指令
- 解釋器Interpreter:讀取源碼或字節碼,并逐條直接執行(javac是在JVM外的)
- 即時編譯器Just-In-Time compiler/JIT: 讀取源碼,更多情況下是字節碼,然后即時編譯為機器碼并執行
- Java虛擬機是可運行Java代碼的假想計算機,java源文件(.java)通過java編譯器javac生成字節碼文件(.class),字節碼文件(.class)通過JVM中的解釋器再翻譯成特定機器上的機器碼
即,源碼/源代碼/Source code/.java -> 字節碼/Bytecode/.class -> 機器碼/Machine code/原生碼/Native Code
execution engine
-
運行時數據區(runtime data areas):JVM運行時需要從整個計算機內存中劃出一塊內存區域存儲jvm需要用到的東西
- 堆Heap:JVM內共享/線程間共享,保存了所有類實例/對象本身instance,不存儲基本數據類型對象和自定義對象引用(這些存在各線程的JVM Stack中),是gc的主要回收區
- 方法區Method Area/永久代Permanent Generation:JVM內共享/線程間共享,保存了每個類的信息(類的名稱、字段信息、方法信息)class、靜態變量static等
- 程序計數器Program Counter Register/PC寄存器:線程內共享,保存每個線程正在執行的虛擬機字節碼指令的地址;若該方法為Native的,則計數器置空Undefined
- 虛擬機棧JVM Stack/線程棧:線程內共享,保存基本數據類型的對象和自定義對象的引用,執行環境的上下文
- 本地方法棧Native Method Stacks:線程內共享,與JVM Stack所發揮的作用是非常相似的,其區別不過是虛擬機棧為虛擬機執行Java方法(也就是字節碼)服務,而本地方法棧則是為虛擬機執行的Native方法服務
垃圾回收器開啟命令
Command line | 新生代gc模式 | 老年代gc模式 |
---|---|---|
-XX:+UseSerialGC |
serial串行回收器 | serialOld串行回收器 |
-XX:+UseParNewGC |
parNew并行回收器 | default |
-XX:+UseParallelGC |
parallel并行回收器 | default |
-XX:+UseParallelOldGC |
default | parallel并行回收器 |
-XX:+UseConcMarkSweepGC |
default | CMS并行回收器 |
-XX:+UseG1GC |
G1回收器 | G1回收器 |
根據上表新生代與老年代的gc模式互為搭配一起為垃圾回收器服務。
Default garbage collectors,
- Java 7 - Parallel GC
- Java 8 - Parallel GC
- Java 9 - G1 GC
Reference
- The JVM Architecture Explained
- 垃圾回收算法與 JVM 垃圾回收器綜述
- Is the JVM a compiler or an interpreter?
- Javac編譯與JIT編譯
- JIT vs Interpreters
- JVM Runtime Data Areas(運行時數據區)
- JVM學習筆記-程序計數器(The Program Counter)
- Java HotSpot VM Options
- Java Garbage Collection Basics
- Difference between -XX:UseParallelGC and -XX:+UseParNewGC
- Default garbage collector for Java 8
- 理解Java里面的jvm,jre,jdk的區別和聯系