JVM之持久代與OutOfMemory 持久代 Permanent Generation space（JDK1.7及以下版本存在）

主要存放存放class文件中類的版本、字段、方法、接口，類和方法的元數(shù)據(jù)等描述信息，運(yùn)行時(shí)常量池，用于存放編譯器生成的各種字面量和符號(hào)引用。

上限是MaxPermSize

PremGen與old區(qū)綁定在一起，在fullGC時(shí)會(huì)一起被GC

PermGen中方法區(qū)移至Metaspace，字符串常量移至Java Heap。類的元數(shù)據(jù)信息（metadata）還在，只不過(guò)不再是存儲(chǔ)在連續(xù)的堆空間上，而是移動(dòng)到叫做“Metaspace”的本地內(nèi)存（Native memory）中。

** MetaSpace組成

**

Klass Metaspace:用來(lái)存klass的（class文件在jvm里的運(yùn)行時(shí)數(shù)據(jù)結(jié)構(gòu)），這塊內(nèi)存是緊接著Heap的。

NoKlass Metaspace:專門來(lái)存klass相關(guān)的其他的內(nèi)容，比如method，constantPool等，這塊內(nèi)存是由多塊內(nèi)存組合起來(lái)的，所以可以認(rèn)為是不連續(xù)的內(nèi)存塊組成的。這塊內(nèi)存是必須的，雖然叫做NoKlassMetaspace，但是也其實(shí)可以存klass的內(nèi)容，上面已經(jīng)提到了對(duì)應(yīng)場(chǎng)景。如果KlassMetaspace用完了，那就會(huì)OOM了，不過(guò)一般情況下不會(huì)，NoKlassMestaspace是由一塊塊內(nèi)存慢慢組合起來(lái)的，在沒(méi)有達(dá)到限制條件的情況下，會(huì)不斷加長(zhǎng)這條鏈，讓它可以持續(xù)工作。

-XX:MetaspaceSize，初始空間大小，達(dá)到該值就會(huì)觸發(fā)垃圾收集進(jìn)行類型卸載，同時(shí)GC會(huì)對(duì)該值進(jìn)行調(diào)整。

-XX:MaxMetaspaceSize，最大空間，默認(rèn)是沒(méi)有限制的（自增）。 建議設(shè)置，如果出現(xiàn)內(nèi)存增長(zhǎng)不釋放，會(huì)占用所有的內(nèi)存空間直至被OS kill掉。

-XX:CompressedClassSpaceSize，默認(rèn)1G，這個(gè)參數(shù)主要是設(shè)置KlassMetaspace的大小，不過(guò)這個(gè)參數(shù)設(shè)置了也不一定起作用，前提是能開啟壓縮指針，假如Xmx超過(guò)了32G，壓縮指針是開啟不來(lái)的。如果有Klass Metaspace，那這塊內(nèi)存是和Heap連著的。

-XX:InitialBootClassLoaderMetaspaceSize，64位下默認(rèn)4M，32位下默認(rèn)2200K，NoKlassMetaspace是由一塊塊內(nèi)存組合起來(lái)的，這個(gè)參數(shù)決定了NoKlassMetaspace的第一個(gè)內(nèi)存Block的大小，即2*InitialBootClassLoaderMetaspaceSize，同時(shí)為bootstrapClassLoader的第一塊內(nèi)存chunk分配了InitialBootClassLoaderMetaspaceSize的大小。

-XX:MinMetaspaceExpansion和XX:MaxMetaspaceExpansion ，默認(rèn)分別是332.8K和5.2M，這兩個(gè)值為了增大觸發(fā)metaspace GC的閾值。gcLocker或者should_concurrent_collect的一些場(chǎng)景，因?yàn)檫@些場(chǎng)景下接下來(lái)會(huì)做一次GC，相信在接下來(lái)的GC中可能會(huì)釋放一些metaspace的內(nèi)存，于是先臨時(shí)擴(kuò)大下metaspace觸發(fā)GC的閾值，而有些內(nèi)存分配失敗其實(shí)正好是因?yàn)檫@個(gè)閾值觸頂導(dǎo)致的，于是可以通過(guò)增大閾值暫時(shí)繞過(guò)去。

