zhoutao198712的专栏

优化CMS（concurrent garbage collection）   使用CMS，old代的垃圾回收执行线程会和应用程序的线程最大程度的并发执行。这个提供了一个机会来减少最坏延迟的频率和最坏延迟的时间消耗。CMS没有执行压缩，所以可以避免old代空间的stop-the-world压缩（会让整个应用暂停运行）。   优化CMS的目标就是避开stop-the-w

CMS垃圾回收器周期      一旦young的空间大小（包含eden和survivor空间）已经完善得满足应用对MinorGC产生延迟要求，注意力可以转移到优化CMS垃圾回收器，降低最差延迟时间的时间长度以及最小化最差延迟的频率。目标是保持可用的old代空间和并发垃圾回收，避免stop-the-world压缩垃圾回收。   stop-the-world压缩垃圾回收是垃圾回

本节的目标是做一些优化以满足对应用对延迟的需求。这次需要几个步骤，包括完善Java堆大小的配置，评估垃圾回收占用的时间和频率，也许还要尝试切换到不同的垃圾回收器，以及由于使用了不同的垃圾回收器，需要重新优化Java堆空间大小。    这一步有如下可能的结果：    1、应用的延迟需求被满足了。如果这一步的优化操作满足了应用的延迟需求，你可以继续下一步优化（优化吞吐量）。

如果你已经进行完了前面的步骤了，那么你应该知道这是最后一步了。在这一步里面，你需要测试应用的吞吐量和为了更高的吞吐量而优化JVM。   这一步的输入就是应用的吞吐量性能要求。应用的吞吐量是在应用层面衡量而不是在JVM层面衡量，因此，应用必须要报告出一些吞吐量指标或者应用的某些操作的吞吐量性能指标。观察到的吞吐量指标然后用可以用来和应用需要的性能指标进行比较，如果达到或者超过要求，那么这

现代JVM是一个具有灵活适应各种应用能力的软件，尽管很多应用能够在JVM的默认配置下运行良好，但是有些应用还是需要优化JVM配置以达到其性能要求。由于各种各样的应用能够运行在现在JVM上面，所以大量的JVM选项可以配置来提升应用的性能。不幸的是，对一个应用而言优化得很好的JVM配置，对应另外的应用不一定适合。所以，真正理解怎样优化JVM配置是非常有必要的。   优化现代JVM是一门很大

选择JVM部署模型   JVM部署模型的选择总体来说就是决定应用是部署在单个JVM实例还是多个JVM实例上（这里简单举例说明一下JVM实例，比如：我们常用eclipse开发，启动一个eclipse就是启动了一个JVM实例，然后在JVM中运行一个main程序，又会启动一个JVM实例，两个JVM实例是隔离开的）。哪一个是最适合你的应用的呢？这个是前面说到系统需求和潜在规则来决定的。比如说:

到目前为止，还没有做明确的优化工作。只是做了初始化选择工作，比如说：JVM部署模型、JVM运行环境、收集哪些垃圾回收器的信息以及需要遵守垃圾回收原则。这一步将介绍如何评估应用需要的内存大小以及Java堆大小。首先需要判断出应用存活的数据的大小，存活数据的大小是决定配置应用需要的Java堆大小的重要条件，也能够决定是否需要重新审视一下应用的内存需求或者修改应用程序以满足内存需求。   注

边缘问题   在某些场景下，按照前面的一步步优化指导无法产生效果。这一节说明一下这些情况。   一些应用分配了一些少量的非常大的长时间存活的对象。这样的场景需要需要young代的空间比old代更大。   一些应用会经历很少的对象转移。这样的场景可能需要old代的空间远远大于存活对象的大小，由于old的占用量增长率很小。   一些应用有小延迟需求，会使

本节主要描述关于垃圾回收器性能的三个指标，三个关于垃圾回收器优化的基本原则，以及优化HotSpot VM的垃圾回收器的信息收集，在这些指标中权衡以及信息的收集是非常重要的。性能指标   吞吐量:衡量垃圾回收器运行在性能峰值的时候不需要关心垃圾回收器暂停的时间或者需要占用内存的能力。   延迟：衡量垃圾回收器最小化甚至消灭由垃圾回收器引起的暂停时间和应用抖动的能力。   内存