??應(yīng)用運(yùn)行過程中是不希望出現(xiàn)長時(shí)間的GC停頓的，因?yàn)檫@會影響服務(wù)的可用性，導(dǎo)致用戶體驗(yàn)變差，甚至?xí)?yán)重?fù)p害一些關(guān)鍵的應(yīng)用程序。本文將會列出可能導(dǎo)致GC停頓時(shí)間長的一些原因和解決方案。

對象創(chuàng)建的速度過高

??如果應(yīng)用創(chuàng)建對象的速度非常高，隨之而來的就是GC頻率也會變快，然后會導(dǎo)致GC的停頓時(shí)間變長。所以說，優(yōu)化代碼以降低對象的創(chuàng)建速率是降低GC停頓時(shí)間最有效的方法。可以使用JProfiler, YourKit, JVisualVM這樣的性能監(jiān)控工具來幫助優(yōu)化對象的創(chuàng)建速度，這些工具會分析出：應(yīng)用到底創(chuàng)建了哪些對象？對象創(chuàng)建的速度是多少？這些對象占用了多少內(nèi)存空間？是誰創(chuàng)建的這些對象？

Young區(qū)過小

??如果Young過小，對象就會過早的晉升到Old區(qū)，Old區(qū)的垃圾回收一般比Young區(qū)會花費(fèi)更多的時(shí)間，因此，可以通過增大Young區(qū)來有效的降低長時(shí)間GC停頓。可以用下面兩個(gè)JVM參數(shù)來設(shè)置Young區(qū)的大小：

-Xmn: 設(shè)置Young區(qū)所占的字節(jié)數(shù) -XX:NewRatio: 設(shè)置Old區(qū)和Young區(qū)的比例， 比如說，-XX:NewRatio=3也就是說Old區(qū)和Young區(qū)的比例是3:1， Young區(qū)占整個(gè)堆的1/4，如果堆是2G，那么Young區(qū)就是0.5G。

選擇合適的GC算法

??GC算法是影響GC停頓時(shí)間的一個(gè)非常重要的因素。選擇使用G1收集器，因?yàn)镚1是自動調(diào)優(yōu)的，只需要設(shè)置一個(gè)停頓時(shí)間的目標(biāo)就可以了，比如： -XX:MaxGCPauseMillis=200。這個(gè)例子設(shè)置了最大停頓時(shí)間的目標(biāo)是200ms，JVM會盡最大努力來滿足這個(gè)目標(biāo)。

進(jìn)程被交換（Swap）出內(nèi)存

??有時(shí)候由于系統(tǒng)內(nèi)存不足，操作系統(tǒng)會把應(yīng)用從內(nèi)存中交換出去。Swap是非常耗時(shí)的，因?yàn)樾枰L問磁盤，相對于訪問物理內(nèi)存來說要慢得多的多。生產(chǎn)環(huán)境下的應(yīng)用是不應(yīng)該被Swap出內(nèi)存的。當(dāng)發(fā)生進(jìn)程Swap的時(shí)候，GC停頓時(shí)間也會變長。如果應(yīng)用被Swap了，你需要：
a:給機(jī)器增加內(nèi)存
b:減少機(jī)器上運(yùn)行的進(jìn)程數(shù)，以釋放更多的內(nèi)存
c:減少應(yīng)用分配的內(nèi)存（不推薦，可能會引起其他問題）

GC線程數(shù)過少

GC日志中的每一個(gè)GC事件都會打印user、sys、real time，比如：

[Times: user=25.56 sys=0.35, real=20.48 secs]

如果GC日志中，real time并不是明顯比user time小，這就說明GC線程數(shù)是不夠的，這就需要增加GC線程了。假如說，user time是25秒，GC線程數(shù)是5，那么real time大概是5左右才是正常的（25/5=5）。注意：GC線程過多會占用大量的系統(tǒng)CPU，從而會影響應(yīng)用能使用的CPU資源。

IO負(fù)載重

??如果系統(tǒng)的IO負(fù)載很重（大量的文件讀寫）也會導(dǎo)致GC停頓時(shí)間過長。這些IO讀寫不一定是應(yīng)用引起的，可能是機(jī)器上其他的進(jìn)程導(dǎo)致的，但是這仍然會導(dǎo)致應(yīng)用的停頓時(shí)間變長。當(dāng)IO負(fù)載很重的時(shí)候，real time會明顯比user time長，比如：

