以下凭记忆进行描述，可能在细节处有些混淆，但不影响整体的策略讨论。关于JVM的GC细节，可以参看sun和ibm的相关文档。
应用服务器层面的调优，涉及比较多的选项，但常见的一般只针对JVM、线程池、数据库连接池、session等项目进行调整。
JVM调优，一般的系统最经常调整的项目如heap、gc策略，下面主要针对IBM的jvm(jdk5)进行说明：
这里最先想到的就是最小(-Xms)、最大堆(-Xmx)的设置。这里容易有个误解，即将最小值和最大值设置成一样大，其实这取决于GC的策略。对于SUN的hotspotjvm,由于其默认的GC策略为分代策略(采取复制、覆盖的分段回收策略），即按对象生存周期的长短分为新生代、老年代、永久代等，新建对象进入新生代，新生代满后进行清理（新生代分为两个区，一个作为存储区，一个作为垃圾区，通过两个区作用轮换的方式进行GC），躲过新生代清理的对象进入老年代。永久代用来存储类等不会被回收的对象。对于这种采取分代回收的GC策略，建议最小值和最大值设置成一样，这样可以避免堆的伸缩造成的开销，同时由于采取的是整个段的copy、回收策略，不会有碎片产生。
而对于IBM的JVM，其默认的GC策略并不是如上所述的分代策略，而是标记(mark)、扫描(scan)、碎片合并(compact)的策略：即先标记存活的对象，然后扫描清除所有未标记的对象，当分配失败时（比如无法回收足够的空闲空间），如果还有可扩展heap（比如未达到最大heap值），则进行堆扩展(heapextension),否则对heap的空闲碎片进行合并(compact).由于这些长存对象以后被回收的机会很少,所以每次扩展前,长存的对象被调整到堆的底部,这样JVM就不需要频繁对这部分heap空间进行处理。
可想而知，这种情况下，如果将最小、最大值设置成一样大，将产生大量的heap碎片，而对碎片进行compact开销是很大的，这样GC的性能会很差。建议先预估一个比较小（比如最小值的一半）的最小值，压力测试一段时间后，分析GC日志（-verbose:gc），几次调整后得出比较合理的最小值。当然即使在同一个应用里，各个时段的应用场景、压力也会有差别，不可能有绝对精确的值，一般大概有个意思就行。
IBMJVM默认的GC策略，有两个选项，一个是吞吐量优先，一个是GC停顿时间优先，用来适应不同的业务场景。在ibmjdk5里，也提供了类似sunhotpsot的分代GC策略，即gencon（-Xgcpolicy:gencon)策略，这种GC适用于有大量临时对象产生的业务场景，比如繁忙的交易系统。经过对我们系统的验证，这种业务场景下使用分代策略的性能远高于默认的gc策略（50-100个并发用户下响应时间降低了30%-40%）。这里需要注意的是分代策略默认的新生代比较小（默认25%或者64M），需要实际场景适当调整，在我们的业务系统里，经过分析，调整为800m（-Xmn800m,最大heap值1600m）。
线程池的大小根据机器性能和业务场景来调整，并不是越大越好。在我们的业务场景里（IBM小机，50个并发用户），经过测试，最小值75，最大值150是个比较理想的值。
本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请
点击举报。
