java吞吐_一步步优化JVM六：优化吞吐量

这一步的输入就是应用的吞吐量性能要求。应用的吞吐量是在应用层面衡量而不是在JVM层面衡量，因此，应用必须要报告出一些吞吐量指标或者应用的某些操作的吞吐量性能指标。观察到的吞吐量指标然后用可以用来和应用需要的性能指标进行比较，如果达到或者超过要求，那么这一步就完成了。如果你需要更好的吞吐量的话，有一些JVM优化可以去做。

这一步的另外一个输入就是，有多少内存可以供应用使用，就想前面说的GC最大化内存原则，越多可用的内存，性能就更好。这条原则不仅仅适用于吞吐量优化，同样适用于延迟优化。

应用的吞吐量需求可能是无法满足的。如果是这种情况，那么就需要重新审视应用吞吐量的需求，应用就需要修改或者改变部署模型。如果上面的一种或者多种情况发生了，那么你需要重新进行前面的优化步骤。

在前面的步骤里面，你可能使用吞吐量垃圾回收器解决了问题(通过-XX:+UseParallelOldGC或者-XX:+UsePrallelGC)，或者你调整到并发垃圾回收器(CMS)来解决的问题。如果使用的CMS来解决的问题，下面有一些选项来提升应用的吞吐量，下面详细介绍。如果是使用的吞吐量垃圾回收器，我们将在CMS之后介绍。

CMS吞吐量优化

能够用来提升CMS吞吐量的选项数量有限，下面列出一些可以单独使用或者联合使用的选项：

1、使用一些额外的命令选项，在后面的“额外的性能命令行选项”中详细介绍。

2、增加young代的空间大小，增加young代的空间大小，可以减少MinorGC的频率，就能够减少在一段时间里面MinorGC占用的时间。

3、增加old代的空间大小，增加old代的空间，可以减少CMS垃圾回收的频率，减少潜在的碎片，可以减少

stop-the-world垃圾回收。

4、进一步优化young代堆大小，已经在前面的“优化延迟和响应时间”里面说过了，以及如何优化eden空间任务后和survivor空间大小以减少对象从young代移动到old也在前面已经说过了。需要注意的是，当优化eden和survivor空间大小的时候考虑到一些权衡。

5、优化CMS周期的启动，也在前面说过了。

任何上面提到的优化，或者组合使用上面的选择，都是减少垃圾回收器占用CPU时间，把CPU留给应用计算。前面两种选择，提供一种可能性来提升吞吐量，但是会有stop-the-world垃圾回收的风险，会增加延迟。

作为指导，不考虑CMS，MinorGC的次数应该减少10%，你可能只能降低1%-3%。通常来讲，如果只能减少3%甚