中文版 Java 6 JVM参数选项大全

注意：你熟悉的代码里没调用System.gc()，不代表你依赖的框架工具没在使用。

例如RMI就在多数用户毫不知情的情况下，显示地调用GC来防止自身OOM。

请仔细权衡禁用带来的影响。

新Class类型校验器，将老的校验步骤拆分成了两步：

1，类型推断。

2，类型校验。

新类型校验器通过在javac编译时嵌入类型信息到bytecode中，省略了类型推断这一步，从而提升了classloader的性能。

Classload顺序(供参考)

load -> verify -> prepare -> resove -> init

关联选项：

-XX:+FailOverToOldVerifier

为什么会失败？

因为JDK6最高向下兼容到JDK1.2，而JDK1.2的class info 与JDK6的info存在较大的差异，所以新校验器可能会出现校验失败的情况。

关联选项：

     -XX:+UseSplitVerifier

在一次理想化的minor gc中，Eden和First Survivor中的活跃对象会被复制到Second Survivor。

然而，Second Survivor不一定能容纳下所有从E和F区copy过来的活跃对象。

为了确保minor gc能够顺利完成，GC需要在年老代中额外保留一块足以容纳所有活跃对象的内存空间。

这个预留操作，就被称之为新生代收集担保(New Generation Guarantee)。如果预留操作无法完成时，仍会触发major gc(full gc)。

为什么要关闭新生代收集担保？

因为在年老代中预留的空间大小，是无法精确计算的。

为了确保极端情况的发生，GC参考了最坏情况下的新生代内存占用，即Eden+First Survivor。

这种策略无疑是在浪费年老代内存，从时序角度看，还会提前触发Full GC。

为了避免如上情况的发生，JVM允许开发者手动关闭新生代收集担保。

在开启本选项后，minor gc将不再提供新生代收集担保，而是在出现survior或年老代不够用时，抛出promotion failed异常。

大家知道，Java的多线程安全是基于Lock机制实现的，而Lock的性能往往不如人意。

原因是，monitorenter与monitorexit这两个控制多线程同步的bytecode原语，是JVM依赖操作系统互斥(mutex)来实现的。

互斥是一种会导致线程挂起，并在较短的时间内又必须重新调度回原线程的，较为消耗资源的操作。

为了避免进入OS互斥，Java6的开发者们提出了自旋锁优化。

自旋锁优化的原理是在线程进入OS互斥前，通过CAS自旋一定的次数来检测锁的释放。

如果在自旋次数未达到预设值前锁已被释放，则当前线程会立即持有该锁。

CAS检测锁的原理详见:http://kenwublog.com/theory-of-lightweight-locking-upon-cas

关联选项：

-XX:PreBlockSpin=10

-XX:+UseSpinning

JVM在启动时，会申请最大值(-Xmx指定的数值)的地址空间，但其中绝大部分空间不会被立即分配(virtual)。

它们会一直保留着，直到运行过程中，JVM发现实际占用接近已分配上限值时，才从virtual里再分配掉一部分内存。

这里提到的已分配上限值，也可以叫做预估上限值。

引入预估上限值的好处是，可以有效地控制堆的大小。堆越小，GC效率越高嘛。

注意：预估上限值的大小一定小于或等于最大值。

1.3.1 -client: 32m

其他默认 64m

关联选项：

-XX:MaxHeapFreeRatio=70

x86 -client: 12

-client: 4 (1.3)

8 (1.3.1+)

x86: 12

其他默认 2

x86, 5.0以后: 640k

其他默认 2.125m

其他默认 32m

Solaris platforms5.0以前: 32

其他默认 8

Sparc 64 bit: 1024

Linux amd64: 1024 (5.0 以前 0)

其他默认 512.

关联选项

-XX:LargePageSizeInBytes=4m

当java进程因OOM或crash被OS强制终止后，会生成一个hprof(Heap PROFling)格式的堆内存快照文件。该文件用于线下调试，诊断，查找问题。

文件名一般为

java____heapDump.hprof

解析快照文件，可以使用 jhat, eclipse MAT，gdb等工具。