JVM 设置

查看 JVM 相关命令

查看整个 JVM 内存状态

jmap -heap [pid]

要注意的是在使用 CMS GC 情况下，jmap -heap 的执行有可能会导致 JAVA 进程挂起

查看 JVM 堆中对象详细占用情况

jmap -histo [pid]

导出整个 JVM 中内存信息

jmap -dump:format=b,file=文件名 [pid]

jhat

jhat 是 sun 1.6 及以上版本中自带的一个用于分析 JVM 堆 DUMP 文件的工具，基于此工具可分析 JVM HEAP 中对象的内存占用情况

jhat -J-Xmx1024M [file]

执行后等待 console 中输出 start HTTP server on port 7000 即可使用浏览器访问 IP：7000

eclipse Memory Analyzer

Eclipse 提供的一个用于分析 JVM 堆 Dump 文件的插件。借助这个插件可查看对象的内存占用状况，引用关系，分析内存泄露等。
https://www.eclipse.org/mat/

kill -3 [pid]

在 Linux 上找到 Java 所在的进程号，然后执行以上命令，线程的相关信息就输出到 console

jstack

jstack 是 sun JDK 自带的工具，通过该工具可以看到 JVM 中线程的运行状况，包括锁等待，线程是否在运行
执行 jstack [pid] ,线程的所有堆栈信息

“http-8080-10” daemon prio=10 tid=x0a949bb60 nid=0x884 waiting for monitor entry […]

“http-8080-10” 这个线程处于等待状态。 waiting for monitor entry 如果在连续几次输出线程堆栈信息都存在于同一个或多个线程上时，则说明系统中有锁竞争激烈，死锁，或锁饿死的想象。

“http-8080-11” daemon prio=10 tix=xxx nid=xxx in object.wait() […]
java.lang.Thread.State:waiting (on object monitor)
该表示 http-8080-11 的线程处于对象的 Wait 上，等待其他线程的唤醒，这也是线程池的常见用法。

“Low Memory Detector”daemon prio=10 tix=xx nid=xxx runnable […] java.lang.Thread.State:runnable
表示“Low Memory Detector” 的线程处于 Runable 状态，等待获取ＣＰＵ的使用权.

jps

jps(Java Virtual Machine Process Status Tool)是 JDK 1.5 提供的一个显示当前所有 java 进程 pid 的命令，简单实用，非常适合在 linux/unix 平台上简单察看当前 java 进程的一些简单情况。

jps 存放在 JAVA_HOME/bin/jps，使用时为了方便请将 JAVA_HOME/bin/加入到 Path.

jstat

1. jstat -gc pid
        可以显示gc的信息，查看gc的次数，及时间。
        其中最后五项，分别是young gc的次数，young gc的时间，full gc的次数，full gc的时间，gc的总时间。
2.jstat -gccapacity pid
        可以显示，VM内存中三代（young,old,perm）对象的使用和占用大小，
        如：PGCMN显示的是最小perm的内存使用量，PGCMX显示的是perm的内存最大使用量，
        PGC是当前新生成的perm内存占用量，PC是但前perm内存占用量。
        其他的可以根据这个类推， OC是old内纯的占用量。
3.jstat -gcutil pid
        统计gc信息统计。
4.jstat -gcnew pid
       年轻代对象的信息。
5.jstat -gcnewcapacity pid
       年轻代对象的信息及其占用量。
6.jstat -gcold pid
      old代对象的信息。
7.stat -gcoldcapacity pid
      old代对象的信息及其占用量。
8.jstat -gcpermcapacity pid
      perm对象的信息及其占用量。
9.jstat -class pid
      显示加载class的数量，及所占空间等信息。
10.jstat -compiler pid
      显示VM实时编译的数量等信息。
