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