-XX:MinMetaspaceFreeRatio和XX:MaxMetaspaceFreeRatio ，默認(rèn)分別是默認(rèn)40和70，主要是影響觸發(fā)metaspaceGC的閾值。每次GC完之后，假設(shè)我們?cè)试S接下來(lái)metaspace可以繼續(xù)被commit的內(nèi)存占到了被commit之后總共committed的內(nèi)存量的MinMetaspaceFreeRatio%，如果這個(gè)總共被committed的量比當(dāng)前觸發(fā)metaspaceGC的閾值要大，那么將嘗試做擴(kuò)容，增大觸發(fā)metaspaceGC的閾值，不過(guò)這個(gè)增量至少是MinMetaspaceExpansion才會(huì)做，不然不會(huì)增加這個(gè)閾值。這個(gè)參數(shù)主要是為了避免觸發(fā)metaspaceGC的閾值和gc之后committed的內(nèi)存的量比較接近，于是將這個(gè)閾值進(jìn)行擴(kuò)大。一般情況下在gc完之后，如果被committed的量還是比較大的時(shí)候，換個(gè)說(shuō)法就是離觸發(fā)metaspaceGC的閾值比較接近的時(shí)候，這個(gè)調(diào)整會(huì)比較明顯。

先了解下內(nèi)存泄漏與內(nèi)存溢出的區(qū)別

out of memory：是指程序在申請(qǐng)內(nèi)存時(shí)，沒(méi)有足夠的內(nèi)存空間供其使用，出現(xiàn)out of memory；比如申請(qǐng)了一個(gè)integer,但給它存了long才能存下的數(shù)，那就是內(nèi)存溢出。

memory leak：是指程序在申請(qǐng)內(nèi)存后，無(wú)法釋放已申請(qǐng)的內(nèi)存空間，一次內(nèi)存泄露危害可以忽略，但內(nèi)存泄露堆積后果很嚴(yán)重，無(wú)論多少內(nèi)存,遲早會(huì)被占光。

memory leak會(huì)最終會(huì)導(dǎo)致out of memory！ JVM常見(jiàn)內(nèi)存溢出區(qū)域 堆溢出 java.lang.OutOfMemoryError:Java heap space 堆溢出GC過(guò)程：

Eden內(nèi)存不夠》進(jìn)入old分配》分配失敗觸發(fā)youngGC》分配失敗觸發(fā)fullGC（soft reference不會(huì)被強(qiáng)制回收）》分配失敗再?gòu)?qiáng)制fullGC（包括soft reference）》分配失敗拋出OOM

檢查程序，看是否有死循環(huán)或不必要地重復(fù)創(chuàng)建大量對(duì)象。

增加Java虛擬機(jī)中Xms（初始堆大?。┖蚗mx（最大堆大?。﹨?shù)的大小。

打印heapdump文件和GC日志分析：-Xmx1536m -Xms1536m -Xmn1024m -XX:SurvivorRatio=4 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=路徑 -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:../logs/gc.log

永久區(qū)是存放類元數(shù)據(jù)的區(qū)域。JDK1.8中，永久區(qū)被一塊元數(shù)據(jù)的區(qū)域替代。

應(yīng)用程序清理引用來(lái)觸發(fā)類卸載。

增加MaxPermSize的大小。

減少系統(tǒng)需要的類的數(shù)量。

使用classloader合理地裝載各個(gè)類，并定期回收。

太多的類或太大的類加載到元空間。

內(nèi)存泄露會(huì)耗盡整個(gè)本地內(nèi)存，導(dǎo)致內(nèi)存交換(swapping)

設(shè)置XX:MaxMetaspaceSize的大小。

java的NIO中支持直接內(nèi)存使用，可以通過(guò)java代碼獲取的一塊堆外的內(nèi)存空間，這塊內(nèi)存是直接向操作系統(tǒng)申請(qǐng)的，其申請(qǐng)速度比堆內(nèi)存慢，是訪問(wèn)速度要快于堆內(nèi)存。此空間沒(méi)有被JVM完全托管，使用不當(dāng)會(huì)造成內(nèi)存溢出。

設(shè)置-XX:MaxDirectMenorySize。若不設(shè)置最大內(nèi)存可以使用到Xmx的值（建議）

使用完畢后執(zhí)行system.gc（慎用）

每個(gè)線程都要占用內(nèi)存空間，因此當(dāng)線程數(shù)量太多時(shí)，也有可能導(dǎo)致OOM，由于線程的棧空間是堆外內(nèi)存分配的，因此與直接內(nèi)存非常相似。

