JVM堆相关知识
    为什么先说JVM堆?
    JVM的堆是Java对象的活动空间，程序中的类的对象从中分配空间，其存储着正在运行着的应用程序用到的所有对象。这些对象的建立方式就是那些new一类的操作，当对象无用后，是GC来负责这个无用的对象(地球人都知道)。
JVM堆
    (1) 新域：存储所有新成生的对象
    (2) 旧域：新域中的对象，经过了一定次数的GC循环后，被移入旧域
    (3)永久域：存储类和方法对象，从配置的角度看，这个域是独立的，不包括在JVM堆内。默认为4M。

新域会被分为3个部分：1.第一个部分叫Eden。(伊甸园？？可能是因为亚当和夏娃是人类最早的活动对象？)2.另两个部分称为辅助生存空间(幼儿园)，我这里一个称为A空间(From sqace)，一个称为B空间(To Space)。

GC浅谈:
GC的工作目的很明确：在堆中，找到已经无用的对象，并把这些对象占用的空间收回使其可以重新利用.大多数垃圾回收的算法思路都是一致的：把所有对象组成一个集合，或可以理解为树状结构，从树根开始找，只要可以找到的都是活动对象，如果找不到，这个对象就是凋零的昨日黄花，应该被回收了。
在sun 的文档说明中，对JVM堆的新域，是采用coping算法，该算法的提出是为了克服句柄的开销和解决堆碎片的垃圾回收。它开始时把堆分成一个对象面和多个空闲面，程序从对象面为对象分配空间，当对象满了，基于 coping算法的垃圾收集就从根集中扫描活动对象，并将每个活动对象复制到空闲面(使得活动对象所占的内存之间没有空闲洞)，这样空闲面变成了对象面，原来的对象面变成了空闲面，程序会在新的对象面中分配内存。

对于新生成的对象，都放在Eden中；当Eden充满时（小孩太多了），GC将开始工作，首先停止应用程序的运行，开始收集垃圾，把所有可找到的对象都复制到A空间中，一旦当A空间充满，GC就把在A空间中可找到的对象都复制到B空间中(会覆盖原有的存储对象)，当B空间满的时间，GC就把在B空间中可找到的对象都复制到A空间中，AB在这个过程中互换角色，那位客官说了：拷来拷去，烦不烦啊？什么时候是头？您别急，在活动对象经过一定次数的GC操作后，这些活动对象就会被放到旧域中。对于这些活动对象，新域的幼儿园生活结束了。
新域为什么要这么折腾？
起初在这块我也很迷糊，又查了些资料，原来是这样：应用程序生成的绝大部分对象都是短命的，copying算法最理想的状态是，所有移出Eden的对象都会被收集，因为这些都是短命鬼，经过一定次数的GC后应该被收集，那么移入到旧域的对象都是长命的，这样可以防止AB空间的来回复制影响应用程序。
实际上这种理想状态是很难达到的，应用程序中不可避免地存在长命的对象，copying算法的发明者要这些对象都尽量放在新域中，以保证小范围的复制，压缩旧域的开销可比新域中的复制大得多(旧域在下面说)。

对于旧域，采用的是tracing算法的一种，称为标记-清除-压缩收集器，注意，这有一个压缩，这是个开销挺大的操作。

垃圾回收主要是对Young Generation块和Old Generation块内存进行回收，YG用来放新产生的对象，经过几次回收还没回收掉的对象往OG中移动，对YG进行垃圾回收又叫做MinorGC，对OG垃圾回收又叫MajorGC，两块内存回收互不干涉。

部署过程描述如下：

1. 在需要监测的机器（我这里是 Linux 机器）部署相关应用：

a)在你需要进行监测的机器上安装 JDK1.5 （狂晕一阵子），别倒下（这个部分就不多说了，因为如果这里还要解释的话，那我就晕了）。

b)正确设置 Java 的运行环境。

c)启动 jstatd 进程。

命令如下： ./jstatd -J-Djava.security.policy=all.policy

一般来说呢，这里是会出现问题的，那就是 permission 的问题了，还好， Sun 的网站上给了相关的解决方法，方法如下，在 vi $JAVA_HOME/jre/lib/security/java.policy文件中添加下面的代码：

grant codebase "file:${java.home}/../lib/tools.jar" {

permission java.security.AllPermission;

};

然后重新启动 jstatd 进程。

d)完了，别让人乱动就好了，我经常是不小心就按 CTRL+C 把程序关闭了。

2.       在客户端（监控者使用的机器）的操作：

a)使用 jps 查看远端机器有哪些 JVM 进程在使用当中，命令如下：

jps 172.25.1.24 // 远端机器的 IP 地址或名称

屏幕输入如下：

13686 Jstatd

14115 XXXJavaServer

15117 Jserver

