【Java】深入理解Java虚拟机1——内存区域以及OOM类型

本文主要是个人在看深入理解Java虚拟机第二版时候的阅读整理，有兴趣的可以入手纸质版本。

其他文章

【Java】深入理解Java虚拟机1——内存区域以及OOM类型：https://www.jianshu.com/p/65c91ba4006e
【Java】深入理解Java虚拟机2——判断对象是否存活和引用：https://www.jianshu.com/p/67c24aa93c03
【Java】深入理解Java虚拟机3——垃圾收集算法：https://www.jianshu.com/p/362407886236
【Java】深入理解Java虚拟机4——内存分配与回收策略：https://www.jianshu.com/p/e21f5d5c4f42
【Java】深入理解Java虚拟机5——类的加载过程：https://www.jianshu.com/p/931ef115d48e
【Java】深入理解Java虚拟机6——类的加载器及双亲委派：https://www.jianshu.com/p/2f33eca93a4f

运行时数据区域

方法区和堆是由所有线程共享的数据区。
虚拟机栈，本地方法栈和程序计数器是线程隔离的数据区,即线程私有的

image.png
程序计数器：是一块较小的内存空间，她可以看作是当前线程执行的字节码的行号指示器。字节码解释器工作时就是通过改变这个计数器的值来选取小一条需要执行的字节指令，分支，循环，跳转，异常处理，线程恢复等基础功能要依赖这个计数器来执行。为了线程切换换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各个线程之间计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。（如果线程正在执行一个java方法，这个计数器执行的是正在执行的虚拟机字节码指令的地址；如果正在执行的是native方法，这个计数器值这位空（Undefined），此内存区域是唯一一个在java虚拟机规范中没有规定任何OutofMemoryError情况的区域）
java虚拟机栈：和程序计数器一样，java虚拟机栈也是线程私有的，它的生命周期与线程相同。虚拟机栈描述的是java方法执行的内存模型：每个方法在执行时都会创建一个 栈帧（Stack Frame）用于存储局部变量表，操作数栈，动态链接，方法出口等信息。每一个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机中入栈到出栈的过程。局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。
经常有人把Java内存区分为堆内存（Heap）和栈内存（Stack），这种分法比较粗糙，Java内存区域的划分实际上远比这复杂。这种划分方式的流行只能说明大多数程序员最关注的、与对象内存分配关系最密切的内存区域是这两块。其中所指的“堆”笔者在后面会专门讲述，而所指的“栈”就是现在讲的虚拟机栈，或者说是虚拟机栈中局部变量表部分。
局部变量表存放了编译期可知的各种基本数据类型（boolean、byte、char、short、int、 float、long、double）、对象引用（reference类型，它不等同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置）和returnAddress类型（指向了一条字节码指令的地址）。
在java虚拟机规范中，对这个区域规范了两种异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflow异常；如果虚拟机栈可以动态拓展（当前大部分的java虚拟机都可以动态拓展，只不过java虚拟机规范中也允许固定长度的虚拟机栈），如果拓展时无法申请到足够的内存，会抛出OutofMemoryError异常。
本地方法栈：与虚拟机栈的作用非常相似，区别在于虚拟机栈执行的是java方法（也就是字节码）服务，而本地方法栈则为虚拟机使用到的Native方法服务。与虚拟机栈一样，本地方法栈区域也会抛出StackOverflow和OutofMemoryError异常。（在虚拟机规范中本地方法栈中方法使用的语言和数据结构并没有强制规定，因此具体的虚拟机可以自由实现它）
Java堆：对大多数应用来说，Java堆（java heap）是java虚拟机所管理的内存中最大的一块。java堆是被所有线程共享的一块内存区域，在java虚拟机启动的时候创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存。java虚拟机孤帆中描述：所有对象实例以及数组都要在堆上分配，但是随着JIT编译器的发展和逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化发生，所有的对象都分配在堆上也渐渐变得不那么“绝对”了。
Java堆是垃圾收集器管理的主要区域，因此很多时候也被称做“GC堆。
1.从内存回收的角度来看，由于现在收集器基 本都采用分代收集算法，所以Java堆中还可以细分为：新生代和老年代；再细致一点的有 Eden空间、From Survivor空间、To Survivor空间等。
2.从内存分配的角度来看，线程共享的 Java堆中可能划分出多个线程私有的分配缓冲区（Thread Local Allocation Buffer,TLAB）。不 过无论如何划分，都与存放内容无关，无论哪个区域，存储的都仍然是对象实例，进一步划 分的目的是为了更好地回收内存，或者更快地分配内存。
3.根据Java虚拟机规范的规定，Java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可，就像我们的磁盘空间一样。在实现时，既可以实现成固定大小的，也可以是可扩展的，不过当前主流的虚拟机都是按照可扩展来实现的（通过-Xmx和-Xms控制）。如 果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异 常。
方法区：方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然Java虚拟机规 范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做Non-Heap（非堆），目的应 该是与Java堆区分开来。
Java虚拟机规范对方法区的限制非常宽松，除了和Java堆一样不需要连续的内存和可以 选择固定大小或者可扩展外，还可以选择不实现垃圾收集。相对而言，垃圾收集行为在这个 区域是比较少出现的，但并非数据进入了方法区就如永久代的名字一样“永久”存在了。这区 域的内存回收目标主要是针对常量池的回收和对类型的卸载，一般来说，这个区域的回 收“成绩”比较难以令人满意，尤其是类型的卸载，条件相当苛刻，但是这部分区域的回收确 实是必要的。在Sun公司的BUG列表中，曾出现过的若干个严重的BUG就是由于低版本的 HotSpot虚拟机对此区域未完全回收而导致内存泄漏。
根据Java虚拟机规范的规定，当方法区无法满足内存分配需求时，将抛出 OutOfMemoryError异常。
运行时常量池：运行时常量池（Runtime Constant Pool）是方法区的一部分。Class文件中除了有类的版 本、字段、方法、接口等描述信息外，还有一项信息是常量池（Constant Pool Table，用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中存放。
Java虚拟机对Class文件每一部分（自然也包括常量池）的格式都有严格规定，每一个字 节用于存储哪种数据都必须符合规范上的要求才会被虚拟机认可、装载和执行，但对于运行 时常量池，Java虚拟机规范没有做任何细节的要求，不同的提供商实现的虚拟机可以按照自 己的需要来实现这个内存区域。不过，一般来说，除了保存Class文件中描述的符号引用外， 还会把翻译出来的直接引用也存储在运行时常量池中
运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性，Java语言并不要求常量一定只有编译期才能产生，也就是并非预置入Class文件中常量池的内容才能进入方 法区运行时常量池，运行期间也可能将新的常量放入池中，这种特性被开发人员利用得比较 多的便是String类的intern（）方法。
既然运行时常量池是方法区的一部分，自然受到方法区内存的限制，当常量池无法再申 请到内存时会抛出OutOfMemoryError异常。
直接内存：直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规 范中定义的内存区域。但是这部分内存也被频繁地使用，而且也可能导致OutOfMemoryError 异常出现。
在JDK 1.4中新加入了NIO（New Input/Output）类，引入了一种基于通道（Channel）与缓 冲区（Buffer）的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据。
显然，本机直接内存的分配不会受到Java堆大小的限制，但是，既然是内存，肯定还是 会受到本机总内存（包括RAM以及SWAP区或者分页文件）大小以及处理器寻址空间的限制。服务器管理员在配置虚拟机参数时，会根据实际内存设置-Xmx等参数信息，但经常忽略直接内存，使得各个内存区域总和大于物理内存限制（包括物理的和操作系统级的限制）， 从而导致动态扩展时出现OutOfMemoryError异常。