11.stat -printcompilation pid
      当前VM执行的信息。
    一些术语的中文解释：
     S0C：年轻代中第一个survivor（幸存区）的容量 (字节)
     S1C：年轻代中第二个survivor（幸存区）的容量 (字节)
     S0U：年轻代中第一个survivor（幸存区）目前已使用空间 (字节)
     S1U：年轻代中第二个survivor（幸存区）目前已使用空间 (字节)
     EC：年轻代中Eden（伊甸园）的容量 (字节)
     EU：年轻代中Eden（伊甸园）目前已使用空间 (字节)
     OC：Old代的容量 (字节)
     OU：Old代目前已使用空间 (字节)
     PC：Perm(持久代)的容量 (字节)
     PU：Perm(持久代)目前已使用空间 (字节)
     YGC：从应用程序启动到采样时年轻代中gc次数
     YGCT：从应用程序启动到采样时年轻代中gc所用时间(s)
     FGC：从应用程序启动到采样时old代(全gc)gc次数
     FGCT：从应用程序启动到采样时old代(全gc)gc所用时间(s)
     GCT：从应用程序启动到采样时gc用的总时间(s)
     NGCMN：年轻代(young)中初始化(最小)的大小 (字节)
     NGCMX：年轻代(young)的最大容量 (字节)
     NGC：年轻代(young)中当前的容量 (字节)
     OGCMN：old代中初始化(最小)的大小 (字节)
     OGCMX：old代的最大容量 (字节)
     OGC：old代当前新生成的容量 (字节)
     PGCMN：perm代中初始化(最小)的大小 (字节)
     PGCMX：perm代的最大容量 (字节)
     PGC：perm代当前新生成的容量 (字节)
     S0：年轻代中第一个survivor（幸存区）已使用的占当前容量百分比
     S1：年轻代中第二个survivor（幸存区）已使用的占当前容量百分比
     E：年轻代中Eden（伊甸园）已使用的占当前容量百分比
     O：old代已使用的占当前容量百分比
     P：perm代已使用的占当前容量百分比
     S0CMX：年轻代中第一个survivor（幸存区）的最大容量 (字节)
     S1CMX ：年轻代中第二个survivor（幸存区）的最大容量 (字节)
     ECMX：年轻代中Eden（伊甸园）的最大容量 (字节)
     DSS：当前需要survivor（幸存区）的容量 (字节)（Eden区已满）
     TT： 持有次数限制
     MTT ： 最大持有次数限制

原理

JVM 堆内存分为 2 块：Permanent Space 和 Heap Space。

• Permanent 即 持久代（Permanent Generation），主要存放的是 Java 类定义信息，与垃圾收集器要收集的 Java 对象关系不大。
• Heap = { Old + NEW = {Eden, from, to} }，Old 即 年老代（Old Generation），New 即 年轻代（Young Generation）。年老代和年轻代的划分对垃圾收集影响比较大。

年轻代

所有新生成的对象首先都是放在年轻代。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。年轻代一般分 3 个区，1 个 Eden 区，2 个 Survivor 区（from 和 to）。
大 部分对象在 Eden 区中生成。当 Eden 区满时，还存活的对象将被复制到 Survivor 区（两个中的一个），当一个 Survivor 区满时，此区的存活 对象将被复制到另外一个 Survivor 区，当另一个 Survivor 区也满了的时候，从前一个 Survivor 区复制过来的并且此时还存活的对象，将可 能被复制到年老代。
2 个 Survivor 区是对称的，没有先后关系，所以同一个 Survivor 区中可能同时存在从 Eden 区复制过来对象，和从另一个 Survivor 区复制过来的对象；而复制到年老区的只有从另一个 Survivor 区过来的对象。而且，因为需要交换的原因，Survivor 区至少有一个是空的。特殊的情况下，根据程序需要，Survivor 区是可以配置为多个的（多于 2 个），这样可以增加对象在年轻代中的存在时间，减少被放到年老代的可能。
针对年轻代的垃圾回收即 Young GC。

年老代

在年轻代中经历了 N 次（可配置）垃圾回收后仍然存活的对象，就会被复制到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。
针对年老代的垃圾回收即 Full GC。

持久代

用 于存放静态类型数据，如 Java Class, Method 等。持久代对垃圾回收没有显著影响。但是有些应用可能动态生成或调用一些 Class，例如 Hibernate CGLib 等，在这种时候往往需要设置一个比较大的持久代空间来存放这些运行过程中动态增加的类型。

所以，当一组对象生成时，内存申请过程如下：

