超詳細JVM性能優化案例全面講解，值得收藏-有解無憂

JVM干貨！最全最詳細的JVM性能優化專題

對vm-性能優化不太熟悉，掌握不透徹的小伙伴可以借此學習一下，對vm-性能優化很熟悉，掌握很好的小伙伴可以當作復習鞏固，寫的不一定你們都會喲！

話不多說，咱們直接上干貨！注意：除了本文講的案例，我還整理了最新5套JAVA架構專案實戰教程及大廠面試題庫，需要的可以進裙 783802103，裙檔案下，沒基礎勿進哦！

類加載機制深度剖析

1、類加載程序

多個java檔案經過編譯打包生成可運行jar包，最終由java命令運行某個主類的main函式啟動程式，這里首先需要通過類加載器把主類加載到JVM，

主類在運行程序中如果使用到其它類，會逐步加載這些類，

注意，jar包里的類不是一次性全部加載的，是使用到時才加載，

類加載到使用整個程序有如下幾步：

加載 >> 驗證 >> 準備 >> 決議 >> 初始化 >> 使用 >> 卸載

加載：在硬碟上查找并通過IO讀入位元組碼檔案，使用到類時才會加載，例如呼叫類的main()方法，new物件等等，在加載階段會在記憶體中生成一個代表這個類的java.lang.Class物件，作為方法區這個類的各種資料的訪問入口
驗證：校驗位元組碼檔案的正確性
準備：給類的靜態變數分配記憶體，并賦予默認值
決議：將符號參考替換為直接參考，該階段會把一些靜態方法(符號參考，比如main()方法)替換為指向資料所存記憶體的指標或句柄等(直接參考)，這是所謂的靜態鏈接程序(類加載期間完成)，動態鏈接是在程式運行期間完成的將符號參考替換為直接參考，下節課會講到動態鏈接
初始化：對類的靜態變數初始化為指定的值，執行靜態代碼塊

file

2、類加載器和雙親委派機制

上面的類加載程序主要是通過類加載器來實作的，Java里有如下幾種類加載器

啟動類加載器：負責加載支撐JVM運行的位于JRE的lib目錄下的核心類別庫，比如rt.jar、charsets.jar等
擴展類加載器：負責加載支撐JVM運行的位于JRE的lib目錄下的ext擴展目錄中的JAR類包
應用程式類加載器：負責加載ClassPath路徑下的類包，主要就是加載你自己寫的那些類
自定義加載器：負責加載用戶自定義路徑下的類包

看一個類加載器示例：

public class TestJDKClassLoader {
    public static void main(String[] args){
        System.out.println(String.class.getClassLoader());
        System.out.println(com.sun.crypto.provider.DESKeyFactory.class.getClassLoader().getClass().getName());
        System.out.println(TestJDKClassLoader.class.getClassLoader().getClass().getName());
        System.out.println(ClassLoader.getSystemClassLoader().getClass().getName());
    }
}

運行結果：

null //啟動類加載器是C++語言實作，所以列印不出來
sun.misc.Launcher$ExtClassLoader
sun.misc.Launcher$AppClassLoader
sun.misc.Launcher$AppClassLoader

自定義一個類加載器示例：

自定義類加載器只需要繼承 java.lang.ClassLoader 類，該類有兩個核心方法，一個是loadClass(String, boolean)，實作了雙親委派機制，大體邏輯

首先，檢查一下指定名稱的類是否已經加載過，如果加載過了，就不需要再加載，直接回傳，
如果此類沒有加載過，那么，再判斷一下是否有父加載器；如果有父加載器，則由父加載器加載（即呼叫parent.loadClass(name, false);）.或者是呼叫bootstrap類加載器來加載，
如果父加載器及bootstrap類加載器都沒有找到指定的類，那么呼叫當前類加載器的findClass方法來完成類加載，

還有一個方法是findClass，默認實作是拋出例外，所以我們自定義類加載器主要是重寫findClass方法，運行結果：

=======自己的加載器加載類呼叫方法=======
com.tuling.jvm.MyClassLoaderTest$MyClassLoader

全盤負責委托機制

“全盤負責”是指當一個ClassLoder裝載一個類時，除非顯示的使用另外一個ClassLoder，該類所依賴及參考的類也由這個ClassLoder載入，

雙親委派機制

JVM類加載器是有親子層級結構的，如下圖

file