对象的创建、内存布局、访问定位（以HotSpot虚拟机为例）

对象的创建：在语言层面上，创建对象（例如克隆、反序列化）通常仅仅是一个new关键字而已，而在虚拟机中，对象（文中讨论的对象限于普通Java对象，不包括数组和Class对象等）又是怎么创建的呢？虚拟机遇到一条new指令时，首先将去检查这个指令的参数是否能在常量池中定位到一 个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程。在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类加载完成后便可完全确定，为对象分配空间的任务等同于把 一块确定大小的内存从Java堆中划分出来。内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头）， 这一步操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值。接下来，虚拟机要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找 到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息。这些信息存放在对象的对 象头（Object Header）之中。
在上面工作都完成之后，从虚拟机的视角来看，一个新的对象已经产生了，但从Java程 序的视角来看，对象创建才刚刚开始——＜init＞方法还没有执行，所有的字段都还为零。 所以，一般来说（由字节码中是否跟随invokespecial指令所决定），执行new指令之后会接着 执行＜init＞方法，把对象按照程序员的意愿进行初始化，这样一个真正可用的对象才算完 全产生出来。
对象的内存布局：在HotSpot虚拟机中，对象在内存中存储的布局可以分为3块区域：对象（Header）、实例数据（Instance Data）和对齐填充（Padding）。
1.HotSpot虚拟机的对象头包括两部分信息，第一部分用于存储对象自身的运行时数据， 如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时 间戳等，这部分数据的长度在32位和64位的虚拟机（未开启压缩指针）中分别为32bit和 64bit，官方称它为“Mark Word”。对象头的另外一部分是类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。并不是所有的虚拟机实现都必须在对象数据上保留类型指针，换句话说，查找对象的元数据信息并不一定要经过对象本身。
2.实例数据部分是对象真正存储的有效信息，也是在程序代码中所定义的各种类 型的字段内容。无论是从父类继承下来的，还是在子类中定义的，都需要记录起来。这部分的存储顺序会受到虚拟机分配策略参数（FieldsAllocationStyle）和字段在Java源码中定义顺 序的影响。HotSpot虚拟机默认的分配策略为longs/doubles、ints、shorts/chars、 bytes/booleans、oops（Ordinary Object Pointers），从分配策略中可以看出，相同宽度的字段 总是被分配到一起。在满足这个前提条件的情况下，在父类中定义的变量会出现在子类之前。
3.第三部分对齐填充并不是必然存在的，也没有特别的含义，它仅仅起着占位符的作用。 由于HotSpot VM的自动内存管理系统要求对象起始地址必须是8字节的整数倍，换句话说， 就是对象的大小必须是8字节的整数倍。而对象头部分正好是8字节的倍数（1倍或者2倍）， 因此，当对象实例数据部分没有对齐时，就需要通过对齐填充来补全。
对象的访问定位：建立对象是为了使用对象，我们的Java程序需要通过栈上的reference数据来操作堆上的具体对象。由于reference类型在Java虚拟机规范中只规定了一个指向对象的引用，并没有定义这个引用应该通过何种方式去定位、访问堆中的对象的具体位置，所以对象访问方式也是 取决于虚拟机实现而定的。目前主流的访问方式有使用句柄和直接指针两种。
1.句柄访问:Java堆中将会划分出一块内存来作为句柄池，reference中 存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自的具体地址信息。
通过句柄访问对象如图：

