這篇文章主要介紹“如何掌握J(rèn)AVA性能調(diào)優(yōu)和jvm垃圾回收”，在日常操作中，相信很多人在如何掌握J(rèn)AVA性能調(diào)優(yōu)和jvm垃圾回收問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”如何掌握J(rèn)AVA性能調(diào)優(yōu)和jvm垃圾回收”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

彭州網(wǎng)站建設(shè)公司成都創(chuàng)新互聯(lián),彭州網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為彭州上千余家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站建設(shè)要多少錢，請找那個售后服務(wù)好的彭州做網(wǎng)站的公司定做！

前言

JVM 是一個虛擬化的操作系統(tǒng)，類似于 Linux 和 Window，只是他被架構(gòu)在了操作系統(tǒng)上進(jìn)行接收 class 文件并把 class 翻譯成系統(tǒng)識別的機(jī)器碼進(jìn)行執(zhí)行，即 JVM 為我們屏蔽了不同操作系統(tǒng)在底層硬件和操作指令的不同。

因此，JVM 最重要的作用浮出水面，即跨平臺性。由于 JVM 為 java 程序屏蔽了操作系統(tǒng)底層的細(xì)節(jié)，Java 只需要關(guān)心如何編譯，如何讓加載進(jìn) JVM 即可。

由于 JVM 接收的是 Class 文件，而不是接收特定的語言，因此只要某種語言可以編譯成 Class 文件，就可以在 JVM 上運(yùn)行，這些語言有 Groovy、Kotlin、Scala 等等。因此 JVM 的另一個重要特性就是語言無關(guān)性，即跨語言。

一、JVM內(nèi)存模型及垃圾收集算法

1.根據(jù)Java虛擬機(jī)規(guī)范，JVM將內(nèi)存劃分為：

New（年輕代）

Tenured（年老代）

永久代（Perm）

其中New和Tenured屬于堆內(nèi)存，堆內(nèi)存會從JVM啟動參數(shù)（-Xmx:3G）指定的內(nèi)存中分配，Perm不屬于堆內(nèi)存，有虛擬機(jī)直接分配，但可以通過 -XX:PermSize -XX:MaxPermSize 等參數(shù)調(diào)整其大小。

年輕代（New）：年輕代用來存放JVM剛分配的Java對象

年老代（Tenured)：年輕代中經(jīng)過垃圾回收沒有回收掉的對象將被Copy到年老代

永久代（Perm）：永久代存放Class、Method元信息，其大小跟項(xiàng)目的規(guī)模、類、方法的量有關(guān)，一般設(shè)置為128M就足夠，設(shè)置原則是預(yù)留30%的空間。

New又分為幾個部分：

Eden：Eden用來存放JVM剛分配的對象

Survivor1

Survivro2：兩個Survivor空間一樣大，當(dāng)Eden中的對象經(jīng)過垃圾回收沒有被回收掉時，會在兩個Survivor之間來回Copy，當(dāng)滿足某個條件，比如Copy次數(shù)，就會被Copy到Tenured。顯然，Survivor只是增加了對象在年輕代中的逗留時間，增加了被垃圾回收的可能性。

2.垃圾回收算法

垃圾回收算法可以分為三類，都基于標(biāo)記-清除（復(fù)制）算法：

Serial算法（單線程）

并行算法

并發(fā)算法

JVM會根據(jù)機(jī)器的硬件配置對每個內(nèi)存代選擇適合的回收算法，比如，如果機(jī)器多于1個核，會對年輕代選擇并行算法，關(guān)于選擇細(xì)節(jié)請參考JVM調(diào)優(yōu)文檔。

稍微解釋下的是，并行算法是用多線程進(jìn)行垃圾回收，回收期間會暫停程序的執(zhí)行，而并發(fā)算法，也是多線程回收，但期間不停止應(yīng)用執(zhí)行。所以，并發(fā)算法適用于交互性高的一些程序。經(jīng)過觀察，并發(fā)算法會減少年輕代的大小，其實(shí)就是使用了一個大的年老代，這反過來跟并行算法相比吞吐量相對較低。

