精华内容
下载资源
问答
  • 本篇文章主要分析了JAVA程序内存溢出问题原因,较为详细的说明了java导致程序内存溢出的原因与解决方法,感兴趣的小伙伴们可以参考一下。
  • Java内存溢出异常及其处理

    千次阅读 2019-02-04 12:19:30
    熟悉Java内存划分及运行的首要目的就是预防JVM抛出内存溢出相关的异常,或者说当发生这样异常是该如何排查问题,定位问题并且给出合理的解决方案,这对于开发工作以及后期维护工作的顺利进行尤为重要。 一、在Java...

        熟悉Java内存划分及运行的首要目的就是预防JVM抛出内存溢出相关的异常,或者说当发生这样异常是该如何排查问题,定位问题并且给出合理的解决方案,这对于开发工作以及后期维护工作的顺利进行尤为重要。

    一、在Java语言中,对象访问是如何进行的?

        即使是最简单的访问,也会涉及Java栈、Java堆、方法区这三个最重要内存区域之间的关联关系。比如下面这行代码:

        Object obj = new Object();

        简单分析一下这行看似普通的代码:

    • 首先,“Object obj ”这部分的语义将会反映到Java栈的本地变量表中,作为一个reference类型数据出现。

    • 其次,“new Object()”这部分语义将会反映到Java堆中,形成一块存储了Object类型所有实例数据值的结构化内存。

    • 另外,在Java堆中还必须包含能查到此对象类型数据(如对象类型、父类、实现的接口、方法等)的地址信息,这些类型的数据类型存储在方法区中。

        而且,不同虚拟机实现的对象访问方式会有所不同,主流的访问方式有两种:使用句柄直接指针。这两种方式应用都十分广泛。

    • 句柄:Java堆中将会划分出一块内存来作为句柄池,reference中存储的就是对象的句柄地址,而句柄中包含了对象实例数据和类型数据各自的具体地址信息。优点是:reference中存储的是稳定的句柄地址只移动指针,不会修改reference本身。

    • 直接指针:Java堆对象的布局中就必须考虑如何放置访问类型数据的相关信息,reference中直接存储的就是对象地址。优点是:速度快,节省开销。

     

    二、有关于OutOfMemoryError异常的实战处理

    目的:

    • 通过代码验证Java虚拟机规范中描述的各个运行时区域储存的内容。

    • 希望开发者能根据异常的信息快速判断是哪个区域的内存溢出,知道怎样的代码可能会导致这些区域的内存溢出,以及出现这些异常后该如何处理。

    1.Java堆溢出

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

       首先,限制Java堆的大小为20MB,不可扩展(将堆的最小值-Xms参数与最大值-Xms参数设置为一样即可避免堆自动扩展),通过参数-XX:+HeapDumpOnOutOfMemoryError可以让虚拟机在出现内存溢出异常时Dump出当前的内存堆转储快照以便事后进行分析。 以下是在Mac下使用idea设置虚拟机参数:

    第一步:打开“Run->Edit Configurations”菜单

    ​第二步:选择“VM Options”选项,输入你要设置的VM参数

    输入参数内容为:

    -verbose:gc
    -Xms20M
    -Xmx20M
    -Xmn10M
    -XX:+PrintGCDetails
    -XX:SurvivorRatio=8

    第三步:点击“Apply->OK”按钮

    第四步:代码如下。

    package com.OOM;
    
    import java.util.ArrayList;
    import java.util.List;
    
    /**
     * @description: OOM异常例子剖析
     * <p>
     * 运行一下代码之前需要限制Java堆的大小为20MB,不可扩展(将堆的最小值-Xms参数与最大值-Xms参数设置为一样即可避免堆自动扩展),
     * 通过参数-XX:+HeapDumpOnOutOfMemoryError可以让虚拟机在出现内存溢出异常时Dump出当前的内存堆转储快照以便事后进行分析。
     * 如何设置虚拟机运行参数的博文连接:https://www.cnblogs.com/huiAlex/p/8227980.html
     * @author: Mr.Wang
     * @create: 2019-02-03 14:23
     **/
    public class HeapOOM {
        static class OOMObject {
        }
    
        public static void main(String[] args) {
            List<OOMObject> list = new ArrayList<>();
            while (true) {
                list.add(new OOMObject());
            }
    
        }
    
    }

        以上代码的运行结果:不光给出了错误原因是OutOfMemoryError,而且指明了是在堆内存中发生的。下面还有堆中各个分区的信息,相比于eclipse,IDEA人性化了很多。

    Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    	at java.util.Arrays.copyOf(Arrays.java:3210)
    	at java.util.Arrays.copyOf(Arrays.java:3181)
    	at java.util.ArrayList.grow(ArrayList.java:265)
    	at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:239)
    	at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:231)
    	at java.util.ArrayList.add(ArrayList.java:462)
    	at com.OOM.HeapOOM.main(HeapOOM.java:22)
    	
    Heap
     PSYoungGen      total 9216K, used 7786K [0x00000007bf600000, 0x00000007c0000000, 0x00000007c0000000)
      eden space 8192K, 95% used [0x00000007bf600000,0x00000007bfd9aa80,0x00000007bfe00000)
      from space 1024K, 0% used [0x00000007bff00000,0x00000007bff00000,0x00000007c0000000)
      to   space 1024K, 0% used [0x00000007bfe00000,0x00000007bfe00000,0x00000007bff00000)
     ParOldGen       total 10240K, used 8783K [0x00000007bec00000, 0x00000007bf600000, 0x00000007bf600000)
      object space 10240K, 85% used [0x00000007bec00000,0x00000007bf493f08,0x00000007bf600000)
     Metaspace       used 3122K, capacity 4500K, committed 4864K, reserved 1056768K
      class space    used 341K, capacity 388K, committed 512K, reserved 1048576K

    那么,应该如何解决这个异常呢?以下是解决方向:

    • 通过内存映像分析功能根据对dump出来的堆转储快照进行分析,重点是确认内存中的对象是否是必要的,也就是要先分清楚到底是出现了内存泄露还是内存溢出。

    • 如果是内存泄露,可进一步通过工具查看泄露对象到GC Roots的引用链。

    • 如果不存在泄露,那就应当检查虚拟机的堆参数(-Xmx与-Xms),与机器物理内存对比看是否还可以调大,从代码上检查是否存在某些对象的生命周期过长,持有状态时间过长的情况,尝试减少程序运行期的内存消耗。

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

        由于在HotSpot虚拟机中并不区分虚拟机栈和本地方法栈,因此对于HotSpot来说,-Xoss参数(设置本地方法栈大小)虽然存在,但实际上是无效的,栈容量只由-Xss参数设定。关于虚拟机栈和本地方法栈,在Java虚拟机规范中描述了两种异常:

    • 如果线程请求的栈深度大于虚拟机所允许的最大深度,将抛出StackOverflowError异常

    • 如果虚拟机在扩展栈时无法申请到足够的内存空间,则抛出OutOfMemoryError异常

    测试代码(一):

    • 使用-Xss参数减少栈内存容量。结果:抛出StackOverflowError异常,异常出现时输出的栈深度相应缩小。

    • 定义了大量的本地变量,增加此方法帧中本地变量表的长度。结果:抛出StackOverflowError异常时输出的栈深度相应缩小。

    package com.OOM;
    
    /**
     * @description: 虚拟机栈和本地方法栈OOM测试    -Xss128k
     * @author: Mr.Wang
     * @create: 2019-02-03 22:14
     **/
    public class JavaVMstackSOF {
        private int stackLength = 1;
    
        public void stackLeak() {
            stackLength++;
            stackLeak();
        }
    
        public static void main(String[] args) {
            JavaVMstackSOF oom = new JavaVMstackSOF();
            try {
                oom.stackLeak();
            } catch (Throwable throwable) {
                System.out.println("stack length:" + oom.stackLength);
                throw throwable;
            }
        }
    }

    输出结果为:

    stack length:20898
    Exception in thread "main" java.lang.StackOverflowError
    	at com.OOM.JavaVMstackSOF.stackLeak(JavaVMstackSOF.java:13)

    实验结果表明:

        在单个线程下,无论是由于栈帧太大,还是虚拟机栈容量太小,当内存无法分配的时候,虚拟机抛出的都是StackOverflowError异常。

        但是,如果是建立过多线程导致的内存溢出,在不能减少线程数或者更换64位虚拟机的情况下,就只能通过减少最大堆和减少栈容量来换取更多的线程。

     

    测试代码(二):

    package com.OOM;
    
    /**
     * @description: 创建线程导致内存溢出异常
     * @author: Mr.Wang
     * @create: 2019-02-03 23:55
     **/
    public class JavaVMStackOOM {
        private void dontStop() {
            while (true) {
    
            }
        }
    
        private void stackLeakByThread() {
            while (true) {
                Thread thread = new Thread(new Runnable() {
                    @Override
                    public void run() {
                        dontStop();
                    }
                });
                thread.start();
            }
        }
    
        public static void main(String[] args) {
            JavaVMStackOOM oom = new JavaVMStackOOM();
            oom.stackLeakByThread();
        }
    }

    注意:在windows平台的虚拟机执行以上代码有较大风险,可能会造成操作系统假死。

    运行结果:

    Exception in thread "main" java.lang.OutOfMemoryError:unable to create new native thread
    

    3.运行时常量池溢出

        如果要向运行时常量池中添加内容,最简单的做法就是使用String.intern()这个Native方法。该方法的作用是:如果池中已经包含一个等于此String对象的字符串,则返回代表池中这个字符串的String对象的引用。由于常量池分配在方法区内,我们可以通过-XX:PermSize和-XX:MaxPermSize限制方法区的大小,从而间接限制其中常量池的容量。

        下面将展示代码实例,在运行代码之前同样需要设置虚拟机参数,如下:

    代码如下:

    package com.OOM;
    
    import java.util.ArrayList;
    import java.util.List;
    
    /**
     * @description: 运行时常量池导致的内存溢出异常  -XX:PermSize=10M -XX:MaxPermSize=10M
     * @author: Mr.Wang
     * @create: 2019-02-04 00:15
     **/
    public class RuntimeConstantPoolOOM {
        public static void main(String[] args) {
            // 使用list保持着常量池引用,避免FULL GC回收常量池行为
            List<String> list = new ArrayList<String>();
            // 10MB的PermSize在integer范围内足够产生OOM了
            int i = 0;
            while (true) {
                System.out.println("i:" + i);
                list.add(String.valueOf(i++).intern());
            }
        }
    }

    运行结果:

    Exception in thread "main" java.lang.OutOfMemoryError:PermGen space

    结论:

        运行结果表示,产生OOM的部分是PermGen space,说明运行时常量池属于方法区(HotSpot虚拟机中的永久代)的一部分。

     

    4.方法区溢出

        方法区用于存放Class的相关信息,如类名、访问修饰符、常量池、字段描述、方法描述等。

        以下代码是模拟方法区溢出时的情形,在Spring和hibernate对类进行增强时也会用到CGLib这类字节码技术,增强的类越多,就需要越大的方法区来保证动态生成的Class可以加载入内存。

    代码如下:

    package com.OOM;
    
    import net.sf.cglib.proxy.Enhancer;
    import net.sf.cglib.proxy.MethodInterceptor;
    import net.sf.cglib.proxy.MethodProxy;
    
    import java.lang.reflect.Method;
    
    /**
     * @description: 借助CGLib使得方法区出现内存溢出异常 -XX:PermSize=10M -XX:MaxPermSize=10M
     * @author: Mr.Wang
     * @create: 2019-02-04 11:40
     **/
    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() {
                    @Override
                    public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
                        return methodProxy.invokeSuper(o, objects);
                    }
                });
                enhancer.create();
    
            }
        }
        static class OOMObject {
        }
    }

    运行结果:

    Caused by:java.lang.OutOfMemoryError:PermGen space

    需要注意的是,如果你的JDK版本是1.8.那么控制台会提示你:

    Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=10M; support was removed in 8.0
    Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=10M; support was removed in 8.0

    也就是说JDK1.8版本不支持这两个参数配置。

     

    5.本机直接内存溢出

        DirectMemory容量可通过-XX:MaxDirectMemorySize指定,如果不指定,则默认与Java堆的最大值(-Xms指定)一样。

    代码如下:

    package com.OOM;
    
    import sun.misc.Unsafe;
    
    import java.lang.reflect.Field;
    
    /**
     * @description: 使用unsafe分配本机内存 -Xmx20M -XX:MaxDirectMemorySize=10M
     * @author: Mr.Wang
     * @create: 2019-02-04 11:53
     **/
    public class DirectMemoryOOM {
        private static final int _1MB = 1024 * 1024;
    
        public static void main(String[] args) throws Exception {
            Field unsafedField = Unsafe.class.getDeclaredFields()[0];
            unsafedField.setAccessible(true);
            Unsafe unsafe = (Unsafe) unsafedField.get(null);
            while (true) {
                unsafe.allocateMemory(_1MB);
            }
        }
    }

    运行结果:

    Exception in thread "main" java.lang.OutOfMemoryError

     

    展开全文
  • 主要介绍了Java编程常见内存溢出异常与代码示例,具有一定参考价值,需要的朋友可以了解下。
  • 相比C、C++开发人员来说,有了JVM,Java程序员不再需要为每一个new操作去写配对的delete/free代码,不容易出现内存泄漏和内存溢出的问题。但也正因为内存控制完全交由JVM,一旦出现内存泄漏和溢出的问...

    对于Java程序员来说,Java虚拟机是再熟悉不过了,尤其是对Hotspot VM最熟悉了,因为它是Sun JDK和OpenJDK中所带的虚拟机,也是目前使用范围最广泛的Java虚拟机。相比C、C++开发人员来说,有了JVM,Java程序员不再需要为每一个new操作去写配对的delete/free代码,不容易出现内存泄漏和内存溢出的问题。但也正因为内存控制完全交由JVM,一旦出现内存泄漏和溢出的问题,如果没有深入了解过JVM的工作机制,那么排查问题将会很困难,所以我准备对JVM相关的东西做一下研究整理。

    1. 首先了解一下Java内存区域

    JVM运行时数据区
    如上图(图片摘自 深入理解Java虚拟机),堆内存和方法区的内容是所有线程共享的,虚拟机栈、本地方法栈和程序计数器是每个线程独有的。其中方法区就是jdk中永久代(jdk1.7之后叫metaspace),本地方法栈一般是指java native方法。

    • 对程序计数器做下介绍
      当前线程所执行的字节码的行号指示器。字节码解释器工作时就是通过改变计时器的值来选取下一条需要执行的字节码指令、分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。每个线程都会有自己独立的计数器,因为多线程之间切换后能恢复到正确的执行位置,就是靠各自的计数器记录的指令地址(如果正在执行的是Native方法,则计数器值为空Undefined)做到的
    • Java虚拟机栈(Java栈)
      它的声明周期和线程相同,每个方法在执行的同时,都会创建一个栈帧(方法运行时的基础数据结构)用于存储局部变量表(存放了编译器可知的各种基本类型、对象引用或句柄,其中只有long、double占用2个局部变量空间Slot,其他数据类型只占1个)、操作数栈、动态链接、方法出口等信息。每个方法从调用直至执行完成的过程,对应着一个栈帧在虚拟机栈(Java栈)中入栈道出栈的过程。
      说明:Java栈有两种异常类型
      StackOverflowError异常:如果线程请求的栈深度大于虚拟机锁允许的深度,就会抛出这个异常;
      OutOfMemoryError异常:如果虚拟机栈动态扩展时,无法申请到足够的内存,就会抛出这个异常;
      稍后会有报错的案例分析
    • 本地方法栈
      它和虚拟机栈的作用基本一样,唯一的区别是它是为虚拟机使用到的Native方法服务(一般Java中执行C语言的方法,使用的就是本地方法栈),而虚拟机栈是为栈执行Java方法服务。
    • Java堆
      堆内存大家都很熟悉了,它的唯一目的就是存放对象实例,几乎所有的对象实例(随着JIT编译器的发展与逃逸分析技术逐渐成熟,栈上分配、标量替换技术使对象不一定在堆上分配)都在这里分内存。
    • 方法区
      它主要用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。在Hotspot虚拟机中,该区域叫“永久代”(jdk1.7之后叫metaspace)。但方法区并不等价于永久代,这个是java虚拟机规范中的概念,仅仅是因为Hotspot设计团队选择把GC分代收集扩展至方法区(或者说使用永久代来实现方法区而已),这样垃圾收集器可以像管理Java堆一样来管理这部分内存,能够省去专门为方法区编写内存管理代码的工作。
      说明:方法区可能抛出的异常
      当方法区无法满足内存分配需求时,将会抛出OutOfMemoryError,如果是jdk1.6及以前的版本,后边会跟随着提示信息是“PermGen space”。
    • 运行时常量池
      它是方法区的一部分(Class文件中除了有类的版本号、字段、方法、接口等描述信息外,还有就是常量池),用于存放编译期生成的各种字面量(例如:常量)和符号引用,这部分内容将在类加载后进入方法区的运行时常量池中存放。
      说明:运行期间使用String.intern()方法可以将新的常量放入池中
    • 符号引用和直接引用区别
      符号引用:使以一组符号来描述所引用的目标,符号可以是任何形式的字面量,只要使用时能够无歧义的定位到目标就好。例如:Class文件中它以Constant_Class_info等类型的常量出现;
      直接引用:可以是直接指向目标的指针,例如:Class对象、类变量的直接引用里可能是指向方法区的指针,相对偏移量、一个能间接定位到目标的句柄。

    2. Hotspot虚拟机内存分析

    接下来,就对最为流程的JVM进行详细的研究学习

    • 对象创建的内存分配方式
      一般有两种分配方式:一种是指针碰撞,但前提是堆内存规整的情况下;
      另一种是空闲列表(可以在堆内存不规整的情况下)。
      Serial、ParNew(带压缩整理) GC算法,通常采用指针碰撞;CMS(标记清除)算法,通常采用空闲列表。

    • 堆内存分配并发处理
      一种是对内存空间的动作进行同步处理,实际上JVM采用CAS+失败重试的方式;
      另一种是把内存分配的动作按照线程分在不同空间之中进行,也就是说每个线程在java堆中预先分配一小块内存,称为本地线程分配缓冲(TLAB)。虚拟机是否使用TLAB,可通过-XX: +/-UseTLAB来设定,默认是开启的。

    • 对象的内存布局
      可分为3块区域:对象头、实例数据、对齐填充;
      **对象头:**包含两部分信息,一是用于存储对象自身的运行时数据(如:哈希码、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳),这些又称为“Mark Word”;另一部分是类型指针,即对象指向它的类元数据的指针,JVM通过这个指针来确定这个对象是哪个类的实例。注意:如果是java数组的话,对象头中还必须有一块用于记录数组长度的数据,因为JVM可以通过普通java对象的元数据信息确定java对象的大小,但是从数组的元数据中却无法确定数组的大小。
      **实例数据:**是对象真正存储的有效信息,也是在程序中所定义的各种类型的字段内容。
      对齐填充: 因为HotspotVM要求对象起始地址必须是8字节的整数倍,也就是说对象大小必须是8字节的整数倍,所以对象实例数据部分没有对齐时,就需要通过对齐填充来补全。

    • 对象的访问定位方式
      有两种方式:一种是使用句柄访问,在java堆中将会分出一块内存来作为句柄池,栈中reference中存储的就是对象的句柄地址,而句柄中包含了对象实例数据和类型数据各自的具体地址信息,如下图(图片来自 深入理解Java虚拟机):
      句柄访问

    另一种方式是使用直接指针访问,reference中存储的直接就是对象地址
    指针访问
    说明:两者优缺点
    这两种方式各有优势,使用句柄来访问,最大的好处就是reference中存储的是稳定的句柄地址,不管对象怎么被移动(垃圾收集时移动对象是非常普遍的行为),只需要改变句柄中的实例数据指针,而reference本身不需要修改;
    使用指针访问,最大的好处就是速度更快,它节省了一次指针定位的时间开销,但是对象变化的频繁,会带来栈指针变化的成本。

    3. 内存溢出分析

    • Java堆溢出 OOM案例,以下为案例代码:
    /**
     * @className: JavaHeapOOM
     * @summary: Java堆内存溢出案例
     * @Description: OOM
     *  VM 参数:-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError
     *  说明:以上参数限制java堆的大小为20MB,不可扩展(堆最大值和最小值设置为一样的)
     *  -XX:+HeapDumpOnOutOfMemoryError参数的作用是让JVM出现内存溢出异常时,
     *  Dump出当前的内存堆转储快照以便事后进行分析。
     * @author: helon
     * date: 2018/10/28 1:13 PM
     * version: v1.0
     */
    public class JavaHeapOOM {
    
        static class OOMObject {
        }
        public static void main(String[] args) {
            List<OOMObject> list = new ArrayList<>();
            while (true) {
                list.add(new OOMObject());
            }
    
        }
    }
    

    在启动运行之前,我们要设置以下idea的VM参数,如下截图:
    VM参数配置
    配置完成后开始启动main方法,发现报出了OOM,如下信息:

    java.lang.OutOfMemoryError: Java heap space
    Dumping heap to java_pid2342.hprof ...
    Heap dump file created [27819705 bytes in 0.095 secs]
    Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    	at java.util.Arrays.copyOf(Arrays.java:3210)
    	at java.util.Arrays.copyOf(Arrays.java:3181)
    	at java.util.ArrayList.grow(ArrayList.java:265)
    	at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:239)
    	at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:231)
    	at java.util.ArrayList.add(ArrayList.java:462)
    	at com.helon.JavaHeapOOM.main(JavaHeapOOM.java:27)
    

    Dumping heap to java_pid2342.hprof … 报错之后dump了一份hprof堆转储快照文件,可以使用Eclipse的MAT(Memory Analyzer Tool)工具进行分析(idea貌似没有类似的工具,找了好久没有找到…),确认对象是否是必要的,也就是说先分析清楚到底是出现了内存泄漏(Memory Leak)还是内存溢出(Memory Overflow)。如果是内存泄漏了,那么可以通过工具查看泄漏对象到GC ROOTS(可达性分析对象到GC ROOTS的引用链关系,包括虚拟机栈中引用的对象、方法区中类静态属性引用的对象、方法区中常量引用的对象、本地方法栈中JNI引用的对象)的引用链,看是什么原因导致对象没有被回收。如果不是内存泄漏,那么就要分析一下,堆内存参数配置对比物理内存是否可以适当调大,或者尝试减少程序运行期的内存消耗。

    • 虚拟机栈和本地方法栈溢出案例
    /**
     * @className: JavaVMStackSOF
     * @summary: 虚拟机栈和本地方法栈OOM测试
     * @Description: 设置虚拟机栈容量 -Xss, -Xoss为本地方法栈大小,但设置不小
     * 设置 -Xss大小为160k
     * 单线程运行
     * @author: helon
     * date: 2018/10/28 4:09 PM
     * version: v1.0
     */
    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("====栈深度:" + oom.stackLength);
                throw e;
            }
        }
    }
    

    在代码运行前,首先配置一下VM参数,将虚拟机栈大小设置为160k,如下截图:
    SOF案例测试
    运行main方法,每次报错都是StackOverflowError,如果定义大量的本地变量,结果也是抛出StackOverflowError:

    ====栈深度:772
    Exception in thread "main" java.lang.StackOverflowError
    	at com.helon.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:18)
    	at com.helon.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:19)
    	at com.helon.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:19)
    	at com.helon.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:19)
    	at com.helon.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:19)
    	at com.helon.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:19)
    	...
    

    测试结果表明:在单线程情况下,无论是由于栈帧太大还是虚拟机栈容量太小,当内存无法分配时,JVM都是抛出StackOverflowError异常。
    那么我们在多线程情况下做个测试,如下代码:

    /**
     * @className: JavaVMStackOOM
     * @summary: 多线程场景下导致虚拟机栈OOM
     * @Description: 设置-Xss2m
     * @author: helon
     * date: 2018/10/28 4:44 PM
     * version: v1.0
     */
    public class JavaVMStackOOM {
    
        private void dontStop() {
            while (true) {
    
            }
        }
        public void stackLeakByThread() {
            while (true) {
                new Thread(() -> {
                    dontStop();
                }).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
    

    测试表明,在多线程情况下可以产生栈内存溢出异常,但是这样产生的内存溢出异常与栈空间是否足够大,并不存在任何联系,或者说为每个线程的栈分配的内存越大,反而越容易产生内存溢出异常。因为堆内存总大小减去Xmx最大堆容量,再减去MaxPermSize最大方法区容量,程序计数器可以忽略不计,那么剩下的内存就是虚拟机栈和本地方法栈的内存大小了。如果每个线程分配到的内存容量越大,那么可以建立的线程数量就越少。

    • 方法区和运行时常量池溢出案例
      首先看以下代码:
    /**
     * @className: RuntimeConstantPoolOOM
     * @summary: JDK1.6及以前版本 使用以下案例可以测出OOM:PermGen space
     * @Description: 设置 -XX:PermSize=10M -XX:MaxPermSize=10M
     * @author: helon
     * date: 2018/10/28 5:30 PM
     * version: v1.0
     */
    public class RuntimeConstantPoolOOM {
    
        public static void main(String[] args) {
            //使用List保持着常量池引用,避免Full GC回收常量池行为
            List<String> list = new ArrayList<>();
            //10MB的PermSize在integer范围内足够产生OOM了
            int i = 0;
            while (true) {
                list.add(String.valueOf(i++).intern());
            }
        }
    }
    

    首先解释下String的intern()方法,它是一个Native方法,作用是:如果字符串常量池中已经包含了一个等于此String对象的字符串,那么就返回常量池中这个字符串的String对象,如果不包含就将此String对象包含的字符串添加到常量池中,并返回引用。
    以上代码需要在JDK1.6及之前版本能够测出OOM异常,我本机为JDK1.8环境,测试不出异常,因为在JDK1.7及以上版本已经去“永久代”,设置PermSize参数是无效的。并且,JDK1.7之后,intern方法不会再复制对象实例,只是在常量池中记录首次出现的引用
    除了以上测试方式,还可以借助CGLib直接操作字节码运行时生成大量的动态类,让其填满方法区,直到溢出,参照以下代码:

    /**
     * @className: JavaMethodAreaOOM
     * @summary: 借助CGLib使方法区出现内存溢出异常
     * @Description: JDK1.6及之前版本,设置-XX:PermSize=10m -XX:MaxPermSize=10m
     * JDK1.7及之后版本,设置-XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=10m
     * @author: helon
     * date: 2018/10/28 6:01 PM
     * version: v1.0
     */
    public class JavaMethodAreaOOM {
        static class OOMObject {
        }
        public static void main(String[] args) {
            while (true) {
                Enhancer enhancer = new Enhancer();
                enhancer.setSuperclass(OOMObject.class);
                enhancer.setUseCache(false);
                enhancer.setCallback(new MethodInterceptor() {
                    @Override
                    public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
                        return methodProxy.invokeSuper(o, objects);
                    }
                });
                enhancer.create();
            }
        }
    }
    

    启动main方法前,先设置一下VM参数:JDK1.6及之前版本,设置-XX:PermSize=10m -XX:MaxPermSize=10m;JDK1.7及之后版本,设置-XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=10m。根据本地环境来设置不同的参数,我使用的是JDK1.8环境,设置的是metaspace的大小,设置完毕运行main方法,运行一小会时间结果抛出了OOM,如下错误信息:

    Exception in thread "main" java.lang.OutOfMemoryError: Metaspace
    

    其实,在当前的很多主流框架里,如:Spring、Hibernate在对类进行增强的时候,都会使用到CGLib这类字节码技术,增强类越多,就需要越大的方法区来保证动态生成的Class可以加载入内存。如果滥用类似字节码增强技术或动态语言(如groovy等),并未做好控制的话,很可能会导致以上异常。

    • 本机直接内存溢出分析
      如果以上查找OOM问题的时候,以上所有情况都没有定位原因,并且Heap Dump文件中没有看到明显的异常,而程序又直接或者间接使用到了NIO,那就有可能是这方面的原因。

    4. 总结

    好了,以上就是JVM常见的几种OOM,并且也总结了虚拟机中的内存划分,后续我还会经常分享一些JVM的其他知识,如果有疑义的地方,欢迎指正批评。

    展开全文
  • 下面我们通过一段代码来模拟一下此种情况的内存溢出。  import java.util.*;  import java.lang.*;  public class OOMTest{  public void stackOverFlowMethod(){  stackOverFlowMetho
  • 下面小编就为大家带来一篇浅谈java内存管理与内存溢出异常。小编觉得挺不错的,现在就分享给大家,也给大家做个参考。一起跟随小编过来看看吧
  • 内存溢出异常(OutOfMemoryError)

    千次阅读 2018-04-27 10:18:55
    在Java虚拟机规范的描述中,除了程序计数器外,虚拟机内存的其他几个运行时区域都有发生OutOfMemoryError(OOM)异常的可能。虚拟机启动参数的设置: 如果使用控制台命令来执行程序,那么直接跟在Java命令之后书写...

         在Java虚拟机规范的描述中,除了程序计数器外,虚拟机内存的其他几个运行时区域都有发生OutOfMemoryError(OOM)异常的可能。

    虚拟机启动参数的设置:

        如果使用控制台命令来执行程序,那么直接跟在Java命令之后书写即可。

        如果使用Eclipse IDE,则可以在Debug/Run页签设置(Debug Configurations->Arguments->VM arguments)

    1、Java堆溢出

        将堆的最小值参数(-Xms)最大值参数(-Xmx)设置为一样即可避免堆自动扩展,通过参数-XX:+HeapDumpOnOutOfMemoryError可以让虚拟机在出现内存溢出异常时Dump出当前的内存堆转储(dump 转储)快照以便事后进行分析。

    异常日志:

            当出现堆溢出时运行结果会抛出: java.lang.OutOfMemoryError: Java heap space

    解决办法:

          Java堆内存的OOM异常是实际应用中最常见的内存溢出异常情况。要解决这一区域的异常,一般的手段是首先通过内存映像分析工具(如Eclipse Memory Analyzer)对dump出来的堆转储快照进行分析,重点是确认内存中的对象是否是必要的,也就是要先分清楚到底是出现了内存泄漏(Memory Leak)还是内存溢出(Memory Overflow)

        如果是内存泄漏,可进一步通过工具查看泄漏对象到GC Roots的引用链。于是就能找到泄漏对象是通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收他们的。掌握了泄漏对象的类型信息,以及GC Roots引用链的信息,就可以比较准确地定位出泄漏代码的位置。

        如果不存在内存泄漏,也就是说内存中的对象确实都还必须存活着,那就应当检查虚拟机的堆参数(-Xmx-Xms),与机器物理内存对比看是否还可以调大,从代码上检查是否存在某些对象生命周期过长、持有状态时间过长的情况,尝试减少程序运行期的内存消耗。

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

           由于在HotSpot虚拟机中并不区分虚拟机栈和本地方法栈,因此对于HotSpot来说,-Xoss参数(设置本地方法栈大小)虽然存在,但实际上是无效的,栈容量只由-Xss参数设定。关于虚拟机栈和本地方法栈,在Java虚拟机规范中描述了两种异常:

               如果线程请求的栈深度超过虚拟机所允许的最大深度,将抛出StackOverflowError异常。

               如果虚拟机在扩展栈时无法申请到足够的内存空间,则抛出OutOfMemoryError异常。

          这两种异常存在着一些互相重叠的地方:当栈空间无法继续分配时,到底是内存太小,还是已使用的栈空间太大,其本质上只是对同一件事情的两种描述而已。

    解决方法

        在单个线程下,无论是由于栈帧太大,还是虚拟机栈容量太小,当内存无法分配的时候,虚拟机抛出的都是StackOverflowError异常。

          在开发多线程应用的时候特别注意,出现StackOverflowError异常时有错误堆栈可以阅读,相对来说比较容易找到问题的所在。而且,如果使用虚拟机默认参数,栈深度在大多数情况下(因为每个方法压入栈的帧大小并不是一样 的,所以只能说大多数情况下)达到1000~2000完全没问题,对于正常的方法调用(包括递归),这个深度应该完全够用了。但是,如果建立过多线程导致的内存溢出,在不能减少线程数或者更换64位虚拟机的情况下,就只能通过减少最大堆和减少栈容量来换取更多的线程

    3、方法区溢出

            方法区用于存放Class的相关信息,如类名、访问修饰符、常量池、字段描述、方法描述等。值得注意的是,当前的很多主流框架,如Spring和Hibernate对类进行增强时,都会使用到CGLib这类字节码技术,增强的类越多,就需要越大的方法区来保证动态生成的Class可以加载入内存。

    异常日志

            java.lang.OutOfMemoryError:PermGen space

    解决方法

        方法区溢出也是一种常见的内存溢出异常,一个类如果要被垃圾收集器回收掉,判定条件是非常苛刻的。在经常动态生成大量Class的应用中,需要特别注意类的回收状况。这类场景应用除了程序使用了CGLib字节码增强外,常见的还有:大量JSP或动态产生JSP文件的应用(JSP第一次运行时需要编译为Java类)、基于OSGi的应用(即使是 同一个类文件,被不同的加载器加载也会视为不同的类)等。

    运行时常量池溢出

          如果要向运行时常量池添加内容,最简单的做法就是使用String.intern()这个Native方法。该方法的作用是:如果池中已经包含了一个等于此String对象的字符串,则返回代表池中这个字符串的String对象;否则,将此String对象包含的字符串添加到常量池中,并且返回此String对象的 引用。由于常量池分配在方法区中,我们可以通过-XX:PermSize-XX:MaxPermSize限制方法区的大小,从而间接限制其中常量池的容量。

    异常日志

            java.lang.OutOfMemoryError:PermGen space

            以上提示信息说明运行时常量池属于方法区(HotSpot虚拟机中的永久代)的一部分。

    5、本机直接内存溢出

     DirectMemory容量可通过-XX:MaxDirectMemorySize指定,如果不指定,则默认与Java堆的最大值(-Xmx)一样。虽然使用DirectByteBuffer分配内存也会抛出内存溢出异常,但它抛出异常时并没有真正向操作系统申请分配内存,而是通过计算得知内存无法分配,于是手动抛出异常,真正申请分配内存的方法是unsafe.allocateMemory()

    /**
    *VM Args:-Xmx20M -XX:MaxDirectMemorySize=10M
    */
    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);
        }
      }
    }
    


    展开全文
  • 主要介绍了Java内存区域与内存溢出异常详解的相关资料,需要的朋友可以参考下
  • Java内存区域与内存溢出异常 1.概述 对于 Java 的开发者来说,在虚拟机的自动内存管理机制的帮助下,不再需要为每一个 new 操作去写配对的 delete/ free 代码,这样不容易出现内存泄露和内存溢出的问题,只要...


    Java内存区域与内存溢出异常

    1.概述

    对于 Java 的开发者来说,在虚拟机的自动内存管理机制的帮助下,不再需要为每一个 new 操作去写配对的 delete/ free 代码,这样不容易出现内存泄露和内存溢出的问题,只要全权交给虚拟机去处理。不过,也正是因为这样,一旦出现内存泄露和溢出方面的问题,如果不了解虚拟机是怎样使用内存的,那么排查错误将会异常艰难。

    所以我们只有了解了虚拟机的各个区域、各个区域的作用、服务对象等,才能在遇到内存问题时去解决这些问题。

    2.运行时数据区域

    Java 虚拟机在执行 Java 程序的过程中会把它所管理的内存划分为若干个不同的数据区域。这些区域都有各自的用途,以及创建和销毁时间。根据《Java 虚拟机规范》的规定,Java 虚拟机所管理的内存将会包括以下几个运行时数据区域。

      

    运行时数据区

    2.1 - 程序计数器(Program Counter Register)

    概述:该区域是一块较小的内存空间,它可以看作是当前线程所执行的字节码的 行号指示器。

    作用:通过改变计数器的值来选取下一条需要执行的字节码指令。(分支、循环、跳转、异常处理、线程恢复等)基础功能都依赖与其完成。

    特点:

    1.线程私有:因为 Java 虚拟机的多线程是通过 线程轮流切换 并 分配处理器执行时间来实现的,在某一时刻,只会执行一条线程。因此,为了线程切换后能恢复到正确的执行位置,每条线程都需要有一个独立的程序计数器。

    2.无内存溢出:如果线程正在执行的是一个 Java 方法,这个计数器记录的是正在执行的虚拟机字节码指令的地址;如果正在执行的是 Native 方法,这个计数器值则为空(Undefined)。此内存区域是唯一一个在 Java 虚拟机程序规范中没有规定任何 OutOfMemoryError 情况的区域。

    2.2 - Java 虚拟机栈(Java Virtual Machine Stacks)

    2.2.1 - Java 虚拟机栈

    概述:描述 Java 方法执行的内存模型,每个方法从调用直至执行的过程,对应着一个 栈帧 在虚拟机栈中入栈到出栈的过程。

    作用:存储局部变量表、操作数栈、动态链接、方法出口等信息。

    特点:

    1.线程私有。

    2.生命周期与线程相同。

    2.2.2 - 局部变量表

    概述:存放了编译期间可知的各种基本数据类型(8种)、对象引用、returnAddress 类型(指向一条字节码指令的地址)。

    占用空间:64位长度的 long 和 double 类型占用 2 个局部变量空间(Slot),其余数据类型只占用 1 个。

    分配时机:在编译期间完成分配,当进入一个方法时,这个方法所需要在帧中分配多大的局部变量空间是完全确定的,在方法运行期间不会改变局部变量表的大小。

    我们经常将 Java 内存分为堆内存(Heap)和栈内存(Stack),这种分法中所指的栈就是 Java 虚拟机栈,或者说是虚拟机栈中 局部变量表 部分。

    2.2.3 - 对象引用

    概述:reference 类型,它不等同于对象本身,可能是一个指向对象起始地址的引用指针,也可能是指向一个代表对象的句柄或其他与此对象相关的位置。

    2.2.4 - 异常

    异常类型

    发生条件

    StackOverflowError

    线程请求的栈深度大于虚拟机所允许的深度时抛出该异常。

    OutOfMemoryError

    无法申请到足够的内存时抛出该异常。

    2.3 - 本地方法栈(Native Method Stack)

    概述:与虚拟机栈类似,是为虚拟机使用到的 Native 方法服务的内存区域。

    区别:

    o 虚拟机栈:为虚拟机执行 Java 方法(字节码)服务。

    o 本地方法栈:为虚拟机使用到的 Native 方法服务。

    异常:与虚拟机栈一致。

    在虚拟机规范中对本地方法栈中方法使用的语言、使用方式与数据结构并没有强制规定,因此具体的虚拟机可以自由实现它。甚至有的虚拟机(e.g. Sun HotSpot VM)直接将本地方法栈与虚拟机栈合二为一。

    2.4 - Java 堆(Java Heap)

    概述:对于大多数应用来说,该区域是 Java 虚拟机所管理的内存中最大的一块区域。

    作用:此区域唯一的目的就是存放对象实例。

    特点:

    1.被所有线程共享。

    2.在虚拟机启动时创建。

    异常

    异常类型

    发生条件

    StackOverflowError

    OutOfMemoryError

    在堆中没有内存来完成实例分配,且堆无法再扩展时,抛出该异常。

    内存:Java 堆可以处于物理上不连续的内存空间中,只要逻辑上是连续的即可。在实现时,既可以实现成固定大小的,也可以是可扩展的,当前主流的虚拟机都是按照可扩展来实现的(通过 -Xmx 和 -Xms 控制)。

    Reminde ��

    随着 JIT 编译器的发展与逃逸分析技术成熟,栈上分配、标量替换 等优化技术将会导致一些微妙的变化发生,所有的对象都分配在堆上也变得不那么绝对了。

    2.5 - 方法区(Method Area)

    概述:Java 虚拟机规范将方法区描述为堆的一个逻辑部分,但是它却有一个别名叫做 Non-Heap(非堆),目的是与 Java 堆区分开。

    作用:存储已被虚拟机加载的(类信息、常量、静态变量、即时编译器编译后的代码)等数据。

    特点:线程共享。

    异常

    异常类型

    发生条件

    StackOverflowError

    OutOfMemoryError

    当方法区无法满足内存分配需求时,抛出该异常。

    ·内存:Java 虚拟机规范对方法区的限制非常宽松,除了和 Java 堆一样不需要连续的内存空间和可以选择固定大小或者可扩展外,可以选择不实现垃圾收集。

    相对而言,垃圾收集行为在这个区域是比较少出现的,这个区域的内存回收目标主要是针对 常量池的回收 和 类型的卸载。

    2.6 - 运行时常量池(Runtime Constant Pool)

    概述:方法区的一部分。Class 文件中除了有类的(版本、字段、方法、接口)等描述信息外,还有一项信息就是常量池。

    作用:用于存放编译器生成的各种 字面量 和 符号引用。

    动态性:Java 语言并不要求常量池一定只有编译期才能产生,也就是并非预置入 Class 文件中常量池的内容后才能进入方法区的运行时常量池,运行期间也可以将新的常量放入池中,这种特性用的比较广泛的便是 String 类的 intern() 方法。

    异常

    异常类型

    发生条件

    StackOverflowError

    OutOfMemoryError

    因为是方法区的一部分,所以受到方法区内存的限制,当常量池无法再申请到内存时抛出该异常。

    Java 虚拟机对 Class 文件的每一部分(包括常量池)的格式都有严格规定,每一个字节用于存储哪种数据类型必须符合规范上的要求才会被虚拟机认可、装载和执行,但对于运行时常量池,Java 虚拟机规范没有做任何细节的要求,不同的提供商实现虚拟机可以按照自己的需求来实现这个内存区域。

    一般来说,除了保存 Class 文件中描述的符号引用外,还会把翻译出来的直接引用也存储在该区域中。

    2.7 - 直接内存(Direct Memory)

    概述:并不是虚拟机运行时数据区的一部分,也不是 Java 虚拟机规范中定义的内存区域。但是这部分内存也被频繁地使用,而且也可能导致 OutOfMemoryError 异常出现。

    作用:在 JDK1.4 中新加入了 NIO(New Input/Output)类,引入了一种基于通道(Channel)与缓冲区(Buffer)的 I/O 方式,它可以使用 Native 函数库直接分配堆外内存,然后通过一个存储在 Java 堆中的 DirectByteBuffer 对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能,因为避免了在 Java 堆和 Native 堆中来回复制数据。

    异常

    异常类型

    发生条件

    StackOverflowError

    OutOfMemoryError

    受到物理内存限制,动态扩展时无法申请到内存时抛出该异常。

    显然,本机直接内存的分配不会受到 Java 堆大小的限制,但是,既然是内存,肯定还是会受到本机内存(包括 RAM 以及 SWAP 区或者分页大小)大小以及处理器寻址空间的限制,当各个内存区域总和大于物理内存限制(包括物理和操作系统级的限制)时会出现异常。

    3.HotSpot 虚拟机对象探秘

    这一部分内容将以 HotSpot 虚拟机和常用的内存区域 Java 堆为例,阐述对象分配、布局和访问的全过程。

    3.1 - 对象的创建

    概述:Java 是一门面向对象的编程语言,在 Java 程序运行过程中无时无刻都有对象被创建出来。在语言层面上,创建对象通常仅仅是一个 new 关键字而已,而在虚拟机中对象的创建则分为以下几个步骤。

    3.1.1 - 类加载

    概述:虚拟机遇到一条 new 指令时,首先将去检查指令参数是否能在常量池中定位到一个类的符号引用,并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有,那必须先执行相应的类加载过程。

    3.1.2 - 分配内存

    概述:在类加载检查通过后,接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类加载完成后便可以完全确定,为对象分配空间的任务等同于把一块确定大小的内存从 Java 堆中划分出来。

    分配方式:

    1.指针碰撞(Bump the Pointer):假设 Java 堆中内存是绝对规整的,所有用过的内存都放在一边,空闲的内存放在另一边,中间放着一个指针作为分界点的指示器,那所分配内存就仅仅是把哪个指针向空闲那边挪动一段与对象大小相等的距离。

    2.空闲列表(Free List):如果 Java 堆中的内存不是规整的,已使用的内存和空闲的内存相互交错,那就没有办法简单地进行指针碰撞了,虚拟机就必须维护一个列表,记录上哪些内存块是可用的,在分配的时候从列表中找到一块足够大的空间划分给对象实例,并更新列表上的记录。

    选择哪种分配方式由 Java 堆是否规整决定,而 Java 堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定。因此,在使用 Serial、ParNew 等带 Compact 过程的收集器时,系统采用的分配算法是指针碰撞,而使用 CMS 这种基于 Mark-Sweep 算法的收集器时,通常采用空闲列表。

    3.1.3 - 同步控制

    概述:对象创建在虚拟机中是非常频繁的行为,即使是仅仅修改一个指针所指向的位置,在并发情况下也并不是线程安全的,可能出现正在给对象 A 分配地址,指针还没来得及修改,对象 B 又同时使用了原来的指针来分配内存的情况。解决这个问题有两种方案。

    方案一:对分配内存空间的动作进行同步处理,虚拟机采用 CAS 配上失败重试 的方式保证更新操作的原子性。

    方案二:将内存分配的动作按照线程划分在不同的空间中进行,每个线程在 Java 堆中预先分配一小块内存,称为 本地线程分配缓冲(Thread Local Allocation Buffer, TLAB) 。哪个线程需要分配内存,就在哪个线程的 TLAB 上分配,只有 TLAB 用完并分配新的 TLAB 时,才需要同步锁定。通过 -XX:+/-UseTLAB 参数设定是否使用 TLAB。

    3.1.4 - 初始化

    概述:内存分配完成后,虚拟机需要将分配到的内存空间都初始化为零值(不包括对象头),如果使用 TLAB,这一过程就可以提前至 TLAB 分配时进行。

    作用:保证对象的实例字段在 Java 代码中可以不赋初值就直接使用,程序能访问到这些字段的数据类型对应的零值。

    3.1.5 - 对象头(Object Header)

    概述:接下来,虚拟机要为对象头数据进行设置。(e.g. 对象的实例类、类的元数据信息的地址、对象的哈希码、对象的 GC 分代年龄)

    3.1.6 - init

    概述:在上面步骤完成后,从虚拟机的角度来看,一个新的对象已经产生了,但从 Java 程序的角度来看,对象的创建才刚刚开始,<init> 方法还没有被执行,所有的字段还为零值。一般来说,执行 new 指令之后会接着执行 <init> 方法,将对象按照我们的意愿进行初始化,这样一个真正的对象才算完全产生。

    3.2 - 对象的内存布局

    在 HotSpot 虚拟机中,对象在内存中存储的布局可以分为以下 3 块区域。

    3.2.1 - 对象头(Header)

    HotSpot 虚拟机的对象头包括两部分信息,存储自身的运行时数据的(Mark Word) 和 类型指针。

    第一部分:Mark Word

    概述:用于存储对象自身的运行时数据,如(HashCode、GC 分代年龄、锁状态标志、线程持有锁、偏向线程ID、偏向时间戳),这部分数据的长度在 32 位和 64 位的虚拟机中(未开启压缩指针)分别为 32bit 和 64bit。

    内存:对象需要存储的运行时数据很多,其实已经超出了 32位、64位 Bitmap 结构所能记录的限度,但是对象头信息是与对象自身定义的数据无关的额外存储成本,考虑到虚拟机的空间效率,Mark Word 被设计成一个 非固定的数据结构 以便在极小的空间内存储尽量多的信息,它会根据对象的状态复用自己的存储空间。

    HotSpot 虚拟机对象头 Mark Word 表如下��

    存储内容

    标志位

    状态

    对象哈希码、对象分代年龄

    01

    未锁定

    指向锁记录的指针

    00

    轻量级锁定

    指向重量级锁的指针

    10

    膨胀(重量级锁定)

    空(不需要记录信息)

    11

    GC 标记

    偏向线程 ID、偏向时间戳、对象分代年龄

    01

    可偏向

    第二部分:类型指针

    概述:即对象指向它的类元数据的指针,虚拟机通过这个指针来确定这个对象是哪个类的实例。

    Reminder ��

    并不是所有的虚拟机实现都必须在对象数据上保留类型指针,换句话说,查找对象的元数据并不一定要经过对象本身。

    数组对象:如果对象是一个 Java 数组,那在对象头中还必须有一块用于记录数组长度的数据,因为虚拟机可以通过普通 Java 对象的元数据信息确定 Java 对象的大小,但是从数组的元数据中却无法确定数组的大小。

    3.2.2 - 实例数据(Instance Data)

    概述:这部分是对象真正存储的有效信息,也是在程序代码中所定义的各种类型字段内容。无论是从父类继承下来的,还是在子类中定义的,都需要记录起来。

    存储顺序:这部分的存储顺序会受到虚拟机 分配策略参数(FieldsAllocationStyle) 和字段在 Java 源码中定义顺序的影响。

    HotSpot 虚拟机默认的分配策略为 longs/doubles => ints =>shorts/chars => bytes/booleans => oops(Ordinary Object Pointers),从分配策略中可以看出,相同宽度的字段总是被分配到一起。在满足这个前提条件的情况下,在父类中定义的变量会出现在子类之前。

    如果 CompactFields 参数值为 true(默认为 true),那么子类之中较窄的变量也可能会插入到父类变量的空隙之中。

    3.2.3 - 对齐填充(Padding)

    概述:不是必然存在的,也没有特别的含义,它仅仅起着占位符的作用。

    原理:由于 HotSpot VM 的自动内存管理系统要求 对象起始地址必须是 8 字节的整倍数,换句话说,就是对象的大小必须是 8 字节的整倍数。而对象头部分正好是 8 字节的整倍数( 1 倍或 2 倍),因此,当对象实例数据部分没有对齐时,就需要通过对齐填充来补全。

    3.3 - 对象的访问定位

    概述:建立对象是为了使用对象,我们的 Java 程序需要通过栈上的 reference 数据来操作堆上的具体对象。由于 reference 类型在 Java 虚拟机规范中只规定了一个指向对象的引用,并没有定义这个引用应该通过何种方式去定位、访问堆中的对象的具体位置,所以 对象访问方式也是取决于虚拟机实现而定的。目前主流的访问方式有两种。

    句柄访问:Java 堆中将会划分出一块内存来作为句柄池,reference 中存储的就是对象的句柄地址,而句柄中包含了对象实例数据与类型数据各自的具体地址信息,如下图所示��。

      

    通过句柄访问对象

    直接指针:Java 堆对象的布局中必须考虑如何放置访问类型数据的相关信息,而 reference 中存储的直接就是对象地址,如下图所示��。

      

    通过直接指针访问对象

    比较:

    o 句柄访问:使用句柄访问的最大好处就是 reference 中存储的是 稳定的 句柄地址,在对象被移动(垃圾收集时移动对象是非常普遍的行为)时只会改变句柄中的实例数据指针,而 reference 本身不需要修改。

    o 指针访问:使用直接访问最大的好处就是 速度快,它节省了一次指针定位的时间开销,由于对象的访问在 Java 中非常频繁,因此这类开销积少成多后也是一项非常可观的执行成本。

    Sun HotSpot 使用的是第二种方式进行对象访问的,但从整个软件开发的范围来看,各种语言和框架使用句柄来访问的情况也十分常见。

    4.实战:OutOfMemoryError 异常

    在 Java 虚拟机规范的描述中,除了程序计数器外,虚拟机内存的其他几个运行时区域都有发生 OutOfMemory(OOM)异常的可能。

    目的:

    1.通过代码验证 Java 虚拟机规范中描述的各个运行时区域的存储内容。

    2.遇到实际的内存溢出异常时,能根据异常的信息快速判断哪个区域的内存溢出。

    3.了解什么样的代码可能会导致这些区域内存溢出,并了解如何处理。

    VM Args 设置

    Eclipse IDE:Debug Configurations => JavaApplication => YoungGenGC => Arguments 中的 VM arguments 中进行书写(书写参数以 - 开头,以空格分隔)。

    控制台:直接跟在 Java 命令之后书写。

    本人运行在 Mac 系统下,使用 IDEA 进行配置,步骤如下所示��。

      

    虚拟机启动参数.gif

    1.打开 Run Configurations(⌃ + ⌥ + R 选择 0 )或者(⌘ + ⇧ + A 输入 run 选择 run…)。

    2.点击并打开 VM options。

    3.写入虚拟机启动参数。

    4.Apply 并 Run。

    4.1 - Java 堆溢出

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

    测试环境:

      

    测试代码:

      

    运行结果:

    分析:Java 堆内存的 OOM 异常是时机应用中常见的内存溢出异常情况。当出现 Java 堆内存溢出时,异常堆栈信息 java.lang.OutOfMemoryError 会跟着进一步提示 Javaheap space。

    解决方式

    1.堆转储快照:要解决这个区域的异常,一般的手段是先通过内存映像分析工具对 Dump 出来的堆转储快找进行分析,重点是确认内存中的对象是否是必要的,也就是要分清楚到底是出现了内存泄露(Memory Leak)还是内存溢出(Memory Overflow)。

    2.内存泄露:进一步通过工具查看泄露对象到 CG Roots 的引用链,于是就能找到内存泄露对象是通过怎样的路径与 GC Roots 相关联并导致垃圾收集器无法自动回收它们的。掌握了泄露对象的类型信息以及 GC Roots 引用链的信息,就可以比较准确地定位出泄露代码的位置。

    3.内存溢出:如果不存在泄露,换句话说,就是内存中的对象确实都必须还活着,那就应当检查虚拟机的堆参数(-Xmx 与 -Xms),与机器物理内存对象看是否还可以调大,从代码上检查是否存在某些对象生命周期过长、持有状态过长的情况,尝试减少程序运行期的内存消耗。

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

    概述:由于在 HotSpot 虚拟机中并不区分虚拟机栈和本地方法栈,因此,对于 HotSpot 来说,虽然 -Xoos 参数(设置本地方法栈大小)存在,但实际上是无效的,栈容量只由 -Xss 参数设定。关于虚拟机栈和本地方法栈,在 Java 虚拟机规范中描述了两种异常。

    异常类型

    发生条件

    StackOverflowError

    线程请求的栈深度大于虚拟机所允许的深度时抛出该异常。

    OutOfMemoryError

    无法申请到足够的内存时抛出该异常。

    这里把异常分为两种情况,看似更加严谨,但却存在一些相互重叠的地方:方栈空间无法继续分配时,到底是内存太小,还是已使用的栈空间太大,其本质上只是对同一件事的两种描述而已。

    4.2.1 - StackOverflowError

    测试环境:在此测试中,将测试范围限制于单线程中操作。

    1.使用 -Xss 参数减少栈内存容量,结果抛出 SOF 异常,异常出现时输出的堆栈深度相应缩小。

    2.定义了大量的本地变量,增大此方法栈中本地变量表长度。结果抛出 SOF 异常时输出的堆栈深度相应缩小。

    测试代码

      

      

    运行结果

    分析:在单个线程下,无论是由于栈帧太大还是虚拟机栈容量太小,当内存无法分配的时候,虚拟机抛出的都是 StackOverflowError 异常。

    但是这样产生的内存溢出异常与栈空间是否足够大并不存在任何联系,或者确切地说,在这种情况下,为每个线程的栈分配的内存越大,反而越容易产生内存溢出异常。

    理解:操作系统分配给每个进程的内存是有限的,虚拟机提供了参数来控制 Java 堆和方法区的这两部分内存的最大值。剩余的内存 -Xms(最大堆容量) -MaxPermSize(最大方法区容量),程序计数器消耗内存很小,可以忽略不计。

    如果虚拟机进程本身耗费的内存不计算在内,剩下的内存就由虚拟机栈和本地方法栈瓜分了。每个线程分配到的栈容量越大,可以建立的线程数量自然越少,建立线程时就越容易把剩下的内存耗尽。

    探索:出现 SOF 异常时有错误堆栈可以阅读,相对来说,比较容易找到问题的所在。而且,如果使用虚拟机默认参数,栈深度在大多数情况下(因为每个方法压入栈的帧大小并不是一样的)达到 1000 - 2000 完全没有问题,对于正常的方法调用(包括递归),这个深度应该完全够用了。

    但是,如果建立过多线程导致内存溢出,在不能减少线程数或者更换 64 位虚拟机的情况下,就只能通过 减少最大堆 和 减少栈容量 来换更多的线程。

    4.2.2 - OutOfMemoryError

    测试环境

    测试代码:创建线程导致内存溢出异常

      

      

      

    运行结果

    4.3 - 方法区和运行时常量池溢出

    概述:由于运行时常量池是方法区的一部分,因此这两个区域的溢出测试就放在一起进行。

    脑补:String.intern() 是一个 Native 方法,它的作用是:如果字符串常量池中已经包含一个等于此 String 对象的字符串,则返回代表池中这个字符串的 String 对象;否则,将此 String 对象包含的字符串添加到常量池中,并且返回此 String 对象的引用。

    在 JDK1.6 以及之前的版本中,由于常量池分配在永久代内,我们可以通过 -XX:PermSize 和 -XX:MaxPermSize 限制方法区的大小名,从而间接限制其中常量池的容量。

    4.3.1 - OutOfMemoryError

    测试环境

    测试代码

      

    运行结果

      

    分析:从运行结果中可以看到,运行时常量池溢出,在 OutOfMemoryError 后面跟随的提示信息是 PermGenspace,说明运行时常量池属于方法区(HotSpot 虚拟机中的永久代)的一部分。

    4.3.2 - String 常量池测试

    使用 JDK1.7 运行这段程序就不会得到相同的结果,while 循环将一直进行下去。关于这个字符串常量池的实现问题,还可以引申出一个更有意思的影响。

    测试代码

    分析:

    o JDK1.6:会得到两个 false,而在 JDK1.7 中运行,会得到一个 true 和一个 false。

    产生差异的原因是:是 JDK1.6 中 intern() 方法会把首次遇到的字符串实例复制到永久代中,返回的也是永久代中这个字符串实例的引用,而由 StringBuilder 创建的字符串实例在 Java 堆上,所以必然不是同一个引用,将返回 false

    o JDK1.7:intern() 实现不会再复制实例,只是在常量池中记录首次出现的实例引用,因此 intern() 返回的引用和由 StringBuilder 创建的那个字符串实例是同一个。

    对 str2 比较返回 false 是因为 java 这个字符串在执行 StringBuilder.toString() 之前已经出现过,字符串常量池中已经有它的引用了,不符合首次出现的原则,而 计算机软件 这个字符串是首次出现的,因此返回 true。

    4.3.3 - 测试设计思路

    方法区用于存放 Class 的相关信息,如类名、访问修饰符、常量池、字段描述、方法描述等。对于这些区域的测试,基本思路就是运行时产生大量的类去填满方法区,直到溢出。另外的,直接使用 Java SE API 也可以动态产生类(如反射时的 GeneratedConstorAccessor 和动态代理等)。

    4.3.4 - 总结

    方法区溢出是一种常见的内存溢出异常,一个类要被垃圾收集器回收掉,判定条件是比较苛刻的。

    在经常动态生成大量的 Class 的应用中,需要特别注意类的回收情况。这类场景除了上面提到的程序使用了 CGLib 字节码增强和动态语言之外,常见的还有:大量 JSP 或动态产生 JSP 文件的应用(JSP 第一次运行时需要编译为 Java 类)、基于 OSGi 应用(即使是同一个类文件,被不同的加载器加载也会视为不同的类)等。

    4.4 - 本机直接内存溢出

    概述:DirectMemory 容量可以通过 -XX:MaxDirectMemorySize 指定,如果不指定,则默认与 Java 堆最大值(-Xmx指定)一样,下面的测试代码越过了 DirectByteBuffer 类,直接通过反射获取 Unsafe 实例进行内存分配(Unsafe 类的 getUnsafe() 方法限制了只有引导类加载器才会返回实例,也就是设计者希望只有 rt.jar 中的类才能使用 Unsafe 的功能)。

    因为,虽然使用 DirectByteBuffer 分配内存也会抛出内存溢出异常,但它抛出异常时并没有真正向操作系统申请分配内存,而是通过计算得知内存无法分配,于是手动抛出异常,真正申请分配内存的方法是 unfase.allocateMemory()。

    测试代码

      

    运行结果

    分析:由 DirectMemory 导致的内存溢出,一个明显的特征是在 Heap Dump 文件中不会看到明显的异常,如果发现 OOM 之后 Dump 文件很小,而程序中又直接或间接使用了 NIO,那就可以考虑检查一下是不是这方面的原因。

    Java内存区域与内存溢出异常

    1.概述

    对于 Java 的开发者来说,在虚拟机的自动内存管理机制的帮助下,不再需要为每一个 new 操作去写配对的 delete/ free 代码,这样不容易出现内存泄露和内存溢出的问题,只要全权交给虚拟机去处理。不过,也正是因为这样,一旦出现内存泄露和溢出方面的问题,如果不了解虚拟机是怎样使用内存的,那么排查错误将会异常艰难。

    所以我们只有了解了虚拟机的各个区域、各个区域的作用、服务对象等,才能在遇到内存问题时去解决这些问题。

    2.运行时数据区域

    Java 虚拟机在执行 Java 程序的过程中会把它所管理的内存划分为若干个不同的数据区域。这些区域都有各自的用途,以及创建和销毁时间。根据《Java 虚拟机规范》的规定,Java 虚拟机所管理的内存将会包括以下几个运行时数据区域。

      

    运行时数据区

    2.1 - 程序计数器(Program Counter Register)

    概述:该区域是一块较小的内存空间,它可以看作是当前线程所执行的字节码的 行号指示器。

    作用:通过改变计数器的值来选取下一条需要执行的字节码指令。(分支、循环、跳转、异常处理、线程恢复等)基础功能都依赖与其完成。

    特点:

    1.线程私有:因为 Java 虚拟机的多线程是通过 线程轮流切换 并 分配处理器执行时间来实现的,在某一时刻,只会执行一条线程。因此,为了线程切换后能恢复到正确的执行位置,每条线程都需要有一个独立的程序计数器。

    2.无内存溢出:如果线程正在执行的是一个 Java 方法,这个计数器记录的是正在执行的虚拟机字节码指令的地址;如果正在执行的是 Native 方法,这个计数器值则为空(Undefined)。此内存区域是唯一一个在 Java 虚拟机程序规范中没有规定任何 OutOfMemoryError 情况的区域。

    2.2 - Java 虚拟机栈(Java Virtual Machine Stacks)

    2.2.1 - Java 虚拟机栈

    概述:描述 Java 方法执行的内存模型,每个方法从调用直至执行的过程,对应着一个 栈帧 在虚拟机栈中入栈到出栈的过程。

    作用:存储局部变量表、操作数栈、动态链接、方法出口等信息。

    特点:

    1.线程私有。

    2.生命周期与线程相同。

    2.2.2 - 局部变量表

    概述:存放了编译期间可知的各种基本数据类型(8种)、对象引用、returnAddress 类型(指向一条字节码指令的地址)。

    占用空间:64位长度的 long 和 double 类型占用 2 个局部变量空间(Slot),其余数据类型只占用 1 个。

    分配时机:在编译期间完成分配,当进入一个方法时,这个方法所需要在帧中分配多大的局部变量空间是完全确定的,在方法运行期间不会改变局部变量表的大小。

    我们经常将 Java 内存分为堆内存(Heap)和栈内存(Stack),这种分法中所指的栈就是 Java 虚拟机栈,或者说是虚拟机栈中 局部变量表 部分。

    2.2.3 - 对象引用

    概述:reference 类型,它不等同于对象本身,可能是一个指向对象起始地址的引用指针,也可能是指向一个代表对象的句柄或其他与此对象相关的位置。

    2.2.4 - 异常

    异常类型

    发生条件

    StackOverflowError

    线程请求的栈深度大于虚拟机所允许的深度时抛出该异常。

    OutOfMemoryError

    无法申请到足够的内存时抛出该异常。

    2.3 - 本地方法栈(Native Method Stack)

    概述:与虚拟机栈类似,是为虚拟机使用到的 Native 方法服务的内存区域。

    区别:

    o 虚拟机栈:为虚拟机执行 Java 方法(字节码)服务。

    o 本地方法栈:为虚拟机使用到的 Native 方法服务。

    异常:与虚拟机栈一致。

    在虚拟机规范中对本地方法栈中方法使用的语言、使用方式与数据结构并没有强制规定,因此具体的虚拟机可以自由实现它。甚至有的虚拟机(e.g. Sun HotSpot VM)直接将本地方法栈与虚拟机栈合二为一。

    2.4 - Java 堆(Java Heap)

    概述:对于大多数应用来说,该区域是 Java 虚拟机所管理的内存中最大的一块区域。

    作用:此区域唯一的目的就是存放对象实例。

    特点:

    1.被所有线程共享。

    2.在虚拟机启动时创建。

    异常

    异常类型

    发生条件

    StackOverflowError

    OutOfMemoryError

    在堆中没有内存来完成实例分配,且堆无法再扩展时,抛出该异常。

    内存:Java 堆可以处于物理上不连续的内存空间中,只要逻辑上是连续的即可。在实现时,既可以实现成固定大小的,也可以是可扩展的,当前主流的虚拟机都是按照可扩展来实现的(通过 -Xmx 和 -Xms 控制)。

    Reminde ��

    随着 JIT 编译器的发展与逃逸分析技术成熟,栈上分配、标量替换 等优化技术将会导致一些微妙的变化发生,所有的对象都分配在堆上也变得不那么绝对了。

    2.5 - 方法区(Method Area)

    概述:Java 虚拟机规范将方法区描述为堆的一个逻辑部分,但是它却有一个别名叫做 Non-Heap(非堆),目的是与 Java 堆区分开。

    作用:存储已被虚拟机加载的(类信息、常量、静态变量、即时编译器编译后的代码)等数据。

    特点:线程共享。

    异常

    异常类型

    发生条件

    StackOverflowError

    OutOfMemoryError

    当方法区无法满足内存分配需求时,抛出该异常。

    ·内存:Java 虚拟机规范对方法区的限制非常宽松,除了和 Java 堆一样不需要连续的内存空间和可以选择固定大小或者可扩展外,可以选择不实现垃圾收集。

    相对而言,垃圾收集行为在这个区域是比较少出现的,这个区域的内存回收目标主要是针对 常量池的回收 和 类型的卸载。

    2.6 - 运行时常量池(Runtime Constant Pool)

    概述:方法区的一部分。Class 文件中除了有类的(版本、字段、方法、接口)等描述信息外,还有一项信息就是常量池。

    作用:用于存放编译器生成的各种 字面量 和 符号引用。

    动态性:Java 语言并不要求常量池一定只有编译期才能产生,也就是并非预置入 Class 文件中常量池的内容后才能进入方法区的运行时常量池,运行期间也可以将新的常量放入池中,这种特性用的比较广泛的便是 String 类的 intern() 方法。

    异常

    异常类型

    发生条件

    StackOverflowError

    OutOfMemoryError

    因为是方法区的一部分,所以受到方法区内存的限制,当常量池无法再申请到内存时抛出该异常。

    Java 虚拟机对 Class 文件的每一部分(包括常量池)的格式都有严格规定,每一个字节用于存储哪种数据类型必须符合规范上的要求才会被虚拟机认可、装载和执行,但对于运行时常量池,Java 虚拟机规范没有做任何细节的要求,不同的提供商实现虚拟机可以按照自己的需求来实现这个内存区域。

    一般来说,除了保存 Class 文件中描述的符号引用外,还会把翻译出来的直接引用也存储在该区域中。

    2.7 - 直接内存(Direct Memory)

    概述:并不是虚拟机运行时数据区的一部分,也不是 Java 虚拟机规范中定义的内存区域。但是这部分内存也被频繁地使用,而且也可能导致 OutOfMemoryError 异常出现。

    作用:在 JDK1.4 中新加入了 NIO(New Input/Output)类,引入了一种基于通道(Channel)与缓冲区(Buffer)的 I/O 方式,它可以使用 Native 函数库直接分配堆外内存,然后通过一个存储在 Java 堆中的 DirectByteBuffer 对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能,因为避免了在 Java 堆和 Native 堆中来回复制数据。

    异常

    异常类型

    发生条件

    StackOverflowError

    OutOfMemoryError

    受到物理内存限制,动态扩展时无法申请到内存时抛出该异常。

    显然,本机直接内存的分配不会受到 Java 堆大小的限制,但是,既然是内存,肯定还是会受到本机内存(包括 RAM 以及 SWAP 区或者分页大小)大小以及处理器寻址空间的限制,当各个内存区域总和大于物理内存限制(包括物理和操作系统级的限制)时会出现异常。

    3.HotSpot 虚拟机对象探秘

    这一部分内容将以 HotSpot 虚拟机和常用的内存区域 Java 堆为例,阐述对象分配、布局和访问的全过程。

    3.1 - 对象的创建

    概述:Java 是一门面向对象的编程语言,在 Java 程序运行过程中无时无刻都有对象被创建出来。在语言层面上,创建对象通常仅仅是一个 new 关键字而已,而在虚拟机中对象的创建则分为以下几个步骤。

    3.1.1 - 类加载

    概述:虚拟机遇到一条 new 指令时,首先将去检查指令参数是否能在常量池中定位到一个类的符号引用,并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有,那必须先执行相应的类加载过程。

    3.1.2 - 分配内存

    概述:在类加载检查通过后,接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类加载完成后便可以完全确定,为对象分配空间的任务等同于把一块确定大小的内存从 Java 堆中划分出来。

    分配方式:

    1.指针碰撞(Bump the Pointer):假设 Java 堆中内存是绝对规整的,所有用过的内存都放在一边,空闲的内存放在另一边,中间放着一个指针作为分界点的指示器,那所分配内存就仅仅是把哪个指针向空闲那边挪动一段与对象大小相等的距离。

    2.空闲列表(Free List):如果 Java 堆中的内存不是规整的,已使用的内存和空闲的内存相互交错,那就没有办法简单地进行指针碰撞了,虚拟机就必须维护一个列表,记录上哪些内存块是可用的,在分配的时候从列表中找到一块足够大的空间划分给对象实例,并更新列表上的记录。

    选择哪种分配方式由 Java 堆是否规整决定,而 Java 堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定。因此,在使用 Serial、ParNew 等带 Compact 过程的收集器时,系统采用的分配算法是指针碰撞,而使用 CMS 这种基于 Mark-Sweep 算法的收集器时,通常采用空闲列表。

    3.1.3 - 同步控制

    概述:对象创建在虚拟机中是非常频繁的行为,即使是仅仅修改一个指针所指向的位置,在并发情况下也并不是线程安全的,可能出现正在给对象 A 分配地址,指针还没来得及修改,对象 B 又同时使用了原来的指针来分配内存的情况。解决这个问题有两种方案。

    方案一:对分配内存空间的动作进行同步处理,虚拟机采用 CAS 配上失败重试 的方式保证更新操作的原子性。

    方案二:将内存分配的动作按照线程划分在不同的空间中进行,每个线程在 Java 堆中预先分配一小块内存,称为 本地线程分配缓冲(Thread Local Allocation Buffer, TLAB) 。哪个线程需要分配内存,就在哪个线程的 TLAB 上分配,只有 TLAB 用完并分配新的 TLAB 时,才需要同步锁定。通过 -XX:+/-UseTLAB 参数设定是否使用 TLAB。

    3.1.4 - 初始化

    概述:内存分配完成后,虚拟机需要将分配到的内存空间都初始化为零值(不包括对象头),如果使用 TLAB,这一过程就可以提前至 TLAB 分配时进行。

    作用:保证对象的实例字段在 Java 代码中可以不赋初值就直接使用,程序能访问到这些字段的数据类型对应的零值。

    3.1.5 - 对象头(Object Header)

    概述:接下来,虚拟机要为对象头数据进行设置。(e.g. 对象的实例类、类的元数据信息的地址、对象的哈希码、对象的 GC 分代年龄)

    3.1.6 - init

    概述:在上面步骤完成后,从虚拟机的角度来看,一个新的对象已经产生了,但从 Java 程序的角度来看,对象的创建才刚刚开始,<init> 方法还没有被执行,所有的字段还为零值。一般来说,执行 new 指令之后会接着执行 <init> 方法,将对象按照我们的意愿进行初始化,这样一个真正的对象才算完全产生。

    3.2 - 对象的内存布局

    在 HotSpot 虚拟机中,对象在内存中存储的布局可以分为以下 3 块区域。

    3.2.1 - 对象头(Header)

    HotSpot 虚拟机的对象头包括两部分信息,存储自身的运行时数据的(Mark Word) 和 类型指针。

    第一部分:Mark Word

    概述:用于存储对象自身的运行时数据,如(HashCode、GC 分代年龄、锁状态标志、线程持有锁、偏向线程ID、偏向时间戳),这部分数据的长度在 32 位和 64 位的虚拟机中(未开启压缩指针)分别为 32bit 和 64bit。

    内存:对象需要存储的运行时数据很多,其实已经超出了 32位、64位 Bitmap 结构所能记录的限度,但是对象头信息是与对象自身定义的数据无关的额外存储成本,考虑到虚拟机的空间效率,Mark Word 被设计成一个 非固定的数据结构 以便在极小的空间内存储尽量多的信息,它会根据对象的状态复用自己的存储空间。

    HotSpot 虚拟机对象头 Mark Word 表如下��

    存储内容

    标志位

    状态

    对象哈希码、对象分代年龄

    01

    未锁定

    指向锁记录的指针

    00

    轻量级锁定

    指向重量级锁的指针

    10

    膨胀(重量级锁定)

    空(不需要记录信息)

    11

    GC 标记

    偏向线程 ID、偏向时间戳、对象分代年龄

    01

    可偏向

    第二部分:类型指针

    概述:即对象指向它的类元数据的指针,虚拟机通过这个指针来确定这个对象是哪个类的实例。

    Reminder ��

    并不是所有的虚拟机实现都必须在对象数据上保留类型指针,换句话说,查找对象的元数据并不一定要经过对象本身。

    数组对象:如果对象是一个 Java 数组,那在对象头中还必须有一块用于记录数组长度的数据,因为虚拟机可以通过普通 Java 对象的元数据信息确定 Java 对象的大小,但是从数组的元数据中却无法确定数组的大小。

    3.2.2 - 实例数据(Instance Data)

    概述:这部分是对象真正存储的有效信息,也是在程序代码中所定义的各种类型字段内容。无论是从父类继承下来的,还是在子类中定义的,都需要记录起来。

    存储顺序:这部分的存储顺序会受到虚拟机 分配策略参数(FieldsAllocationStyle) 和字段在 Java 源码中定义顺序的影响。

    HotSpot 虚拟机默认的分配策略为 longs/doubles => ints =>shorts/chars => bytes/booleans => oops(Ordinary Object Pointers),从分配策略中可以看出,相同宽度的字段总是被分配到一起。在满足这个前提条件的情况下,在父类中定义的变量会出现在子类之前。

    如果 CompactFields 参数值为 true(默认为 true),那么子类之中较窄的变量也可能会插入到父类变量的空隙之中。

    3.2.3 - 对齐填充(Padding)

    概述:不是必然存在的,也没有特别的含义,它仅仅起着占位符的作用。

    原理:由于 HotSpot VM 的自动内存管理系统要求 对象起始地址必须是 8 字节的整倍数,换句话说,就是对象的大小必须是 8 字节的整倍数。而对象头部分正好是 8 字节的整倍数( 1 倍或 2 倍),因此,当对象实例数据部分没有对齐时,就需要通过对齐填充来补全。

    3.3 - 对象的访问定位

    概述:建立对象是为了使用对象,我们的 Java 程序需要通过栈上的 reference 数据来操作堆上的具体对象。由于 reference 类型在 Java 虚拟机规范中只规定了一个指向对象的引用,并没有定义这个引用应该通过何种方式去定位、访问堆中的对象的具体位置,所以 对象访问方式也是取决于虚拟机实现而定的。目前主流的访问方式有两种。

    句柄访问:Java 堆中将会划分出一块内存来作为句柄池,reference 中存储的就是对象的句柄地址,而句柄中包含了对象实例数据与类型数据各自的具体地址信息,如下图所示��。

      

    通过句柄访问对象

    直接指针:Java 堆对象的布局中必须考虑如何放置访问类型数据的相关信息,而 reference 中存储的直接就是对象地址,如下图所示��。

      

    通过直接指针访问对象

    比较:

    o 句柄访问:使用句柄访问的最大好处就是 reference 中存储的是 稳定的 句柄地址,在对象被移动(垃圾收集时移动对象是非常普遍的行为)时只会改变句柄中的实例数据指针,而 reference 本身不需要修改。

    o 指针访问:使用直接访问最大的好处就是 速度快,它节省了一次指针定位的时间开销,由于对象的访问在 Java 中非常频繁,因此这类开销积少成多后也是一项非常可观的执行成本。

    Sun HotSpot 使用的是第二种方式进行对象访问的,但从整个软件开发的范围来看,各种语言和框架使用句柄来访问的情况也十分常见。

    4.实战:OutOfMemoryError 异常

    在 Java 虚拟机规范的描述中,除了程序计数器外,虚拟机内存的其他几个运行时区域都有发生 OutOfMemory(OOM)异常的可能。

    目的:

    1.通过代码验证 Java 虚拟机规范中描述的各个运行时区域的存储内容。

    2.遇到实际的内存溢出异常时,能根据异常的信息快速判断哪个区域的内存溢出。

    3.了解什么样的代码可能会导致这些区域内存溢出,并了解如何处理。

    VM Args 设置

    Eclipse IDE:Debug Configurations => JavaApplication => YoungGenGC => Arguments 中的 VM arguments 中进行书写(书写参数以 - 开头,以空格分隔)。

    控制台:直接跟在 Java 命令之后书写。

    本人运行在 Mac 系统下,使用 IDEA 进行配置,步骤如下所示��。

      

    虚拟机启动参数.gif

    1.打开 Run Configurations(⌃ + ⌥ + R 选择 0 )或者(⌘ + ⇧ + A 输入 run 选择 run…)。

    2.点击并打开 VM options。

    3.写入虚拟机启动参数。

    4.Apply 并 Run。

    4.1 - Java 堆溢出

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

    测试环境:

      

    测试代码:

      

    运行结果:

    分析:Java 堆内存的 OOM 异常是时机应用中常见的内存溢出异常情况。当出现 Java 堆内存溢出时,异常堆栈信息 java.lang.OutOfMemoryError 会跟着进一步提示 Javaheap space。

    解决方式

    1.堆转储快照:要解决这个区域的异常,一般的手段是先通过内存映像分析工具对 Dump 出来的堆转储快找进行分析,重点是确认内存中的对象是否是必要的,也就是要分清楚到底是出现了内存泄露(Memory Leak)还是内存溢出(Memory Overflow)。

    2.内存泄露:进一步通过工具查看泄露对象到 CG Roots 的引用链,于是就能找到内存泄露对象是通过怎样的路径与 GC Roots 相关联并导致垃圾收集器无法自动回收它们的。掌握了泄露对象的类型信息以及 GC Roots 引用链的信息,就可以比较准确地定位出泄露代码的位置。

    3.内存溢出:如果不存在泄露,换句话说,就是内存中的对象确实都必须还活着,那就应当检查虚拟机的堆参数(-Xmx 与 -Xms),与机器物理内存对象看是否还可以调大,从代码上检查是否存在某些对象生命周期过长、持有状态过长的情况,尝试减少程序运行期的内存消耗。

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

    概述:由于在 HotSpot 虚拟机中并不区分虚拟机栈和本地方法栈,因此,对于 HotSpot 来说,虽然 -Xoos 参数(设置本地方法栈大小)存在,但实际上是无效的,栈容量只由 -Xss 参数设定。关于虚拟机栈和本地方法栈,在 Java 虚拟机规范中描述了两种异常。

    异常类型

    发生条件

    StackOverflowError

    线程请求的栈深度大于虚拟机所允许的深度时抛出该异常。

    OutOfMemoryError

    无法申请到足够的内存时抛出该异常。

    这里把异常分为两种情况,看似更加严谨,但却存在一些相互重叠的地方:方栈空间无法继续分配时,到底是内存太小,还是已使用的栈空间太大,其本质上只是对同一件事的两种描述而已。

    4.2.1 - StackOverflowError

    测试环境:在此测试中,将测试范围限制于单线程中操作。

    1.使用 -Xss 参数减少栈内存容量,结果抛出 SOF 异常,异常出现时输出的堆栈深度相应缩小。

    2.定义了大量的本地变量,增大此方法栈中本地变量表长度。结果抛出 SOF 异常时输出的堆栈深度相应缩小。

    测试代码

      

      

    运行结果

    分析:在单个线程下,无论是由于栈帧太大还是虚拟机栈容量太小,当内存无法分配的时候,虚拟机抛出的都是 StackOverflowError 异常。

    但是这样产生的内存溢出异常与栈空间是否足够大并不存在任何联系,或者确切地说,在这种情况下,为每个线程的栈分配的内存越大,反而越容易产生内存溢出异常。

    理解:操作系统分配给每个进程的内存是有限的,虚拟机提供了参数来控制 Java 堆和方法区的这两部分内存的最大值。剩余的内存 -Xms(最大堆容量) -MaxPermSize(最大方法区容量),程序计数器消耗内存很小,可以忽略不计。

    如果虚拟机进程本身耗费的内存不计算在内,剩下的内存就由虚拟机栈和本地方法栈瓜分了。每个线程分配到的栈容量越大,可以建立的线程数量自然越少,建立线程时就越容易把剩下的内存耗尽。

    探索:出现 SOF 异常时有错误堆栈可以阅读,相对来说,比较容易找到问题的所在。而且,如果使用虚拟机默认参数,栈深度在大多数情况下(因为每个方法压入栈的帧大小并不是一样的)达到 1000 - 2000 完全没有问题,对于正常的方法调用(包括递归),这个深度应该完全够用了。

    但是,如果建立过多线程导致内存溢出,在不能减少线程数或者更换 64 位虚拟机的情况下,就只能通过 减少最大堆 和 减少栈容量 来换更多的线程。

    4.2.2 - OutOfMemoryError

    测试环境

    测试代码:创建线程导致内存溢出异常

      

      

      

    运行结果

    4.3 - 方法区和运行时常量池溢出

    概述:由于运行时常量池是方法区的一部分,因此这两个区域的溢出测试就放在一起进行。

    脑补:String.intern() 是一个 Native 方法,它的作用是:如果字符串常量池中已经包含一个等于此 String 对象的字符串,则返回代表池中这个字符串的 String 对象;否则,将此 String 对象包含的字符串添加到常量池中,并且返回此 String 对象的引用。

    在 JDK1.6 以及之前的版本中,由于常量池分配在永久代内,我们可以通过 -XX:PermSize 和 -XX:MaxPermSize 限制方法区的大小名,从而间接限制其中常量池的容量。

    4.3.1 - OutOfMemoryError

    测试环境

    测试代码

      

    运行结果

      

    分析:从运行结果中可以看到,运行时常量池溢出,在 OutOfMemoryError 后面跟随的提示信息是 PermGenspace,说明运行时常量池属于方法区(HotSpot 虚拟机中的永久代)的一部分。

    4.3.2 - String 常量池测试

    使用 JDK1.7 运行这段程序就不会得到相同的结果,while 循环将一直进行下去。关于这个字符串常量池的实现问题,还可以引申出一个更有意思的影响。

    测试代码

    分析:

    o JDK1.6:会得到两个 false,而在 JDK1.7 中运行,会得到一个 true 和一个 false。

    产生差异的原因是:是 JDK1.6 中 intern() 方法会把首次遇到的字符串实例复制到永久代中,返回的也是永久代中这个字符串实例的引用,而由 StringBuilder 创建的字符串实例在 Java 堆上,所以必然不是同一个引用,将返回 false

    o JDK1.7:intern() 实现不会再复制实例,只是在常量池中记录首次出现的实例引用,因此 intern() 返回的引用和由 StringBuilder 创建的那个字符串实例是同一个。

    对 str2 比较返回 false 是因为 java 这个字符串在执行 StringBuilder.toString() 之前已经出现过,字符串常量池中已经有它的引用了,不符合首次出现的原则,而 计算机软件 这个字符串是首次出现的,因此返回 true。

    4.3.3 - 测试设计思路

    方法区用于存放 Class 的相关信息,如类名、访问修饰符、常量池、字段描述、方法描述等。对于这些区域的测试,基本思路就是运行时产生大量的类去填满方法区,直到溢出。另外的,直接使用 Java SE API 也可以动态产生类(如反射时的 GeneratedConstorAccessor 和动态代理等)。

    4.3.4 - 总结

    方法区溢出是一种常见的内存溢出异常,一个类要被垃圾收集器回收掉,判定条件是比较苛刻的。

    在经常动态生成大量的 Class 的应用中,需要特别注意类的回收情况。这类场景除了上面提到的程序使用了 CGLib 字节码增强和动态语言之外,常见的还有:大量 JSP 或动态产生 JSP 文件的应用(JSP 第一次运行时需要编译为 Java 类)、基于 OSGi 应用(即使是同一个类文件,被不同的加载器加载也会视为不同的类)等。

    4.4 - 本机直接内存溢出

    概述:DirectMemory 容量可以通过 -XX:MaxDirectMemorySize 指定,如果不指定,则默认与 Java 堆最大值(-Xmx指定)一样,下面的测试代码越过了 DirectByteBuffer 类,直接通过反射获取 Unsafe 实例进行内存分配(Unsafe 类的 getUnsafe() 方法限制了只有引导类加载器才会返回实例,也就是设计者希望只有 rt.jar 中的类才能使用 Unsafe 的功能)。

    因为,虽然使用 DirectByteBuffer 分配内存也会抛出内存溢出异常,但它抛出异常时并没有真正向操作系统申请分配内存,而是通过计算得知内存无法分配,于是手动抛出异常,真正申请分配内存的方法是 unfase.allocateMemory()。

    测试代码

      

    运行结果

    分析:由 DirectMemory 导致的内存溢出,一个明显的特征是在 Heap Dump 文件中不会看到明显的异常,如果发现 OOM 之后 Dump 文件很小,而程序中又直接或间接使用了 NIO,那就可以考虑检查一下是不是这方面的原因。

    展开全文
  • 这是自己读《深入理解Java虚拟机》时候用XMind建立的思维导图,目的是为了能够帮助自己整理、梳理相关的知识以及方便自己日后的回顾,帮助自己建立起关于JVM的知识体系,里边也有一些对相关内容的补充,通过备注的...
  • 如果虚拟机在扩展栈时无法申请到足够的内存空间,则抛出OutOfMemory Error异常。 这里把异常分成两种情况,看似更加严谨,但却存在着一些互相重叠的地方:当栈空间 无法继续分配时,到底是内存太小,还是已使用的...
  • 深入理解JVM内存区域与内存溢出异常
  • java异常处理:OOM(内存溢出异常

    千次阅读 2018-08-27 16:47:45
    OOM,全称“Out Of Memory”,翻译成中文就是“内存用完了”,来源于java.lang.OutOfMemoryError。当JVM因为没有足够的内存来为对象分配空间并且垃圾回收器也已经没有空间可回收时,就会抛出这个error(注:非...
  • 1. JVM运行时内存区域 JVM在执行Java程序的过程中会把它所管理的内存划分为以下几个区域 1.1 程序计数器 程序计数器是一块较小的内存空间在Java虚拟机规范中是唯一一个未规定 OutOfMemoryError的内存区域 程序计数器...
  • 解决方案:经常动态生成大量Class的应用中,应该特别注意类的回收,由于一个类是否要被垃圾回收器回收掉,判定条件比较苛刻,所以方法区溢出是一种常见的内存溢出异常。 StackOverflowError异常 原因:...
  • 深入理解Java虚拟机-Java内存区域与内存溢出异常

    万次阅读 多人点赞 2020-01-03 21:42:24
    Java与C++之间有一堵由内存动态分配和垃圾收集技术所围成的"高墙",墙外面的人想进去,墙里面的人却想出来。 文章目录概述运行时数据区域程序计数器(线程私有)Java虚拟机栈(线程私有)局部变量表操作数栈动态链接...
  • JVM内存溢出异常  想了解Java虚拟机内存溢出异常就要先明白JVM内存有那些,它们都有什么作用,这样我们才能更加深入的理解内存溢出是怎么回事。 在JAVA虚拟机内存中运行时内存区域除了PC(程序计数器)不会发生...
  • 主要是阅读《深入理解java虚拟机:JVM高级特性与最佳实践》第二章:Java内存区域与内存溢出异常的笔记。
  • 由于SpringBoot自带logging,但我们又偏偏不想用,这时导入log4j2(抽的),在测试环境与本地没问题,一发布到线上就启动不起来,并报出栈溢出,需要在pom做如下配置: &lt;dependency&gt; &lt;groupId&...
  • 主要介绍以下内容: Java虚拟机内存的各个区域, 这些区域的作用, 服务对象以及其中可能产生的问题运行时数据区域概览图程序计数器(Program Counter Register)可以看做当前线程所执行的字节码的行号指示器. 在多线程...
  • JVM解读(四):JVM内存溢出异常分析

    千次阅读 2015-06-27 10:51:19
    JVM内存溢出异常分析 《JVM解读》第五篇: JVM垃圾收集 在实际的开发中我们可能会遇到各种各样的内存溢出(OutOfMemoryError)问题,我在开发的时候就遇到过这样的情况。当时是报的这样异常 Caused by:...
  • Java内存溢出异常主要分为两类:内存溢出和堆栈溢出。在下列情况下,将引发内存异常:Java堆溢出、虚拟机堆栈和本地方法栈溢出、方法区域和运行时常数池溢出以及本地直接内存溢出。以下各节将逐一描述这些类型的异常...
  • Java8内存溢出异常

    2018-10-21 23:05:48
    多的不说最近看了周老师的深入理解Java虚拟机了解一点内存溢出异常知识。 JAVA 堆溢出 package com.dairujie.demo; import java.util.ArrayList; import java.util.List; /** * * @ClassName: 堆溢出 * @...
  • 深入理解Java内存区域与内存溢出异常 前言 Java开发中,我们不需要像在进行C/C++开发那样,需要自己去写delete/free来释放申请的内存,在Java中内存是交给虚拟机管理,凡事都是两面的,因为我们把内存控制权交给...
  • Java内存区域与内存溢出异常1. 概述(为什么要去了解虚拟机是怎样使用内存的?) 2. 运行时数据区域(虚拟机中的内存是如何划分的?) 3. HotSpot 虚拟机对象探秘 (HotSpot 虚拟机在 Java 堆中对象是如何创建、...
  • 内存溢出,又称为OOM(OutOfMemoryError),处理内存溢出,首先要查看是否是由于内存泄露(Memory Leak)造成的内存溢出(Memory Overflow),可以使用内存影响分析工具(如 Eclipse Memory Analyzer)对dump出来的堆存储快照...
  • Java 常见内存溢出异常与代码实现

    千次阅读 2018-04-11 09:52:33
    因此如果我们不断地创建对象, 并且保证 GC Root 和创建的对象之间有可达路径以免对象被垃圾回收, 那么当创建的对象过多时, 会导致 heap 内存不足, 进而引发 OutOfMemoryError 异常./** * @author xiongyongshun *...
  • 1.栈溢出异常(StackOverflowError) 形成原因: 死循环调用方法。 前几天提了关于栈溢出的一个故障单。微服务A请求微服务B资源的一个方法变成了懒加载,懒加载方法中判断当资源为空时就向微服务C请求资源,请求...
  • JAVA内存溢出异常测试

    千次阅读 2017-10-10 22:27:43
    JAVA堆异常溢出: /** * Vm args:-Xms20M -Xms20M -XX:+... * java 堆内存溢出测试,深入理解java虚拟机 p51 * @author Rail * */ public class HeapOutOfMemoryError { static class OutOfMemoryError{

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 133,563
精华内容 53,425
关键字:

内存溢出异常