JVM很難？或者你看完這篇文章就夠了
概念
虛擬機：指以軟件的方式模擬具有完整硬件系統(tǒng)功能、運行在一個完全隔離環(huán)境中的完整計算機系統(tǒng) ，是物理機的軟件實現(xiàn)。常用的虛擬機有VMWare，Visual Box，Java Virtual Machine(Java虛擬機，簡稱JVM)。
Java虛擬機陣營：Sun HotSpot VM、BEA JRockit VM、IBM J9 VM、Azul VM、Apache Harmony、Google Dalvik VM、Microsoft JVM…
啟動流程
基本架構
Java運行時編譯源碼(.java)成字節(jié)碼，由jre運行。jre由java虛擬機(jvm)實現(xiàn)。Jvm分析字節(jié)碼，后解釋并執(zhí)行。
JVM由三個主要的子系統(tǒng)構成：
- 1.類加載器子系統(tǒng)
- 2.運行時數(shù)據(jù)區(qū)(內存)
- 3.執(zhí)行引擎
垃圾收集(GC：Garbage Collection)
1.如何識別垃圾，判定對象是否可被回收?
- 引用計數(shù)法：給每個對象添加一個計數(shù)器，當有地方引用該對象時計數(shù)器加1，當引用失效時計數(shù)器減1。用對象計數(shù)器是否為0來判斷對象是否可被回收。缺點：無法解決循環(huán)引用的問題
- 根搜索算法：也稱可達性分析法，通過“GC ROOTs”的對象作為搜索起始點，通過引用向下搜索，所走過的路徑稱為引用鏈。通過對象是否有到達引用鏈的路徑來判斷對象是否可被回收(可作為GC ROOTs的對象：虛擬機棧中引用的對象，方法區(qū)中類靜態(tài)屬性引用的對象，方法區(qū)中常量引用的對象，本地方法棧中JNI引用的對象)
2.Java 中的堆是 GC 收集垃圾的主要區(qū)域，GC 分為兩種：Minor GC、Full GC ( 或稱為 Major GC )。
- Minor GC：新生代(Young Gen)空間不足時觸發(fā)收集，由于Java 中的大部分對象通常不需長久存活，新生代是GC收集頻繁區(qū)域，所以采用復制算法。
- Full GC：老年代(Old Gen )空間不足或元空間達到高水位線執(zhí)行收集動作，由于存放大對象及長久存活下的對象，占用內存空間大，回收效率低，所以采用標記-清除算法。
GC算法
按照回收策略劃分為：標記-清除算法，標記-整理算法，復制算法。
1.標記-清除算法：分為兩階段“標記”和“清除”。首先標記出哪些對象可被回收，在標記完成之后統(tǒng)一回收所有被標記的對象所占用的內存空間。不足之處：1.無法處理循環(huán)引用的問題2.效率不高3.產生大量內存碎片(ps：空間碎片太多可能會導致以后在分配大對象的時候而無法申請到足夠的連續(xù)內存空間，導致提前觸發(fā)新一輪gc)
2.標記-整理算法：分為兩階段“標記”和“整理”。首先標記出哪些對象可被回收，在標記完成后，將對象向一端移動，然后直接清理掉邊界以外的內存。
3.復制算法：把內存空間劃為兩個相等的區(qū)域，每次只使用其中一個區(qū)域。gc時遍歷當前使用區(qū)域，把正在使用中的對象復制到另外一個區(qū)域中。算法每次只處理正在使用中的對象，因此復制成本比較小，同時復制過去以后還能進行相應的內存整理，不會出現(xiàn)“碎片”問題。不足之處：1.內存利用率問題2.在對象存活率較高時，其效率會變低。
按分區(qū)對待可分為：增量收集算法，分代收集算法
1.增量收集:實時垃圾回收算法，即：在應用進行的同時進行垃圾回收，理論上可以解決傳統(tǒng)分代方式帶來的問題。增量收集把對堆空間劃分成一系列內存塊，使用時先使用其中一部分，垃圾收集時把之前用掉的部分中的存活對象再放到后面沒有用的空間中，這樣可以實現(xiàn)一直邊使用邊收集的效果，避免了傳統(tǒng)分代方式整個使用完了再暫停的回收的情況。
2.分代收集:(商用默認)基于對象生命周期劃分為新生代、老年代、元空間，對不同生命周期的對象使用不同的算法進行回收。
按系統(tǒng)線程可分為：串行收集算法，并行收集算法，并發(fā)收集算法
1.串行收集:使用單線程處理垃圾回收工作，實現(xiàn)容易，效率較高。不足之處：1.無法發(fā)揮多處理器的優(yōu)勢 2.需要暫停用戶線程
2.并行收集:使用多線程處理垃圾回收工作，速度快，效率高。理論上CPU數(shù)目越多，越能體現(xiàn)出并行收集器的優(yōu)勢。不足之處：需要暫停用戶線程
3.并發(fā)收集:垃圾線程與用戶線程同時工作。系統(tǒng)在垃圾回收時不需要暫停用戶線程
GC收集器常用組合
JVM性能調優(yōu)思路
理解GC日志
- [GC [PSYoungGen: 8192K->1000K(9216K)] 16004K->14604K(29696K), 0.0317424 secs] [Times: user=0.06 sys=0.00, real=0.03 secs]
- [GC [PSYoungGen: 9192K->1016K(9216K)] 22796K->20780K(29696K), 0.0314567 secs] [Times: user=0.06 sys=0.00, real=0.03 secs]
- [Full GC [PSYoungGen: 8192K->8192K(9216K)] [ParOldGen: 20435K->20435K(20480K)] 28627K->28627K(29696K), [Metaspace: 8469K->8469K(1056768K)], 0.1307495 secs] [Times: user=0.50 sys=0.00, real=0.13 secs]
- [Full GC [PSYoungGen: 8192K->8192K(9216K)] [ParOldGen: 20437K->20437K(20480K)] 28629K->28629K(29696K), [Metaspace: 8469K->8469K(1056768K)], 0.1240311 secs] [Times: user=0.42 sys=0.00, real=0.12 secs]
常見異常
- StackOverflowError:(棧溢出)
- OutOfMemoryError: Java heap space(堆空間不足)
- OutOfMemoryError: GC overhead limit exceeded (GC花費的時間超過 98%, 并且GC回收的內存少于 2%)