垃圾回收動作何時執(zhí)行？

還有一個問題是，垃圾回收動作何時執(zhí)行？

當(dāng)年輕代內(nèi)存滿時，會引發(fā)一次普通GC，該GC僅回收年輕代。需要強(qiáng)調(diào)的時，年輕代滿是指Eden代滿，Survivor滿不會引發(fā)GC

當(dāng)年老代滿時會引發(fā)Full GC，F(xiàn)ull GC將會同時回收年輕代、年老代

當(dāng)永久代滿時也會引發(fā)Full GC，會導(dǎo)致Class、Method元信息的卸載

另一個問題是，何時會拋出OutOfMemoryException，并不是內(nèi)存被耗空的時候才拋出

JVM98%的時間都花費(fèi)在內(nèi)存回收

每次回收的內(nèi)存小于2%

滿足這兩個條件將觸發(fā)OutOfMemoryException，這將會留給系統(tǒng)一個微小的間隙以做一些Down之前的操作，比如手動打印Heap Dump。

二、內(nèi)存泄漏及解決方法

1.系統(tǒng)崩潰前的一些現(xiàn)象：

每次垃圾回收的時間越來越長，由之前的10ms延長到50ms左右，F(xiàn)ullGC的時間也有之前的0.5s延長到4、5s

FullGC的次數(shù)越來越多，最頻繁時隔不到1分鐘就進(jìn)行一次FullGC

年老代的內(nèi)存越來越大并且每次FullGC后年老代沒有內(nèi)存被釋放

之后系統(tǒng)會無法響應(yīng)新的請求，逐漸到達(dá)OutOfMemoryError的臨界值。

2.生成堆的dump文件

通過JMX的MBean生成當(dāng)前的Heap信息，大小為一個3G（整個堆的大?。┑膆prof文件，如果沒有啟動JMX可以通過Java的jmap命令來生成該文件。

3.分析dump文件

下面要考慮的是如何打開這個3G的堆信息文件，顯然一般的Window系統(tǒng)沒有這么大的內(nèi)存，必須借助高配置的Linux。當(dāng)然我們可以借助X-Window把Linux上的圖形導(dǎo)入到Window。我們考慮用下面幾種工具打開該文件：

Visual VM

IBM HeapAnalyzer

JDK 自帶的Hprof工具

使用這些工具時為了確保加載速度，建議設(shè)置最大內(nèi)存為6G。使用后發(fā)現(xiàn)，這些工具都無法直觀地觀察到內(nèi)存泄漏，Visual VM雖能觀察到對象大小，但看不到調(diào)用堆棧；HeapAnalyzer雖然能看到調(diào)用堆棧，卻無法正確打開一個3G的文件。因此，我們又選用了Eclipse專門的靜態(tài)內(nèi)存分析工具：Mat。

4.分析內(nèi)存泄漏

通過Mat我們能清楚地看到，哪些對象被懷疑為內(nèi)存泄漏，哪些對象占的空間最大及對象的調(diào)用關(guān)系。針對本案，在ThreadLocal中有很多的JbpmContext實(shí)例，經(jīng)過調(diào)查是JBPM的Context沒有關(guān)閉所致。

另，通過Mat或JMX我們還可以分析線程狀態(tài)，可以觀察到線程被阻塞在哪個對象上，從而判斷系統(tǒng)的瓶頸。

5.回歸問題

Q：為什么崩潰前垃圾回收的時間越來越長？

A:根據(jù)內(nèi)存模型和垃圾回收算法，垃圾回收分兩部分：內(nèi)存標(biāo)記、清除（復(fù)制），標(biāo)記部分只要內(nèi)存大小固定時間是不變的，變的是復(fù)制部分，因?yàn)槊看卫厥斩加幸恍┗厥詹坏舻膬?nèi)存，所以增加了復(fù)制量，導(dǎo)致時間延長。所以，垃圾回收的時間也可以作為判斷內(nèi)存泄漏的依據(jù)

