超詳細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 = 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，裙文件下，沒基礎勿進哦！
本文的文字及圖片來源於網絡加上自己的想法,僅供學習、交流使用,不具有任何商業用途,版權歸原作者所有,如有問題請及時聯系我們以作處理