为什么80%的码农都做不了架构师？>>> 
本文将由浅入深详细介绍Java内存分配的原理，以帮助新手更轻松的学习Java。这类文章网上有很多，但大多比较零碎。本文从认知过程角度出发，将带给读者一个系统的介绍。
进入正题前首先要知道的是Java程序运行在JVM(Java Virtual Machine，Java虚拟机)上，可以把JVM理解成Java程序和操作系统之间的桥梁，JVM实现了Java的平台无关性，由此可见JVM的重要性。所以在学习Java内存分配原理的时候一定要牢记这一切都是在JVM中进行的，JVM是内存分配原理的基础与前提。
简单通俗的讲，一个完整的Java程序运行过程会涉及以下内存区域：
l 寄存器：JVM内部虚拟寄存器，存取速度非常快，程序不可控制。
l 栈：保存局部变量的值，包括：1.用来保存基本数据类型的值；2.保存类的实例，即堆区对象的引用(指针)。也可以用来保存加载方法时的帧。
l 堆：用来存放动态产生的数据，比如new出来的对象。注意创建出来的对象只包含属于各自的成员变量，并不包括成员方法。因为同一个类的对象拥有各自的成员变量，存储在各自的堆中，但是他们共享该类的方法，并不是每创建一个对象就把成员方法复制一次。
l 常量池：JVM为每个已加载的类型维护一个常量池，常量池就是这个类型用到的常量的一个有序集合。包括直接常量(基本类型，String)和对其他类型、方法、字段的符号引用(1)。池中的数据和数组一样通过索引访问。由于常量池包含了一个类型所有的对其他类型、方法、字段的符号引用，所以常量池在Java的动态链接中起了核心作用。常量池存在于堆中。
l 代码段：用来存放从硬盘上读取的源程序代码。
l 数据段：用来存放static定义的静态成员。
下面是内存表示图：
上图中大致描述了Java内存分配，接下来通过实例详细讲解Java程序是如何在内存中运行的（注：以下图片引用自尚学堂马士兵老师的J2SE课件，图右侧是程序代码，左侧是内存分配示意图，我会一一加上注释）。
预备知识：
1.一个Java文件，只要有main入口方法，我们就认为这是一个Java程序，可以单独编译运行。
2.无论是普通类型的变量还是引用类型的变量(俗称实例)，都可以作为局部变量，他们都可以出现在栈中。只不过普通类型的变量在栈中直接保存它所对应的值，而引用类型的变量保存的是一个指向堆区的指针，通过这个指针，就可以找到这个实例在堆区对应的对象。因此，普通类型变量只在栈区占用一块内存，而引用类型变量要在栈区和堆区各占一块内存。
示例：
1.JVM自动寻找main方法，执行第一句代码，创建一个Test类的实例，在栈中分配一块内存，存放一个指向堆区对象的指针110925。
2.创建一个int型的变量date，由于是基本类型，直接在栈中存放date对应的值9。
3.创建两个BirthDate类的实例d1、d2，在栈中分别存放了对应的指针指向各自的对象。他们在实例化时调用了有参数的构造方法，因此对象中有自定义初始值。
调用test对象的change1方法，并且以date为参数。JVM读到这段代码时，检测到i是局部变量，因此会把i放在栈中，并且把date的值赋给i。
把1234赋给i。很简单的一步。
change1方法执行完毕，立即释放局部变量i所占用的栈空间。
调用test对象的change2方法，以实例d1为参数。JVM检测到change2方法中的b参数为局部变量，立即加入到栈中，由于是引用类型的变量，所以b中保存的是d1中的指针，此时b和d1指向同一个堆中的对象。在b和d1之间传递是指针。
change2方法中又实例化了一个BirthDate对象，并且赋给b。在内部执行过程是：在堆区new了一个对象，并且把该对象的指针保存在栈中的b对应空间，此时实例b不再指向实例d1所指向的对象，但是实例d1所指向的对象并无变化，这样无法对d1造成任何影响。
change2方法执行完毕，立即释放局部引用变量b所占的栈空间，注意只是释放了栈空间，堆空间要等待自动回收。
调用test实例的change3方法，以实例d2为参数。同理，JVM会在栈中为局部引用变量b分配空间，并且把d2中的指针存放在b中，此时d2和b指向同一个对象。再调用实例b的setDay方法，其实就是调用d2指向的对象的setDay方法。
调用实例b的setDay方法会影响d2，因为二者指向的是同一个对象。
change3方法执行完毕，立即释放局部引用变量b。
以上就是Java程序运行时内存分配的大致情况。其实也没什么，掌握了思想就很简单了。无非就是两种类型的变量：基本类型和引用类型。二者作为局部变量，都放在栈中，基本类型直接在栈中保存值，引用类型只保存一个指向堆区的指针，真正的对象在堆里。作为参数时基本类型就直接传值，引用类型传指针。
小结：
1.分清什么是实例什么是对象。Class a= new Class();此时a叫实例，而不能说a是对象。实例在栈中，对象在堆中，操作实例实际上是通过实例的指针间接操作对象。多个实例可以指向同一个对象。
2.栈中的数据和堆中的数据销毁并不是同步的。方法一旦结束，栈中的局部变量立即销毁，但是堆中对象不一定销毁。因为可能有其他变量也指向了这个对象，直到栈中没有变量指向堆中的对象时，它才销毁，而且还不是马上销毁，要等垃圾回收扫描时才可以被销毁。
3.以上的栈、堆、代码段、数据段等等都是相对于应用程序而言的。每一个应用程序都对应唯一的一个JVM实例，每一个JVM实例都有自己的内存区域，互不影响。并且这些内存区域是所有线程共享的。这里提到的栈和堆都是整体上的概念，这些堆栈还可以细分。
4.类的成员变量在不同对象中各不相同，都有自己的存储空间(成员变量在堆中的对象中)。而类的方法却是该类的所有对象共享的，只有一套，对象使用方法的时候方法才被压入栈，方法不使用则不占用内存。
以上分析只涉及了栈和堆，还有一个非常重要的内存区域：常量池，这个地方往往出现一些莫名其妙的问题。常量池是干嘛的上边已经说明了，也没必要理解多么深刻，只要记住它维护了一个已加载类的常量就可以了。接下来结合一些例子说明常量池的特性。
预备知识：
基本类型和基本类型的包装类。基本类型有：byte、short、char、int、long、boolean。基本类型的包装类分别是：Byte、Short、Character、Integer、Long、Boolean。注意区分大小写。二者的区别是：基本类型体现在程序中是普通变量，基本类型的包装类是类，体现在程序中是引用变量。因此二者在内存中的存储位置不同：基本类型存储在栈中，而基本类型包装类存储在堆中。上边提到的这些包装类都实现了常量池技术，另外两种浮点数类型的包装类则没有实现。另外，String类型也实现了常量池技术。
实例：
-
public class test { public static void main(String[] args) { objPoolTest(); } public static void objPoolTest() { int i = 40; int i0 = 40; Integer i1 = 40; Integer i2 = 40; Integer i3 = 0; Integer i4 = new Integer(40); //重新创建对象 Integer i5 = new Integer(40); Integer i6 = new Integer(0); Double d1=1.0; Double d2=1.0; System.out.println("i=i0\t" + (i == i0)); System.out.println("i1=i2\t" + (i1 == i2)); System.out.println("i1=i2+i3\t" + (i1 == i2 + i3)); System.out.println("i4=i5\t" + (i4 == i5)); System.out.println("i4=i5+i6\t" + (i4 == i5 + i6)); System.out.println("d1=d2\t" + (d1==d2)); System.out.println(); } }
- i=i0 true
- i1=i2 true
- i1=i2+i3 true
- i4=i5 false
- i4=i5+i6 true
- d1=d2 false
结果分析：
1.i和i0均是普通类型(int)的变量，所以数据直接存储在栈中，而栈有一个很重要的特性：栈中的数据可以共享。当我们定义了int i = 40;，再定义int i0 = 40;这时候会自动检查栈中是否有40这个数据，如果有，i0会直接指向i的40，不会再添加一个新的40。
2.i1和i2均是引用类型，在栈中存储指针，因为Integer是包装类。由于Integer包装类实现了常量池技术，因此i1、i2的40均是从常量池中获取的，均指向同一个地址，因此i1=12。
3.很明显这是一个加法运算，Java的数学运算都是在栈中进行的，Java会自动对i1、i2进行拆箱操作转化成整型，因此i1在数值上等于i2+i3。
4.i4和i5均是引用类型，在栈中存储指针，因为Integer是包装类。但是由于他们各自都是new出来的，因此不再从常量池寻找数据，而是从堆中各自new一个对象，然后各自保存指向对象的指针，所以i4和i5不相等，因为他们所存指针不同，所指向对象不同。
5.这也是一个加法运算，和3同理。
6.d1和d2均是引用类型，在栈中存储指针，因为Double是包装类。但Double包装类没有实现常量池技术，因此Doubled1=1.0;相当于Double d1=new Double(1.0);，是从堆new一个对象，d2同理。因此d1和d2存放的指针不同，指向的对象不同，所以不相等。
小结：
1.以上提到的几种基本类型包装类均实现了常量池技术，但他们维护的常量仅仅是【-128至127】这个范围内的常量，如果常量值超过这个范围，就会从堆中创建对象，不再从常量池中取。比如，把上边例子改成Integer i1 = 400; Integer i2 = 400;，很明显超过了127，无法从常量池获取常量，就要从堆中new新的Integer对象，这时i1和i2就不相等了。
2.String类型也实现了常量池技术，但是稍微有点不同。String型是先检测常量池中有没有对应字符串，如果有，则取出来；如果没有，则把当前的添加进去。
凡是涉及内存原理，一般都是博大精深的领域，切勿听信一家之言，多读些文章。我在这只是浅析，里边还有很多猫腻，就留给读者探索思考了。希望本文能对大家有所帮助！
脚注：
(1) 符号引用，顾名思义，就是一个符号，符号引用被使用的时候，才会解析这个符号。如果熟悉linux或unix系统的，可以把这个符号引用看作一个文件的软链接，当使用这个软连接的时候，才会真正解析它，展开它找到实际的文件
对于符号引用，在类加载层面上讨论比较多，源码级别只是一个形式上的讨论。
当一个类被加载时，该类所用到的别的类的符号引用都会保存在常量池，实际代码执行的时候，首次遇到某个别的类时，JVM会对常量池的该类的符号引用展开，转为直接引用，这样下次再遇到同样的类型时，JVM就不再解析，而直接使用这个已经被解析过的直接引用。
除了上述的类加载过程的符号引用说法，对于源码级别来说，就是依照引用的解析过程来区别代码中某些数据属于符号引用还是直接引用，如，System.out.println("test" +"abc");//这里发生的效果相当于直接引用，而假设某个Strings = "abc"; System.out.println("test" + s);//这里的发生的效果相当于符号引用，即把s展开解析，也就相当于s是"abc"的一个符号链接，也就是说在编译的时候，class文件并没有直接展看s，而把这个s看作一个符号，在实际的代码执行时，才会展开这个。
一、自定义类加载器的一般步骤
Java的类加载器自从JDK1.2开始便引入了一条机制叫做父类委托机制。一个类需要被加载的时候，JVM先会调用他的父类加载器进行加载，父类调用父类的父类，一直到顶级类加载器。如果父类加载器加载不了，依次再使用其子类进行加载。当然这类所说的父类加载器，不一定他们之间是继承的关系，有可能仅仅是包装的关系。
Java之所以出现这条机制，因为是处于安全性考虑。害怕用户自己定义class文件然后自己写一个类加载器来加载原本应该是JVM自己加载的类。这样会是JVM虚拟机混乱或者说会影响到用户的安全。下面我们来自己实现一个类加载器，其中主要就是继承ClassLoader类。我们有必要明白：
虽然在绝大多数情况下系统默认提供的类加载器实现已经可以满足需求。但是在某些情况下，您还是需要为应用开发出自己的类加载器。比如您的应用通过网络来传输 Java 类的字节代码，为了保证安全性，这些字节码经过了加密处理。这个时候您就需要自己的类加载器来从某个网络地址上读取加密后的字节代码，接着进行解密和验证，最后定义出要在 Java 虚拟机中运行的类来。下面将通过两个具体的实例来说明类加载器的开发。
①ClassLoader加载类的顺序
1调用findLoadedClass(String) 来检查是否已经加载类
2在父类加载器上调用loadClass方法。如果父亲不能加载，一次一级一级传给子类
3调用子类findClass(String) 方法查找类。若还加载不了就返回ClassNotFoundException，不交给发起请求的加载器的子加载器
②实现自己的类加载器
1 获取类的class文件的字节数组，如loadClassData方法
2 将字节数组转换为Class类的实例，重写findClass中调用的defineClass方法
- package cn.M_ClassLoader2;
- import java.io.ByteArrayOutputStream;
- import java.io.File;
- import java.io.FileInputStream;
- public class ClassLoaderTest
- {
- public static void main(String[] args) throws InstantiationException, IllegalAccessException, ClassNotFoundException
- {
- // 新建一个类加载器
- MyClassLoader cl = new MyClassLoader("myClassLoader");
- // 加载类，得到Class对象
- Class clazz = cl.loadClass("cn.M_ClassLoader2.Animal");
- // 得到类的实例
- Animal animal = (Animal) clazz.newInstance();
- animal.say();
- }
- }
- class Animal
- {
- public void say()
- {
- System.out.println("hello world!");
- }
- }
- class MyClassLoader extends ClassLoader
- {
- // 类加载器的名称
- private String name;
- // 类存放的路径
- private String path = MyClassLoader.getSystemClassLoader().getResource("").getPath();;
- MyClassLoader(String name)
- {
- this.name = name;
- }
- MyClassLoader(ClassLoader parent, String name)
- {
- super(parent);
- this.name = name;
- }
- /**
- * 重写findClass方法
- */
- @Override
- public Class findClass(String name)
- {
- byte[] data = loadClassData(name);
- return this.defineClass(name, data, 0, data.length);
- }
- public byte[] loadClassData(String name)
- {
- try
- {
- name = name.replace(".", "//");
- FileInputStream is = new FileInputStream(new File(path + name + ".myclass"));
- ByteArrayOutputStream baos = new ByteArrayOutputStream();
- int b = 0;
- while ((b = is.read()) != -1)
- {
- baos.write(b);
- }
- System.out.println("我是自定义类加载器哦！");
- return baos.toByteArray();
- }
- catch (Exception e)
- {
- e.printStackTrace();
- }
- return null;
- }
- }
一般来说自己开发的类加载器只需要覆写findClass(String name)方法即可。java.lang.ClassLoader类的方法loadClass()封装了前面提到的代理模式的实现。该方法会首先调用findLoadedClass()方法来检查该类是否已经被加载过；如果没有加载过的话，会调用父类加载器的loadClass()方法来尝试加载该类；如果父类加载器无法加载该类的话，就调用findClass()方法来查找该类。因此，为了保证类加载器都正确实现代理模式，在开发自己的类加载器时，最好不要覆写loadClass()方法，而是覆写findClass()方法。
二、自定义类加载器的运行问题
由于只重写了findClass方法并没有重写loadClass方法，故没有改变父类委托机制。也就数说如果某个.class可以被父类加载，我们自定义的类加载器就不会被执行了。比如Animal.java被自动编译为Animal.class放在bin目录下，AppClassLoader完全可以加载，所以就不调用自定义的加载器了。
尝试办法1：把Animal.class放在别的目录中比如D盘的根目录下
报 Class A can not access a member of class B with modifiers ""错。Java语言中的包访问成员实际上指的是运行时包访问可见，而不是编译时。因此当你试图访问不在同一个runtime package的成员时，即便在编译时它们在同一个包内，但是却由不同的class loader加载，也同样会得到java.lang.IllegalAccessException: Class A can not access a member of class B with modifiers "" 这样的异常。
尝试办法2：把该Animal.class的后缀名为.myClass，让AppClassLoader找不到
网上有人说可以解决，但是我实验的结果是会和办法1报一样的异常。
尝试办法3：解决方案是通过扩展自定义的ClassLoader，重写loadClass方法先从当前类加载器加载再从父类加载器加载。
该解决办法是可以解决的，网址是http://blog.csdn.net/zhangxinrun/article/details/6161426
1、用户自定义的类加载器：
要创建用户自己的类加载器，只需要扩展java.lang.ClassLoader类，然后覆盖它的findClass(String name)方法即可，该方法根据参数指定类的名字，返回对应的Class对象的引用。
findClass protected Class findClass(String name) throws ClassNotFoundException使用指定的二进制名称查找类。此方法应该被类加载器的实现重写，该实现按照委托模型来加载类。在通过父类加载器检查所请求的类后，此方法将被 loadClass 方法调用。默认实现抛出一个 ClassNotFoundException。参数：
name - 类的二进制名称返回：
得到的 Class 对象抛出：
ClassNotFoundException - 如果无法找到类从以下版本开始：
1.2
创建用户自定义的类加载器：
自定义类加载器：
public class MyClassLoader extends ClassLoader { //类加载器名称 private String name; //加载类的路径 private String path = "D:/"; private final String fileType = ".class"; public MyClassLoader(String name){ //让系统类加载器成为该类加载器的父加载器 super(); this.name = name;
} public MyClassLoader(ClassLoader parent, String name){ //显示指定该类加载器的父加载器 super(parent); this.name = name;
} public String getPath() { return path;
} public void setPath(String path) { this.path = path;
}
@Override public String toString() { return this.name;
} /** * 获取.class文件的字节数组
* @param name
* @return */ private byte[] loaderClassData(String name){
InputStream is = null; byte[] data = null;
ByteArrayOutputStream baos = new ByteArrayOutputStream(); this.name = this.name.replace(".", "/"); try {
is = new FileInputStream(new File(path + name + fileType)); int c = 0; while(-1 != (c = is.read())){
baos.write(c);
}
data = baos.toByteArray();
} catch (Exception e) {
e.printStackTrace();
} finally{ try {
is.close();
baos.close();
} catch (IOException e) {
e.printStackTrace();
}
} return data;
} /** * 获取Class对象 */ @Override public Class findClass(String name){ byte[] data = loaderClassData(name); return this.defineClass(name, data, 0, data.length);
} public static void main(String[] args) throws ClassNotFoundException, InstantiationException, IllegalAccessException { //loader1的父加载器为系统类加载器 MyClassLoader loader1 = new MyClassLoader("loader1");
loader1.setPath("D:/lib1/"); //loader2的父加载器为loader1 MyClassLoader loader2 = new MyClassLoader(loader1, "loader2");
loader2.setPath("D:/lib2/"); //loader3的父加载器为根类加载器 MyClassLoader loader3 = new MyClassLoader(null, "loader3");
loader3.setPath("D:/lib3/");
Class clazz = loader2.loadClass("Sample");
Object object = clazz.newInstance();
}
}public class Sample { public Sample(){
System.out.println("Sample is loaded by " + this.getClass().getClassLoader()); new A();
}
}
public class A { public A(){
System.out.println("A is loaded by " + this.getClass().getClassLoader());
}
}当执行loader2.loaderClass("Sample")时，先由它上层的所有父加载器尝试加载Sample类。loader1从D:/lib1/目录下成功的加载了Sample类，因此laoder1是Sample类的定义类加载器，loader1和loader2是Sample类的初始类加载器。
当执行loader3.loadClass("Sample")时，先由它上层的所有父加载器尝试加载Sample类。loader3的父加载器为根类加载器，它无法加载Sample类，接着loader3从D:/lib3/目录下成功地加载了Sample类，因此loader3是Sample类的定义类加载器即初始类加载器。
在Sample类中主动使用了A类，当执行Sample类的构造方法中的new A()语句时，Java虚拟机需要先加载Dog类，Java虚拟机会勇Sample类的定义类加载器去加载Dog类，加载过程也同样采用父亲委托机制。
2、不同类加载器的命名空间关系：
同一个命名空间内的类是相互可见的。
子加载器的命名空间包含所有父加载器的命名空间。因此子加载器加载的类能看见父加载器加载的类。例如系统类加载器加载的类能看见根类加载器加载的类。
由父加载器加载的类不能看见子加载器加载的类。
如果两个加载器之间没有直接或间接的父子关系，那么它们各自加载的类相互不可见。
当两个不同命名空间内的类相互不可见时，可以采用Java的反射机制来访问实例的属性和方法。
扩展类加载器-------改变JAVA的父优先类加载顺序
java的类加载机制默认情况下是采用委托模型：当加载某个类时JVM会首先尝试用当前类加载器的父类加载器加载该类，若父类加载器加载不到再由当前类加载器来加载，因此这种模型又叫做“父优先”模型。
但是在实际项目中我们可能会要求先从当前类加载加载再从父类加载器加载，如项目中的某类的版本可能和container中的不一致的时候，若还从container加载就会报jar包冲突的异常，实际上jar包冲突的问题在实际开发过程中是经常会遇到的。如我们在开发Loong时就遇到了类似问题。
解决方案是通过扩展自定义的ClassLoader，重写loadClass方法，先从当前类加载器加载再从父类加载器加载。
public class MCFClassLoader extends URLClassLoader { public MCFClassLoader(URL[] urls) { super(urls);
} public MCFClassLoader(URL[] urls, ClassLoader parent) { super(urls, parent);
} public MCFClassLoader(URL[] urls, ClassLoader parent,
URLStreamHandlerFactory factory) { super(urls, parent, factory);
} public Class loadClass(String name) throws ClassNotFoundException {
Class c = findLoadedClass(name); if (c == null) { try {
c = findClass(name);
} catch (ClassNotFoundException e) { return super.loadClass(name);
}
} return c;
}
} 通过上面的ClassLoader就解决了我们遇到的问题。
思考：通过扩展URLClassLoader可以实现好多有趣的功能，如支持多父、支持加载顺序配置等等。
作为补充给出一个使用上面的ClassLoader的示例代码：
上面的例子说明当xxx.jar或yyy.jar中有需要加载的类时就从这些jar包里加载，即使所在的container里有同样的类，这样可在一定程度上避免jar包版本冲突的问题！
使用Visual VM监控运行时的项目
1.1 Visual VM简介
VisualVM 提供在 Java 虚拟机 (Java Virutal Machine, JVM) 上运行的 Java 应用程序的详细信息。在 VisualVM 的图形用户界面中，您可以方便、快捷地查看多个 Java 应用程序的相关信息。（摘自官方） 简单说来，VisualVM是一种集成了多个JDK命令行工具的可视化工具，它能为您提供强大的分析能力。所有这些都是免费的！它囊括的命令行工具包括jstat, JConsole, jstack, jmap 和 jinfo，这些工具与JDK的标准版本是一致的。 可以使用VisualVM生成和分析海量数据、跟踪内存泄漏、监控垃圾回收器、执行内存和CPU分析，同时它还支持在MBeans上进行浏览和操作。尽管VisualVM自身要在JDK6这个版本上运行，但是JDK1.4以上版本的程序它都能监控。
1.2 如何获取VisualVM
VisualVM的一个最大好处就是，它已经在你的JDK bin目录里了，只要你使用的是JDK1.6 Update7之后的版本。点击一下jvisualvm.exe图标它就可以运行了。
这里是VisualVM 的官方网站：http://visualvm.java.net/download.html，资料很全，同时提供VisualVM最近版本下载。
当然，如果你使用Myeclipse的话，该IDE也集成了对应的工具！
2.1 开启Visual VM之旅
如果你使用的是JDK是1.6Update7之后的版本，那么Visual VM已经包含在bin目录下了，否则需要去官方下载。
2.1.1 启动问题
如果你在windows上使用Visual VM，需要做的只是点一下jvisualvm.exe，就能启动它；绿色，好用。但是Visual VM所在的分区如果是NTFS格式，那么第一个问题就出现了：sun对NTFS格式的硬盘支持有问题！但可通过参数可避免，并完成启动。步骤如下：
1. 创建一个visualvm.exe的快捷方式（或者像上文一样，在MyEclipse中启动）
2. 在“目标”中添加如下参数
-XX:+PerfBypassFileSystemCheck
2.1.2 界面简介
Visual VM启动成功！可以看到Visual VM的界面了。通过Visual VM可以看到本机运行中的所有Java应用。你会发现根本不需要在VisualVM 里为Java应用程序注册，它们就会自动显示出来。甚至还可以在导航栏里查看到远程的Java应用。导航栏即为Applications，其中分为Local（本地Java应用）和Remote（远程Java应用）。
2.1.3 安装插件
Visual VM有很多好用的插件,步骤如下：
1. 点击Tools -> Plugins
2. 推荐安装全部插件
2.2 监控本地Java应用
Visual VM本身就是一个Java应用，所以打开Visual VM看到的第一个可监控应用就是Visual VM本身；可以用它热热身，小试下牛刀。在Visual VM可视化界面中可以监控到Visual VM本身的内存使用情况、线程情况、Jvm启动参数、cpu消耗情况、垃圾回收情况等很多参数。当然如果在本地启一个Tomcat一样可以看到这些参数，可以方便我们在本地对JVM进行调优。但是且接如果你是在windows下起应用，如果你的Java应用是在NTFS格式的盘附上，记得加参数：-XX:+PerfBypassFileSystemCheck
2.2.1 使用Visual VM监测内存泄漏、解决内存溢出问题
2.2.1.1 内存泄露、溢出的异同
同：都会导致应用程序运行出现问题，性能下降或挂起。
异：
1) 内存泄露是导致内存溢出的原因之一；内存泄露积累起来将导致内存溢出。
2) 内存泄露可以通过完善代码来避免；内存溢出可以通过调整配置来减少发生频率，但无法彻底避免。
2.2.1.2 监测内存泄漏
-
内存泄漏是指程序中间动态分配了内存，但在程序结束时没有释放这部分内存，从而造成那部分内存不可用的情况，重启计算机可以解决，但也有可能再次发生内存泄露，内存泄露和硬件没有关系，它是由软件设计缺陷引起的。
-
内存泄漏可以分为4类：
1) 常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。
2) 偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。
3) 一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次。
4) 隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。
每隔一段时间给所监测的Java应用来一个heap dump，如下面三图所示：
对比上面三个截图，发现似乎有个东西在急速飙升，仔细一看是这个对象：org.eclipse.swt.graphics.Image 在第一章图中这个还没排的上，第二次dump已经上升到5181个，第三次就是7845个了。涨速相当快，而且和任务管理器里面看到的GDI数量增涨一致，就是它了。
问题到这儿就比较清楚了，回到代码里面仔细一看可以发现，是某个地方反复的用图片来创建Image对象导致的，改掉以后搞定问题。
到这里其实我想说的是，Java使用起来其实要比C++更容易导致内存泄漏。对于C++来说，每一个申请的对象都必须明确释放，任何没有释放的对象都会导致memleak，这是不可饶恕的，而且这类问题已经有很多工具和方法来解决。但是到了Java里面情况就不同了，对于Java程序员来说对象都是不需要也无法主动销毁的，所以一般的思路是：随用随new，用完即丢。很多对象具体的生命周期可能连写代码的人自己也不清楚，或者不需要清楚，只知道某个时刻垃圾收集器会去做的，不用管。但很可能某个对象在“用完即丢”的时候在另一个不容易发现的地方被保存了一个引用，那么这个对象就永远不会被回收。更加糟糕的是整个程序从设计之初就没有考虑过对象回收的问题，对于C++程序员来说memleak必然是一个设计错误，但是对Java程序员来说这只是一个疏忽，而且似乎没有什么好的办法来避免。今天看到的这个问题是因为GDI泄漏会造成严重后果才被重视，但如果仅仅是造成内存泄漏，那这个程序可能得连续跑上个十天半个月才会发现问题。最后就是，对于c++，错误的代码在测试阶段就可以快速的侦测出哪怕一个byte的memleak并加以改正，但是对于java程序，理论上没有哪个工具能够知道是不是有泄漏，因为除了作者自己以外没有人能够知道一个被引用的对象是不是应该被销毁，只有通过大量的，长期的压力测试才能发现问题，这是很危险的一件事情。
2.2.1.3 解决内存溢出问题
1、java.lang.OutOfMemoryError: PermGen space
JVM管理两种类型的内存，堆和非堆。堆是在JVM启动时创建；非堆是留给JVM自己用的，用来存放类的信息的。它和堆不同，运行期内GC不会释放空间。如果web app用了大量的第三方jar或者应用有太多的class文件而恰好MaxPermSize设置较小，超出了也会导致这块内存的占用过多造成溢出，或者tomcat热部署时侯不会清理前面加载的环境，只会将context更改为新部署的，非堆存的内容就会越来越多。
PermGen space的全称是Permanent Generation space，是指内存的永久保存区域，这块内存主要是被JVM存放Class和Meta信息的，Class在被Loader时就会被放到PermGen space中，它和存放类实例(Instance)的Heap区域不同，GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的应用中有很CLASS的话，就很可能出现PermGen space错误，这种错误常见在web服务器对JSP进行pre compile的时候。如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。
如上图所示，PermGen在程序运行一段时间后超出了我们指定的128MB，通过Classes视图看到，Java在运行的同时加载了大量的类到内存中。PermGen会存储Jar或者Class的描述信息；所以在class大量增加的同时PermGen超出了我们指定的范围。为了让应用稳定，我们需要探寻新的PermGen范围。检测时段时候后（如下图）发现PermGen在145MB左右稳定，那么我们就得到了稳定的新参数；这样PermGen内存溢出的问题得到解决。
2、java.lang.OutOfMemoryError: Java heap space
第一种情况是个补充，主要存在问题就是出现在这个情况中。其默认空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。如果内存剩余不到40％，JVM就会增大堆到Xmx设置的值，内存剩余超过70％，JVM就会减小堆到Xms设置的值。所以服务器的Xmx和Xms设置一般应该设置相同避免每次GC后都要调整虚拟机堆的大小。假设物理内存无限大，那么JVM内存的最大值跟操作系统有关，一般32位机是1.5g到3g之间，而64位的就不会有限制了。
注意：如果Xms超过了Xmx值，或者堆最大值和非堆最大值的总和超过了物理内存或者操作系统的最大限制都会引起服务器启动不起来。
垃圾回收GC的角色，JVM调用GC的频度还是很高的，主要两种情况下进行垃圾回收：
一个是当应用程序线程空闲；另一个是java内存堆不足时，会不断调用GC，若连续回收都解决不了内存堆不足的问题时，就会报out of memory错误。因为这个异常根据系统运行环境决定，所以无法预期它何时出现。
根据GC的机制，程序的运行会引起系统运行环境的变化，增加GC的触发机会。
为了避免这些问题，程序的设计和编写就应避免垃圾对象的内存占用和GC的开销。显示调用System.GC()只能建议JVM需要在内存中对垃圾对象进行回收，但不是必须马上回收。一个是并不能解决内存资源耗空的局面，另外也会增加GC的消耗。
如上图所示，used heap的折线图呈峰状，说明垃圾对象及时被回收了，内存得以释放。如果used heap的值只增不减说明存在内存泄漏了，如果超过heap size的值，会报内存溢出的错误。
2.2.1.4 如何避免内存泄漏、溢出
1) 尽早释放无用对象的引用。
好的办法是使用临时变量的时候，让引用变量在退出活动域后自动设置为null，暗示垃圾收集器来收集该对象，防止发生内存泄露。
2) 程序进行字符串处理时，尽量避免使用String，而应使用StringBuffer。
因为每一个String对象都会独立占用内存一块区域，如：
-
String str = "aaa";
-
String str2 = "bbb";
-
String str3 = str + str2;
-
// 假如执行此次之后str , str2再不被调用，那么它们就会在内存中等待GC回收；
-
// 假如程序中存在过多的类似情况就会出现内存错误；
3) 尽量少用静态变量。
因为静态变量是全局的，GC不会回收。
4) 避免集中创建对象尤其是大对象，如果可以的话尽量使用流操作。
JVM会突然需要大量内存，这时会触发GC优化系统内存环境； 一个案例如下：
-
// 使用jspsmartUpload作文件上传，运行过程中经常出现java.outofMemoryError的错误，
-
// 检查之后发现问题：组件里的代码
-
m_totalBytes = m_request.getContentLength();
-
m_binArray = new byte[m_totalBytes];
-
// totalBytes这个变量得到的数极大，导致该数组分配了很多内存空间，而且该数组不能及时释放。
-
// 解决办法只能换一种更合适的办法，至少是不会引发outofMemoryError的方式解决。
-
// 参考：http://bbs.xml.org.cn/blog/more.asp?name=hongrui&id=3747
5) 尽量运用对象池技术以提高系统性能。
生命周期长的对象拥有生命周期短的对象时容易引发内存泄漏，例如大集合对象拥有大数据量的业务对象的时候，可以考虑分块进行处理，然后解决一块释放一块的策略。
6) 不要在经常调用的方法中创建对象，尤其是忌讳在循环中创建对象。
可以适当的使用hashtable，vector 创建一组对象容器，然后从容器中去取那些对象，而不用每次new之后又丢弃。
7) 优化配置。
1、 设置-Xms、-Xmx相等；
2、 设置NewSize、MaxNewSize相等；
3、 设置Heap size, PermGen space:
Tomcat 的配置示例：修改 %TOMCAT_HOME%/bin/catalina.bat or catalina.sh
在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：
set JAVA_OPTS=-Xms800m -Xmx800m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m