A、JVM运行时数据区域
JVM执行Java程序的过程中，会使用到各种数据区域，这些区域有各自的用途、创建和销毁时间。根据《Java虚拟机规范（第二版）》（下文称VM Spec）的规定，JVM包括下列几个运行时数据区域：
1.程序计数器（Program Counter Register）：
每一个Java线程都有一个程序计数器来用于保存程序执行到当前方法的哪一个指令，对于非Native方法，这个区域记录的是正在执行的VM原语的地址，如果正在执行的是Natvie方法，这个区域则为空（undefined）。此内存区域是唯一一个在VM Spec中没有规定任何OutOfMemoryError情况的区域。
2.Java虚拟机栈（Java Virtual Machine Stacks）
与程序计数器一样，VM栈的生命周期也是与线程相同。VM栈描述的是Java方法调用的内存模型：每个方法被执行的时候，都会同时创建一个帧（Frame）用于存储本地变量表、操作栈、动态链接、方法出入口等信息。每一个方法的调用至完成，就意味着一个帧在VM栈中的入栈至出栈的过程。在后文中，我们将着重讨论VM栈中本地变量表部分。
经常有人把Java内存简单的区分为堆内存（Heap）和栈内存（Stack），实际中的区域远比这种观点复杂，这样划分只是说明与变量定义密切相关的内存区域是这两块。其中所指的“堆”后面会专门描述，而所指的“栈”就是VM栈中各个帧的本地变量表部分。本地变量表存放了编译期可知的各种标量类型（boolean、byte、char、short、int、float、long、double）、对象引用（不是对象本身，仅仅是一个引用指针）、方法返回地址等。其中long和double会占用2个本地变量空间（32bit），其余占用1个。本地变量表在进入方法时进行分配，当进入一个方法时，这个方法需要在帧中分配多大的本地变量是一件完全确定的事情，在方法运行期间不改变本地变量表的大小。
在VM Spec中对这个区域规定了2中异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；如果VM栈可以动态扩展（VM Spec中允许固定长度的VM栈），当扩展时无法申请到足够内存则抛出OutOfMemoryError异常。
3.本地方法栈（Native Method Stacks）
本地方法栈与VM栈所发挥作用是类似的，只不过VM栈为虚拟机运行VM原语服务，而本地方法栈是为虚拟机使用到的Native方法服务。它的实现的语言、方式与结构并没有强制规定，甚至有的虚拟机（譬如Sun Hotspot虚拟机）直接就把本地方法栈和VM栈合二为一。和VM栈一样，这个区域也会抛出StackOverflowError和OutOfMemoryError异常。
4.Java堆（Java Heap）
对于绝大多数应用来说，Java堆是虚拟机管理最大的一块内存。Java堆是被所有线程共享的，在虚拟机启动时创建。Java堆的唯一目的就是存放对象实例，绝大部分的对象实例都在这里分配。这一点在VM Spec中的描述是：所有的实例以及数组都在堆上分配（原文：The heap is the runtime data area from which memory for all class instances and arrays is allocated），但是在逃逸分析和标量替换优化技术出现后，VM Spec的描述就显得并不那么准确了。
Java堆内还有更细致的划分：新生代、老年代，再细致一点的：eden、from survivor、to survivor，甚至更细粒度的本地线程分配缓冲（TLAB）等，无论对Java堆如何划分，目的都是为了更好的回收内存，或者更快的分配内存，在本章中我们仅仅针对内存区域的作用进行讨论，Java堆中的上述各个区域的细节，可参见本文第二章《JVM内存管理：深入垃圾收集器与内存分配策略》。
根据VM Spec的要求，Java堆可以处于物理上不连续的内存空间，它逻辑上是连续的即可，就像我们的磁盘空间一样。实现时可以选择实现成固定大小的，也可以是可扩展的，不过当前所有商业的虚拟机都是按照可扩展来实现的（通过-Xmx和-Xms控制）。如果在堆中无法分配内存，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。
5.方法区（Method Area）
叫“方法区”可能认识它的人还不太多，如果叫永久代（Permanent Generation）它的粉丝也许就多了。它还有个别名叫做Non-Heap（非堆），但是VM Spec上则描述方法区为堆的一个逻辑部分（原文：the method area is logically part of the heap），这个名字的问题还真容易令人产生误解，我们在这里就不纠结了。
方法区中存放了每个Class的结构信息，包括常量池、字段描述、方法描述等等。VM Space描述中对这个区域的限制非常宽松，除了和Java堆一样不需要连续的内存，也可以选择固定大小或者可扩展外，甚至可以选择不实现垃圾收集。相对来说，垃圾收集行为在这个区域是相对比较少发生的，但并不是某些描述那样永久代不会发生GC（至少对当前主流的商业JVM实现来说是如此），这里的GC主要是对常量池的回收和对类的卸载，虽然回收的“成绩”一般也比较差强人意，尤其是类卸载，条件相当苛刻。
6.运行时常量池（Runtime Constant Pool）
Class文件中除了有类的版本、字段、方法、接口等描述等信息外，还有一项信息是常量表(constant_pool table)，用于存放编译期已可知的常量，这部分内容将在类加载后进入方法区（永久代）存放。但是Java语言并不要求常量一定只有编译期预置入Class的常量表的内容才能进入方法区常量池，运行期间也可将新内容放入常量池（最典型的String.intern()方法）。
运行时常量池是方法区的一部分，自然受到方法区内存的限制，当常量池无法在申请到内存时会抛出OutOfMemoryError异常。
7.本机直接内存（Direct Memory）
直接内存并不是虚拟机运行时数据区的一部分，它根本就是本机内存而不是VM直接管理的区域。但是这部分内存也会导致OutOfMemoryError异常出现，因此我们放到这里一起描述。
在JDK1.4中新加入了NIO类，引入一种基于渠道与缓冲区的I/O方式，它可以通过本机Native函数库直接分配本机内存，然后通过一个存储在Java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java对和本机堆中来回复制数据。
显然本机直接内存的分配不会受到Java堆大小的限制，但是即然是内存那肯定还是要受到本机物理内存（包括SWAP区或者Windows虚拟内存）的限制的，一般服务器管理员配置JVM参数时，会根据实际内存设置-Xmx等参数信息，但经常忽略掉直接内存，使得各个内存区域总和大于物理内存限制（包括物理的和操作系统级的限制），而导致动态扩展时出现OutOfMemoryError异常。
B、实战OutOfMemoryError
上述区域中，除了程序计数器，其他在VM Spec中都描述了产生OutOfMemoryError（下称OOM）的情形，那我们就实战模拟一下，通过几段简单的代码，令对应的区域产生OOM异常以便加深认识，同时初步介绍一些与内存相关的虚拟机参数。下文的代码都是基于Sun Hotspot虚拟机1.6版的实现，对于不同公司的不同版本的虚拟机，参数与程序运行结果可能结果会有所差别。
Java堆
Java堆存放的是对象实例，因此只要不断建立对象，并且保证GC Roots到对象之间有可达路径即可产生OOM异常。测试中限制Java堆大小为20M，不可扩展，通过参数-XX:+HeapDumpOnOutOfMemoryError让虚拟机在出现OOM异常的时候Dump出内存映像以便分析。（关于Dump映像文件分析方面的内容，可参见本文第三章《JVM内存管理：深入JVM内存异常分析与调优》。）
清单1：Java堆OOM测试
|
/** * VM Args：-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError * @author zzm */ public class HeapOOM {
static class OOMObject { }
public static void main(String[] args) { List<OOMObject> list = new ArrayList<OOMObject>();
while (true) { list.add(new OOMObject()); } } } |
运行结果：
|
java.lang.OutOfMemoryError: Java heap space Dumping heap to java_pid3404.hprof ... Heap dump file created [22045981 bytes in 0.663 secs] |
VM栈和本地方法栈
Hotspot虚拟机并不区分VM栈和本地方法栈，因此-Xoss参数实际上是无效的，栈容量只由-Xss参数设定。关于VM栈和本地方法栈在VM Spec描述了两种异常：StackOverflowError与OutOfMemoryError，当栈空间无法继续分配分配时，到底是内存太小还是栈太大其实某种意义上是对同一件事情的两种描述而已，在笔者的实验中，对于单线程应用尝试下面3种方法均无法让虚拟机产生OOM，全部尝试结果都是获得SOF异常。
1.使用-Xss参数削减栈内存容量。结果：抛出SOF异常时的堆栈深度相应缩小。
2.定义大量的本地变量，增大此方法对应帧的长度。结果：抛出SOF异常时的堆栈深度相应缩小。
3.创建几个定义很多本地变量的复杂对象，打开逃逸分析和标量替换选项，使得JIT编译器允许对象拆分后在栈中分配。结果：实际效果同第二点。
清单2：VM栈和本地方法栈OOM测试（仅作为第1点测试程序）
|
/** * VM Args：-Xss128k * @author zzm */ public class JavaVMStackSOF {
private int stackLength = 1;
public void stackLeak() { stackLength++; stackLeak(); }
public static void main(String[] args) throws Throwable { JavaVMStackSOF oom = new JavaVMStackSOF(); try { oom.stackLeak(); } catch (Throwable e) { System.out.println("stack length:" + oom.stackLength); throw e; } } } |
运行结果：
|
stack length:2402 Exception in thread "main" java.lang.StackOverflowError at org.fenixsoft.oom.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:20) at org.fenixsoft.oom.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:21) at org.fenixsoft.oom.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:21) |
如果在多线程环境下，不断建立线程倒是可以产生OOM异常，但是基本上这个异常和VM栈空间够不够关系没有直接关系，甚至是给每个线程的VM栈分配的内存越多反而越容易产生这个OOM异常。
原因其实很好理解，操作系统分配给每个进程的内存是有限制的，譬如32位Windows限制为2G，Java堆和方法区的大小JVM有参数可以限制最大值，那剩余的内存为2G（操作系统限制）-Xmx（最大堆）-MaxPermSize（最大方法区），程序计数器消耗内存很小，可以忽略掉，那虚拟机进程本身耗费的内存不计算的话，剩下的内存就供每一个线程的VM栈和本地方法栈瓜分了，那自然每个线程中VM栈分配内存越多，就越容易把剩下的内存耗尽。
清单3：创建线程导致OOM异常
|
/** * VM Args：-Xss2M （这时候不妨设大些） * @author zzm */ public class JavaVMStackOOM {
private void dontStop() { while (true) { } }
public void stackLeakByThread() { while (true) { Thread thread = new Thread(new Runnable() { @Override public void run() { dontStop(); } }); thread.start(); } }
public static void main(String[] args) throws Throwable { JavaVMStackOOM oom = new JavaVMStackOOM(); oom.stackLeakByThread(); } } |
特别提示一下，如果读者要运行上面这段代码，记得要存盘当前工作，上述代码执行时有很大令操作系统卡死的风险。
运行结果：
|
Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread |
运行时常量池
要在常量池里添加内容，最简单的就是使用String.intern()这个Native方法。由于常量池分配在方法区内，我们只需要通过-XX:PermSize和-XX:MaxPermSize限制方法区大小即可限制常量池容量。实现代码如下：
清单4：运行时常量池导致的OOM异常
|
/** * VM Args：-XX:PermSize=10M -XX:MaxPermSize=10M * @author zzm */ public class RuntimeConstantPoolOOM {
public static void main(String[] args) { // 使用List保持着常量池引用，压制Full GC回收常量池行为 List<String> list = new ArrayList<String>(); // 10M的PermSize在integer范围内足够产生OOM了 int i = 0; while (true) { list.add(String.valueOf(i++).intern()); } } } |
运行结果：
|
Exception in thread "main" java.lang.OutOfMemoryError: PermGen space at java.lang.String.intern(Native Method) at org.fenixsoft.oom.RuntimeConstantPoolOOM.main(RuntimeConstantPoolOOM.java:18) |
方法区
上文讲过，方法区用于存放Class相关信息，所以这个区域的测试我们借助CGLib直接操作字节码动态生成大量的Class，值得注意的是，这里我们这个例子中模拟的场景其实经常会在实际应用中出现：当前很多主流框架，如Spring、Hibernate对类进行增强时，都会使用到CGLib这类字节码技术，当增强的类越多，就需要越大的方法区用于保证动态生成的Class可以加载入内存。
清单5：借助CGLib使得方法区出现OOM异常
|
/** * VM Args： -XX:PermSize=10M -XX:MaxPermSize=10M * @author zzm */ public class JavaMethodAreaOOM {
public static void main(String[] args) { while (true) { Enhancer enhancer = new Enhancer(); enhancer.setSuperclass(OOMObject.class); enhancer.setUseCache(false); enhancer.setCallback(new MethodInterceptor() { public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable { return proxy.invokeSuper(obj, args); } }); enhancer.create(); } }
static class OOMObject {
} } |
运行结果：
|
Caused by: java.lang.OutOfMemoryError: PermGen space at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) at java.lang.ClassLoader.defineClass(ClassLoader.java:616) ... 8 more |
本机直接内存
DirectMemory容量可通过-XX:MaxDirectMemorySize指定，不指定的话默认与Java堆（-Xmx指定）一样，下文代码越过了DirectByteBuffer，直接通过反射获取Unsafe实例进行内存分配（Unsafe类的getUnsafe()方法限制了只有引导类加载器才会返回实例，也就是基本上只有rt.jar里面的类的才能使用），因为DirectByteBuffer也会抛OOM异常，但抛出异常时实际上并没有真正向操作系统申请分配内存，而是通过计算得知无法分配既会抛出，真正申请分配的方法是unsafe.allocateMemory()。
|
/** * VM Args：-Xmx20M -XX:MaxDirectMemorySize=10M * @author zzm */ public class DirectMemoryOOM {
private static final int _1MB = 1024 * 1024;
public static void main(String[] args) throws Exception { Field unsafeField = Unsafe.class.getDeclaredFields()[0]; unsafeField.setAccessible(true); Unsafe unsafe = (Unsafe) unsafeField.get(null); while (true) { unsafe.allocateMemory(_1MB); } } } |
运行结果：
|
Exception in thread "main" java.lang.OutOfMemoryError at sun.misc.Unsafe.allocateMemory(Native Method) at org.fenixsoft.oom.DirectMemoryOOM.main(DirectMemoryOOM.java:20) |
C、JVM的gc
1.JVM的gc概述
gc即垃圾收集机制是指JVM用于释放那些不再使用的对象所占用的内存。Java语言并不要求JVM有gc，也没有规定gc如何工作。不过常用的JVM都有gc，而且大多数gc都使用类似的算法管理内存和执行收集操作。
在充分理解了垃圾收集算法和执行过程后，才能有效的优化它的性能。有些垃圾收集专用于特殊的应用程序。比如，实时应用程序主要是为了避免垃圾收集中断，而大多数OLTP应用程序则注重整体效率。理解了应用程序的工作负荷和JVM支持的垃圾收集算法，便可以进行优化配置垃圾收集器。
垃圾收集的目的在于清除不再使用的对象。gc通过确定对象是否被活动对象引用来确定是否收集该对象。gc首先要判断该对象是否是时候可以收集。两种常用的方法是引用计数和对象引用遍历。
1.1.引用计数
引用计数存储对特定对象的所有引用数，也就是说，当应用程序创建引用以及引用超出范围时，JVM必须适当增减引用数。当某对象的引用数为0时，便可以进行垃圾收集。
1.2.对象引用遍历
早期的JVM使用引用计数，现在大多数JVM采用对象引用遍历。对象引用遍历从一组对象开始，沿着整个对象图上的每条链接，递归确定可到达（reachable）的对象。如果某对象不能从这些根对象的一个（至少一个）到达，则将它作为垃圾收集。在对象遍历阶段，gc必须记住哪些对象可以到达，以便删除不可到达的对象，这称为标记（marking）对象。
下一步，gc要删除不可到达的对象。删除时，有些gc只是简单的扫描堆栈，删除未标记的未标记的对象，并释放它们的内存以生成新的对象，这叫做清除（sweeping）。这种方法的问题在于内存会分成好多小段，而它们不足以用于新的对象，但是组合起来却很大。因此，许多gc可以重新组织内存中的对象，并进行压缩（compact），形成可利用的空间。
为此，gc需要停止其他的活动活动。这种方法意味着所有与应用程序相关的工作停止，只有gc运行。结果，在响应期间增减了许多混杂请求。另外，更复杂的gc不断增加或同时运行以减少或者清除应用程序的中断。有的gc使用单线程完成这项工作，有的则采用多线程以增加效率。
2.几种垃圾回收机制
2.1.标记－清除收集器
这种收集器首先遍历对象图并标记可到达的对象，然后扫描堆栈以寻找未标记对象并释放它们的内存。这种收集器一般使用单线程工作并停止其他操作。
2.2.标记－压缩收集器
有时也叫标记－清除－压缩收集器，与标记－清除收集器有相同的标记阶段。在第二阶段，则把标记对象复制到堆栈的新域中以便压缩堆栈。这种收集器也停止其他操作。
2.3.复制收集器
这种收集器将堆栈分为两个域，常称为半空间。每次仅使用一半的空间，JVM生成的新对象则放在另一半空间中。gc运行时，它把可到达对象复制到另一半空间，从而压缩了堆栈。这种方法适用于短生存期的对象，持续复制长生存期的对象则导致效率降低。
2.4.增量收集器
增量收集器把堆栈分为多个域，每次仅从一个域收集垃圾。这会造成较小的应用程序中断。
2.5.分代收集器
这种收集器把堆栈分为两个或多个域，用以存放不同寿命的对象。JVM生成的新对象一般放在其中的某个域中。过一段时间，继续存在的对象将获得使用期并转入更长寿命的域中。分代收集器对不同的域使用不同的算法以优化性能。
2.6.并发收集器
并发收集器与应用程序同时运行。这些收集器在某点上（比如压缩时）一般都不得不停止其他操作以完成特定的任务，但是因为其他应用程序可进行其他的后台操作，所以中断其他处理的实际时间大大降低。
2.7.并行收集器
并行收集器使用某种传统的算法并使用多线程并行的执行它们的工作。在多cpu机器上使用多线程技术可以显著的提高Java应用程序的可扩展性。
3.Sun HotSpot
1.4.1 JVM堆大小的调整
Sun HotSpot 1.4.1使用分代收集器，它把堆分为三个主要的域：新域、旧域以及永久域。JVM生成的所有新对象放在新域中。一旦对象经历了一定数量的垃圾收集循环后，便获得使用期并进入旧域。
在永久域中JVM则存储class和method对象。就配置而言，永久域是一个独立域并且不认为是堆的一部分。下面介绍如何控制这些域的大小。可使用-Xms和-Xmx 控制整个堆的原始大小或最大值。
下面的命令是把初始大小设置为128M：
Java –Xms128m |
–Xmx256m为控制新域的大小，可使用-XX:NewRatio设置新域在堆中所占的比例。下面的命令把整个堆设置成128m，新域比率设置成3，即新域与旧域比例为1：3，新域为堆的1/4或32M：
Java –Xms128m –Xmx128m |
–XX:NewRatio =3可使用-XX:NewSize和-XX:MaxNewsize设置新域的初始值和最大值。
下面的命令把新域的初始值和最大值设置成64m:
Java –Xms256m –Xmx256m –Xmn64m |
永久域默认大小为4m。运行程序时，JVM会调整永久域的大小以满足需要。每次调整时，JVM会对堆进行一次完全的垃圾收集。
使用-XX:MaxPerSize标志来增加永久域搭大小。在WebLogic Server应用程序加载较多类时，经常需要增加永久域的最大值。当JVM加载类时，永久域中的对象急剧增加，从而使JVM不断调整永久域大小。为了避免调整，可使用-XX:PerSize标志设置初始值。下面把永久域初始值设置成32m，最大值设置成64m。
Java -Xms512m -Xmx512m -Xmn128m -XX:PermSize=32m -XX:MaxPermSize=64m |
默认状态下，HotSpot在新域中使用复制收集器。该域一般分为三个部分。第一部分为Eden，用于生成新的对象。另两部分称为救助空间，当Eden充满时，收集器停止应用程序，把所有可到达对象复制到当前的from救助空间，一旦当前的from救助空间充满，收集器则把可到达对象复制到当前的to救助空间。
From和to救助空间互换角色。维持活动的对象将在救助空间不断复制，直到它们获得使用期并转入旧域。使用-XX:SurvivorRatio可控制新域子空间的大小。
同NewRation一样，SurvivorRation规定某救助域与Eden空间的比值。比如，以下命令把新域设置成64m，Eden占32m，每个救助域各占16m：
Java -Xms256m -Xmx256m -Xmn64m -XX:SurvivorRation =2 |
如前所述，默认状态下HotSpot对新域使用复制收集器，对旧域使用标记－清除－压缩收集器。在新域中使用复制收集器有很多意义，因为应用程序生成的大部分对象是短寿命的。理想状态下，所有过渡对象在移出Eden空间时将被收集。
如果能够这样的话，并且移出Eden空间的对象是长寿命的，那么理论上可以立即把它们移进旧域，避免在救助空间反复复制。但是，应用程序不能适合这种理想状态，因为它们有一小部分中长寿命的对象。
最好是保持这些中长寿命的对象并放在新域中，因为复制小部分的对象总比压缩旧域廉价。为控制新域中对象的复制，可用-XX:TargetSurvivorRatio控制救助空间的比例（该值是设置救助空间的使用比例。
如救助空间位1M，该值50表示可用500K）。该值是一个百分比，默认值是50。当较大的堆栈使用较低的sruvivorratio时，应增加该值到80至90，以更好利用救助空间。用-XX:maxtenuring threshold可控制上限。
为放置所有的复制全部发生以及希望对象从eden扩展到旧域，可以把MaxTenuring Threshold设置成0。设置完成后，实际上就不再使用救助空间了，因此应把SurvivorRatio设成最大值以最大化Eden空间，设置如下：
Java … -XX:MaxTenuringThreshold=0 –XX:SurvivorRatio＝50000 … |
4.BEA JRockit JVM的使用
Bea WebLogic 8.1使用的新的JVM用于Intel平台。在Bea安装完毕的目录下可以看到有一个类似于jrockit81sp1_141_03的文件夹。这就是Bea新JVM所在目录。不同于HotSpot把Java字节码编译成本地码，它预先编译成类。
JRockit还提供了更细致的功能用以观察JVM的运行状态，主要是独立的GUI控制台（只能适用于使用Jrockit才能使用jrockit81sp1_141_03自带的console监控一些cpu及memory参数）或者WebLogic Server控制台。
Bea JRockit JVM支持4种垃圾收集器：
4.1.1.分代复制收集器
它与默认的分代收集器工作策略类似。对象在新域中分配，即JRockit文档中的nursery。这种收集器最适合单cpu机上小型堆操作。
4.1.2.单空间并发收集器
该收集器使用完整堆，并与背景线程共同工作。尽管这种收集器可以消除中断，但是收集器需花费较长的时间寻找死对象，而且处理应用程序时收集器经常运行。如果处理器不能应付应用程序产生的垃圾，它会中断应用程序并关闭收集。
分代并发收集器 这种收集器在护理域使用排它复制收集器，在旧域中则使用并发收集器。由于它比单空间共同发生收集器中断频繁，因此它需要较少的内存，应用程序的运行效率也较高，注意，过小的护理域可以导致大量的临时对象被扩展到旧域中。这会造成收集器超负荷运作，甚至采用排它性工作方式完成收集。
4.1.3.并行收集器
该收集器也停止其他进程的工作，但使用多线程以加速收集进程。尽管它比其他的收集器易于引起长时间的中断，但一般能更好的利用内存，程序效率也较高。
默认状态下，JRockit使用分代并发收集器。要改变收集器，可使用：
-Xgc:<gc_name>
|
对应四个收集器分别为gencopy，singlecon，gencon以及parallel。可使用-Xms和-Xmx设置堆的初始大小和最大值。要设置护理域，则使用：
-Xns:Java –jrockit –Xms512m
–Xmx512m –Xgc:gencon –Xns128m…
|
尽管JRockit支持-verbose:gc开关，但它输出的信息会因收集器的不同而异。JRockit还支持memory、load和codegen的输出。
注意 ：如果 使用JRockit JVM的话还可以使用WLS自带的console（C:/bea/jrockit81sp1_141_03/bin下）来监控一些数据，如cpu，memery等。要想能构监控必须在启动服务时startWeblogic.cmd中加入－Xmanagement参数。
5.如何从JVM中获取信息来进行调整
-verbose.gc开关可显示gc的操作内容。打开它，可以显示最忙和最空闲收集行为发生的时间、收集前后的内存大小、收集需要的时间等。打开-xx:+ printgcdetails开关，可以详细了解gc中的变化。
打开-XX: + PrintGCTimeStamps开关，可以了解这些垃圾收集发生的时间，自JVM启动以后以秒计量。最后，通过-xx: + PrintHeapAtGC开关了解堆的更详细的信息。
为了了解新域的情况，可以通过-XX:=PrintTenuringDistribution开关了解获得使用期的对象权。
6.Pdm系统JVM调整
6.1.服务器：前提内存1G 单CPU
可通过如下参数进行调整：－server 启用服务器模式（如果CPU多，服务器机建议使用此项）
－Xms,－Xmx一般设为同样大小。 800m
－Xmn 是将NewSize与MaxNewSize设为一致。320m
－XX:PerSize 64m
－XX:NewSize 320m
此值设大可调大新对象区，减少Full GC次数
－XX:MaxNewSize 320m
－XX:NewRato NewSize
设了可不设。
－XX: SurvivorRatio
－XX:userParNewGC
可用来设置并行收集
－XX:ParallelGCThreads
可用来增加并行度
－XXUseParallelGC
设置后可以使用并行清除收集器
－XX：UseAdaptiveSizePolicy
与上面一个联合使用效果更好，利用它可以自动优化新域大小以及救助空间比值
6.2.客户机：通过在JNLP文件中设置参数来调整客户端JVM
JNLP中参数：initial-heap-size和max-heap-size
这可以在framework的RequestManager中生成JNLP文件时加入上述参数，但是这些值是要求根据客户机的硬件状态变化的（如客户机的内存大小等）。建议这两个参数值设为客户机可用内存的60％（有待测试）。
为了在动态生成JNLP时以上两个参数值能够随客户机不同而不同，可靠虑获得客户机系统信息并将这些嵌到首页index.jsp中作为连接请求的参数。
在设置了上述参数后可以通过Visualgc 来观察垃圾回收的一些参数状态，再做相应的调整来改善性能。一般的标准是减少fullgc的次数，最好硬件支持使用并行垃圾回收（要求多CPU）。
D、JAVA运行机制
一.GC基本概念：
GC定义：GC其实就是JVM的内存管理，GC在Heap中分配存储区域，在这些储存区域定义对象，数组和classes字节码。主要包括分配，回收2个步骤。
对象分配（Object allocation）：对象分配是请求驱动的（Driven by request）。每次的对象分配，为了解决线程的同步问题，均需要申请一个堆锁。每个线程都分配了一个线程本地堆（Thread Local Heap，TLH），作为对象分配的cache。如果对象小于512字节，则从TLH从分配，从而不需要申请堆锁，从而提高性能。
对象可达性（Reachable Objects）：当一个对象在JVM中属于活动状态，则成为对象可达。JVM通过记录root集来发现对象是否可达。JVM的活动状态是由线程栈，Java字节码，和本地和全局的JNI引用组成的。所有的函数调用，都会引发一个线程帧，通过这些线程帧可以得到root集。
GC：IBM JVM的GC采用的是MSC算法，即Mark-Sweep-Compaction，其中Compaction属于可选步骤。当堆空间不足以分配对象，或者调用System.gc()时发生GC。GC步骤是STW的（Stop The World），将会挂起所有的线程。
Mark：先获取Root集，然后通过root扫描所有引用，最后得到一个活动对象的数组。
Sweep：JVM中保存一个已分配内存的数组，Mark阶段得到一个活动对象的数组，2者相减就是回收的内存。目前采用的是bitsweep技术，避免直接扫描堆，通过检查已分配内存数组，可以分析出连续的空余空间，然后做出回收。
Compaction：即压缩活动对象，从而得到整块的空余空间。因为Compaction阶段非常消耗资源，尽量避免使用。
堆尺寸：通过-Xmx指定堆最大值，-Xms初始值。其中Windows 32位平台不超过2G-1，实际大概最大是1.5G。堆的尺寸会在运行过程中发生调整，直到一个稳定状态，即通常认为的70%占用率。
通过-verbosegc可以进行堆的参数调整。如：
<!--[if !supportLists]-->1. <!--[endif]-->当达到稳定状态前GC非常频繁，则应该提高堆初始值。
<!--[if !supportLists]-->2. <!--[endif]-->当堆的尺寸扩展超过70%，应该提高堆最大值，但是应该保证堆一直在物理内存里。
<!--[if !supportLists]-->3. <!--[endif]-->当发生70%扩展的频率过高，可以通过-Xminf调整比率参数。
<!--[if !supportLists]-->4. <!--[endif]-->如果停止时间过长，可以考虑通过-Xgcpolicy:optavgpause参数减少停止时间，大概比率是5%。
堆使用应该避免的事项：
<!--[if !supportLists]-->1. <!--[endif]-->避免页面换出
<!--[if !supportLists]-->2. <!--[endif]-->避免finalizer
<!--[if !supportLists]-->3. <!--[endif]-->避免compaction
系统堆
即System Heap，是具备完整JVM生命周期的对象。系统堆里面的对象不会被GC。初始化系统堆是128k（32位），8M（64位）。
二，GC内存分配
堆锁分配：
当申请对象超过512字节，或者TLH没有足够空间时需要在堆中进行内存分配，需要申请堆锁。算法：
1.如果有空间即直接分配，转5。
2.否则进行GC
3.如果GC后有足够内存，则进行分配，转5。
4.如果GC没有足够内存，则返回Out of memory.
5.释放堆锁HEAP_LOCK
TLH分配，即Cache分配：
前文已经描述，cache的尺寸从2K到164K。
LOA，即大对象的分配
为了增加大对象的分配性能。
初始化的LOA是堆的5%，每次GC后重新调整。LOA的优先级较低，调整优先满足-Xminf设置。调整算法：
1.如果空余空间和LOA相加小于-Xminf参数，则LOA是0.
2.如果空余空间少于-Xminf参数，LOA减少，直至2者相加等于-Xminf.
LOA缩小：如果在堆中分配内存失败，需要进行LOA缩小
1.如果当前堆尺寸大于初始化值，LOA空余空间大于70%，则LOA减少1%
2.如果当前堆尺寸等于或者小于初始值，且LOA空余空间大于90%
2.1如果LOA大于1%，则减少LOA1%
2.2如果LOA等于或小于1%，减少LOA0.1%
LOA扩展：如果在LOA中分配失败，需要进行LOA扩展
1.如果当前申请内存高于5倍的LOA，则每次扩展1%，直到20%。
2.如果当前堆小于初始值，且LOA空余空间小于50%，增加LOA1%。
3.如果当前堆大于或等于初始值，且LOA空余空间小于30%，增加LOA1%，直到20%。
分配：
LOA中的内存分配：
1.当请求内存超过64K
2.或者堆中没有空间不能满足，则从尝试从LOA分配空间。
固化对象簇（Pinned Cluster）:
在JVM中有些对象是不能被移动的，GC在堆底部分配一个kCluster对象，包括1280个入口，每个入口存储256个字节，用于存储固定对象。
另外，GC分配一个pCluster对象，用户存储任何的固定地址对象，16K大小。
1.当kCluster满以后，则分配在pCluster
2.pCluster满，则增加2k。
一，基本概念
JVM的阶段：
Loading：获取Class的字节码
Verification：检查字节码的结构，并且检查字节码的不能执行不被运行的操作。
Preparation：分配静态变量存储空间，创建方法列表。
Initializtion：执行类的初始化方法。
Eager和Lazy加载
JVM缺省加载所有的带有public static void main的方法
其他的类可以被延迟加载。
延迟加载：只有当第一个活动行为时加载该类：
<!--[if !supportLists]-->1. <!--[endif]-->一个对象被创建
<!--[if !supportLists]-->2. <!--[endif]-->子类的对象被创建
<!--[if !supportLists]-->3. <!--[endif]-->静态成员初始化
一些特别的类，如ClassNotFoundException被JVM加载。
二，Java2 CL
类装载器是用来把Class装载进JVM，为了安全性考虑，目前的Java2采用的是Parent-Delegation模型进行类加载的管理。
JVM规范定义了2种类型的类装载器：启动内装载器（bootstrap）和用户自定义装载器（user-defined class loader）。运行时会产生三个ClassLoader，即Bootstrap CL、Extension CL和Application CL。其中Bootstrap是用C++编写的，在Java中看不到它，是JVM自带的类装载器用来装载核心类库，如java.lang.*等。Application CL的Parent是Extension CL，而Extension CL的Parent为Bootstrap CL。
其中Application ClassLoader从本地文件系统加载，加载类的搜索路径在CLASSPATH定义。
命名空间及其作用：
每个类装载器有自己的命名空间，命名空间由所有以此装载器为创始类装载器的类组成。不同命名空间的两个类是不可见的，但只要得到类所对应的Class对象的reference，还是可以访问另一命名空间的类。
写自己的CL，常见的3中情况需要写自己的CL：
<!--[if !supportLists]-->1. <!--[endif]-->允许从其他的存储加载Class，如从网络加载
<!--[if !supportLists]-->2. <!--[endif]-->区分用户模式，如在Servlet引擎中使用
<!--[if !supportLists]-->3. <!--[endif]-->允许卸载Class。
IBM WAS中的CL：
目前WAS区分了4个层次，即
<!--[if !supportLists]-->1. <!--[endif]-->Java class loaders：JVM提供
<!--[if !supportLists]-->2. <!--[endif]-->WebSphere Extension class loader：加载Runtime, Library JARs等。
<!--[if !supportLists]-->3. <!--[endif]-->Application class loader：加载EJBs, RARs, Utility JARs等
<!--[if !supportLists]-->4. <!--[endif]-->WAR：加载具体的class loader
另外增加了一些特别的代理策略，
CL策略：
Single：只有一个单独的CL加载所有的类。
Application：WAR模块使用EAR应用的CL
Multiple：每个EAR应用有独立的CL。
其中CL的代理模式区分PARENT_FIRST和PARENT_LAST，即寻找类是否优先寻找父类的CL。
三，JIT
JIT，即Just-in-time Compiler，JIT技术是指将需要的java类字节码编译为本地机制的代码，从而取得更好的性能。
如果运行没有JIT，则启动增快，但是运行变慢；反之，如果启动有SIT，则启动变慢，但是运行变快。
JIT编译的4个阶段
<!--[if !supportLists]-->1. <!--[endif]-->字节码优化
<!--[if !supportLists]-->2. <!--[endif]-->Quad优化
<!--[if !supportLists]-->3. <!--[endif]-->DAG（有向无环图）优化
<!--[if !supportLists]-->4. <!--[endif]-->本地码生成