Q：為什么Full GC的次數(shù)越來越多？

A：因此內(nèi)存的積累，逐漸耗盡了年老代的內(nèi)存，導(dǎo)致新對象分配沒有更多的空間，從而導(dǎo)致頻繁的垃圾回收

Q:為什么年老代占用的內(nèi)存越來越大？

A:因?yàn)槟贻p代的內(nèi)存無法被回收，越來越多地被Copy到年老代

三、性能調(diào)優(yōu)

除了上述內(nèi)存泄漏外，我們還發(fā)現(xiàn)CPU長期不足3%，系統(tǒng)吞吐量不夠，針對8core×16G、64bit的Linux服務(wù)器來說，是嚴(yán)重的資源浪費(fèi)。

在CPU負(fù)載不足的同時，偶爾會有用戶反映請求的時間過長，我們意識到必須對程序及JVM進(jìn)行調(diào)優(yōu)。從以下幾個方面進(jìn)行：

線程池：解決用戶響應(yīng)時間長的問題

連接池

JVM啟動參數(shù)：調(diào)整各代的內(nèi)存比例和垃圾回收算法，提高吞吐量

程序算法：改進(jìn)程序邏輯算法提高性能

1.Java線程池（java.util.concurrent.ThreadPoolExecutor）

大多數(shù)JVM6上的應(yīng)用采用的線程池都是JDK自帶的線程池，之所以把成熟的Java線程池進(jìn)行羅嗦說明，是因?yàn)樵摼€程池的行為與我們想象的有點(diǎn)出入。Java線程池有幾個重要的配置參數(shù)：

corePoolSize：核心線程數(shù)（最新線程數(shù)）

maximumPoolSize：最大線程數(shù)，超過這個數(shù)量的任務(wù)會被拒絕，用戶可以通過RejectedExecutionHandler接口自定義處理方式

keepAliveTime：線程保持活動的時間

workQueue：工作隊(duì)列，存放執(zhí)行的任務(wù)

Java線程池需要傳入一個Queue參數(shù)（workQueue）用來存放執(zhí)行的任務(wù)，而對Queue的不同選擇，線程池有完全不同的行為：

SynchronousQueue：一個無容量的等待隊(duì)列，一個線程的insert操作必須等待另一線程的remove操作，采用這個Queue線程池將會為每個任務(wù)分配一個新線程

LinkedBlockingQueue ：無界隊(duì)列，采用該Queue，線程池將忽略maximumPoolSize參數(shù)，僅用corePoolSize的線程處理所有的任務(wù)，未處理的任務(wù)便在LinkedBlockingQueue中排隊(duì)

ArrayBlockingQueue： 有界隊(duì)列，在有界隊(duì)列和maximumPoolSize的作用下，程序?qū)⒑茈y被調(diào)優(yōu)：更大的Queue和小的maximumPoolSize將導(dǎo)致CPU的低負(fù)載；小的Queue和大的池，Queue就沒起動應(yīng)有的作用。

其實(shí)我們的要求很簡單，希望線程池能跟連接池一樣，能設(shè)置最小線程數(shù)、最大線程數(shù)，當(dāng)最小數(shù)<任務(wù)<最大數(shù)時，應(yīng)該分配新的線程處理；當(dāng)任務(wù)>最大數(shù)時，應(yīng)該等待有空閑線程再處理該任務(wù)。

線程池的設(shè)計(jì)思路

但線程池的設(shè)計(jì)思路是，任務(wù)應(yīng)該放到Queue中，當(dāng)Queue放不下時再考慮用新線程處理，如果Queue滿且無法派生新線程，就拒絕該任務(wù)。設(shè)計(jì)導(dǎo)致“先放等執(zhí)行”、“放不下再執(zhí)行”、“拒絕不等待”。所以，根據(jù)不同的Queue參數(shù)，要提高吞吐量不能一味地增大maximumPoolSize。

