Java之OutOfMemoryError简单分析

Java之OutOfMemoryError简单分析

　　最近编码遇到了Java内存溢出的问题，所以就想顺便总结一下几种导致Java内存溢出的栗子，以及碰到Java内存溢出要如何去解决。

Java堆溢出

　　Java堆用于存储对象实例，只要不断的创建对象，并且保证GC Roots到对象之间有可达的路径来避免垃圾回收机制清除这些对象，那么在对象数量到达最大堆容量限制之后就会产生内存溢出的异常。

　　下面通过一段代码进行堆内存溢出异常的测试。　

 public class HeapOOM{
   static class HeapOOM{
     }
    public static void main(String[] args)
   {
     List<OOMObject> list = new ArrayList<OOMObject>（）;
       While(1)
        {
            list.add(new OOMObject());
     }
 }
 }

　　代码中对Java堆的限制大小是20M，不可扩展。具体设置是在VM Args：-Xms20m -Xmx20m -XX：+HeapDumpOnOutOfMemoryError。

　　当有堆溢出异常时，在异常堆栈信息栏中会出现“java.lang.OutOfMemoryError”，然后会提示：“Java heap space”。

　　解决思路：

　　一般是通过内存映象分析工具对Dump出来的堆转储快照进行分析，重点是确认内存中对象是否是必要的，也就是先分清楚是Memory Leak（内存泄露）还是Memory OverFlow（内存溢出）。如果是内存泄露，可以通过工具检查泄露对象到GC Roots的引用链。然后就能进而定位出泄露代码的位置。

　　如果不是内存泄露，也就是说内存中的对象都存活。那就检查虚机的参数，与物理机进行对比，看看是否可以调大，从代码检查是否存在生命周期过长的对象，尝试减少程序运行期间内存的消耗。

虚拟机栈和本地方法栈溢出

　　由于在HotSpot虚拟机中并不区分虚拟机栈以及本地方法栈，因此虽然-Xoss（用于设置本地方法栈的大小）参数存在，但是实际上是无效的。栈容量只由-Xss参数设定。

　　下面是虚拟机和本地方法栈OOM的测试代码：

 public class JavaVMStackSOF{
     private int stackLength = 1;
     public void stackLeak() {
         stackLength++;
         stackLeak();
     }
     public static void  main(String[] args) {
         JavaVMStackSOF com = new JavaVMStackSOF();
         try{
             com.stackLeak();
         }
         catch (Throwable e){
             System.out.println("Stack Length" + com.stackLength);
             throw e;
         }
     }
 }

　　上述代码使用了-Xss=128k，减少了栈内存的容量，结果抛出StackOverflowError异常，异常出现时输出的堆栈深度相应的缩小。

　　定义了大量的本地变量，增大此方法帧中本地变量表的长度，结果抛出StackOverflowError异常时输出的堆栈深度相应缩小。也就是说在单个线程下，无论是由于栈帧太大还是虚拟机栈容量太小，当内存无法分配时，都会抛出StackOverflowError异常。

　　解决思路：

　　如果使用虚拟机默认参数，栈深度在大多数情况下达到1000-2000没问题，正常的方法调用（含递归），这个深度完全够用，如果是建立多线程导致内存溢出，在不能减少线程数情况下，只能通过减少最大堆和减少栈容量来换取更多的线程。

方法区以及运行时常量池溢出

　　由于运行时常量池是方法区一部分，所以就放在一起了。

　　下面上代码：

 public class RuntimeConstantPoolOOM{
     public static void main(String[] args) {
         List<String> list  = new ArrayList<String>();
         int i =0;
         while(1)
             list.add(String.valueOf(i++).intern());
     }
 }

　　设置VM Args：-XX：PermSize=10M -XX：MaxPermSize=10M。String.intern()是一个Native方法，它的作用是：如果字符串常量池已经包含了等于此String对象的字符串，则返回代表池中这个字符串的String对象：否则，将此String包含的字符串添加到常量池中，并且返回此String的引用。从结果中可以看到，在OutOfMemoryError后跟随的提示信息是：PermGen Space，说明运行时常量池属于方法区一部分。

　　解决思路：

　　方法区溢出是一种常见的内存溢出异常，一个类要被垃圾收集器回收掉，判断条件是比较苛刻的。在经常动态生成大量的Class应用中，需要特别注意类的回收状况，常见的场景有：大量jsp或动态生成jsp文件的应用、基于OSGI的应用以及使用GGLib字节码增强（当前许多主流框架Spring、Hibernate都会用到GGLib这类字节码技术）和动态语言。

本机直接内存溢出

　　DirectMemory容量可以通过-XX：MaxDirectMemorySize指定，如不指定，默认与java堆最大值一样。

　　下面贴代码：　

 public class DirectMemroyOOM{

     public static final int _1MB = 1024 * 1024;

     public static void main(String[] args) throws Exception{
         Field unsafeField = Unsafe.class.getDeclareFields()[0];
         unsafeField.setAccessible(true);
         Unsafe unsafe = (Unsafe) unsafeField.get(null);
         while (1)
             unsafe.allocateMemory(_1MB);
     }
 }

　　指定VM Args: -Xmx20M -XX:MaxDirectMemorySize=10M,代码越过了DirectByBuffer类，直接通过反射获取Unsafe实例进行内存分配，之所以这么做是因为虽然使用DirectByteBuffer分配内存也会抛出内存溢出异常，但是抛出的异常并没有真正向操作系统申请分配内存，而是通过计算得知内存无法分配，于是手动抛出异常，真正申请内存的方法是unsafe.allocateMemory()。

　　解决思路：

　　由于此种内存溢出一个明显的特征是在Heap Dump文件中不会看见明显的异常，如果发现OOM之后Dump文件很小，而程序中又直接或间接使用了NIO，那就可以考虑一下是不是本机内存直接溢出了。

　　以上就是有关java内存溢出相关的总结了，如果有不对的地方，欢迎指出，大家一起交流。

　　

　　PS:本博客欢迎转发，但请注明博客地址及作者~

　 　博客地址：http://www.cnblogs.com/voidy/

　　 <。)#)))≦