這里類加載其實就有一個雙親委派機制，加載某個類時會先委托父加載器尋找目標類，找不到再委托上層父加載器加載，如果所有父加載器在自己的加載類路徑下都找不到目標類，則在自己的類加載路徑中查找并載入目標類，

比如我們的Math類，最先會找應用程式類加載器加載，應用程式類加載器會先委托擴展類加載器加載，擴展類加載器再委托啟動類加載器，頂層啟動類加載器在自己的類加載路徑里找了半天沒找到Math類，則向下退回加載Math類的請求，擴展類加載器收到回復就自己加載，在自己的類加載路徑里找了半天也沒找到Math類，又向下退回Math類的加載請求給應用程式類加載器，應用程式類加載器于是在自己的類加載路徑里找Math類，結果找到了就自己加載了，

雙親委派機制說簡單點就是，先找父親加載，不行再由兒子自己加載

為什么要設計雙親委派機制？

沙箱安全機制：自己寫的java.lang.String.class類不會被加載，這樣便可以防止核心API庫被隨意篡改
避免類的重復加載：當父親已經加載了該類時，就沒有必要子ClassLoader再加載一次，保證被加載類的唯一性

看一個類加載示例：

package java.lang;
public class String {
    public static void main(String[] args) {
        System.out.println("**************My String Class**************");
    }
}

運行結果：

錯誤: 在類 java.lang.String 中找不到 main 方法, 請將 main 方法定義為:
public static void main(String[] args)
否則 JavaFX 應用程式類必須擴展javafx.application.Application

再來一個沙箱安全機制示例，嘗試打破雙親委派機制，用自定義類加載器加載我們自己實作的

java.lang.String.class

public class MyClassLoaderTest {
    static class MyClassLoader extends ClassLoader {
        private String classPath;
        public MyClassLoader(String classPath) {
            this.classPath = classPath;
        }
        private byte[] loadByte(String name) throws Exception {
            name = name.replaceAll("\.", "/");
            FileInputStream fis = new FileInputStream(classPath + "/" + name
                    + ".class");
            int len = fis.available();
            byte[] data = https://www.cnblogs.com/chengxuyuanaa/p/new byte[len];
            fis.read(data);
            fis.close();
            return data;
        }
        protected Class<?> findClass(String name) throws ClassNotFoundException {
            try {
                byte[] data = loadByte(name);
                return defineClass(name, data, 0, data.length);
            } catch (Exception e) {
                e.printStackTrace();
                throw new ClassNotFoundException();
            }
        }
        /**
         * 重寫類加載方法，實作自己的加載邏輯，不委派給雙親加載
         * @param name
         * @param resolve
         * @return
         * @throws ClassNotFoundException
         */
        protected Class<?> loadClass(String name, boolean resolve)
                throws ClassNotFoundException {
            synchronized (getClassLoadingLock(name)) {
                // First, check if the class has already been loaded
                Class<?> c = findLoadedClass(name);
 
                if (c == null) {
                    // If still not found, then invoke findClass in order
                    // to find the class.
                    long t1 = System.nanoTime();
                    c = findClass(name);
 
                    // this is the defining class loader; record the stats
                    sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                    sun.misc.PerfCounter.getFindClasses().increment();
                }
                if (resolve) {
                    resolveClass(c);
                }
                return c;
            }
        }
    }
    public static void main(String args[]) throws Exception {
        MyClassLoader classLoader = new MyClassLoader("D:/test");
        //嘗試用自己改寫類加載機制去加載自己寫的java.lang.String.class
        Class clazz = classLoader.loadClass("java.lang.String");
        Object obj = clazz.newInstance();
        Method method= clazz.getDeclaredMethod("sout", null);
        method.invoke(obj, null);
        System.out.println(clazz.getClassLoader().getClass().getName());
    }
}

運行結果：

java.lang.SecurityException: Prohibited package name: java.lang
at java.lang.ClassLoader.preDefineClass(ClassLoader.java:659)
at java.lang.ClassLoader.defineClass(ClassLoader.java:758)

打破雙親委派

以Tomcat類加載為例，Tomcat 如果使用默認的雙親委派類加載機制行不行？

我們思考一下：Tomcat是個web容器，那么它要解決什么問題：

