在看內存管理術語表的時候偶然發(fā)現(xiàn)了”Pig in the Python（注：有點像中文里的貪心不足蛇吞象）”的定義，于是便有了這篇文章。表面上看，這個術語說的是GC不停地將大對象從一個分代提升到另一個分代的情景。這么做就好比巨蟒整個吞食掉它的獵物，以至于它在消化的時候都沒辦法移動了。

在接下來的這24個小時里我的頭腦中充斥著這個令人窒息的巨蟒的畫面，揮之不去。正如精神病醫(yī)生所說的，消除恐懼最好的方法就是說出來。于是便有了這篇文章。不過接下的故事我們要講的不是蟒蛇，而是GC的調優(yōu)。我對天發(fā)誓。

大家都知道GC暫停很容易造成性能瓶頸。現(xiàn)代JVM在發(fā)布的時候都自帶了高級的垃圾回收器，不過從我的使用經驗來看，要找出某個應用最優(yōu)的配置真是難上加難。手動調優(yōu)或許仍有一線希望，但是你得了解GC算法的確切機制才行。關于這點，本文倒是會對你有所幫助，下面我會通過一個例子來講解JVM配置的一個小的改動是如何影響到你的應用程序的吞吐量的。

示例

我們用來演示GC對吞吐量產生影響的應用只是一個簡單的程序。它包含兩個線程：

PigEater – 它會模仿巨蟒不停吞食大肥豬的過程。代碼是通過往java.util.List中添加 32MB字節(jié)來實現(xiàn)這點的，每次吞食完后會睡眠100ms。
PigDigester – 它模擬異步消化的過程。實現(xiàn)消化的代碼只是將豬的列表置為空。由于這是個很累的過程，因此每次清除完引用后這個線程都會睡眠2000ms。
兩個線程都會在一個while循環(huán)中運行，不停地吃了消化直到蛇吃飽為止。這大概得吃掉5000頭豬。

現(xiàn)在我們將這個系統(tǒng)的吞吐量定義為“每秒可以消化的豬的頭數(shù)”。考慮到每100ms就會有豬被塞到這條蟒蛇里，我們可以看到這個系統(tǒng)理論上的最大吞吐量可以達到10頭/秒。

GC配置示例

我們來看下使用兩個不同的配置系統(tǒng)的表現(xiàn)分別是什么樣的。不管是哪個配置，應用都運行在一臺擁有雙核，8GB內存的Mac（OS X10.9.3）上。

第一個配置：

1.4G的堆（-Xms4g -Xmx4g）
2.使用CMS來清理老年代（-XX:+UseConcMarkSweepGC）使用并行回收器清理新生代（-XX:+UseParNewGC）
3.將堆的12.5%（-Xmn512m）分配給新生代，并將Eden區(qū)和Survivor區(qū)的大小限制為一樣的。
第二個配置則略有不同：

1.2G的堆（-Xms2g -Xms2g）
2.新生代和老年代都使用Parellel GC(-XX:+UseParallelGC)
3.將堆的75%分配給新生代（-Xmn 1536m）
4.現(xiàn)在是該下注的時候了，哪個配置的表現(xiàn)會更好一些(就是每秒能吃多少豬，還記得吧)？那些把籌碼放到第一個配置上的家伙，你們一定會失望的。結果正好相反：

1.第一個配置（大堆，大的老年代，CMS GC）每秒能吞食8.2頭豬
2.第二個配置（小堆，大的新生代，Parellel GC）每秒可以吞食9.2頭豬

現(xiàn)在我們來客觀地看待一下這個結果。分配的資源少了2倍但吞吐量提升了12%。這和常識正好相反，因此有必要進一步分析下到底發(fā)生了什么。

分析GC的結果

原因其實并不復雜，你只要仔細看一下運行測試的時候GC在干什么就能發(fā)現(xiàn)答案了。這個你可以自己選擇要使用的工具。在jstat的幫助下我發(fā)現(xiàn)了背后的秘密，命令大概是這樣的：

通過分析數(shù)據(jù)，我注意到配置1經歷了1129次GC周期（YGCT_FGCT），總共花了63.723秒：

第二個配置一共暫停了168次（YGCT+FGCT），只花了11.409秒。

考慮到兩種情況下的工作量是等同的，因此——在這個吃豬的實驗中當GC沒有發(fā)現(xiàn)長期存活的對象時，它能更快地清理掉垃圾對象。而采用第一個配置的話，GC運行的頻率大概會是6到7倍之多，而總的暫停時間則是5至6倍。

說這個故事有兩個目的。第一個也是最主要的一個，我希望把這條抽風的蟒蛇趕緊從我的腦海里趕出去。另一個更明顯的收獲就是——GC調優(yōu)是個很需要技巧的經驗活，它需要你對底層的這些概念了如指掌。盡管本文中用到的這個只是很平常的一個應用，但選擇的不同結果也會對你的吞吐量和容量規(guī)劃產生很大的影響。在現(xiàn)實生活中的應用里面，這里的區(qū)別則會更為巨大。因此，就看你如何抉擇了，你可以去掌握這些概念，或者，只關注你日常的工作就好了，讓Plumbr來找出你所需要的最合適的GC配置吧。

最新評論