1. JVM 会试图为相关 Java 对象在年轻代的 Eden 区中初始化一块内存区域。
2. 当 Eden 区空间足够时，内存申请结束。否则执行下一步。
3. JVM 试图释放在 Eden 区中所有不活跃的对象（Young GC）。释放后若 Eden 空间仍然不足以放入新对象，JVM 则试图将部分 Eden 区中活跃对象放入 Survivor 区。
4. Survivor 区被用来作为 Eden 区及年老代的中间交换区域。当年老代空间足够时，Survivor 区中存活了一定次数的对象会被移到年老代。
5. 当年老代空间不够时，JVM 会在年老代进行完全的垃圾回收（Full GC）。
6. Full GC 后，若 Survivor 区及年老代仍然无法存放从 Eden 区复制过来的对象，则会导致 JVM 无法在 Eden 区为新生成的对象申请内存，即出现“Out of Memory”。

OOM（“Out of Memory”）异常一般主要有如下 2 种原因：

1. 年老代溢出，表现为：java.lang.OutOfMemoryError:Javaheapspace
   这是最常见的情况，产生的原因可能是：设置的内存参数 Xmx 过小或程序的内存泄露及使用不当问题。
   例如循环上万次的字符串处理、创建上千万个对象、在一段代码内申请上百 M 甚至上 G 的内存。还有的时候虽然不会报内存溢出，却会使系统不间断的垃圾回收，也无法处理其它请求。这种情况下除了检查程序、打印堆内存等方法排查，还可以借助一些内存分析工具，比如 MAT 就很不错。

2. 持久代溢出，表现为：java.lang.OutOfMemoryError:PermGenspace
   通
   常由于持久代设置过小，动态加载了大量 Java 类而导致溢出，解决办法唯有将参数 -XX:MaxPermSize
   调大（一般 256m 能满足绝大多数应用程序需求）。将部分 Java 类放到容器共享区（例如 Tomcat share
   lib）去加载的办法也是一个思路，但前提是容器里部署了多个应用，且这些应用有大量的共享类库。

参数说明

• -Xmx3550m：设置 JVM 最大堆内存为 3550M。
• -Xms3550m：设置 JVM 初始堆内存为 3550M。此值可以设置与-Xmx 相同，以避免每次垃圾回收完成后 JVM 重新分配内存。
• -Xss128k： 设置每个线程的栈大小。JDK5.0 以后每个线程栈大小为 1M，之前每个线程栈大小为 256K。应当根据应用的线程所需内存大小进行调整。在相同物理内存 下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在 3000~5000 左右。需要注意的是：当这个 值被设置的较大（例如>2MB）时将会在很大程度上降低系统的性能。
• -Xmn2g：设置年轻代大小为 2G。在整个堆内存大小确定的情况下，增大年轻代将会减小年老代，反之亦然。此值关系到 JVM 垃圾回收，对系统性能影响较大，官方推荐配置为整个堆大小的 3/8。
• -XX:NewSize=1024m：设置年轻代初始值为 1024M。
• -XX:MaxNewSize=1024m：设置年轻代最大值为 1024M。
• -XX:PermSize=256m：设置持久代初始值为 256M。
• -XX:MaxPermSize=256m：设置持久代最大值为 256M。
• -XX:NewRatio=4：设置年轻代（包括 1 个 Eden 和 2 个 Survivor 区）与年老代的比值。表示年轻代比年老代为 1:4。
• -XX:SurvivorRatio=4：设置年轻代中 Eden 区与 Survivor 区的比值。表示 2 个 Survivor 区（JVM 堆内存年轻代中默认有 2 个大小相等的 Survivor 区）与 1 个 Eden 区的比值为 2:4，即 1 个 Survivor 区占整个年轻代大小的 1/6。
• -XX:MaxTenuringThreshold=7： 表示一个对象如果在 Survivor 区（救助空间）移动了 7 次还没有被垃圾回收就进入年老代。如果设置为 0 的话，则年轻代对象不经过 Survivor 区， 直接进入年老代，对于需要大量常驻内存的应用，这样做可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在 Survivor 区进行多次复制，这样 可以增加对象在年轻代存活时间，增加对象在年轻代被垃圾回收的概率，减少 Full GC 的频率，这样做可以在某种程度上提高服务稳定性。

疑问解答

-Xmn，-XX:NewSize/-XX:MaxNewSize，-XX:NewRatio 3 组参数都可以影响年轻代的大小，混合使用的情况下，优先级是什么？
如下：