[Times: user=0.20 sys=0.01, real=18.45 secs]

如果發(fā)生了這種情況，可以這么辦：
a:如果是應(yīng)用導(dǎo)致的，優(yōu)化代碼
b:如果是別的進(jìn)程導(dǎo)致的，把它殺掉或者遷走
c:把應(yīng)用遷到一個(gè)IO負(fù)載小的機(jī)器上
tip：如何來監(jiān)控IO負(fù)載？在linux上可以用sar命令來監(jiān)控IO的負(fù)載：sar -d -p 1，這個(gè)命令每隔一秒會打印一次每秒的讀寫數(shù)量。

顯式調(diào)用了System.gc()

??當(dāng)調(diào)用了System.gc()或者是Runtime.getRuntime().gc()以后，就會導(dǎo)致FullGC。FullGC的過程當(dāng)中，整個(gè)JVM是暫停的（所有的應(yīng)用都被暫停掉）。System.gc()可能是以下幾種情況產(chǎn)生的：
a:應(yīng)用的程序員手動調(diào)用了System.gc()
b:應(yīng)用引用的三方庫或者框架甚至是應(yīng)用服務(wù)器可能調(diào)用了System.gc()
c:可能是由外部使用了JMX的工具觸發(fā)
d:如果應(yīng)用使用了RMI，RMI會每隔一段時(shí)間調(diào)用一次System.gc()，這個(gè)時(shí)間間隔是可以設(shè)置的：
– Dsun.rmi.dgc.server.gcInterval=n
– Dsun.rmi.dgc.client.gcInterval=n

什么情況下，會手動調(diào)用System.gc()

??一般來說，在編寫Java代碼并將其留給JVM時(shí)，不要考慮內(nèi)存管理。在一些特殊情況下，如正在編寫一個(gè)性能基準(zhǔn)，可以在運(yùn)行之間調(diào)用System.gc()。??MappedByteBuffer用于需要最佳IO性能的地方。MappedByteBuffer提供到底層文件的直接內(nèi)存映射。內(nèi)存映射文件的許多細(xì)節(jié)固有地依賴于底層操作系統(tǒng)，因此是未指定的。當(dāng)請求的區(qū)域未完全包含在該通道的文件中時(shí)，此方法的行為是未指定的。對該程序或另一個(gè)的底層文件的內(nèi)容或大小進(jìn)行的更改是否被傳播到緩沖區(qū)是未指定的。沒有指定將緩沖區(qū)的更改傳播到文件的速率。
??因?yàn)镸appedByteBuffer依賴于操作系統(tǒng)，垃圾收集器不能立即回收。但是當(dāng)調(diào)用System.gc()垃圾收集器釋放句柄，可以刪除該文件。在使用MappedByteBuffer的同時(shí)，如果我們正在使用內(nèi)存敏感程序，那么最好調(diào)用System.gc()。

堆內(nèi)存過大

??堆內(nèi)存過大也會導(dǎo)致GC停頓時(shí)間過長，如果堆內(nèi)存過大，那么堆中就會累計(jì)過多的垃圾，當(dāng)發(fā)生FullGC要回收所有的垃圾的時(shí)候，就會花費(fèi)更多的時(shí)間。如果你的JVM的堆內(nèi)存有18G，可以考慮分成3個(gè)6G的JVM實(shí)例，堆內(nèi)存小會降低GC的停頓時(shí)間。

GC任務(wù)分配不均

??就算有多個(gè)GC線程，線程之間的任務(wù)分配可能也不是均衡的，這個(gè)可能有很多種原因：
a:掃描大的線性的數(shù)據(jù)結(jié)構(gòu)目前是無法并行的。
b:有些GC事件只發(fā)生在單個(gè)線程上，比如CMS中的‘concurrent mode failure’。如果你碰巧使用的CMS，可以使用-XX:+CMSScavengeBeforeRemark 這個(gè)參數(shù)，它可以讓多個(gè)GC線程之間任務(wù)分配的更平均。

總結(jié)

以上是生活随笔為你收集整理的GC时间过长优化方法的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。