转载

JVM的类型和模式(client+server)

 关于JVM的类型和模式

JVM client模式和Server模式的区别

JVM两种类型的区别:

曾几何时,我也敲打过无数次这样的命令:

JVM的类型和模式(client+server)

然而之前的我都只关心过版本号,也就是第一行的内容。今天,我们就来看看第3行输出的内容:JVM的类型和工作模式。

其实说Server和Client是JVM的两种工作模式是不准确的,因为它们就是不同的虚拟机,因此应该说有两种类型的JVM。

第三行的输出中可以看到: JVM的名字(HotSpot)、类型(Client)和build ID(24.79-b02) 。除此之外,我们还知道 JVM以混合模式(mixed mode) 在运行,这是HotSpot默认的运行模式, 意味着JVM在运行时可以动态的把字节码编译为本地代码。 我们也可以看到类数据共享(class data sharing)是开启(即第三行最后的sharing)的。类数据共享(class data sharing)是一种在只读缓存(在jsa文件中,”Java Shared Archive”)中存储JRE的系统类,被所有Java进程的类加载器用来当做共享资源,它可能在经常从jar文档中读所有的类数据的情况下显示出性能优势。

-Server VM启动时,速度较慢,但是一旦运行起来后,性能将会有很大的提升

当虚拟机运行在-client模式的时候,使用的是一个代号为C1的轻量级编译器, 而-server模式启动的虚拟机采用相对重量级,代号为C2的编译器. C2比C1编译器编译的相对彻底,,服务起来之后,性能更高.

前段时间有个同事给我发了个java跟c++性能比较的文章,其中有个对比图引起了我的兴趣,意外的是,我感兴趣的不是java和c++的对比,而是java -Server模式和java -client模式的对比。从来没想到两者间的性能有如此巨大的差别。而在后来自己的亲身测试中发现确实如此。

下面是我看到的那个对比图:

JVM的类型和模式(client+server) 图中最显著的就是JVM client模式和Server模式关于method call的对比,那个差别不是一般的大,在后来的测试中发现,相差至少有10倍。

如果想要在windows平台下从Client JVM切换到Server JVM,需要 下载JDK 而非JRE。打开JDK安装目录(即%JAVA_HOME%):我们可以看到 %JAVA_HOME%/jre/bin下有一个server和client文件夹,这里面各有一个jvm.dll ,但是大小不同,这就说明了它们是不同的JVM的文件

JVM的类型和模式(client+server)

打开 %JAVA_HOME%/jre/lib/i386/jvm.cfg 文件 (正如第一幅图所见,我这里安装的是32JDK,其他版本的JDK可能不是i386文件夹)(注意是JDK文件夹下的jre,而非和JDK同级的jre6/7/8),会注意到以下内容(灰色选中部分):

JVM的类型和模式(client+server)

再看看下方的配置, 第一行就配置了使用client方式,因此首选使用client模式的JVM ,这就是为什么一开始的java -version命令会输出Java HotSpot(TM) Client VM的原因了。现在将第33、34行配置交换一下,再在命令行中输入java -version,则会得到以下结果:

JVM的类型和模式(client+server)

JVM工作在Server模式可以大大提高性能,但应用的启动会比client模式慢大概10%。当该参数不指定时,虚拟机启动检测主机是否为服务器,如果是,则以Server模式启动,否则以client模式启动,J2SE5.0检测的根据是至少2个CPU和最低2GB内存。

当JVM用于启动GUI界面的交互应用时适合于使用client模式,当JVM用于运行服务器后台程序时建议用Server模式。

JVM在client模式默认-Xms是1M,-Xmx是64M;JVM在Server模式默认-Xms是128M,-Xmx是1024M。我们可以通过运行:java -version来查看jvm默认工作在什么模式。

JVM工作模式:

JVM的类型和模式(client+server)

其实这两个是JVM工作的模式。JVM有以下几种模式:-Xint, -Xcomp, 和 -Xmixed。从上图的输出结果中也可以看到,mixed是JVM的默认模式,其实在文章一开始的时候就提到了

 -Xmixed代表混合模式(mixed mode) ,前面也提到了, 混合模式是JVM的默认工作模式 。它会同时使用编译模式和解释模式。 对于字节码中多次被调用的部分,JVM会将其编译成 本地代码 以提高执行效率;而被调用很少(甚至只有一次)的方法在解释模式下会继续执行,从而 减少编译和优化成本 。JIT编译器在运行时创建方法使用文件,然后一步一步的优化每一个方法,有时候会主动的优化应用的行为。这些优化技术,比如积极的分支预测(optimistic branch prediction),如果不先分析应用就不能有效的使用。这样将频繁调用的部分提取出来,编译成本地代码,也就是在应用中构建某种热点(即HotSpot,这也是HotSpot JVM名字的由来)。使用混合模式可以获得最好的执行效率。

 -Xint代表解释模式(interpreted mode) ,-Xint标记会 强制JVM以解释方式执行所有的字节码 ,当然这 会降低运行速度 ,通常低10倍或更多。

 -Xcomp代表编译模式(compiled mode) ,与它(-Xint)正好相反, JVM在第一次使用时会把所有的字节码编译成本地代码,从而带来最大程度的优化 。这听起来不错,因为这 完全绕开了缓慢的解释器 。然而,很多应用在使用-Xcomp也会有一些性能损失,但是这比使用-Xint损失的少,原因是-Xcomp没有让JVM启用JIT编译器的全部功能。因此在上图中,我们并没有看到-Xcomp比-Xmixed快多少。

在都使用Client JVM的前提下,混合模式下,平均耗时150ms,然而在解释模式下,平均耗时超过1600ms,这基本上是10倍以上的差距。

原文  http://uule.iteye.com/blog/2420000
正文到此结束
Loading...