这个是目前公司某高并发应用生产环境的JVM启动参数，该应用日pv近亿。
一、先看一下生产环境的Java版本：
java version "1.6.0_33" Java(TM) SE Runtime Environment (build 1.6.0_33-b04) Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03, mixed mode)
二、JVM参数如下(将应用名以xxxxx代替)：
java -Xms4g -Xmx4g -Xmn3g -Xss256k -server -XX:PermSize=64M -XX:MaxPermSize=64M -XX:+UseConcMarkSweepGC -XX:+UseAdaptiveSizePolicy -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -XX:+UseCMSCompactAtFullCollection -XX:+DisableExplicitGC -XX:CMSFullGCsBeforeCompaction=10 -XX:CMSMaxAbortablePrecleanTime=5 -XX:+HeapDumpOnOutOfMemoryError -jar xxxxx.jar
三、部分参数解析：
由于原先写过一篇《JVM分代、垃圾回收概念与一个JVM参数调优示例》，那个应用(同样高并发)的JVM参数和这个基本相同，因此，这里就直接略过一些常见参数，只对一些关键参数重新做一下说明。
-server：
启用-server时新生代默认采用并行收集，其他情况下，默认不启用。-server策略为：新生代使用并行清除，年老代使用单线程Mark-Sweep-Compact的垃圾收集器。
-XX:+UseConcMarkSweepGC：
设置年老代为并发收集。
-XX:+UseAdaptiveSizePolicy：
上文中，因启用-server模式，所以新生代使用并行收集器。
设置此选项后，并行收集器会自动选择年轻代区大小和相应的Survivor区比例，以达到目标系统规定的最低相应时间或者收集频率等，建议使用并行收集器时一直打开。
-XX:+CMSClassUnloadingEnabled：
年老代启用CMS，但默认是不会回收永久代(Perm)的。此处对Perm区启用类回收，防止Perm区内存满。（需要与+CMSPermGenSweepingEnabled同时启用）。
-XX:+CMSPermGenSweepingEnabled：
同上，为了避免Perm区满引起的Full GC，开启并发收集器回收Perm区选项。
-XX:+UseCMSCompactAtFullCollection：
年老代使用CMS，默认是不会整理堆碎片的。设置此配置打开对年老代的压缩，即执行Full GC后对内存进行整理压缩，免得产生内存碎片，但有可能会影响性能。
-XX:CMSFullGCsBeforeCompaction=10：
接上文，因为过于频繁的在Full GC后进行碎片整理会影响性能，因此，设置执行10次Full GC后做一次碎片整理。
-XX:CMSMaxAbortablePrecleanTime=5：
指定CMS-concurrent-abortable-preclean阶段执行的时间，该阶段主要是执行一些预清理，减少应用暂停的时间。但在JDK 5.0+、6.0+的版本中有可能会由于JDK的bug29导致CMS在remark完毕后很久才触发sweeping动作。通过设置-XX: CMSMaxAbortablePrecleanTime=5（单位为ms）来避免。
PS：
关于CMS(Concurrent Mark-Sweep)：并发垃圾收集器，以牺牲吞吐量为代价来获得最短回收停顿时间的垃圾回收器，适用于要求服务器响应速度的应用。标记-清除、垃圾回收都是多线程，应用只暂停很少时间。
关于并行垃圾收集器：标记-清除为单线程，回收仍为多个线程并发执行。应用暂停时间较长(相对于并发垃圾回收器)。