image.png
2.直接指针访问，那么Java堆对象的布局中就必须考虑如何放置访问类型数据的相关信息，而reference中存储的直接就是对象地。
通过直接指针访问对象如图：
image.png
这两种对象访问方式各有优势，使用句柄来访问的最大好处就是reference中存储的是稳定的句柄地址，在对象被移动（垃圾收集时移动对象是非常普遍的行为）时只会改变句柄中的实例数据指针，而reference本身不需要修改。 使用直接指针访问方式的最大好处就是速度更快，它节省了一次指针定位的时间开销， 由于对象的访问在Java中非常频繁，因此这类开销积少成多后也是一项非常可观的执行成 本。就本文讨论的主要虚拟机Sun HotSpot而言，它是使用第二种方式进行对象访问的，但从整个软件开发的范围来看，各种语言和框架使用句柄来访问的情况也十分常见。

OutOfMemoryError异常(OOM)

除了程序计数器外，虚拟机内存的其他几个运行时区域都有发生OutOfMemoryError（下文称OOM）异常的可能。
Java堆溢出:Java堆用于存储对象实例，只要不断地创建对象，并且保证GC Roots到对象之间有可达 路径来避免垃圾回收机制清除这些对象，那么在对象数量到达最大堆的容量限制后就会产生 内存溢出异常。
模拟代码：

 /**
     * VM Args：-Xms20m-Xmx20m-XX：+HeapDumpOnOutOfMemoryError *@author zzm
     *Java堆的大小为20MB，不可扩展（将堆的最小值-Xms参数与最 大值-Xmx参数设置为一样即可避免堆自动扩展）
     *通过参数-XX： +HeapDumpOnOutOfMemoryError可以让虚拟机在出现内存溢出异常时Dump出当前的内存堆 转储快照以便事后进行分析。 
     */
    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]