問(wèn)題引發(fā)：

線程的?？臻g在堆外內(nèi)存分配，線程太多導(dǎo)致OOM

嘗試減少堆空間（Xmx）

減少每一個(gè)線程所占的內(nèi)存空間，使用Xss參數(shù)（默認(rèn)1M）可以指定線程的?？臻g

減少線程數(shù)

GC overhead limt exceed檢查是Hotspot VM 1.6定義的一個(gè)策略，通過(guò)統(tǒng)計(jì)GC時(shí)間來(lái)預(yù)測(cè)是否要OOM了，提前拋出異常，防止OOM發(fā)生。Sun 官方對(duì)此的定義是：“并行/并發(fā)回收器在GC回收時(shí)間過(guò)長(zhǎng)時(shí)會(huì)拋出OutOfMemroyError。過(guò)長(zhǎng)的定義是，超過(guò)98%的時(shí)間用來(lái)做GC并且回收了不到2%的堆內(nèi)存。用來(lái)避免內(nèi)存過(guò)小造成應(yīng)用不能正常工作

假如生產(chǎn)環(huán)境中遇到了這個(gè)問(wèn)題，在不知道原因時(shí)不要簡(jiǎn)單地猜測(cè)和規(guī)避?？梢酝ㄟ^(guò)**-verbose:gc -XX:+PrintGCDetails 看下到底什么原因造成了異常。通常原因都是因?yàn)閛ld區(qū)占用過(guò)多導(dǎo)致頻繁Full GC**，最終導(dǎo)致GC overhead limit exceed。如果gc log不夠可以借助于JProfile等工具查看內(nèi)存的占用，old區(qū)是否有內(nèi)存泄露。分析內(nèi)存泄露還有一個(gè)方法**-XX:+HeapDumpOnOutOfMemoryError**，這樣OOM時(shí)會(huì)自動(dòng)做Heap Dump，可以拿MAT來(lái)排查了。還要留意 young區(qū)，如果有過(guò)多短暫對(duì)象分配，可能也會(huì)拋這個(gè)異常 。

下載數(shù)據(jù)時(shí)文件大小超過(guò)某一峰值是會(huì)報(bào)這個(gè)錯(cuò)誤。原因是在頁(yè)面點(diǎn)擊下載時(shí)，在數(shù)據(jù)庫(kù)查詢了很龐大的數(shù)據(jù)量，導(dǎo)致內(nèi)存使用增加，才會(huì)出現(xiàn)這個(gè)問(wèn)題。

查看項(xiàng)目中是否有大量的死循環(huán)或有使用大內(nèi)存的代碼，優(yōu)化代碼。

JVM給出這樣一個(gè)參數(shù)： -XX:UseGCOverheadLimit禁用這個(gè)檢查，其實(shí)這個(gè)參數(shù)解決不了內(nèi)存問(wèn)題，只是把錯(cuò)誤的信息延后，替換成 java.lang.OutOfMemoryError: Java heap space。

增大堆內(nèi)存 set JAVA_OPTS=server Xms512m Xmx1024m XX:MaxNewSize=1024m XX:MaxPermSize=1024m

如果有設(shè)置**-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=路徑，直接拿dump文件去分析，常用工具： MAT 與Visual VM（JDK自帶的jvisualvm.exe）。**

如果沒(méi)有設(shè)置，則執(zhí)行 jmap -dump:live,format=b,file=filename.bin PID ，拿到****dump文件再去分析。

淺堆：一個(gè)對(duì)象所消耗的內(nèi)存。

深堆：一個(gè)對(duì)象被回收后，可以真實(shí)釋放的內(nèi)存大小。

對(duì)象的實(shí)際大小定義為一個(gè)對(duì)象所能觸及的所有對(duì)象的淺堆大小之和，也就是通常意義上說(shuō)的對(duì)象大小。與深堆相比，這個(gè)概念在日常中更容易被接受，但實(shí)際上這個(gè)概念和垃圾回收無(wú)關(guān)。

如圖所示：對(duì)象A的實(shí)際大小為A、C、D之和，但A的深堆大小為A、D之和。

展開全文

如果覺(jué)得本文對(duì)你有幫助，可以轉(zhuǎn)發(fā)關(guān)注支持一下

收藏

舉報(bào)