1. 高优先级：-XX:NewSize/-XX:MaxNewSize
2. 中优先级：-Xmn（默认等效 -Xmn=-XX:NewSize=-XX:MaxNewSize=?）
3. 低优先级：-XX:NewRatio
4. 推荐使用-Xmn 参数，原因是这个参数简洁，相当于一次设定 NewSize/MaxNewSIze，而且两者相等，适用于生产环境。-Xmn 配合 -Xms/-Xmx，即可将堆内存布局完成。
   -Xmn 参数是在 JDK 1.4 开始支持。

垃圾回收器选择

JVM 给出了 3 种选择：串行收集器、并行收集器、并发收集器。串行收集器只适用于小数据量的情况，所以生产环境的选择主要是并行收集器和并发收集器。
默认情况下 JDK5.0 以前都是使用串行收集器，如果想使用其他收集器需要在启动时加入相应参数。JDK5.0 以后，JVM 会根据当前系统配置进行智能判断。

串行收集器

• -XX:+UseSerialGC：设置串行收集器。

并行收集器（吞吐量优先）

• -XX:+UseParallelGC：设置为并行收集器。此配置仅对年轻代有效。即年轻代使用并行收集，而年老代仍使用串行收集。
• -XX:ParallelGCThreads=20：配置并行收集器的线程数，即：同时有多少个线程一起进行垃圾回收。此值建议配置与 CPU 数目相等。
• -XX:+UseParallelOldGC：配置年老代垃圾收集方式为并行收集。JDK6.0 开始支持对年老代并行收集。
• -XX:MaxGCPauseMillis=100：设置每次年轻代垃圾回收的最长时间（单位毫秒）。如果无法满足此时间，JVM 会自动调整年轻代大小，以满足此时间。
• -XX:+UseAdaptiveSizePolicy：设置此选项后，并行收集器会自动调整年轻代 Eden 区大小和 Survivor 区大小的比例，以达成目标系统规定的最低响应时间或者收集频率等指标。此参数建议在使用并行收集器时，一直打开。

并发收集器（响应时间优先）

• -XX:+UseConcMarkSweepGC： 即 CMS 收集，设置年老代为并发收集。CMS 收集是 JDK1.4 后期版本开始引入的新 GC 算法。它的主要适合场景是对响应时间的重要性需求大于对吞吐量的 需求，能够承受垃圾回收线程和应用线程共享 CPU 资源，并且应用中存在比较多的长生命周期对象。CMS 收集的目标是尽量减少应用的暂停时间，减少 Full GC 发生的几率，利用和应用程序线程并发的垃圾回收线程来标记清除年老代内存。
• -XX:+UseParNewGC：设置年轻代为并发收集。可与 CMS 收集同时使用。JDK5.0 以上，JVM 会根据系统配置自行设置，所以无需再设置此参数。
• -XX:CMSFullGCsBeforeCompaction=0： 由于并发收集器不对内存空间进行压缩和整理，所以运行一段时间并行收集以后会产生内存碎片，内存使用效率降低。此参数设置运行 0 次 Full GC 后对内存空间进行压缩和整理，即每次 Full GC 后立刻开始压缩和整理内存。
• -XX:+UseCMSCompactAtFullCollection：打开内存空间的压缩和整理，在 Full GC 后执行。可能会影响性能，但可以消除内存碎片。
• -XX:+CMSIncrementalMode：设置为增量收集模式。一般适用于单 CPU 情况。
• -XX:CMSInitiatingOccupancyFraction=70：表示年老代内存空间使用到 70%时就开始执行 CMS 收集，以确保年老代有足够的空间接纳来自年轻代的对象，避免 Full GC 的发生。

其它垃圾回收参数

• -XX:+ScavengeBeforeFullGC：年轻代 GC 优于 Full GC 执行。
• -XX:-DisableExplicitGC：不响应 System.gc() 代码。
• -XX:+UseThreadPriorities：启用本地线程优先级 API。即使 java.lang.Thread.setPriority() 生效，不启用则无效。
• -XX:SoftRefLRUPolicyMSPerMB=0：软引用对象在最后一次被访问后能存活 0 毫秒（JVM 默认为 1000 毫秒）。
• -XX:TargetSurvivorRatio=90：允许 90%的 Survivor 区被占用（JVM 默认为 50%）。提高对于 Survivor 区的使用率。

