這幾天測(cè)試一個(gè)引擎的性能，用一個(gè)單表查詢的case，測(cè)試出來(lái)的結(jié)果是210tps，cpu也正常，在85%左右，也沒(méi)懷疑。
后面再重新測(cè)試的時(shí)候，加上了gc log，用gc分析工具分析了一下gc的吞吐量，發(fā)現(xiàn)吞吐量奇低，竟然只有77%左右，很是奇怪，看了一下gc日志，所有都是global gc， 懷疑gc策略有問(wèn)題，查了一下資料，參考了下面一篇文章：
http://www.ibm.com/developerworks/cn/java/j-ibmjava2/
缺省gc策略是針對(duì)吞吐量進(jìn)行優(yōu)化：-Xgcpolicy:optthruput ，對(duì)于吞吐量比短暫的 GC 停頓更重要的應(yīng)用程序，通常使用這種策略。每當(dāng)進(jìn)行垃圾收集時(shí)，應(yīng)用程序都會(huì)停頓。
我摘下面一段其他幾個(gè)gc策略：
切換到其他 GC 策略的原因
切換到
原因
optavgpause
- 我的應(yīng)用程序無(wú)法忍受那么長(zhǎng)的 GC 停頓時(shí)間。如果 GC 停頓時(shí)間能夠減少的話，性能降低一些也可以接受。
- 我的應(yīng)用程序正在一個(gè) 64 位平臺(tái)上運(yùn)行并使用非常大的堆 —— 超過(guò) 3 或 4GB。
- 我的應(yīng)用程序是一個(gè) GUI 應(yīng)用程序，我很關(guān)注用戶響應(yīng)時(shí)間。
gencon
- 我的應(yīng)用程序分配了許多短期存活的對(duì)象。
- 堆空間出現(xiàn)碎片化。
- 我的應(yīng)用程序是基于事務(wù)的（也就是說(shuō)，在事務(wù)提交之后，事務(wù)中的對(duì)象就不再存活了）。
subpool
- 在大型多處理器計(jì)算機(jī)上，我遇到了可伸縮性問(wèn)題。
試了一下gencon策略，hoho，好家伙，測(cè)試case的吞吐量竟然提升到290tps（直接提升40%），太夸張了，gc吞吐量也提升到了98%，記得以前1.4的時(shí)候沒(méi)有分代的gc策略，而且印象中，ibm jdk不分代，估計(jì)是引入分代機(jī)制之后，缺省的optthruput策略變得復(fù)雜起來(lái)，不像以前那樣效率高了。
這里也給大家提個(gè)醒，當(dāng)心ibm jdk 1.5的gc策略，發(fā)現(xiàn)gc效率很低的時(shí)候切換到gencon，也許會(huì)有很大的驚喜！