b)从上面可以看到远端机器的 Jstatd 进程已经启动起来了。我们就可以使用 jstat 对相关进程的具体情况进行查看。

Jstat 命令用法如下：

jstat -<option> [-t] [-h<lines>] <vmid> [<interval> [<count>]]

解释如下：

Option 包括以下选项：

-class

-compiler

-gc

-gccapacity

-gccause

-gcnew

-gcnewcapacity

-gcold

-gcoldcapacity

-gcpermcapacity

-gcutil

-printcompilation

Vmid 就是 jps 查看到的进程 id ，如上 Jserver 的进程 id 是 15117 。

Interval 是时间间隔，单位为毫秒， 1000 就是一秒。

Count 就是需要查看的次数。

例子假设我们需要查看 172.25.1.24 机器 vmid 为 15117 的 gc 的情况，可以输入下面的命令：

jstat -gc 15117@172.25.1.24 1000 3

然后你能看到四行信息（一行为 title ，剩下的就是你要的信息了），仔细看看就可以发现很多信息的了。

c) 那么下面就开始配置可视化的监控包， jvmstat ，下载好了后，解压到任意目录。

执行 visualgc ，然后就可以看到可视化的监控窗口。

例：

成功执行后你就能看见一个 java 的监视窗口（样子还蛮专业的），这个时候就 可以开始监视了。

StatGen.java
import java.util.ArrayList;
import java.util.List;

public class StatGen {

    static final int MAX_BLOCK = 8*1024*100;

    public static void main(String[] args) {
        try{
            int numLoops = 1;
            if (args.length > 0){
                 numLoops = Integer.parseInt(args[0]);
            }
            System.out.println("#loops="+numLoops);
            
            List<long[]> list = new ArrayList<long[]>(numLoops);
            for (int i=0;i<numLoops;i++){
                int sz = (int) (Math.random()*MAX_BLOCK);
                long[] garbage = new long[sz];
                if (sz % 5 == 0){
                    list.add(garbage);
                }
                System.out.println("Sleeping 0.5s");
                Thread.sleep(500);
            }
            System.out.println("Done");
        } catch (Throwable t) {
              t.printStackTrace();
        }
        System.exit(0);
    }
}

 注：由于JVM内存设置较大，图中百分比变化不太明显



    图中参数含义如下：

    S0  — Heap上的 Survivor space 0 区已使用空间的百分比
    S1  — Heap上的 Survivor space 1 区已使用空间的百分比
    E   — Heap上的 Eden space 区已使用空间的百分比
    O   — Heap上的 Old space 区已使用空间的百分比
    P   — Perm space 区已使用空间的百分比
    YGC — 从应用程序启动到采样时发生 Young GC 的次数
    YGCT– 从应用程序启动到采样时 Young GC 所用的时间(单位秒)
    FGC — 从应用程序启动到采样时发生 Full GC 的次数
    FGCT– 从应用程序启动到采样时 Full GC 所用的时间(单位秒)
    GCT — 从应用程序启动到采样时用于垃圾回收的总时间(单位秒) 

*************************************

Sun的   Java   HotSpot(热区)   虚拟机将堆划分成三块区域同时用了三种垃圾收集技术。将堆进行拆分的目的是允许为新建立的对象和旧对象使用不同的算法。   这种技术是因为大多数的Java对象是生命周期较短的对象。堆的三个块区域为：

1. permanent space持久空间: 用于类和方法对象的存储

2. old space 旧对象空间:用于建立一段时间的对象

3. eden space 新对象空间:用于新建立的对象

新对象空间被进一步划分成3个子区域：  
      1，Eden：所有的新建立的对象存储处。  
      2，Survivor   Space   0   或   1：在新对象成为旧对象之前的对象存储处。

*************************************


          上图的示例，红框中，我们可以看到，5次young gc之后，垃圾内存被从Eden space区(E)放入了Old space区(O)，并引起了百分比的变化，导致 Survivor space使用的百分比从19.69%(S0)降到10.34%(S1)。有效释放了内存空间。绿框中，我们可以看到，一次full gc之后，Old space区(O)的内存被回收，从36.81%降到35.01%。 


          图中同时打印了young gc和full gc的总次数、总耗时。而，每次young gc消耗的时间，可以用相间隔的两行YGCT相减得到。每次full gc消耗的时间，可以用相隔的两行FGCT相减得到。例如红框中表示的第一行、第二行之间发生了1次young gc，消耗的时间为52.281-52.252＝0.029秒。


         常驻内存区(P)的使用率，始终停留在37.6%左右，说明常驻内存没有突变，比较正常。

           如果young gc和full gc能够正常发生，而且都能有效回收内存，常驻内存区变化不明显，则说明java内存释放情况正常，垃圾回收及时，java内存泄露的几率就会大大降低。但也不能说明一定没有内存泄露。