辅助信息参数设置

• -XX:-CITime：打印消耗在 JIT 编译的时间。
• -XX:ErrorFile=./hs_err_pid.log：保存错误日志或数据到指定文件中。
• -XX:HeapDumpPath=./java_pid.hprof：指定 Dump 堆内存时的路径。
• -XX:-HeapDumpOnOutOfMemoryError：当首次遭遇内存溢出时 Dump 出此时的堆内存。
• -XX:OnError=”;”：出现致命 ERROR 后运行自定义命令。
• -XX:OnOutOfMemoryError=”;”：当首次遭遇内存溢出时执行自定义命令。
• -XX:-PrintClassHistogram：按下 Ctrl+Break 后打印堆内存中类实例的柱状信息，同 JDK 的 jmap -histo 命令。
• -XX:-PrintConcurrentLocks：按下 Ctrl+Break 后打印线程栈中并发锁的相关信息，同 JDK 的 jstack -l 命令。
• -XX:-PrintCompilation：当一个方法被编译时打印相关信息。
• -XX:-PrintGC：每次 GC 时打印相关信息。
• -XX:-PrintGCDetails：每次 GC 时打印详细信息。
• -XX:-PrintGCTimeStamps：打印每次 GC 的时间戳。
• -XX:-TraceClassLoading：跟踪类的加载信息。
• -XX:-TraceClassLoadingPreorder：跟踪被引用到的所有类的加载信息。
• -XX:-TraceClassResolution：跟踪常量池。
• -XX:-TraceClassUnloading：跟踪类的卸载信息。

关于参数名称等

• 标准参数（-），所有 JVM 都必须支持这些参数的功能，而且向后兼容；例如：
• -client——设置 JVM 使用 Client 模式，特点是启动速度比较快，但运行时性能和内存管理效率不高，通常用于客户端应用程序或开发调试；在 32 位环境下直接运行 Java 程序默认启用该模式。
• -server——设置 JVM 使 Server 模式，特点是启动速度比较慢，但运行时性能和内存管理效率很高，适用于生产环境。在具有 64 位能力的 JDK 环境下默认启用该模式。
• 非标准参数（-X），默认 JVM 实现这些参数的功能，但是并不保证所有 JVM 实现都满足，且不保证向后兼容；
• 非稳定参数（-XX），此类参数各个 JVM 实现会有所不同，将来可能会不被支持，需要慎重使用；

JVM 服务参数调优实战

大型网站服务器案例

承受海量访问的动态 Web 应用
服务器配置：8 CPU, 8G MEM, JDK 1.6.X

参数方案：
-server -Xmx3550m -Xms3550m -Xmn1256m -Xss128k -XX:SurvivorRatio=6 -XX:MaxPermSize=256m -XX:ParallelGCThreads=8 -XX:MaxTenuringThreshold=0 -XX:+UseConcMarkSweepGC

调优说明：

• -Xmx 与 -Xms 相同以避免 JVM 反复重新申请内存。-Xmx 的大小约等于系统内存大小的一半，即充分利用系统资源，又给予系统安全运行的空间。
• -Xmn1256m 设置年轻代大小为 1256MB。此值对系统性能影响较大，Sun 官方推荐配置年轻代大小为整个堆的 3/8。
• -Xss128k 设置较小的线程栈以支持创建更多的线程，支持海量访问，并提升系统性能。
• -XX:SurvivorRatio=6 设置年轻代中 Eden 区与 Survivor 区的比值。系统默认是 8，根据经验设置为 6，则 2 个 Survivor 区与 1 个 Eden 区的比值为 2:6，一个 Survivor 区占整个年轻代的 1/8。
• -XX:ParallelGCThreads=8 配置并行收集器的线程数，即同时 8 个线程一起进行垃圾回收。此值一般配置为与 CPU 数目相等。
• -XX:MaxTenuringThreshold=0 设置垃圾最大年龄（在年轻代的存活次数）。如果设置为 0 的话，则年轻代对象不经过 Survivor 区直接进入年老代。对于年老代比较多的应用，可以提高效 率；如果将此值设置为一个较大值，则年轻代对象会在 Survivor 区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概率。 根据被海量访问的动态 Web 应用之特点，其内存要么被缓存起来以减少直接访问 DB，要么被快速回收以支持高并发海量请求，因此其内存对象在年轻代存活多次 意义不大，可以直接进入年老代，根据实际应用效果，在这里设置此值为 0。
• -XX:+UseConcMarkSweepGC 设置年老代为并发收集。CMS（ConcMarkSweepGC）收集的目标是尽量减少应用的暂停时间，减少 Full GC 发生的几率，利用和应用程序线程并发的垃圾回收线程来标记清除年老代内存，适用于应用中存在比较多的长生命周期对象的情况。