當(dāng)然，要達(dá)到我們的目標(biāo)，必須對線程池進(jìn)行一定的封裝，幸運(yùn)的是ThreadPoolExecutor中留了足夠的自定義接口以幫助我們達(dá)到目標(biāo)。我們封裝的方式是：

以SynchronousQueue作為參數(shù)，使maximumPoolSize發(fā)揮作用，以防止線程被無限制的分配，同時可以通過提高maximumPoolSize來提高系統(tǒng)吞吐量

自定義一個RejectedExecutionHandler，當(dāng)線程數(shù)超過maximumPoolSize時進(jìn)行處理，處理方式為隔一段時間檢查線程池是否可以執(zhí)行新Task，如果可以把拒絕的Task重新放入到線程池，檢查的時間依賴keepAliveTime的大小。

2.連接池（org.apache.commons.dbcp.BasicDataSource）

在使用org.apache.commons.dbcp.BasicDataSource的時候，因?yàn)橹安捎昧四J(rèn)配置，所以當(dāng)訪問量大時，通過JMX觀察到很多Tomcat線程都阻塞在BasicDataSource使用的Apache ObjectPool的鎖上，直接原因當(dāng)時是因?yàn)锽asicDataSource連接池的最大連接數(shù)設(shè)置的太小，默認(rèn)的BasicDataSource配置，僅使用8個最大連接。

我還觀察到一個問題，當(dāng)較長的時間不訪問系統(tǒng)，比如2天，DB上的MySQL會斷掉所以的連接，導(dǎo)致連接池中緩存的連接不能用。為了解決這些問題，我們充分研究了BasicDataSource，發(fā)現(xiàn)了一些優(yōu)化的點(diǎn)：

Mysql默認(rèn)支持100個鏈接，所以每個連接池的配置要根據(jù)集群中的機(jī)器數(shù)進(jìn)行，如有2臺服務(wù)器，可每個設(shè)置為60

initialSize：參數(shù)是一直打開的連接數(shù)

minEvictableIdleTimeMillis：該參數(shù)設(shè)置每個連接的空閑時間，超過這個時間連接將被關(guān)閉

timeBetweenEvictionRunsMillis：后臺線程的運(yùn)行周期，用來檢測過期連接

maxActive：最大能分配的連接數(shù)

maxIdle：最大空閑數(shù)，當(dāng)連接使用完畢后發(fā)現(xiàn)連接數(shù)大于maxIdle，連接將被直接關(guān)閉。只有initialSize < x < maxIdle的連接將被定期檢測是否超期。這個參數(shù)主要用來在峰值訪問時提高吞吐量。

initialSize是如何保持的？

initialSize是如何保持的？經(jīng)過研究代碼發(fā)現(xiàn)，BasicDataSource會關(guān)閉所有超期的連接，然后再打開initialSize數(shù)量的連接，這個特性與minEvictableIdleTimeMillis、timeBetweenEvictionRunsMillis一起保證了所有超期的initialSize連接都會被重新連接，從而避免了Mysql長時間無動作會斷掉連接的問題。

3.JVM參數(shù)

在JVM啟動參數(shù)中，可以設(shè)置跟內(nèi)存、垃圾回收相關(guān)的一些參數(shù)設(shè)置，默認(rèn)情況不做任何設(shè)置JVM會工作的很好，但對一些配置很好的Server和具體的應(yīng)用必須仔細(xì)調(diào)優(yōu)才能獲得最佳性能。通過設(shè)置我們希望達(dá)到一些目標(biāo)：

GC的時間足夠的小

GC的次數(shù)足夠的少

發(fā)生Full GC的周期足夠的長

前兩個目前是相悖的，要想GC時間小必須要一個更小的堆，要保證GC次數(shù)足夠少，必須保證一個更大的堆，我們只能取其平衡。

