一步步优化JVM二：JVM部署模型和JVM Runtime

选择JVM部署模型

   JVM部署模型的选择总体来说就是决定应用是部署在单个JVM实例还是多个JVM实例上（这里简单举例说明一下JVM实例，比如：我们常用eclipse开发，启动一个eclipse就是启动了一个JVM实例，然后在JVM中运行一个main程序，又会启动一个JVM实例，两个JVM实例是隔离开的）。哪一个是最适合你的应用的呢？这个是前面说到系统需求和潜在规则来决定的。比如说:假如你要部署您的应用在一个64位的机器上面，可以支持更大Java堆，如果应用依赖第三方的本地代码组件，而且这个第三方暂时不支持64位机器，那么你就必须要强制使用32位的JVM而且要使用更小优化的Java堆。

   单实例JVM模型

   在单实例的JVM上部署应用，有一个好处，就是可以减低管理成本，毕竟有更少的JVM需要去维护嘛。应用能够使用的总内存更小，由于每一个单独部署的JVM有能够使用的内存上限。

   部署应用在单个JVM上存在的挑战是应用的可用性存在极高的风险，比如：JVM失败或者应用灾难性错误。

   多实例JVM模型

   部署Java应用在多个JVM上面有提高可用性和能够间接降低延迟的好处，由于应用部署在多个JVM上，某一个JVM出错，只会导致应用某部分无法使用，不会导致整个应用无法使用。多JVM部署可以提供低延迟，在多JVM部署中，Java堆的大小倾向于更小，更小Java堆可以允许有更小的垃圾回收暂停，垃圾回收器的暂停是明显影响延迟。另外，如果应用存在明显瓶颈，多个JVM部署可能帮助提升吞吐量，把压力分布到多个JVM上面，可以让用承受更大的压力。

   使用多个JVM，JVM可能会和处理器绑定。把JVM和处理器绑定在一起，可以避免应用和JVM的线程在多个CPU上切换，提升CPU cache的命中率。

   部署多JVM的挑战在于管理、监控和维护需要更多的努力。 

   一般的建议

   没有最好的JVM部署模型，做出最合适的选择依赖于系统的需求，系统的需求才是最重要的。

   一个约束需要意识到的是，如果Java应用需要大量的内存占用，把应用部署在单个JVM上面可能需要使用64位JVM上，64位可以提供比32位JVM更大Java堆大小。如果使用64位JVM，需要保证应用使用的任何第三方软件需要支持64位。另外，如果任何使用JNI去调用本地组件，不管是第三方组件还是自己应用开发的程序，需要确保的是他们必须在64位环境下编译。

   根据作者的经验来看，越少的JVM数量越好，毕竟越容易维护。

选择JVM Runtime

   为Java应用选择JVM Runtime，就是根据实际情况来选择使用合适的client或者server。

   Client或者Server Runtime

   当使用HotSpot VM的时候，有两种可以选择的JVM runtime。client runtime是快速启动，更小的内存占用以及快速代码（机器码）生成的JIT编译器。server runtime有更复杂的代码生成优化，作为服务型应用更为靠谱。在server runtime中可以发现针对JIT编译器有很多的优化，主要是收集了更多的关于程序的信息，以生成更高性能的代码。

   第三种HotSpot VM runtime还在开发中，叫做tiered，他结合了client和server runtime优秀面，即更快的的启动时间和更高性能的生成代码。如果你使用的是Java 6 Update 25,Java 7或者更新的版本，你也许可以考虑使用tiered server runtime替换client runtime。要使用tiered server runtime可以使用这个命令行选项：-server  -XX：+TieredCompilation。在这本书编写的时候，还不是极力推荐替换掉client runtime或者server runtime。

   小提示：如果你不知道该如何选择，可以先选择server runtime。如果启动时间和内存占用无法接受，可以考虑切换成client runtime或者tiered runtime。依赖于你是使用什么版本的JVM。

   32位或者64位JVM

   除了client和server runtime的选择，还需要在32位或者64位之间做出选择，HotSpot VM的默认配置是32位的。做出32位和64位的选择取决于应用需要的内存占用以及依赖的第三方库是否支持64位系统——如果有通过JNI使用本地接口。决定应用需要消耗的内存占用，会在下节中介绍。下面的表格列出了一些指导帮助在32位JVM或者64位JVM之间做出选择。注意的是HotSpot VM还没有64位的client runtime。

   

   垃圾回收器

   在进入下一步优化之前，需要先做出选择初始的垃圾回收器。在HotSpot VM里面有好几种垃圾回收器可以使用：serial，throughput，mostly concurrent以及garbage first。

   由于使用throughput垃圾回收器有可能能够满足应用对暂停时间的需要，可以优先选择throughput垃圾回收器，如果有需要再切换到concurrent垃圾回收器（CMS）。如果有切换到concurrent垃圾回收器的需要，我们将会在后面的优化延迟的时候讨论 。

   使用throughput垃圾回收器可以通过HotSpot VM的命令行参数来指定：-XX:+UseParallelOldGC或者-XX:+UseParallelGC。 如果在你的HotSpont VM的版本上-XX:+UseParallelOldGC选项不能使用，使用+XX:UseParallelGC。两者的不同点在于，-XX:+UseParallelOldGC促发了多线程young代的垃圾回收和多线程old代的垃圾回收，也就是说minor垃圾回收和full垃圾回收都是多线程的。+XX:+UseParallelGC仅仅是young代的垃圾回收是多线程的，old代的垃圾回收的单线程的。因此，如果你想要young代和old代的垃圾回收都是多线程的就配置-XX:+UserParallelOldGC。而且-XX:+UserParallelOldGC是兼容-XX:+UseParallelGC。