内部集成构建服务器案例

高性能数据处理的工具应用
服务器配置：1 CPU, 4G MEM, JDK 1.6.X

参数方案：
-server -XX:PermSize=196m -XX:MaxPermSize=196m -Xmn320m -Xms768m -Xmx1024m

调优说明：

• -XX:PermSize=196m -XX:MaxPermSize=196m 根据集成构建的特点，大规模的系统编译可能需要加载大量的 Java 类到内存中，所以预先分配好大量的持久代内存是高效和必要的。
• -Xmn320m 遵循年轻代大小为整个堆的 3/8 原则。
• -Xms768m -Xmx1024m 根据系统大致能够承受的堆内存大小设置即可。
  在 64 位服务器上运行应用程序，构建执行时，用 jmap -heap 11540 命令观察 JVM 堆内存状况如下：

Attaching to process ID 11540, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 20.12-b01


using thread-local object allocation.
Parallel GC with 4 thread(s)


Heap Configuration:
   MinHeapFreeRatio = 40
   MaxHeapFreeRatio = 70
   MaxHeapSize      = 1073741824 (1024.0MB)
   NewSize          = 335544320 (320.0MB)
   MaxNewSize       = 335544320 (320.0MB)
   OldSize          = 5439488 (5.1875MB)
   NewRatio         = 2
   SurvivorRatio    = 8
   PermSize         = 205520896 (196.0MB)
   MaxPermSize      = 205520896 (196.0MB)


Heap Usage:
PS Young Generation
Eden Space:
   capacity = 255852544 (244.0MB)
   used     = 101395504 (96.69828796386719MB)
   free     = 154457040 (147.3017120361328MB)
   39.63044588683081% used
From Space:
   capacity = 34144256 (32.5625MB)
   used     = 33993968 (32.41917419433594MB)
   free     = 150288 (0.1433258056640625MB)
   99.55984397492803% used
To Space:
   capacity = 39845888 (38.0MB)
   used     = 0 (0.0MB)
   free     = 39845888 (38.0MB)
   0.0% used
PS Old Generation
   capacity = 469762048 (448.0MB)
   used     = 44347696 (42.29325866699219MB)
   free     = 425414352 (405.7067413330078MB)
   9.440459523882184% used
PS Perm Generation
   capacity = 205520896 (196.0MB)
   used     = 85169496 (81.22396087646484MB)
   free     = 120351400 (114.77603912353516MB)
   41.440796365543285% used

结果是比较健康的。

JVM Server 与 Client 运行模式

JVM Server 模式与 client 模式启动，最主要的差别在于：-Server 模式启动时，速度较慢，但是一旦运行起来后，性能将会有很大的提升.原因是:

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

Java -version 可以直接查看出你使用的是 client 还是 server

Jvm client 代码:

C:\Documents and Settings\Administrator>java -version
java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b06)
Java HotSpot(TM) Client VM (build 17.0-b16, mixed mode, sharing)

Jvm server 代码:

[root@kaifa02 ~]# java -version
java version "1.6.0_06"
Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot(TM) Server VM (build 10.0-b22, mixed mode)

两种模式的切换可以通过更改配置(jvm.cfg 配置文件)来实现:
32 位的虚拟机在目录 JAVA_HOME/jre/lib/i386/jvm.cfg,

64 位的在 JAVA_HOME/jre/lib/amd64/jvm.cfg, 目前 64 位只支持 server 模式, 配置内容大致如下

-server KNOWN
-client KNOWN
-hotspot ALIASED_TO -client
-classic WARN
-native ERROR
-green ERROR

一般只要变更 -server KNOWN 与 -client KNOWN 两个配置位置先后顺序即可,前提是 JAVA_HOME/jre/bin 目录下同时存在 server 与 client 两个文件夹,分别对应着各自的 jvm.