（1）針對JVM堆的設(shè)置一般，可以通過-Xms -Xmx限定其最小、最大值，為了防止垃圾收集器在最小、最大之間收縮堆而產(chǎn)生額外的時間，我們通常把最大、最小設(shè)置為相同的值

（2）年輕代和年老代將根據(jù)默認(rèn)的比例（1：2）分配堆內(nèi)存，可以通過調(diào)整二者之間的比率NewRadio來調(diào)整二者之間的大小，也可以針對回收代，比如年輕代，通過 -XX:newSize -XX:MaxNewSize來設(shè)置其絕對大小。同樣，為了防止年輕代的堆收縮，我們通常會把-XX:newSize -XX:MaxNewSize設(shè)置為同樣大小

（3）年輕代和年老代設(shè)置多大才算合理？這個我問題毫無疑問是沒有答案的，否則也就不會有調(diào)優(yōu)。我們觀察一下二者大小變化有哪些影響

更大的年輕代必然導(dǎo)致更小的年老代，大的年輕代會延長普通GC的周期，但會增加每次GC的時間；小的年老代會導(dǎo)致更頻繁的Full GC

更小的年輕代必然導(dǎo)致更大年老代，小的年輕代會導(dǎo)致普通GC很頻繁，但每次的GC時間會更短；大的年老代會減少Full GC的頻率

如何選擇應(yīng)該依賴應(yīng)用程序?qū)ο笊芷诘姆植记闆r：如果應(yīng)用存在大量的臨時對象，應(yīng)該選擇更大的年輕代；如果存在相對較多的持久對象，年老代應(yīng)該適當(dāng)增大。但很多應(yīng)用都沒有這樣明顯的特性，在抉擇時應(yīng)該根據(jù)以下兩點(diǎn)：（A）本著Full GC盡量少的原則，讓年老代盡量緩存常用對象，JVM的默認(rèn)比例1：2也是這個道理 （B）通過觀察應(yīng)用一段時間，看其他在峰值時年老代會占多少內(nèi)存，在不影響Full GC的前提下，根據(jù)實(shí)際情況加大年輕代，比如可以把比例控制在1：1。但應(yīng)該給年老代至少預(yù)留1/3的增長空間

（4）在配置較好的機(jī)器上（比如多核、大內(nèi)存），可以為年老代選擇并行收集算法： -

XX:+UseParallelOldGC，默認(rèn)為Serial收集 復(fù)制代碼

（5）線程堆棧的設(shè)置：每個線程默認(rèn)會開啟1M的堆棧，用于存放棧幀、調(diào)用參數(shù)、局部變量等，對大多數(shù)應(yīng)用而言這個默認(rèn)值太了，一般256K就足用。理論上，在內(nèi)存不變的情況下，減少每個線程的堆棧，可以產(chǎn)生更多的線程，但這實(shí)際上還受限于操作系統(tǒng)。

（4）可以通過下面的參數(shù)打Heap Dump信息

-XX:HeapDumpPath-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-Xloggc:/usr/aaa/dump/heap_trace.txt 復(fù)制代碼

通過下面參數(shù)可以控制OutOfMemoryError時打印堆的信息

-XX:+HeapDumpOnOutOfMemoryError 復(fù)制代碼

請看一下一個時間的Java參數(shù)配置：（服務(wù)器：Linux 64Bit，8Core×16G）

JAVA_OPTS="$JAVA_OPTS -server -Xms3G -Xmx3G -Xss256k -XX:PermSize=128m -XX:MaxPermSize=128m -XX:+UseParallelOldGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/aaa/dump -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/usr/aaa/dump/heap_trace.txt -XX:NewSize=1G -XX:MaxNewSize=1G" 復(fù)制代碼

經(jīng)過觀察該配置非常穩(wěn)定，每次普通GC的時間在10ms左右，F(xiàn)ull GC基本不發(fā)生，或隔很長很長的時間才發(fā)生一次

到此，關(guān)于“如何掌握J(rèn)AVA性能調(diào)優(yōu)和jvm垃圾回收”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！