JVM：我就想知道我是怎么沒的
這可不是什么好事，與 JVM 一起崩潰的，除了服務，還有我們的心態(tài)。
所謂的 JVM 崩潰，一般情況下就是指內(nèi)存溢出，也就是 OutOfMemoryError 和 StackOverflowError。另外還有一種情況就是堆外內(nèi)存占用過大，這種情況會導致 JVM 所在機器的內(nèi)存被撐爆，從而導致機器重啟等異常情況發(fā)生，我們把這種情況叫做內(nèi)存泄漏。
那什么情況下會造成 JVM 崩潰呢，有哪幾種類型的崩潰呢？俗話說，知己知彼，方能百戰(zhàn)不殆。了解了發(fā)生崩潰的原因，才能更好的解決 JVM 崩潰問題。
首先還是放出 JVM 內(nèi)存模型圖，JVM 要理解起來是很抽象的，借助下面這張圖可以具象化的了解 JVM 內(nèi)存模型，而發(fā)生溢出的幾個部分都可以在圖中找到。在 JDK 8 中，永久代已經(jīng)不存在了，取而代之的是元空間（metaspace）。
下面就以 Hotspot JDK 8 為背景，看一下 JVM 內(nèi)存溢出和內(nèi)存泄漏的幾種情況。
首先設置 JVM 啟動參數(shù)，限制堆空間大小，堆空間設置為 20M，其中新生代10M，元空間10M，并指定垃圾收集算法采用 CMS 算法。之后的例子都會使用這套參數(shù)。
-XX:+UseConcMarkSweepGC
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=70
-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
-XX:+CMSClassUnloadingEnabled
-XX:+ParallelRefProcEnabled
-XX:+CMSScavengeBeforeRemark
-verbose:gc
-Xms20M
-Xmx20M
-Xmn10M
-XX:+PrintGCDetails
-XX:SurvivorRatio=8
-XX:+HeapDumpOnOutOfMemoryError
-XX:MetaspaceSize=10M
-XX:MaxMetaspaceSize=10M
-XX:HeapDumpPath=/Users/fengzheng/jvmlog
?
?
堆溢出
堆溢出，應該是最常見的一種內(nèi)存溢出的場景了。JVM 中分配絕大多數(shù)對象實例和數(shù)組都存在堆上，另外堆內(nèi)存也是垃圾收集器工作的主要戰(zhàn)場。
當我們的 Java 程序啟動的時候，會指定堆空間的大小，新建對象和數(shù)組的時候會分配到堆上面，當新對象申請空間的時候，如果堆內(nèi)存不夠了，就會發(fā)生垃圾收集動作，大多數(shù)時候會發(fā)生在新生代，叫做 Minor GC。當新生代回收完成，空間仍然不夠的話，會發(fā)生一次 FullGC。FullGC 后，空間仍然不夠，此時就會發(fā)生 OOM 錯誤，也就是堆溢出。
模擬一下這個場景
private?final?static?int?_1K?=?1024;
public?static?void?main(String[]?args){
??List<byte[]>?byteList?=?new?ArrayList<>();
??quietlyWaitingForCrashHeap(byteList);
}
public?static?void?quietlyWaitingForCrashHeap(List<byte[]>?byteList)?{
??try?{
????while?(true)?{
??????byteList.add(new?byte[500?*?_1K]);
??????//Thread.sleep(1000);
??????Thread.sleep(100);
????}
??}?catch?(InterruptedException?e)?{
??}
}
上面的方法會持續(xù)的向List數(shù)組中每次添加500k的元素，整個堆只有20M，可想而知，程序一運行起來，馬上就會將對空間填滿，導致后面的元素加不進去，而又回收不掉，從而導致堆內(nèi)存溢出。
下面是程序運行之后的結果，經(jīng)過垃圾回收最終還是沒有多余的空間，從而發(fā)生 java.lang.OutOfMemoryError: Java heap space異常。
發(fā)生堆內(nèi)存溢出的根本原因就是使用中的對象大小超過了堆內(nèi)存大小。
堆內(nèi)存空間設置的太小，要根據(jù)預估的實際使用堆大小合理的設置堆空間設置。
程序有漏洞導致，某些靜態(tài)變量持續(xù)的增大，例如緩存數(shù)據(jù)錯誤的初始化，導致緩存無止境的增加，最終導致堆內(nèi)存溢出。針對這種情況，恐怕沒什么好方法，除了做好測試之外，就是在問題發(fā)生后做好日志分析。
?
棧溢出
虛擬機棧是用來存儲局部變量表、操作數(shù)棧、動態(tài)鏈接、方法出口等信息的，每調(diào)用一個 Java 方法就會為此方法在虛擬機棧中生成棧幀。
棧除了包括虛擬機棧之外，還包括本地方法棧，當調(diào)用的方法是本地方法（例如 C 語言實現(xiàn)的方法）時，會用到本地方法棧。不過，在 HotSpot 虛擬機中，虛擬機棧和本地方法棧被合二為一了。
模擬棧溢出場景
public?static?void?main(String[]?args){
??stackOverflow();
}
/**
*?stackoverflow
*/
public?static?void?stackOverflow()?{
??stackOverflow();
}
在上面的代碼中，stackOverflow() 方法的調(diào)用是一個無限遞歸的過程，沒有遞歸出口。前面說了，每調(diào)用一個方法就會在虛擬機棧中生成棧幀，無限的遞歸，必定造成無限的生成棧幀，最后導致棧空間被填滿，從而發(fā)生溢出。
上面模擬了最常見的一種狀況，產(chǎn)生這種狀況的原因很可能是由于程序 bug 導致的，一般來說，遞歸必定會有遞歸出口，如果由于某些原因導致了程序在執(zhí)行的過程中無法達到出口條件，那就會造成這種異常。還有就是循環(huán)體，循環(huán)體的循環(huán)次數(shù)如果過大，也有可能出現(xiàn)棧溢出。
另外還可能是其他比較不容易出現(xiàn)的原因，比如創(chuàng)建的線程數(shù)過多，線程創(chuàng)建要在虛擬機棧中分配空間，如果創(chuàng)建線程過多，可能會出現(xiàn) OutOfMemoryError異常，但是一般來說，都會用線程池的方法代替手動創(chuàng)建線程的方式，所以，這種情況不容易出現(xiàn)。
?
元空間溢出
用于存儲已被虛擬機加載的類信息，常量，靜態(tài)變量，即時編譯(JIT)后的代碼等數(shù)據(jù)，在 JDK 8 中，已經(jīng)用 metaSpace 代替了永久代的。默認情況下 metaSpace 的大小是沒有限制的，也就是所在服務器的實際內(nèi)存大小，但是，一般情況下，最好還是設置元空間的大小。
一般在產(chǎn)生大量動態(tài)生成類的情景中，可能會出現(xiàn)元空間的內(nèi)存溢出。
模擬元空間溢出
public?static?void?main(String[]?args){
??List<byte[]>?byteList?=?new?ArrayList<>();
??//quietlyWaitingForCrashHeap(byteList);
??//?stackOverflow();
??methodAreaOverflow();
}
public?static?void?methodAreaOverflow()?{
??int?i?=?0;
??while?(true)?{
????Enhancer?enhancer?=?new?Enhancer();
????enhancer.setUseCache(false);
????enhancer.setSuperclass(MethodOverflow.class);
????enhancer.setCallback(new?MethodInterceptor()?{
??????@Override
??????public?Object?intercept(Object?o,?Method?method,?Object[]?objects,?MethodProxy?methodProxy)?throws?Throwable?{
????????return?methodProxy.invokeSuper(o,?objects);
??????}
????});
????enhancer.create();
????System.out.println(++i);
??}
}
通過 CGLIB 的方式動態(tài)的創(chuàng)建很多個動態(tài)類，這樣一來，類信息就會越來越多的存到元空間，從而導致元空間溢出。
例如在使用 Spring、 MyBatis 等技術框架的時候會動態(tài)創(chuàng)建 Bean 實例類，另外，Spring AOP 也會產(chǎn)生動態(tài)代理類。
?
?
堆外內(nèi)存溢出
大多數(shù)情況下，內(nèi)存都會在 JVM 堆內(nèi)存中分配，很少情況下需要直接在堆外分配內(nèi)存空間。使用堆外內(nèi)存的幾個好處是：
在進程間可以共享，減少虛擬機間的復制
對垃圾回收停頓的改善：如果應用某些長期存活并大量存在的對象，經(jīng)常會觸發(fā)YGC或者FullGC，可以考慮把這些對象放到堆外。過大的堆會影響Java應用的性能。如果使用堆外內(nèi)存的話，堆外內(nèi)存是直接受操作系統(tǒng)管理( 而不是虛擬機 )。這樣做的結果就是能保持一個較小的堆內(nèi)內(nèi)存，以減少垃圾收集對應用的影響。
在某些場景下可以提升程序I/O操縱的性能。少去了將數(shù)據(jù)從堆內(nèi)內(nèi)存拷貝到堆外內(nèi)存的步驟。
通常在需要大量頻繁的進行 IO 操作的時候會用到堆外內(nèi)存，例如 Netty、RocketMQ 等使用到了堆外內(nèi)存，目的就是為了加快速度。
所以，在出現(xiàn)系統(tǒng)內(nèi)存占用過大的情況時，排查堆棧無果后，可以看一下堆外內(nèi)存的使用情況，看看是不是堆外內(nèi)存溢出了。
?
總結
事前做好配置
JVM 問題本身就是比較抽象和難以直觀發(fā)現(xiàn)的，所以在項目上線前除了做好代碼邏輯的測試外，還要對 JVM 參數(shù)進行合理配置，根據(jù)應用程序的體量和特點選擇好合適的參數(shù)，比如堆棧大小、垃圾收集器種類等等。
另外，垃圾收集日志一定要有保留，還有就是發(fā)生內(nèi)存溢出時要保存 dump 文件。
事中做好監(jiān)控
在程序上線運行的過程中，做好 JVM 的監(jiān)控工作，比如用 Spring Admin 這種比較輕量的監(jiān)控工具，或者大型項目用 Cat、SkyWallking 等這些分布式鏈路監(jiān)控系統(tǒng)。
事后做好現(xiàn)場保護和分析
再合理的參數(shù)配置和監(jiān)控平臺，也難免不發(fā)生異常，這也是很正常的，不出現(xiàn)異常才有問題好吧。在發(fā)生異常之后，要及時的保留現(xiàn)場，如果是多實例應用，可以暫時將發(fā)生異常的實例做下線處理，然后再進行問題的排查。如果是單實例的服務，那要及時的確認最新的日志和dump已經(jīng)留存好，確認完成后，再采取錯誤讓服務重啟。
有道無術，術可成；有術無道，止于術
歡迎大家關注Java之道公眾號
好文章，我在看??