原文地址：https://blog.codecentric.de/en/2012/07/useful-jvm-flags-part-1-jvm-types-and-compiler-modes/html
译者：赵峰，iDestiny 校对：郭蕾java
如今的JVM运行Java程序（和其它的兼容性语言）时在高效性和稳定性方面作的很是出色。自适应内存管理、垃圾收集、及时编译、动态类加载、锁优化——这里仅仅列举了某些场景下会发生的神奇的事情，但他们几乎不会直接与普通的程序员相关。在运行时，JVM会不断的计算并优化应用或者应用的某些部分。程序员
虽然有了这种程度的自动化（或者说有这么多自动化），可是JVM仍然提供了足够多的外部监控和手动调优工具。在有错误或低性能的状况下，JVM必须可以让专家调试。顺便说一句，除了这些隐藏在引擎中的神奇功能，容许大范围的手动调优也是现代JVM的优点之一。有趣的是，一些命令行参数能够在JVM启动时传入到JVM中。一些JVM提供了几百个这样的参数，因此若是没有这方面的知识很容易迷失。这系列博客的目标是着重讲解平常相关的一些参数以及他们的适用场合。咱们将专一于Java6的Sun/Oracle HotSpot JVM，大多数状况下，这些参数也会适用于其余一些流行的JVM里。编程
-server and -client缓存
有两种类型的 HotSpot JVM，即”server”和”client”。服务端的VM中的默认为堆提供了一个更大的空间以及一个并行的垃圾收集器，而且在运行时能够更大程度地优化代码。客户端的VM更加保守一些（校对注：这里做者指客户端虚拟机有较小的默认堆大小），这样能够缩短JVM的启动时间和占用更少的内存。有一个叫”JVM功效学”的概念，它会在JVM启动的时候根据可用的硬件和操做系统来自动的选择JVM的类型。具体的标准能够在这里找到。从标准表中，咱们能够看到客户端的VM只在32位系统中可用。bash
若是咱们不喜欢预选（校对注：指JVM自动选择的JVM类型）的JVM，咱们可使用-server和-client参数来设置使用服务端或客户端的VM。虽然当初服务端VM的目标是长时间运行的服务进程，可是如今看来，在运行独立应用程序时它比客户端VM有更出色的性能。当应用的性能很是重要时，我推荐使用-server参数来选择服务端VM。一个常见的问题：在一个32位的系统上，HotSpot JDK能够运行服务端VM，可是32位的JRE只能运行客户端VM。并发
-version and -showversionoracle
当咱们调用“java”命令时，咱们如何才能知道咱们安装的是哪一个版本的Java和JVM类型呢？在同一个系统中安装多个Java，若是不注意的话有运行错误JVM的风险。在不一样的Linux版本上预装JVM这方面，我认可如今已经变的比之前好不少了。幸运的是，咱们如今可使用-version参数，它能够打印出正在使用的JVM的信息。例如：jvm
1 $ java -version 2 java version "1.6.0_24" 3 Java(TM) SE Runtime Environment (build 1.6.0_24-b07) 4 Java HotSpot(TM) Client VM (build 19.1-b02, mixed mode, sharing)
-version参数在打印完上述信息后当即终止JVM。还有一个相似的参数-showversion能够用来输出相同的信息，可是-showversion紧接着会处理并执行Java程序。所以，-showversion对几乎全部Java应用的命令行都是一个有效的补充。你永远不知道你何时，忽然须要了解一个特定的Java应用（崩溃时）使用的JVM的一些信息。在启动时添加-showversion，咱们就能保证当咱们须要时能够获得这些信息。输出显示的是Java版本号(1.6.0_24)和JRE确切的build号(1.6.0_24-b07)。咱们也能够看到JVM的名字(HotSpot)、类型(client)和build ID（19.1-b02) ）。除此以外，咱们还知道JVM以混合模式(mixed mode)在运行，这是HotSpot默认的运行模式，意味着JVM在运行时能够动态的把字节码编译为本地代码。咱们也能够看到类数据共享（class data sharing）是开启的，类数据共享（class data sharing）是一种在只读缓存（在jsa文件中，”Java Shared Archive”）中存储JRE的系统类，被全部Java进程的类加载器用来当作共享资源。类数据共享(Class data sharing)可能在常常从jar文档中读全部的类数据的状况下显示出性能优点。ide
-Xint, -Xcomp, 和 -Xmixed
-Xint和-Xcomp参数和咱们的平常工做不是很相关，可是我很是有兴趣经过它来了解下JVM。在解释模式(interpreted mode)下，-Xint标记会强制JVM执行全部的字节码，固然这会下降运行速度，一般低10倍或更多。-Xcomp参数与它（-Xint）正好相反，JVM在第一次使用时会把全部的字节码编译成本地代码，从而带来最大程度的优化。这听起来不错，由于这彻底绕开了缓慢的解释器。然而，不少应用在使用-Xcomp也会有一些性能损失，固然这比使用-Xint损失的少，缘由是-xcomp没有让JVM启用JIT编译器的所有功能。JIT编译器在运行时建立方法使用文件，而后一步一步的优化每个方法，有时候会主动的优化应用的行为。这些优化技术，好比，积极的分支预测（optimistic branch prediction），若是不先分析应用就不能有效的使用。另外一方面方法只有证实它们与此相关时才会被编译，也就是，在应用中构建某种热点。被调用不多（甚至只有一次）的方法在解释模式下会继续执行，从而减小编译和优化成本。
注意混合模式也有他本身的参数，-Xmixed。最新版本的HotSpot的默认模式是混合模式，因此咱们不须要特别指定这个标记。咱们来用对象填充HashMap而后检索它的结果作一个简单的用例。每个例子，它的运行时间都是不少次运行的平均时间。
1 $ java -server -showversion Benchmark 2 java version "1.6.0_24" 3 Java(TM) SE Runtime Environment (build 1.6.0_24-b07) 4 Java HotSpot(TM) Server VM (build 19.1-b02, mixed mode) 5 6 Average time: 0.856449 seconds
1 $ java -server -showversion -Xcomp Benchmark 2 java version "1.6.0_24" 3 Java(TM) SE Runtime Environment (build 1.6.0_24-b07) 4 Java HotSpot(TM) Server VM (build 19.1-b02, compiled mode) 5 6 Average time: 0.950892 seconds
1 $ java -server -showversion -Xint Benchmark 2 java version "1.6.0_24" 3 Java(TM) SE Runtime Environment (build 1.6.0_24-b07) 4 Java HotSpot(TM) Server VM (build 19.1-b02, interpreted mode) 5 6 Average time: 7.622285 seconds
固然也有不少使-Xcomp表现很好的例子。特别是运行时间长的应用，我强烈建议你们使用JVM的默认设置,让JIT编译器充分发挥其动态潜力，毕竟JIT编译器是组成JVM最重要的组件之一。事实上，正是由于JVM在这方面的进展才让Java再也不那么慢。
原创文章，转载请注明： 转载自并发编程网 – ifeve.com本文连接地址: JVM实用参数（一）JVM类型以及编译器模式