一個web容器可能需要部署兩個應用程式，不同的應用程式可能會依賴同一個第三方類別庫的不同版本，不能要求同一個類別庫在同一個服務器只有一份，因此要保證每個應用程式的類別庫都是獨立的，保證相互隔離，
部署在同一個web容器中相同的類別庫相同的版本可以共享，否則，如果服務器有10個應用程式，那么要有10份相同的類別庫加載進虛擬機，
web容器也有自己依賴的類別庫，不能與應用程式的類別庫混淆，基于安全考慮，應該讓容器的類別庫和程式的類別庫隔離開來，
web容器要支持jsp的修改，我們知道，jsp 檔案最終也是要編譯成class檔案才能在虛擬機中運行，但程式運行后修改jsp已經是司空見慣的事情， web容器需要支持 jsp 修改后不用重啟，

再看看我們的問題：Tomcat 如果使用默認的雙親委派類加載機制行不行？

答案是不行的，為什么？

第一個問題，如果使用默認的類加載器機制，那么是無法加載兩個相同類別庫的不同版本的，默認的類加器是不管你是什么版本的，只在乎你的全限定類名，并且只有一份，第二個問題，默認的類加載器是能夠實作的，因為他的職責就是保證唯一性，

第三個問題和第一個問題一樣，

我們再看第四個問題，我們想我們要怎么實作jsp檔案的熱加載，jsp 檔案其實也就是class檔案，那么如果修改了，但類名還是一樣，類加載器會直接取方法區中已經存在的，修改后的jsp是不會重新加載的，那么怎么辦呢？我們可以直接卸載掉這jsp檔案的類加載器，所以你應該想到了，每個jsp檔案對應一個唯一的類加載器，當一個jsp檔案修改了，就直接卸載這個jsp類加載器，重新創建類加載器，重新加載jsp檔案，

Tomcat自定義加載器詳解

file

tomcat的幾個主要類加載器：

commonLoader：Tomcat最基本的類加載器，加載路徑中的class可以被Tomcat容器本身以及各個Webapp訪問；
catalinaLoader：Tomcat容器私有的類加載器，加載路徑中的class對于Webapp不可見；
sharedLoader：各個Webapp共享的類加載器，加載路徑中的class對于所有Webapp可見，但是對于Tomcat容器不可見；
WebappClassLoader：各個Webapp私有的類加載器，加載路徑中的class只對當前Webapp可見；

從圖中的委派關系中可以看出：

CommonClassLoader能加載的類都可以被CatalinaClassLoader和SharedClassLoader使用，從而實作了公有類別庫的共用，而CatalinaClassLoader和SharedClassLoader自己能加載的類則與對方相互隔離，

WebAppClassLoader可以使用SharedClassLoader加載到的類，但各個WebAppClassLoader實體之間相互隔離，

而JasperLoader的加載范圍僅僅是這個JSP檔案所編譯出來的那一個.Class檔案，它出現的目的就是為了被丟棄：當Web容器檢測到JSP檔案被修改時，會替換掉目前的JasperLoader的實體，并通過再建立一個新的Jsp類加載器來實作JSP檔案的熱加載功能，

tomcat 這種類加載機制違背了java 推薦的雙親委派模型了嗎？答案是：違背了，

我們前面說過，雙親委派機制要求除了頂層的啟動類加載器之外，其余的類加載器都應當由自己的父類加載器加載，

很顯然，tomcat 不是這樣實作，tomcat 為了實作隔離性，沒有遵守這個約定，每個webappClassLoader加載自己的目錄下的class檔案，不會傳遞給父類加載器，打破了雙親委派機制，

JVM記憶體模型深度剖析

1、JVM整體結構及記憶體模型

file

2、JVM記憶體引數設定

file

Spring Boot程式的JVM引數設定格式(Tomcat啟動直接加在bin目錄下catalina.sh檔案里)：

java -Xms2048M -Xmx2048M -Xmn1024M -Xss512K -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -jar microservice-eureka-server.jar

關于元空間的JVM引數有兩個：-XX:MetaspaceSize=N和 -XX:MaxMetaspaceSize=N，對于64位JVM來說，元空間的默認初始大小是21MB，默認的元空間的最大值是無限，MaxMetaspaceSize用于設定metaspace區域的最大值，

元空間的動態擴展，默認–XX:MetaspaceSize值為21MB的高水位線，一旦觸及則Full GC將被觸發并卸載沒有用的類（類對應的類加載器不再存活），然后高水位線將會重置，新的高水位線的值取決于GC后釋放的元空間，如果釋放的空間少，這個高水位線則上升，如果釋放空間過多，則高水位線下降，

