JVM性能優化簡介
01. JVM是什麼
概述:
大白話:
全稱Java Virtual Machine(Java虛擬機), 它是一個虛構出來的計算機, 經過實際的計算機來模擬各類計算機的功能.
專業版:
JVM是一個進程, 用來模擬計算單元, 將.class字節碼文件轉成計算機可以識別的指令.
//這裏能夠聯想之前你們學的"VM ware", 它也是一個虛擬機.
//它們的區別就在於: VM Ware是你能看見的, JVM是你看不見的.
回顧:
咱們之前寫的Java程序是: 編寫 --> 編譯 --> 運行三個階段的.
.class文件是Java語言獨有的, 只有JVM能識別, 其餘任何軟件都識別不了.
因此Java語言的"跨平臺性(一次編譯處處運行)"就是由JVM來保證的.
畫圖演示:
JVM把.class字節碼文件 轉成 計算機可以識別的指令的過程.
代碼演示:
D:\compile\Worker.java文件, 經過"jps"命令查看啓動的進程.
02. JVM虛擬機運行的流程
JVM是一個進程,接下來咱們來研究它的: 工做機制, 這個問題是很深奧的, 不亞於研究一個完整VM Ware虛擬機,可是諸如"硬盤, CD/DVD這些部分和咱們都不要緊", 因此研究JVM的工做機制就是在研究它的: 運算機制.
首先, 請你思考一個問題: 若是我給你一個A.class字節碼文件, 想把它運行起來, 你會作哪些事情?
畫圖演示:
1. 讀取字節碼文件所在的路徑.
//類加載機制
2. 獲取字節碼文件中具體的內容.
//方法區: 用來存放類的描述信息.
3. 獲取該類的實例(對象)
//堆(Heap): 用來存儲對象的(全部new出來的內容)
4. 經過對象名.的方式調用方法.
//棧(Stack): 用來存放局部變量及全部代碼執行的.
今天咱們的學習順序, 就是按照這個流程來走的.
03. JVM虛擬機類加載機制(一):運行順序
首先, 咱們先來研究JVM的類加載機制, 類加載機制就是把類給讀取出來, 咱們來看一下它是如何運行的.
畫圖演示:
JVM底層加載類依靠三大組件:
BootStrapClassLoader //啓動類加載器
//負責加載: jre\lib\rt.jar //rt: runtime, 運行的意思
//windows最先不支持java, 沒有JRE, 後來Sun公司打官司贏了, windows開始默認支持JRE.
ExtClassLoader: //擴展類加載器
//負責加載: jre\lib\ext\* 文件夾下全部的jar包
//這兩個加載器執行完畢後, JVM虛擬機基本上就初始化完畢了.
APPClassLoader: //應用程序類加載器
//負責加載: 用戶自定義的類的.
//就是加載: 用戶配置的classpath環境變量值的.
//UserClassLoader //自定義類加載器
//自定義類加載器就是自定義一個類繼承ClassLoader, 而後重寫findClass(), loadClass()兩個方法便可.
加載順序是: BootStrap --> ExtClassLoader --> AppClassLoader --> UserClassLoader
代碼演示:
1) 隨便編寫一個A類, 而後演示: jar包的加載過程(rt.jar, ext\*等相關的jar包)
2) 打印類加載器對象:
//1. 獲取當前線程的類加載器
ClassLoader load = Thread.currentThread().getContextClassLoader();
//2. 打印當前線程的類加載器.
System.out.println(load); //AppClassLoader
//3. 打印當前線程的類加載器的父類(加載器).
System.out.println(load.getParent()); //ExtClassLoader
//4. 打印當前線程的類加載器的父類的父類(加載器).
System.out.println(load.getParent().getParent()); //null: 其實應該是BootStrapClassLoader, 可是它是C語言寫的, 因此打印不出來.
04) JVM虛擬機類加載機制(二):檢查順序
剛纔咱們學完了JVM類加載機制的"加載循序", 如今, 咱們來研究下它的"檢查順序", 請你思考,
假設: D:\compile, ext\*.jar, rt.jar三類中都有 A.class, 那麼A.class是否會被加載3次, 若是不會, 它的加載順序是什麼樣的?
不會, BootStrap會加載A.class.
運行順序是:
bootstrap --> ext --> app
1) bootstrap先加載 A.class
2) ext檢查A.class是否加載:
是: 不加載A.class
否: 加載A.class
3) app檢查A.class是否加載:
是: 不加載A.class
否: 加載A.class
例如:
UserClassLoader
APPClassLoader
ExtClassLoader
BootStrapClassLoader
總結:
自上而下檢查, 自下而上運行.
05) JVM的內存模型(方法區, 堆區, 棧區, 程序計數器)
到目前爲止咱們已經知道類加載器是用來加載字節碼文件的, 那加載完字節碼文件以後, 是否是要運行起來啊?
那它是怎麼運行的呢? 在個人課件中有一個"JVM運行時內存數據區", 接下來咱們詳細的來學習一下.
1) A.class字節碼文件被加載到內存.
//存儲在方法區中, 而且方法區中也包含常量池.
2) 建立本類的實例對象, 存儲在堆中(heap)
3) 經過對象名.的形式調用方法, 方法執行過程是在: 虛擬機棧中完成的.
//一個線程對應一個虛擬機棧, 每個方法對應一個: 虛擬機棧中的棧幀
4) 程序計數器區域記錄的是當前程序的執行位置, 例如:
線程1: print(), 第3行
5) 將具體要執行的代碼交給: 執行引擎來執行.
6) 執行引擎調用: 本地庫接口, 本地方法庫來執行具體的內容.
//這部分了解便可, 用native修飾的方法都是本地方法.
7) 本地方法棧: 顧名思義, 就是本地方法執行的區域.(C語言, 外部庫運行的空間)
//瞭解便可.
8) 直接內存: 大白話翻譯, 當JVM內存不夠用的時候, 會找操做系統"借點"內存.
//瞭解便可.
06) JVM的一個小例子
1) 編寫源代碼.
//建立一個A類, 裏邊有個print()方法.
public class A {
public void print() {
System.out.println("h");
System.out.println("e");
System.out.println("l");
System.out.println("l");
System.out.println("o");
}
}
2) 在A類中, 編寫main()函數, 建立兩個線程, 分別調用A#print()方法.
/*
java A //運行Java程序
加載類:
1) bootstrap 加載rt.jar
2) ext 加載 jre\lib\ext\*.jar
3) app 加載 A.class
具體運行:
1) 主函數運行. 棧中有個主線程, 調用MainThread.main();
2) 執行第23行, A a = new A(); 將a對象存儲到堆區.
3) 執行第24行, 調用a.print()方法, 生成一個棧幀, 壓入主線程棧.
-----> 執行, 運行print()方法的5行代碼.
4) 棧中有個新的線程, t1,
t1 --> run棧幀 --> print棧幀
5) 棧中有個新的線程, t2,
t2 --> run棧幀 --> print棧幀
*/
public class A {
public void print() {
System.out.println("h");
System.out.println("e");
System.out.println("l");
System.out.println("l");
System.out.println("o");
}
public static void main(String[] args) {
A a = new A();
a.print();
//建立兩個線程對象, 調用A#print();
//線程是CPU運行的基本單位, 建立銷燬由操做系統執行.
new Thread(new Runnable() {
@Override
public void run() {
a.print();
}
}).start();
new Thread(new Runnable() {
@Override
public void run() {
a.print();
}
}).start();
}
}
3) 畫圖演示此代碼的執行流程.
4) 時間夠的狀況下, 演示下: 守護線程和非守護線程.
07) 線程安全和內存溢出的問題
到目前爲止, 你們已經知道了JVM的內存模型, 也知道了各個模塊的做用,
接下來, 請你思考一個問題: 上述的模塊中, 哪些模塊會出現線程安全的問題,
哪些模塊有內存溢出的問題?
舉例:
public class A{
int i;
public void add() {
i++;
}
}
//當兩個線程同時調用add()方法修改變量i的值時, 就會引起線程安全問題.
畫圖演示上述代碼.
結論:
1) 存在線程安全問題的模塊.
堆: 會. //多線程, 併發, 操做同一數據.
棧: 不會. //線程棧之間是相互獨立的.
方法區: 不會. //存儲常量, 類的描述信息(.class字節碼文件).
程序計數器:不會.//記錄程序的執行流程.
2) 存在內存溢出問題的模塊.
堆: 會. //不斷建立對象, 內存被撐爆.
棧: 會. //不斷調用方法, 內存被撐爆.
方法區: 會. //常量過多, jar包過大, 內存被撐爆.
程序計數器: 會. //理論上來說會, 由於線程過多, 致使計數器過多, 內存被撐爆.
其實咱們研究JVM性能優化, 研究的就是這兩個問題, 這兩個問題也是常見面試題.
//面試題:說一下你對 線程安全和內存溢出這兩個問題的見解.
總結:
研究這兩個問題, 其實主要研究的仍是"堆(Heap)內存".
08) JDK1.7的堆內存的垃圾回收算法
JDK1.7 將堆內存劃分爲3部分: 年輕代, 年老代, 持久代(就是方法區).
年輕代又分爲三個區域: //使用的是 複製算法(須要有足夠多的空閒空間).
Eden: 伊甸園
//存儲的新生對象, 當伊甸園滿的時候, 會將存活對象複製到S1區.
//並移除那些垃圾對象(空指針對象).
Survivor: 倖存者區1
//當該區域滿的時候, 會將存活對象複製到S2區
//並移除那些垃圾對象.
Survivor: 倖存者區2
//當該區域滿的時候, 會將存活對象複製到S1區.
//並移除那些垃圾對象.
大白話翻譯:
s1區 和 s2區是來回互相複製的.
年老代: //使用的是標記清除算法, 標記整理算法.
//當對象在S1區和S2區之間來回複製15次, 纔會被加載到: 年老代.
//當年輕代和年老代所有裝滿的時候, 就會報: 堆內存溢出.
持久代: //就是方法區
存儲常量, 類的描述信息(也叫: 元數據).
09) JDK1.7默認垃圾回收器 //所謂的回收器, 就是已經存在的產品, 能夠直接使用.
Serial收集器:
單線程收集器, 它使用一個CPU或者一個線程來回收對象,
它在垃圾收集的時候, 必須暫停其餘工做線程, 直到垃圾回收完畢.
//相似於: 國家領導人出行(封路), 排隊點餐(遇到插隊現象)
//假設它在回收垃圾的時候用了3秒, 其餘線程就要等3秒, 這樣作效率很低.
ParNew收集器:
多線程收集器, 至關於: Serial的多線程版本.
Parallel Scavenge收集器:
是一個新生代的收集器，而且使用複製算法，並且是一個並行的多線程收集器.
其餘收集器是儘可能縮短垃圾收集時用戶線程的停頓時間，而Parallel Scavenge收集器的目標是達到一個可控制的吞吐量:
吞吐量 = 運行用戶代碼時間 / (運行用戶代碼時間+垃圾收集時間)
(虛擬機總共運行100分鐘，垃圾收集時間爲1分鐘，那麼吞吐量就是99%)
//由於虛擬機會根據系統運行狀況進行自適應調節, 因此不須要咱們設置.
CMS收集器: //主要針對於年老代.
整個過程分爲:
初始標記; //用戶線程等待
併發標記; //用戶線程能夠執行
從新標記; //用戶線程等待
併發清除; //用戶線程能夠執行
能夠理解爲是:
精細化運營, 前邊的垃圾收集器都是一刀切(在回收垃圾的時候, 其餘線程等待), 而CMS是儘量的下降等待時間, 並行執行程序, 提升運行效率.
以上爲JDK1.7及其之前的垃圾回收器, JDK1.8的時候多了一個: G1.
G1在JDK1.9的時候, 成爲了默認的垃圾回收器.
10) VM宏觀結構梳理
1) Java程序的三個階段:
編寫: A.java
編譯: javac A.java
運行: java A.class
2) 類加載器
bootstrap
ext
app
3) JVM的內存結構
堆:
年輕代
年老代
持久代(也就是方法區)
元數據(類的描述信息, 也就是.class字節碼文件), 常量池
棧:
有n個線程棧, 每一個線程棧又會有n個棧幀(一個棧幀就是一個方法)
程序計數器:
用來記錄程序的執行流程的.
本地方法棧:
C語言, 外部程序運行空間.
11) G1垃圾回收器
在上個圖解上作優化, 用G1新圖解, 覆蓋以前堆中的內容.
1) 將內存劃分爲一樣大小的region(區域).
2) 每一個region既能夠是年輕代, 也能夠是老年代, 還能夠是倖存者區.
3) 程序運行前期, 建立大量對象的時候, 能夠將每一個region看作是: Eden(伊甸園).
4) 程序運行中期, 能夠將eden的region變成old的region.
5) 程序運行後期, 能夠縮短Eden, Survivor的區域, 變成Old區域.
//這樣作的好處是: 儘量大的利用堆內存空間.
6) H: 存儲大對象的.
7) G1是JDK1.8出來的, 在JDK1.9的時候變成了: 默認垃圾處理器.
12) G1中的持久代(方法區)不見了
方法區從JVM模型中遷移出去了, 徹底使用系統的內存.
方法區也更名叫: 元數據區.
13) 內存溢出的代碼演示
1) 堆內存溢出演示: main.java.heap.PrintGC_demo.java
//建立對象多, 致使內存溢出.
2) 棧內存溢出演示:
main.java.stack.StackOverFlow(遞歸致使的)
//不設置的話在5000次左右, 設置256K後在1100次左右.
main.java.stack.Thread(不斷建立線程致使的)
//這個自行演示便可, 電腦太卡, 影響上課效果.
3) 方法區內存溢出演示:
main.java.method.MethodOOM //常量過多
main.java.direct.DirectMenOOM //jar包過大, 直接溢出.
總結:
可能你將來的10年都碰不到JVM性能調優這個事兒, 先不說能不能調優, 而是大多數的
公司上來就擼代碼, 不多會有"JVM調優"這個動做, 即便遇到了"JVM調優", 公司裏邊
還有架構師呢, 可是咱們立刻要找工做了, 把這些相關的題了解了解, 看看, 對面試會
比較有幫助.
//JVM調優通常是隻看, 不用, 目前只是爲了面試作準備.
14) 引用地址值比較
直接演示src.main.method.ATest類中的代碼便可.
//講解==比較引用類型的場景.
15) JVM調優案例賞析
百度搜索 --> JVM調優實踐, 一搜一大堆的案例.
16) GC的調優工具jstat //主要針對於GC的.
1) 經過Dos命令運行 D:\compile\Worker.java
2) 從新開啓一個Dos窗口:
//能夠經過jps指令查看pid值.
jstat -class 2041(Java程序的PID值) //查看加載了多少個類
jstat -compiler 2041(Java程序的PID值) //查看編譯的狀況
jstat -gc 2041(Java程序的PID值) //查看垃圾回收的統計
jstat -gc 2041 1000 5 //1秒打印1次, 總共打印5次
17) GC的調優工具jmap //主要針對於內存使用狀況的.
1) 經過Dos命令運行 D:\compile\Worker.java
2) jmap -heap 2041(Java程序的PID值) //查看內存使用狀況
jmap -histo 2041 | more //查看內存中對象數量及大小
jmap -dump:format=b,file=d:/compile/dump.dat 2041 //將內存使用狀況dump到文件中
jhat -port 9999 d:/compile/dump.dat //經過jhat對dump文件進行分析
//端口號能夠自定義, 而後在瀏覽器中經過127.0.0.1:9999就能夠訪問了.
18) GC的調優工具jstack-死鎖 //針對於線程的.
1) 線程的六種狀態:
新建, 就緒, 運行(運行的時候會發生等待或者阻塞), 死亡.
2) 編寫一個死鎖的代碼.
//兩個線程, 兩把鎖, 一個先拿鎖1, 再拿鎖2, 另外一個先拿鎖2, 在拿鎖1.
3) 經過jstack命令能夠查看Java程序狀態.
jstack 2041 //查看死鎖狀態
19) GC的可視化調優工具 //jstat, jmap, jstack
1) 本地調優.
1.1) 該工具位於 JDK安裝目錄/bin/jvisualvm.exe
//雙擊能夠直接使用.
1.2) 以IntelliJ Platform爲例, 演示下各個模塊的做用.
1.3) 該工具涵蓋了上述全部的命令.
2) 遠程調優. //自行測試(目前先了解便可).
java -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.port=9999 DeadLock
這幾個參數的意思是:
-Dcom.sun.management.jmxremote ：容許使用JMX遠程管理
-Dcom.sun.management.jmxremote.port=9999 ：JMX遠程鏈接端口
-Dcom.sun.management.jmxremote.authenticate=false ：不進行身份認證，任何用戶均可以鏈接
-Dcom.sun.management.jmxremote.ssl=false ：不使用ssl
20) JVM的總結
1) 什麼是JVM?
2) JVM類加載機制.
//bootstrap, ext, app
3) JVM內存模型.
4) 垃圾回收算法.
複製算法:
針對於年輕代.
標記清除算法:
標記整理算法:
針對於老年代
5) JVM垃圾回收器.
Serial單線程.
ParNew多線程.
Parallel Scavenge: 併發多線程.
CMS: 以獲取"最短垃圾回收停頓時間"爲目標的收集器.
G1: JDK1.8出現的, JDK1.9被設置成默認垃圾回收器.
6) JVM調優工具:
jstat, jmap, jstack, 可視化調優工具(jvisualvm.exe).
//如下內容是爲了面試用, 找工做前一週, 看看下面的題便可.
21) JVM的線程安全與鎖的兩種方式
線程安全:
多線程, 併發, 操做同一數據, 就有可能引起安全問題, 須要用到"同步"解決.
"同步"分類:
同步代碼塊:
格式:
synchronized(鎖對象) {
//要加鎖的代碼
}
注意:
1) 同步代碼塊的鎖對象能夠是任意類型的對象.
//對象多, 類鎖都可.
2) 必須使用同一把鎖, 不然可能出現鎖不住的狀況. //String.class
同步方法:
靜態同步方法:
鎖對象是: 該類的字節碼文件對象. //類鎖
非靜態同步方法:
鎖對象是: this //對象鎖
22) 髒讀-高圓圓是男的
1) 演示main.java.thread.DirtyRead.java類的代碼便可.
2) 自定義線程修改姓名後, 要休眠3秒, 而主線程休眠1秒後即調用getValue()打印姓名和年齡,
若是getValue()方法沒加同步, 會出現"髒讀"的狀況.
23) 瞭解Lock鎖.
1) Lock和synchronized的區別
1.1) synchronized是java內置的語言，是java的關鍵字
1.2) synchronized不須要手動去釋放鎖，當synchronized方法或者synchronized代碼塊執行完畢。
系統會自動釋放對該鎖的佔用。
而lock必須手動的釋放鎖，若是沒有主動的釋放鎖，則可能形成死鎖的問題
2) 示例代碼
public class Demo02 {
private Lock lock = new ReentrantLock();
public void method01() {
lock.lock();
System.out.print("i");
System.out.print("t");
System.out.print("c");
System.out.print("a");
System.out.print("s");
System.out.print("t");
System.out.println();
lock.unlock();
}
public void method02() {
lock.lock();
System.out.print("我");
System.out.print("愛");
System.out.print("你");
System.out.print("中");
System.out.print("國");
System.out.println();
lock.unlock();
}
}
java
https://blogs.oracle.com/jonthecollector/our-collectors
面試
- 1. JVM性能優化， Part 1 ―― JVM簡介
- 2. web性能優化——簡介
- 3. 性能優化（JVM優化）
- 4. JVM性能優化
- 5. jvm性能優化
- 6. JVM中鎖優化簡介
- 7. JVM性能優化一些概念簡介
- 8. JVM的性能優化(上)
- 9. JVM的性能優化(下)
- 10. JVM性能淺談優化
- 更多相關文章...
- • SEO - 搜索引擎優化 - 網站建設指南
- • Scala 簡介 - Scala教程
- • Git可視化極簡易教程 — Git GUI使用方法
- • Github 簡明教程
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. JVM性能優化， Part 1 ―― JVM簡介
- 2. web性能優化——簡介
- 3. 性能優化（JVM優化）
- 4. JVM性能優化
- 5. jvm性能優化
- 6. JVM中鎖優化簡介
- 7. JVM性能優化一些概念簡介
- 8. JVM的性能優化(上)
- 9. JVM的性能優化(下)
- 10. JVM性能淺談優化