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

引用 :http://blog.csdn.net/zhoutao198712/article/details/7783044

选择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。

代码交流 2021