由于調整元空間的大小需要Full GC，這是非常昂貴的操作，如果應用在啟動的時候發生大量Full GC，通常都是由于永久代或元空間發生了大小調整，基于這種情況，一般建議在JVM引數中將MetaspaceSize和MaxMetaspaceSize設定成一樣的值，并設定得比初始值要大，對于8G物理記憶體的機器來說，一般我會將這兩個值都設定為256M，

Jdk1.6及之前：有永久代, 常量池在方法區
Jdk1.7：有永久代，但已經逐步“去永久代”，常量池在堆
Jdk1.8及之后：無永久代，常量池在元空間

StackOverflowError示例：

// JVM設定  -Xss128k(默認1M)
public class StackOverflowTest {
    static int count = 0;
    static void redo() {
        count++;
        redo();
    }
    public static void main(String[] args) {
        try {
            redo();
        } catch (Throwable t) {
            t.printStackTrace();
            System.out.println(count);
        }
    }
}

運行結果：

java.lang.StackOverflowError
at com.tuling.jvm.StackOverflowTest.redo(StackOverflowTest.java:12)
at com.tuling.jvm.StackOverflowTest.redo(StackOverflowTest.java:13)
at com.tuling.jvm.StackOverflowTest.redo(StackOverflowTest.java:13)

結論：

-Xss設定越小count值越小，說明一個執行緒堆疊里能分配的堆疊幀就越少，但是對JVM整體來說能開啟的執行緒數會更多

JVM記憶體引數大小該如何設定？

JVM引數大小設定并沒有固定標準，需要根據實際專案情況分析，給大家舉個例子

日均百萬級訂單交易系統如何設定JVM引數

file

一天百萬級訂單這個絕對是現在頂尖電商公司交易量級，對于這種量級的系統我們該如何設定JVM引數了？

我們可以試著估算下，其實日均百萬訂單主要也就是集中在當日的幾個小時生成的，我們假設是三小時，也就是每秒大概生成100單左右，

這種系統我們一般至少要三四臺機器去支撐，假設我們部署了四臺機器，也就是每臺每秒鐘大概處理完成25單左右，往上毛估每秒處理30單吧，

也就是每秒大概有30個訂單物件在堆空間的新生代內生成，一個訂單物件的大小跟里面的欄位多少及型別有關，比如int型別的訂單id和用戶id等欄位，double型別的訂單金額等，int型別占用4位元組，double型別占用8位元組，初略估計下一個訂單物件大概1KB左右，也就是說每秒會有30KB的訂單物件分配在新生代內，

真實的訂單交易系統肯定還有大量的其他業務物件，比如購物車、優惠券、積分、用戶資訊、物流資訊等等，實際每秒分配在新生代內的物件大小應該要再擴大幾十倍，我們假設30倍，也就是每秒訂單系統會往新生代內分配近1M的物件資料，這些資料一般在訂單提交完的操作做完之后基本都會成為垃圾物件，

我們一般線上服務器的配置用得較多的就是雙核4G或4核8G，如果我們用雙核4G的機器，因為服務器作業系統包括一些后臺服務本身可能就要占用1G多記憶體，也就是說給JVM行程最多分配2G多點記憶體，刨開給方法區和虛擬機堆疊分配的記憶體，那么堆記憶體可能也就能分配到1G多點，對應的新生代記憶體最后可能就幾百M，那么意味著沒過幾百秒新生代就會被垃圾物件撐滿而觸發minor gc，這么頻繁的gc對系統的性能還是有一定影響的，

如果我們選擇4核8G的服務器，就可以給JVM行程分配四五個G的記憶體空間，那么堆記憶體可以分到三四個G左右，于是可以給新生代至少分配2G，這樣算下差不多需要半小時到一小時才能把新生代放滿觸發minor gc，這就大大降低了minor gc的頻率，所以一般我們線上服務器用得較多的還是4核8G的服務器配置，

如果系統業務量繼續增長那么可以水平擴容增加更多的機器，比如五臺甚至十臺機器，這樣每臺機器的JVM處理請求可以保證在合適范圍，不至于壓力過大導致大量的gc，