Java堆内存的OOM异常是实际应用中常见的内存溢出异常情况。当出现Java堆内存溢出 时，异常堆栈信息“java.lang.OutOfMemoryError”会跟着进一步提示“Java heap space”。确认内存中的对象是否是必要的，也 就是要先分清楚到底是出现了内存泄漏（Memory Leak）还是内存溢出（Memory Overflow）。如果是内存泄漏就要精准的找到内存泄露的位置，如果是内存溢出，就是内存中的对象确实都还必须存活着，那就应当检查虚 拟机的堆参数（-Xmx与-Xms），与机器物理内存对比看是否还可以调大，从代码上检查是 否存在某些对象生命周期过长、持有状态时间过长的情况，尝试减少程序运行期的内存消耗。
虚拟机栈和本地方法栈溢出：关于虚拟机栈和本地方法栈，在Java虚拟机规范中描述了两种异常：如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError异常。如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常。
实验结果表明：在单个线程下，无论是由于栈帧太大还是虚拟机栈容量太小，当内存无法分配的时候，虚拟机抛出的都是StackOverflowError异常。开发多线程的应用时特别注意，出现StackOverflowError异常时有错误 栈可以阅读，相对来说，比较容易找到问题的所在。代码如下：

    /**
     * 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.VMStackSOF.leak（VMStackSOF.java：20） at
    org.fenixsoft.oom.VMStackSOF.leak（VMStackSOF.java：21） at
    org.fenixsoft.oom.VMStackSOF.leak（VMStackSOF.java：21） 
    后续异常堆栈信息省略

    /**
     * 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

方法区和运行时常量池溢出：方法区用于存放Class的相关信息，如类名、访问修饰符、常量池、字段描述、方法描述等。对于这些区域的测试，基本的思路是运行时产生大量的类去填满方法区，直到溢出。虽然直接使用Java SE API也可以动态产生类（如反射时的GeneratedConstructorAccessor和动态 代理等），但在本次实验中操作起来比较麻烦。本文借助直接操作字节码运行时生成了大量的动态类。 方法区溢出也是一种常见的内存溢出异常，一个类要被垃圾收集器回收掉，判定条件是 比较苛刻的。在经常动态生成大量Class的应用中，需要特别注意类的回收状况。

    /**
     * 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指定）一样，代码清单2-9越过了DirectByteBuffer类，直接通过反射获取Unsafe实例进行内存分配（Unsafe类的getUnsafe（）方法限制了只有引导类加载器才会返回 实例，也就是设计者希望只有rt.jar中的类才能使用Unsafe的功能）。因为，虽然使用DirectByteBuffer分配内存也会抛出内存溢出异常，但它抛出异常时并没有真正向操作系统申请分配内存，而是通过计算得知内存无法分配，于是手动抛出异常，真正申请分配内存的方 法是unsafe.allocateMemory（）。由DirectMemory导致的内存溢出，一个明显的特征是在Heap Dump文件中不会看见明显 的异常，如果读者发现OOM之后Dump文件很小，而程序中又直接或间接使用了NIO，那就 可以考虑检查一下是不是这方面的原因

    /**
     * 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.DMOOM.main（DMOOM.java：20）

【Java】深入理解Java虚拟机2——GC:https://www.jianshu.com/p/67c24aa93c03

错误不足之处或相关建议欢迎大家评论指出，谢谢！如果觉得内容可以的话麻烦喜欢（♥）一下