前言如果在文中用詞或者理解方面出現(xiàn)問題,歡迎指出。此文旨在提及而不深究,但會盡量效率地把知識點(diǎn)都拋出來 一、JVM的基本介紹JVM 是 Java Virtual Machine 的縮寫,它是一個虛構(gòu)出來的計算機(jī),一種規(guī)范。通過在實際的計算機(jī)上仿真模擬各類計算機(jī)功能實現(xiàn)··· 好,其實拋開這么專業(yè)的句子不說,就知道JVM其實就類似于一臺小電腦運(yùn)行在windows或者linux這些操作系統(tǒng)環(huán)境下即可。它直接和操作系統(tǒng)進(jìn)行交互,與硬件不直接交互,可操作系統(tǒng)可以幫我們完成和硬件進(jìn)行交互的工作。 1.1 Java文件是如何被運(yùn)行的比如我們現(xiàn)在寫了一個 HelloWorld.java 好了,那這個 HelloWorld.java 拋開所有東西不談,那是不是就類似于一個文本文件,只是這個文本文件它寫的都是英文,而且有一定的縮進(jìn)而已。 那我們的 JVM 是不認(rèn)識文本文件的,所以它需要一個 編譯 ,讓其成為一個它會讀二進(jìn)制文件的 HelloWorld.class ① 類加載器如果 JVM 想要執(zhí)行這個 .class 文件,我們需要將其裝進(jìn)一個 類加載器 中,它就像一個搬運(yùn)工一樣,會把所有的 .class 文件全部搬進(jìn)JVM里面來。 ② 方法區(qū)方法區(qū) 是用于存放類似于元數(shù)據(jù)信息方面的數(shù)據(jù)的,比如類信息,常量,靜態(tài)變量,編譯后代碼···等 類加載器將 .class 文件搬過來就是先丟到這一塊上 ③ 堆堆 主要放了一些存儲的數(shù)據(jù),比如對象實例,數(shù)組···等,它和方法區(qū)都同屬于 線程共享區(qū)域 。也就是說它們都是 線程不安全 的 ④ 棧棧 這是我們的代碼運(yùn)行空間。我們編寫的每一個方法都會放到 棧 里面運(yùn)行。 我們會聽說過 本地方法棧 或者 本地方法接口 這兩個名詞,不過我們基本不會涉及這兩塊的內(nèi)容,它倆底層是使用C來進(jìn)行工作的,和Java沒有太大的關(guān)系。 ⑤ 程序計數(shù)器主要就是完成一個加載工作,類似于一個指針一樣的,指向下一行我們需要執(zhí)行的代碼。和棧一樣,都是 線程獨(dú)享 的,就是說每一個線程都會有自己對應(yīng)的一塊區(qū)域而不會存在并發(fā)和多線程的問題。 小總結(jié)
1.2 簡單的代碼例子一個簡單的學(xué)生類 一個main方法 執(zhí)行main方法的步驟如下:
其實也不用管太多,只需要知道對象實例初始化時會去方法區(qū)中找類信息,完成后再到棧那里去運(yùn)行方法。找方法就在方法表中找。 二、類加載器的介紹之前也提到了它是負(fù)責(zé)加載.class文件的,它們在文件開頭會有特定的文件標(biāo)示,將class文件字節(jié)碼內(nèi)容加載到內(nèi)存中,并將這些內(nèi)容轉(zhuǎn)換成方法區(qū)中的運(yùn)行時數(shù)據(jù)結(jié)構(gòu),并且ClassLoader只負(fù)責(zé)class文件的加載,而是否能夠運(yùn)行則由 Execution Engine 來決定 2.1 類加載器的流程從類被加載到虛擬機(jī)內(nèi)存中開始,到釋放內(nèi)存總共有7個步驟:加載,驗證,準(zhǔn)備,解析,初始化,使用,卸載。其中驗證,準(zhǔn)備,解析三個部分統(tǒng)稱為連接 2.1.1 加載
2.1.2 連接
2.1.3 初始化初始化其實就是一個賦值的操作,它會執(zhí)行一個類構(gòu)造器的()方法。由編譯器自動收集類中所有變量的賦值動作,此時準(zhǔn)備階段時的那個 static int a = 3 的例子,在這個時候就正式賦值為3 2.1.4 卸載GC將無用對象從內(nèi)存中卸載 2.2 類加載器的加載順序加載一個Class類的順序也是有優(yōu)先級的,類加載器從最底層開始往上的順序是這樣的
2.3 雙親委派機(jī)制當(dāng)一個類收到了加載請求時,它是不會先自己去嘗試加載的,而是委派給父類去完成,比如我現(xiàn)在要new一個Person,這個Person是我們自定義的類,如果我們要加載它,就會先委派App ClassLoader,只有當(dāng)父類加載器都反饋?zhàn)约簾o法完成這個請求(也就是父類加載器都沒有找到加載所需的Class)時,子類加載器才會自行嘗試加載 這樣做的好處是,加載位于rt.jar包中的類時不管是哪個加載器加載,最終都會委托到BootStrap ClassLoader進(jìn)行加載,這樣保證了使用不同的類加載器得到的都是同一個結(jié)果。 其實這個也是一個隔離的作用,避免了我們的代碼影響了JDK的代碼,比如我現(xiàn)在要來一個 public class String(){ public static void main(){sout;} } 這種時候,我們的代碼肯定會報錯,因為在加載的時候其實是找到了rt.jar中的String.class,然后發(fā)現(xiàn)這也沒有main方法 三、運(yùn)行時數(shù)據(jù)區(qū)3.1 本地方法棧和程序計數(shù)器比如說我們現(xiàn)在點(diǎn)開Thread類的源碼,會看到它的start0方法帶有一個native關(guān)鍵字修飾,而且不存在方法體,這種用native修飾的方法就是本地方法,這是使用C來實現(xiàn)的,然后一般這些方法都會放到一個叫做本地方法棧的區(qū)域。 程序計數(shù)器其實就是一個指針,它指向了我們程序中下一句需要執(zhí)行的指令,它也是內(nèi)存區(qū)域中唯一一個不會出現(xiàn)OutOfMemoryError的區(qū)域,而且占用內(nèi)存空間小到基本可以忽略不計。這個內(nèi)存僅代表當(dāng)前線程所執(zhí)行的字節(jié)碼的行號指示器,字節(jié)碼解析器通過改變這個計數(shù)器的值選取下一條需要執(zhí)行的字節(jié)碼指令。 如果執(zhí)行的是native方法,那這個指針就不工作了。 3.2 方法區(qū)方法區(qū)主要的作用技術(shù)存放類的元數(shù)據(jù)信息,常量和靜態(tài)變量···等。當(dāng)它存儲的信息過大時,會在無法滿足內(nèi)存分配時報錯。 3.3 虛擬機(jī)棧和虛擬機(jī)堆一句話便是:棧管運(yùn)行,堆管存儲。則虛擬機(jī)棧負(fù)責(zé)運(yùn)行代碼,而虛擬機(jī)堆負(fù)責(zé)存儲數(shù)據(jù)。 3.3.1 虛擬機(jī)棧的概念它是Java方法執(zhí)行的內(nèi)存模型。里面會對局部變量,動態(tài)鏈表,方法出口,棧的操作(入棧和出棧)進(jìn)行存儲,且線程獨(dú)享。同時如果我們聽到局部變量表,那也是在說虛擬機(jī)棧 public class Person{ int a = 1; public void doSomething(){ int b = 2; } } 3.3.2 虛擬機(jī)棧存在的異常如果線程請求的棧的深度大于虛擬機(jī)棧的最大深度,就會報 StackOverflowError (這種錯誤經(jīng)常出現(xiàn)在遞歸中)。Java虛擬機(jī)也可以動態(tài)擴(kuò)展,但隨著擴(kuò)展會不斷地申請內(nèi)存,當(dāng)無法申請足夠內(nèi)存時就會報錯 OutOfMemoryError。 3.3.3 虛擬機(jī)棧的生命周期對于棧來說,不存在垃圾回收。只要程序運(yùn)行結(jié)束,棧的空間自然就會釋放了。棧的生命周期和所處的線程是一致的。 這里補(bǔ)充一句:8種基本類型的變量+對象的引用變量+實例方法都是在棧里面分配內(nèi)存。 3.3.4 虛擬機(jī)棧的執(zhí)行我們經(jīng)常說的棧幀數(shù)據(jù),說白了在JVM中叫棧幀,放到Java中其實就是方法,它也是存放在棧中的。 棧中的數(shù)據(jù)都是以棧幀的格式存在,它是一個關(guān)于方法和運(yùn)行期數(shù)據(jù)的數(shù)據(jù)集。比如我們執(zhí)行一個方法a,就會對應(yīng)產(chǎn)生一個棧幀A1,然后A1會被壓入棧中。同理方法b會有一個B1,方法c會有一個C1,等到這個線程執(zhí)行完畢后,棧會先彈出C1,后B1,A1。它是一個先進(jìn)后出,后進(jìn)先出原則。 3.3.5 局部變量的復(fù)用局部變量表用于存放方法參數(shù)和方法內(nèi)部所定義的局部變量。它的容量是以Slot為最小單位,一個slot可以存放32位以內(nèi)的數(shù)據(jù)類型。 虛擬機(jī)通過索引定位的方式使用局部變量表,范圍為[0,局部變量表的slot的數(shù)量]。方法中的參數(shù)就會按一定順序排列在這個局部變量表中,至于怎么排的我們可以先不關(guān)心。而為了節(jié)省棧幀空間,這些slot是可以復(fù)用的,當(dāng)方法執(zhí)行位置超過了某個變量,那么這個變量的slot可以被其它變量復(fù)用。當(dāng)然如果需要復(fù)用,那我們的垃圾回收自然就不會去動這些內(nèi)存。 3.3.6 虛擬機(jī)堆的概念JVM內(nèi)存會劃分為堆內(nèi)存和非堆內(nèi)存,堆內(nèi)存中也會劃分為年輕代和老年代,而非堆內(nèi)存則為永久代。年輕代又會分為Eden和Survivor區(qū)。Survivor也會分為FromPlace和ToPlace,toPlace的survivor區(qū)域是空的。Eden,F(xiàn)romPlace和ToPlace的默認(rèn)占比為 8:1:1。當(dāng)然這個東西其實也可以通過一個 -XX:+UsePSAdaptiveSurvivorSizePolicy 參數(shù)來根據(jù)生成對象的速率動態(tài)調(diào)整 堆內(nèi)存中存放的是對象,垃圾收集就是收集這些對象然后交給GC算法進(jìn)行回收。非堆內(nèi)存其實我們已經(jīng)說過了,就是方法區(qū)。在1.8中已經(jīng)移除永久代,替代品是一個元空間(MetaSpace),最大區(qū)別是metaSpace是不存在于JVM中的,它使用的是本地內(nèi)存。并有兩個參數(shù) MetaspaceSize:初始化元空間大小,控制發(fā)生GC MaxMetaspaceSize:限制元空間大小上限,防止占用過多物理內(nèi)存。 移除的原因可以大致了解一下:融合HotSpot JVM和JRockit VM而做出的改變,因為JRockit是沒有永久代的,不過這也間接性地解決了永久代的OOM問題。 3.3.7 Eden年輕代的介紹當(dāng)我們new一個對象后,會先放到Eden劃分出來的一塊作為存儲空間的內(nèi)存,但是我們知道對堆內(nèi)存是線程共享的,所以有可能會出現(xiàn)兩個對象共用一個內(nèi)存的情況。這里JVM的處理是每個線程都會預(yù)先申請好一塊連續(xù)的內(nèi)存空間并規(guī)定了對象存放的位置,而如果空間不足會再申請多塊內(nèi)存空間。這個操作我們會稱作TLAB,有興趣可以了解一下。 當(dāng)Eden空間滿了之后,會觸發(fā)一個叫做Minor GC(就是一個發(fā)生在年輕代的GC)的操作,存活下來的對象移動到Survivor0區(qū)。Survivor0區(qū)滿后觸發(fā) Minor GC,就會將存活對象移動到Survivor1區(qū),此時還會把from和to兩個指針交換,這樣保證了一段時間內(nèi)總有一個survivor區(qū)為空且to所指向的survivor區(qū)為空。經(jīng)過多次的 Minor GC后仍然存活的對象(這里的存活判斷是15次,對應(yīng)到虛擬機(jī)參數(shù)為 -XX:MaxTenuringThreshold 。為什么是15,因為HotSpot會在對象投中的標(biāo)記字段里記錄年齡,分配到的空間僅有4位,所以最多只能記錄到15)會移動到老年代。老年代是存儲長期存活的對象的,占滿時就會觸發(fā)我們最常聽說的Full GC,期間會停止所有線程等待GC的完成。所以對于響應(yīng)要求高的應(yīng)用應(yīng)該盡量去減少發(fā)生Full GC從而避免響應(yīng)超時的問題。 而且當(dāng)老年區(qū)執(zhí)行了full gc之后仍然無法進(jìn)行對象保存的操作,就會產(chǎn)生OOM,這時候就是虛擬機(jī)中的堆內(nèi)存不足,原因可能會是堆內(nèi)存設(shè)置的大小過小,這個可以通過參數(shù)-Xms、-Xmx來調(diào)整。也可能是代碼中創(chuàng)建的對象大且多,而且它們一直在被引用從而長時間垃圾收集無法收集它們。 3.3.8 如何判斷一個對象需要被干掉圖中程序計數(shù)器、虛擬機(jī)棧、本地方法棧,3個區(qū)域隨著線程的生存而生存的。內(nèi)存分配和回收都是確定的。隨著線程的結(jié)束內(nèi)存自然就被回收了,因此不需要考慮垃圾回收的問題。而Java堆和方法區(qū)則不一樣,各線程共享,內(nèi)存的分配和回收都是動態(tài)的。因此垃圾收集器所關(guān)注的都是堆和方法這部分內(nèi)存。 在進(jìn)行回收前就要判斷哪些對象還存活,哪些已經(jīng)死去。下面介紹兩個基礎(chǔ)的計算方法 1.引用計數(shù)器計算:給對象添加一個引用計數(shù)器,每次引用這個對象時計數(shù)器加一,引用失效時減一,計數(shù)器等于0時就是不會再次使用的。不過這個方法有一種情況就是出現(xiàn)對象的循環(huán)引用時GC沒法回收。 2.可達(dá)性分析計算:這是一種類似于二叉樹的實現(xiàn),將一系列的GC ROOTS作為起始的存活對象集,從這個節(jié)點(diǎn)往下搜索,搜索所走過的路徑成為引用鏈,把能被該集合引用到的對象加入到集合中。搜索當(dāng)一個對象到GC Roots沒有使用任何引用鏈時,則說明該對象是不可用的。主流的商用程序語言,例如Java,C#等都是靠這招去判定對象是否存活的。 (了解一下即可)在Java語言匯總能作為GC Roots的對象分為以下幾種:
這種方法的優(yōu)點(diǎn)是能夠解決循環(huán)引用的問題,可它的實現(xiàn)需要耗費(fèi)大量資源和時間,也需要GC(它的分析過程引用關(guān)系不能發(fā)生變化,所以需要停止所有進(jìn)程) 3.3.9 如何宣告一個對象的真正死亡首先必須要提到的是一個名叫 finalize() 的方法 finalize()是Object類的一個方法、一個對象的finalize()方法只會被系統(tǒng)自動調(diào)用一次,經(jīng)過finalize()方法逃脫死亡的對象,第二次不會再調(diào)用。 補(bǔ)充一句:并不提倡在程序中調(diào)用finalize()來進(jìn)行自救。建議忘掉Java程序中該方法的存在。因為它執(zhí)行的時間不確定,甚至是否被執(zhí)行也不確定(Java程序的不正常退出),而且運(yùn)行代價高昂,無法保證各個對象的調(diào)用順序(甚至有不同線程中調(diào)用)。在Java9中已經(jīng)被標(biāo)記為 deprecated ,且java.lang.ref.Cleaner(也就是強(qiáng)、軟、弱、幻象引用的那一套)中已經(jīng)逐步替換掉它,會比finalize來的更加的輕量及可靠。 判斷一個對象的死亡至少需要兩次標(biāo)記
如果確定對象已經(jīng)死亡,我們又該如何回收這些垃圾呢 3.4 垃圾回收算法不會非常詳細(xì)的展開,常用的有標(biāo)記清除,復(fù)制,標(biāo)記整理和分代收集算法 3.4.1 標(biāo)記清除算法標(biāo)記清除算法就是分為“標(biāo)記”和“清除”兩個階段。標(biāo)記出所有需要回收的對象,標(biāo)記結(jié)束后統(tǒng)一回收。這個套路很簡單,也存在不足,后續(xù)的算法都是根據(jù)這個基礎(chǔ)來加以改進(jìn)的。 其實它就是把已死亡的對象標(biāo)記為空閑內(nèi)存,然后記錄在一個空閑列表中,當(dāng)我們需要new一個對象時,內(nèi)存管理模塊會從空閑列表中尋找空閑的內(nèi)存來分給新的對象。 不足的方面就是標(biāo)記和清除的效率比較低下。且這種做法會讓內(nèi)存中的碎片非常多。這個導(dǎo)致了如果我們需要使用到較大的內(nèi)存塊時,無法分配到足夠的連續(xù)內(nèi)存。比如下圖 此時可使用的內(nèi)存塊都是零零散散的,導(dǎo)致了剛剛提到的大內(nèi)存對象問題 3.4.2 復(fù)制算法為了解決效率問題,復(fù)制算法就出現(xiàn)了。它將可用內(nèi)存按容量劃分成兩等分,每次只使用其中的一塊。和survivor一樣也是用from和to兩個指針這樣的玩法。fromPlace存滿了,就把存活的對象copy到另一塊toPlace上,然后交換指針的內(nèi)容。這樣就解決了碎片的問題。 這個算法的代價就是把內(nèi)存縮水了,這樣堆內(nèi)存的使用效率就會變得十分低下了 不過它們分配的時候也不是按照1:1這樣進(jìn)行分配的,就類似于Eden和Survivor也不是等價分配是一個道理。 3.4.3 標(biāo)記整理算法復(fù)制算法在對象存活率高的時候會有一定的效率問題,標(biāo)記過程仍然與“標(biāo)記-清除”算法一樣,但后續(xù)步驟不是直接對可回收對象進(jìn)行清理,而是讓所有存活的對象都向一端移動,然后直接清理掉邊界以外的內(nèi)存 3.4.4 分代收集算法這種算法并沒有什么新的思想,只是根據(jù)對象存活周期的不同將內(nèi)存劃分為幾塊。一般是把Java堆分為新生代和老年代,這樣就可以根據(jù)各個年代的特點(diǎn)采用最適當(dāng)?shù)氖占惴āT谛律?,每次垃圾收集時都發(fā)現(xiàn)有大批對象死去,只有少量存活,那就選用復(fù)制算法,只需要付出少量存活對象的復(fù)制成本就可以完成收集。而老年代中因為對象存活率高、沒有額外空間對它進(jìn)行分配擔(dān)保,就必須使用“標(biāo)記-清理”或者“標(biāo)記-整理”算法來進(jìn)行回收。 說白了就是八仙過海各顯神通,具體問題具體分析了而已。 3.5 (了解)各種各樣的垃圾回收器HotSpot VM中的垃圾回收器,以及適用場景 到j(luò)dk8為止,默認(rèn)的垃圾收集器是Parallel Scavenge 和 Parallel Old 從jdk9開始,G1收集器成為默認(rèn)的垃圾收集器 3.6 (了解)JVM的常用參數(shù)JVM的參數(shù)非常之多,這里只列舉比較重要的幾個,通過各種各樣的搜索引擎也可以得知這些信息。
其實還有一些打印及CMS方面的參數(shù),這里就不以一一列舉了 四、關(guān)于JVM調(diào)優(yōu)的一些方面根據(jù)剛剛涉及的jvm的知識點(diǎn),我們可以嘗試對JVM進(jìn)行調(diào)優(yōu),主要就是堆內(nèi)存那塊 所有線程共享數(shù)據(jù)區(qū)大小=新生代大小 + 年老代大小 + 持久代大小。持久代一般固定大小為64m。所以java堆中增大年輕代后,將會減小年老代大小(因為老年代的清理是使用fullgc,所以老年代過小的話反而是會增多fullgc的)。此值對系統(tǒng)性能影響較大,Sun官方推薦配置為java堆的3/8。 4.1 調(diào)整最大堆內(nèi)存和最小堆內(nèi)存-Xmx –Xms:指定java堆最大值(默認(rèn)值是物理內(nèi)存的1/4(<1GB))和初始java堆最小值(默認(rèn)值是物理內(nèi)存的1/64(<1GB)) 默認(rèn)(MinHeapFreeRatio參數(shù)可以調(diào)整)空余堆內(nèi)存小于40%時,JVM就會增大堆直到-Xmx的最大限制.,默認(rèn)(MaxHeapFreeRatio參數(shù)可以調(diào)整)空余堆內(nèi)存大于70%時,JVM會減少堆直到 -Xms的最小限制。簡單點(diǎn)來說,你不停地往堆內(nèi)存里面丟數(shù)據(jù),等它剩余大小小于40%了,JVM就會動態(tài)申請內(nèi)存空間不過會小于-Xmx,如果剩余大小大于70%,又會動態(tài)縮小不過不會小于–Xms。就這么簡單 開發(fā)過程中,通常會將 -Xms 與 -Xmx兩個參數(shù)的配置相同的值,其目的是為了能夠在java垃圾回收機(jī)制清理完堆區(qū)后不需要重新分隔計算堆區(qū)的大小而浪費(fèi)資源。 我們執(zhí)行下面的代碼 System.out.println("Xmx=" + Runtime.getRuntime().maxMemory() / 1024.0 / 1024 + "M"); //系統(tǒng)的最大空間 System.out.println("free mem=" + Runtime.getRuntime().freeMemory() / 1024.0 / 1024 + "M"); //系統(tǒng)的空閑空間 System.out.println("total mem=" + Runtime.getRuntime().totalMemory() / 1024.0 / 1024 + "M"); //當(dāng)前可用的總空間 注意:此處設(shè)置的是Java堆大小,也就是新生代大小 + 老年代大小 設(shè)置一個VM options的參數(shù) -Xmx20m -Xms5m -XX:+PrintGCDetails 再次啟動main方法 這里GC彈出了一個Allocation Failure分配失敗,這個事情發(fā)生在PSYoungGen,也就是年輕代中 這時候申請到的內(nèi)存為18M,空閑內(nèi)存為4.214195251464844M 我們此時創(chuàng)建一個字節(jié)數(shù)組看看,執(zhí)行下面的代碼 byte[] b = new byte[1 * 1024 * 1024];System.out.println("分配了1M空間給數(shù)組"); System.out.println("Xmx=" + Runtime.getRuntime().maxMemory() / 1024.0 / 1024 + "M"); //系統(tǒng)的最大空間 System.out.println("free mem=" + Runtime.getRuntime().freeMemory() / 1024.0 / 1024 + "M"); //系統(tǒng)的空閑空間 System.out.println("total mem=" + Runtime.getRuntime().totalMemory() / 1024.0 / 1024 + "M"); 此時free memory就又縮水了,不過total memory是沒有變化的。Java會盡可能將total mem的值維持在最小堆內(nèi)存大小 byte[] b = new byte[10 * 1024 * 1024];System.out.println("分配了10M空間給數(shù)組"); System.out.println("Xmx=" + Runtime.getRuntime().maxMemory() / 1024.0 / 1024 + "M"); //系統(tǒng)的最大空間 System.out.println("free mem=" + Runtime.getRuntime().freeMemory() / 1024.0 / 1024 + "M"); //系統(tǒng)的空閑空間 System.out.println("total mem=" + Runtime.getRuntime().totalMemory() / 1024.0 / 1024 + "M"); //當(dāng)前可用的總空間 這時候我們創(chuàng)建了一個10M的字節(jié)數(shù)據(jù),這時候最小堆內(nèi)存是頂不住的。我們會發(fā)現(xiàn)現(xiàn)在的total memory已經(jīng)變成了15M,這就是已經(jīng)申請了一次內(nèi)存的結(jié)果。 此時我們再跑一下這個代碼 System.gc(); System.out.println("Xmx=" + Runtime.getRuntime().maxMemory() / 1024.0 / 1024 + "M"); //系統(tǒng)的最大空間 System.out.println("free mem=" + Runtime.getRuntime().freeMemory() / 1024.0 / 1024 + "M"); //系統(tǒng)的空閑空間 System.out.println("total mem=" + Runtime.getRuntime().totalMemory() / 1024.0 / 1024 + "M"); //當(dāng)前可用的總空間 此時我們手動執(zhí)行了一次fullgc,此時total memory的內(nèi)存空間又變回5.5M了,此時又是把申請的內(nèi)存釋放掉的結(jié)果。 4.2 調(diào)整新生代和老年代的比值-XX:NewRatio --- 新生代(eden+2*Survivor)和老年代(不包含永久區(qū))的比值 例如:-XX:NewRatio=4,表示新生代:老年代=1:4,即新生代占整個堆的1/5。在Xms=Xmx并且設(shè)置了Xmn的情況下,該參數(shù)不需要進(jìn)行設(shè)置。 4.3 調(diào)整Survivor區(qū)和Eden區(qū)的比值-XX:SurvivorRatio(幸存代)--- 設(shè)置兩個Survivor區(qū)和eden的比值 例如:8,表示兩個Survivor:eden=2:8,即一個Survivor占年輕代的1/10 4.4 設(shè)置年輕代和老年代的大小-XX:NewSize --- 設(shè)置年輕代大小 -XX:MaxNewSize --- 設(shè)置年輕代最大值 可以通過設(shè)置不同參數(shù)來測試不同的情況,反正最優(yōu)解當(dāng)然就是官方的Eden和Survivor的占比為8:1:1,然后在剛剛介紹這些參數(shù)的時候都已經(jīng)附帶了一些說明,感興趣的也可以看看。反正最大堆內(nèi)存和最小堆內(nèi)存如果數(shù)值不同會導(dǎo)致多次的gc,需要注意。 4.5 小總結(jié)根據(jù)實際事情調(diào)整新生代和幸存代的大小,官方推薦新生代占java堆的3/8,幸存代占新生代的1/10 在OOM時,記得Dump出堆,確??梢耘挪楝F(xiàn)場問題,通過下面命令你可以輸出一個.dump文件,這個文件可以使用VisualVM或者Java自帶的Java VisualVM工具。 -Xmx20m -Xms5m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=你要輸出的日志路徑 一般我們也可以通過編寫腳本的方式來讓OOM出現(xiàn)時給我們報個信,可以通過發(fā)送郵件或者重啟程序等來解決。 4.6 永久區(qū)的設(shè)置-XX:PermSize -XX:MaxPermSize 初始空間(默認(rèn)為物理內(nèi)存的1/64)和最大空間(默認(rèn)為物理內(nèi)存的1/4)。也就是說,jvm啟動時,永久區(qū)一開始就占用了PermSize大小的空間,如果空間還不夠,可以繼續(xù)擴(kuò)展,但是不能超過MaxPermSize,否則會OOM。 tips:如果堆空間沒有用完也拋出了OOM,有可能是永久區(qū)導(dǎo)致的。堆空間實際占用非常少,但是永久區(qū)溢出 一樣拋出OOM。 4.7 JVM的棧參數(shù)調(diào)優(yōu)4.7.1 調(diào)整每個線程??臻g的大小可以通過-Xss:調(diào)整每個線程棧空間的大小 JDK5.0以后每個線程堆棧大小為1M,以前每個線程堆棧大小為256K。在相同物理內(nèi)存下,減小這個值能生成更多的線程。但是操作系統(tǒng)對一個進(jìn)程內(nèi)的線程數(shù)還是有限制的,不能無限生成,經(jīng)驗值在3000~5000左右 4.7.2 設(shè)置線程棧的大小-XXThreadStackSize: 設(shè)置線程棧的大小(0 means use default stack size) 這些參數(shù)都是可以通過自己編寫程序去簡單測試的,這里礙于篇幅問題就不再提供demo了 4.8 (可以直接跳過了)JVM其他參數(shù)介紹形形色色的參數(shù)很多,就不會說把所有都扯個遍了,因為大家其實也不會說一定要去深究到底。 4.8.1 設(shè)置內(nèi)存頁的大小-XXThreadStackSize: 設(shè)置內(nèi)存頁的大小,不可設(shè)置過大,會影響Perm的大小復(fù)制代碼 4.8.2 設(shè)置原始類型的快速優(yōu)化-XX:+UseFastAccessorMethods: 設(shè)置原始類型的快速優(yōu)化 4.8.3 設(shè)置關(guān)閉手動GC-XX:+DisableExplicitGC: 設(shè)置關(guān)閉System.gc()(這個參數(shù)需要嚴(yán)格的測試) 4.8.4 設(shè)置垃圾最大年齡-XX:MaxTenuringThreshold 設(shè)置垃圾最大年齡。如果設(shè)置為0的話,則年輕代對象不經(jīng)過Survivor區(qū),直接進(jìn)入年老代. 對于年老代比較多的應(yīng)用,可以提高效率。如果將此值設(shè)置為一個較大值, 則年輕代對象會在Survivor區(qū)進(jìn)行多次復(fù)制,這樣可以增加對象再年輕代的存活時間, 增加在年輕代即被回收的概率。該參數(shù)只有在串行GC時才有效. 4.8.5 加快編譯速度-XX:+AggressiveOpts 加快編譯速度 4.8.6 改善鎖機(jī)制性能-XX:+UseBiasedLocking 4.8.7 禁用垃圾回收-Xnoclassgc 4.8.8 設(shè)置堆空間存活時間-XX:SoftRefLRUPolicyMSPerMB 設(shè)置每兆堆空閑空間中SoftReference的存活時間,默認(rèn)值是1s。 4.8.9 設(shè)置對象直接分配在老年代-XX:PretenureSizeThreshold 設(shè)置對象超過多大時直接在老年代分配,默認(rèn)值是0。 4.8.10 設(shè)置TLAB占eden區(qū)的比例-XX:TLABWasteTargetPercent 設(shè)置TLAB占eden區(qū)的百分比,默認(rèn)值是1% 。 4.8.11設(shè)置是否優(yōu)先YGC-XX:+CollectGen0First 設(shè)置FullGC時是否先YGC,默認(rèn)值是false。
|
|