有的同學可能有疑問說雙核4G的服務器好像也夠用啊，無非就是minor gc頻率稍微高一點呀，不是說minor gc對系統的影響不是特別大嗎，我成本有限，只能用這樣的服務器啊，

其實如果系統業務量比較平穩也能湊合用，如果經常業務量可能有個幾倍甚至幾十倍的增長，比如時不時的搞個促銷秒殺活動什么的，那我們思考下會不會有什么問題，

假設業務量暴增幾十倍，在不增加機器的前提下，整個系統每秒要生成幾千個訂單，之前每秒往新生代里分配的1M物件資料可能增長到幾十M，而且因為系統壓力驟增，一個訂單的生成不一定能在1秒內完成，可能要幾秒甚至幾十秒，那么就有很多物件會在新生代里存活幾十秒之后才會變為垃圾物件，如果新生代只分配了幾百M，意味著一二十秒就會觸發一次minor gc，那么很有可能部分物件就會被挪到老年代，這些物件到了老年代后因為對應的業務操作執行完畢，馬上又變為了垃圾物件，隨著系統不斷運行，被挪到老年代的物件會越來越多，最終可能又會導致full gc，full gc對系統的性能影響還是比較大的，

如果我們用的是4核8G的服務器，新生代分配到2G以上的水平，那么至少也要幾百秒才會放滿新生代觸發minor gc，那些在新生代即便存活幾十秒的物件在minor gc觸發的時候大部分已經變為垃圾物件了，都可以被及時回收，基本不會被挪到老年代，這樣可以大大減少老年代的full gc次數，

file

3、逃逸分析

JVM的運行模式有三種：

解釋模式（Interpreted Mode）：只使用解釋器（-Xint 強制JVM使用解釋模式），執行一行JVM位元組碼就編譯一行為機器碼

編譯模式（Compiled Mode）：只使用編譯器（-Xcomp JVM使用編譯模式），先將所有JVM位元組碼一次編譯為機器碼，然后一次性執行所有機器碼

混合模式（Mixed Mode）：依然使用解釋模式執行代碼，但是對于一些 "熱點" 代碼采用編譯模式執行，JVM一般采用混合模式執行代碼

解釋模式啟動快，對于只需要執行部分代碼，并且大多數代碼只會執行一次的情況比較適合；編譯模式啟動慢，但是后期執行速度快，而且比較占用記憶體，因為機器碼的數量至少是JVM位元組碼的十倍以上，這種模式適合代碼可能會被反復執行的場景；

混合模式是JVM默認采用的執行代碼方式，一開始還是解釋執行，但是對于少部分 “熱點 ”代碼會采用編譯模式執行，這些熱點代碼對應的機器碼會被快取起來，下次再執行無需再編譯，這就是我們常見的JIT(Just In Time Compiler)即時編譯技術，

在即時編譯程序中JVM可能會對我們的代碼做一些優化，比如物件逃逸分析等，

物件逃逸分析：就是分析物件動態作用域，當一個物件在方法中被定義后，它可能被外部方法所參考，例如作為呼叫引數傳遞到其他地方中，

public User test1() {
   User user = new User();
   user.setId(1);
   user.setName("zhuge");
   //TODO 保存到資料庫
   return user;
}
public void test2() {
   User user = new User();
   user.setId(1);
   user.setName("zhuge");
   //TODO 保存到資料庫
}

很顯然test1方法中的user物件被回傳了，這個物件的作用域范圍不確定，test2方法中的user物件我們可以確定當方法結束這個物件就可以認為是無效物件了，對于這樣的物件我們其實可以將其分配的堆疊記憶體里，讓其在方法結束時跟隨堆疊記憶體一起被回收掉，

JVM對于這種情況可以通過開啟逃逸分析引數(-XX:+DoEscapeAnalysis)來優化物件記憶體分配位置，JDK7之后默認開啟逃逸分析，如果要關閉使用引數(-XX:-DoEscapeAnalysis)，

最后注意：除了本文講的案例，我還整理了最新5套JAVA架構專案實戰教程及大廠面試題庫，需要的可以進裙 783802103，裙檔案下，沒基礎勿進哦！
本文的文字及圖片來源于網路加上自己的想法,僅供學習、交流使用,不具有任何商業用途,著作權歸原作者所有,如有問題請及時聯系我們以作處理

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/188604.html

標籤：Java

上一篇：Java學習-JDK動態代理

下一篇：JDK安裝與配置環境變數