jvm性能调优 - 01类加载机制Review
文章目錄
- 困惑
- 代碼是如何運行起來的（粗流程）
- 編譯
- 類裝載子系統
- 字節碼執行引擎
- 類裝載子系統
- JVM在什么情況下會加載一個類
- 驗證、準備和初始化的過程
- 驗證階段
- 準備階段
- 解析階段
- 核心階段：初始化
- 主要職責
- 什么時候會初始化一個類？
- 類加載器
- 啟動類加載器 Bootstrap ClassLoader
- 擴展類加載器 Extension ClassLoader
- 應用程序類加載器 Application ClassLoader
- 自定義類加載器
- 雙親委派機制
- 思考
困惑
目前JVM的書籍大部分都是站在理論知識總結和梳理的角度，構建一個完整的理論知識體系 ，但是很少會涉及生產故障的實踐經驗和解決方案。
對JVM生產環境中的優化很少有機會去接觸… 突然遇到線上JVM生產事故,依然毫無頭緒。
接下來幾篇文章，主要是高屋建瓴的把JVM運行機制的整體脈絡梳理清楚。
代碼是如何運行起來的（粗流程）
要研究JVM技術，先得搞明白一個問題：
我們平時寫的Java代碼，到底是怎么運行起來的？
我們來一步一步的分析
當我們寫好這些“.java”后綴的代碼文件之后，接下來你要部署到線上的機器上去運行，你會怎么做？
一般來說，都是把代碼給打成“.jar”后綴的jar包，或者是“.war”后綴的war包，是不是？
然后呢，就是把你打包好的jar包或者是war包給放到線上機器去部署。
部署就有很多種途徑了 : 比如通過Tomcat這類容器來部署代碼，或者編寫一個shell 調用“java”命令來運行一個jar包中的代碼。
先用下面這張圖，回憶一下這個順序
編譯
這里有一個非常關鍵的步驟，那就是“編譯”
也就是說，在我們寫好的“.java”代碼打包的過程中，一般就會把代碼編譯成“.class”后綴的字節碼文件，比如“User.class”，“Hello.class”，”Customer.class“。
然后這個“.class”后綴的字節碼文件，才是可以被運行起來的！
所以首先，先來回顧一下這個編譯的過程，以及“.class”字節碼文件的概念。
來看看下圖
接著我們可能就要思考下一個問題：
這個時候就需要使用諸如“java -jar”之類的命令來運行我們寫好的代碼了。 實際上此時就會啟動一個JVM進程。 這個JVM就會來負責運行這些“.class”字節碼文件，也就相當于是負責運行我們寫好的系統。
所以平時我們寫好的某個系統在一臺機器上部署的時候，一旦啟動，其實就是啟動了一個JVM，由它來負責運行這臺機器上運行的這個系統。
如下圖
類裝載子系統
接著下一步，JVM要運行這些“.class”字節碼文件中的代碼，那是不是首先得把這些“.class”文件中包含的各種類給加載進來？
這些“.class”文件不就是我們寫好的一個一個的類嗎？對不對？
此時就會有一個“類加載器”
此時會采用類加載器把編譯好的那些“.class”字節碼文件給加載到JVM中，然后供后續代碼運行來使用。
字節碼執行引擎
接著，最后一步，JVM就會基于自己的字節碼執行引擎，來執行加載到內存里的我們寫好的那些類了
比如你的代碼中有一個“main()”方法，那么JVM就會從這個“main()”方法開始執行里面的代碼。
需要哪個類的時候，就會使用類加載器來加載對應的類，反正對應的類就在“.class”文件中。
類裝載子系統
類加載過程非常的瑣碎復雜，但是對于平時從工作中實用的角度來說，主要是把握他的核心工作原理就可以。
JVM在什么情況下會加載一個類
一個類從加載到使用，一般會經歷下面的這個過程：
加載 -> 驗證 -> 準備 -> 解析 -> 初始化 -> 使用 -> 卸載
所以首先要搞明白的第一個問題，就是JVM在執行我們寫好的代碼的過程中，一般在什么情況下會去加載一個類呢？
也就是說，啥時候會從“.class”字節碼文件中加載這個類到JVM內存里來。
在你的代碼中用到這個類的時候。
舉個簡單的例子，比如下面你有一個類（Kafka.class），里面有一個“main()”方法作為主入口。
那么一旦你的JVM進程啟動之后，它一定會先把你的這個類（Kafka.cass）加載到內存里，然后從“main()”方法的入口代碼開始執行。
畫個圖，感受下
接著假設上面的代碼中，出現了如下的這么一行代碼：
這時可能大家就想了，你的代碼中明顯需要使用“ReplicaManager”這個類去實例化一個對象，此時必須得把“ReplicaManager.class”字節碼文件中的這個類加載到內存里來啊！是不是？
所以這個時候就會觸發JVM通過類加載器，從“ReplicaManager.class”字節碼文件中加載對應的類到內存里來使用，這樣代碼才能跑起來。
我們來看下面的圖：
簡單概括一下：首先你的代碼中包含“main()”方法的主類一定會在JVM進程啟動之后被加載到內存，開始執行你的“main()”方法中的代碼
接著遇到你使用了別的類，比如“ReplicaManager”，此時就會從對應的“.class”字節碼文件加載對應的類到內存里來。
驗證、準備和初始化的過程
這三個概念 ，這里的細節很多很繁瑣，我們先簡單了解下
驗證階段
簡單來說，這一步就是根據Java虛擬機規范，來校驗你加載進來的“.class”文件中的內容，是否符合指定的規范。
這個相信很好理解，假如說，你的“.class”文件被人篡改了，里面的字節碼壓根兒不符合規范，那么JVM是沒法去執行這個字節碼的！
所以把“.class”加載到內存里之后，必須先驗證一下，校驗他必須完全符合JVM規范，后續才能交給JVM來運行。
下面用一張圖，展示了這個過程：
準備階段
這個階段其實也很好理解，咱們都知道，我們寫好的那些類，其實都有一些類變量
比如下面的這個“ReplicaManager”類：
假設你有這么一個“ReplicaManager”類，他的“ReplicaManager.class”文件內容剛剛被加載到內存之后，會進行驗證，確認這個字節碼文件的內容是規范的
接著就會進行準備工作。
這個準備工作，其實就是給這個“ReplicaManager”類分配一定的內存空間
然后給他里面的類變量（也就是static修飾的變量）分配內存空間，來一個默認的初始值
比如上面的示例里，就會給“flushInterval”這個類變量分配內容空間，給一個“0”這個初始值。
整個過程，如下圖所示：
解析階段
這個階段干的事兒，實際上是把符號引用替換為直接引用的過程，其實這個部分的內容很復雜，涉及到JVM的底層, 暫時不展開。
從實用角度而言，對很多同學在工作中實踐JVM技術其實也用不到，所以這里大家就暫時知道有這么一個階段就可以了。
如下圖
其實這三個階段里，最核心的就是“準備階段” ，因為這個階段是給加載進來的類分配好了內存空間，類變量也分配好了內存空間，并且給了默認的初始值，這個概念，大家心里一定要牢記。
核心階段：初始化
主要職責
之前說過，在準備階段時，就會把我們的“ReplicaManager”類給分配好內存空間
另外他的一個類變量“flushInterval”也會給一個默認的初始值“0”，那么接下來，在初始化階段，就會正式執行我們的類初始化的代碼了。
那么什么是類初始化的代碼呢？我們來看看下面這段代碼：
大家可以看到，對于“flushInterval”這個類變量，我們是打算通過Configuration.getInt(“replica.flush.interval”)這段代碼來獲取一個值，并且賦值給他的
但是在準備階段會執行這個賦值邏輯嗎？
NO！在準備階段，僅僅是給“flushInterval”類變量開辟一個內存空間，然后給個初始值0 罷了。
那么這段賦值的代碼什么時候執行呢？答案是在初始化 階段來執行。
在這個階段，就會執行類的初始化代碼，比如上面的 Configuration.getInt("replica.flush.interval") 代碼就會在這里執行，完成一個配置項的讀取，然后賦值給這個類變量“flushInterval”。
另外比如下圖的static靜態代碼塊，也會在這個階段來執行。
類似下面的代碼語義，可以理解為類初始化的時候，調用“loadReplicaFromDish()”方法從磁盤中加載數據副本，并且放在靜態變量“replicas”中：
那么搞明白了類的初始化是什么，就得來看看類的初始化的規則了。
什么時候會初始化一個類？
一般來說有以下一些時機：比如“new ReplicaManager()”來實例化類的對象了，此時就會觸發類的加載到初始化的全過程，把這個類準備好，然后再實例化一個對象出來；
或者是包含“main()”方法的主類，必須是立馬初始化的。
此外，這里還有一個非常重要的規則，就是如果初始化一個類的時候，發現他的父類還沒初始化，那么必須先初始化他的父類
如下
如果你要“new ReplicaManager()”初始化這個類的實例，那么會加載這個類，然后初始化這個類
但是初始化這個類之前，發現AbstractDataManager作為父類還沒加載和初始化，那么必須先加載這個父類，并且初始化這個父類。
這個規則，大家必須得牢記，再來一張圖，借助圖片來進行理解：
類加載器
現在相信大家都搞明白了整個類加載從觸發時機到初始化的過程了，接著給大家說一下類加載器的概念
因為實現上述過程，那必須是依靠類加載器來實現的
那么Java里有哪些類加載器呢？簡單來說有下面幾種：
啟動類加載器 Bootstrap ClassLoader
Bootstrap ClassLoader，他主要是負責加載我們在機器上安裝的Java目錄下的核心類的
在你的Java安裝目錄下，就有一個“lib”目錄， Java最核心的一些類庫，支撐你的Java系統的運行。
所以一旦你的JVM啟動，那么首先就會依托啟動類加載器，去加載你的Java安裝目錄下的“lib”目錄中的核心類庫。
擴展類加載器 Extension ClassLoader
Extension ClassLoader，這個類加載器其實也是類似的，就是你的Java安裝目錄下，有一個“lib\ext”目錄
大致就理解為去加載你寫好的Java代碼吧，這個類加載器就負責加載你寫好的那些類到內存里。
應用程序類加載器 Application ClassLoader
Application ClassLoader，這類加載器就負責去加載“ClassPath”環境變量所指定的路徑中的類
自定義類加載器
除了上面那幾種之外，還可以自定義類加載器，去根據你自己的需求加載你的類。
雙親委派機制
JVM的類加載器是有親子層級結構的，就是說啟動類加載器是最上層的，擴展類加載器在第二層，第三層是應用程序類加載器，最后一層是自定義類加載器。
然后，基于這個親子層級結構，就有一個雙親委派的機制
什么意思呢？
就是假設你的應用程序類加載器需要加載一個類，他首先會委派給自己的父類加載器去加載，最終傳導到頂層的類加載器去加載
但是如果父類加載器在自己負責加載的范圍內，沒找到這個類，那么就會下推加載權利給自己的子類加載器。
用一個例子來說明一下:
比如你的JVM現在需要加載“ReplicaManager”類，此時應用程序類加載器會問問自己的爸爸，也就是擴展類加載器，你能加載到這個類嗎？
然后擴展類加載器直接問自己的爸爸，啟動類加載器，你能加載到這個類嗎？
啟動類加載器心想，我在Java安裝目錄下，沒找到這個類啊，自己找去！
然后，就下推加載權利給擴展類加載器這個兒子，結果擴展類加載器找了半天，也沒找到自己負責的目錄中有這個類。
這時他很生氣，說：明明就是你應用程序加載器自己負責的，你自己找去。
然后應用程序類加載器在自己負責的范圍內，比如就是你寫好的那個系統打包成的jar包吧，一下子發現，就在這里！然后就自己把這個類加載到內存里去了。
這就是所謂的雙親委派模型：先找父親去加載，不行的話再由兒子來加載。
這樣的話，可以避免多層級的加載器結構重復加載某些類。
最后，給大家來一張圖圖，感受一下類加載器的雙親委派模型。
思考
首先你編譯時，就可以采用一些小工具對字節碼加密，或者做混淆等處理
現在有很多第三方公司，都是專門做商業級的字節碼文件加密的，所以可以付費購買他們的產品。
然后在類加載的時候，對加密的類，考慮采用自定義的類加載器來解密文件即可，這樣就可以保證你的源代碼不被人竊取。
首先Tomcat的 類加載器體系如下圖所示，他是自定義了很多類加載器的。
Tomcat自定義了Common、Catalina、Shared等類加載器，其實就是用來加載Tomcat自己的一些核心基礎類庫的。
然后Tomcat為每個部署在里面的Web應用都有一個對應的WebApp類加載器，負責加載我們部署的這個Web應用的類
至于Jsp類加載器，則是給每個JSP都準備了一個Jsp類加載器。
而且大家一定要記得，Tomcat是打破了雙親委派機制的
每個WebApp負責加載自己對應的那個Web應用的class文件，也就是我們寫好的某個系統打包好的war包中的所有class文件，不會傳導給上層類加載器去加載。
總結
以上是生活随笔為你收集整理的jvm性能调优 - 01类加载机制Review的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 深入理解分布式技术 - 负载均衡策略
- 下一篇： jvm性能调优 - 02JVM中内存区域