Java虚拟机内存管理（一）--Java内存区域与内存溢出异常

概述

    对于Java程序员来说，在虚拟机自动内存管理机制的帮助下，不在需要为没哟个new操作去写配对的delete/free代码（C/C++语音这样操作），不容易出现内存泄露和内存
溢出问题，由虚拟机管理内存，这一切看起来都很美好。
    不过，也正是因为Java程序员把内存控制的权利交给了Java虚拟机，一旦出现内存泄露和溢出方面的问题，如果不了解虚拟机是怎样使用内存的，那么排查错误将会成为一
项异常艰难的工作。
    我们先从概念上了解下Java虚拟机内存的各个区域，以及这些区域的作用、服务对象、其中可能产生的问题。

运行时数据区

    Java虚拟机在执行Java程序的过程中会把它所管理的内存划分成若干个不同的数据区域，这些区域都有各自的用途，以及创建和销毁时间，有的区域随着虚拟机进程的启动
而存在（堆、方法区），有些区域则以来用户线程的启动和结束而建立和销毁（虚拟机栈、本地方法栈、程序计数器）。Java虚拟机规范中规定，Java虚拟机所管理的内存将会包括以
下几个运行时数据区，如下图所示。

程序计数器（Program Counter Register）

    在汇编语音中，程序计数器是指CPU中的寄存器，保存的是程序当前执行的指令的地址（也可以说是保存下一条指令的所在存储单元的地址），当CPU需要执行指令时，需要从
程序计数器中得到当前需要执行的指令所在存储单元的地址，然后根据得到的地址获取指令，在得到指令后，程序计数器便自动加1或者根据转移指针得到下一条指令的地址，如
此循环，直到执行完所有的指令。

    JVM中的程序计数器的功能跟汇编语言中的程序计数器功能在逻辑上是等同的，也是用来指示执行哪条指令的。
    由于在JVM中，多线程是通过线程轮流切换来获得CPU执行时间的。因此，在任一具体时刻，一个CPU的内核只会执行一条线程中的指令。因此，为了能够使得每个线程都在线
程切换后能够恢复到切换之前的程序执行位置，每个线程都需要有自己独立的程序计数器，并且不能互相被干扰，否则会影响到程序的正常执行次序。因此，程序计数器是每个线
程所私有的。
    在JVM中规定，如果线程执行的是非native方法，则程序计数器中保存的是当前需要执行的指令的地址；如果线程执行的是native方法，则程序计数器中的值时undefined。
由于程序计数器的数据所占空间的大小不会随程序的执行发生改变，因此，程序计数器是不会发生内存溢出（OutOfMemory）的，此区域也是唯一一个在Java虚拟机规范中没有
规定任何OutOfMemoryError的区域。

Java虚拟机栈（JVM Stack）

    Java栈也称虚拟机栈（JVM Stack）。与程序计数器一样，Java虚拟机栈也是线程私有的，它的生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型：每个方法
在执行的同时都会创建一个栈帧（Stack Frame），用于存储局部变量表、操作数栈、指向运行时常量池的引用（指向当前方法所属的类的运行时常量池的引用）、方法返回地址和
一些额外的附加信息等。每个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。由此可知，线程当前执行的方法所对应的栈帧必定位于Java
栈的顶部。
    （A）、局部变量表 ： 用来存储方法中的局部变量（包括方法中声明的非静态变量、函数形参）。对于基本数据类型的变量，则直接存储它的值，其中64位长度的long和double
类型的数据会占用2个局部变量空间（Slot），其余的数据类型只占用1个；对于引用类型的变量，则存的是指向对象的引用。局部变量表所需的内存空间在编译期间完成分配，当进
入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。
    （B）、操作数栈 ： 栈最典型的一个应用就是用来对表达式求值，一个线程执行方法的过程中，实际上就是不断执行语句的过程，而归根到底就是进行计算的过程。因此可以
这么说，线程中所有计算过程都是在借助于操作数来完成的。
    （C）、指向运行时常量池的引用 ： 在方法执行过程中有可能用到类中的常量，所以必须要有一个引用指向运行时常量。
    （D）、方法返回地址 ： 当一个方法执行完毕之后，要返回之前调用它的地方，因此在栈帧中必须保存一个方法返回地址。
    在Java虚拟机规范中，对这个区域规定了两种异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；如果虚拟机栈可以动态扩展
（当前大部分的Java虚拟机都可动态扩展，只不过Java虚拟机规范中也允许固定长度的虚拟机栈），如果扩展时无法申请到足够的内存，就会抛出OutOfMemoryError异常。

本地方法栈（Native Method Stack）

    本地方法栈与虚拟机栈所发挥的作用时类似的，区别只是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则为虚拟机使用到的Native方法服务。在
JVM规范中，并没有对本地方法栈的具体实现以及数据结构作强制规定，虚拟机可以自由实现它。甚至有的虚拟机（如HotSpot虚拟机）直接把本地方法栈和虚拟机栈合二为一。与
虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError和OutOfMemoryError异常。

Java堆(Java Heap)

    对于大多数应用来说，Java堆是Java虚拟机所管理的内存中最大的一块，是所有线程共享的一块内存区域，在虚拟机启动时创建。该区域的唯一目的就是存放对象实例，几
乎所有的对象实例都在这里分配内存。Java虚拟机规范中描述如下：所有的对象实例以及数组（数组的引用是存放在Java栈中的）都要在堆上分配内存。

    在Java中，Java的垃圾回收机制会自动处理释放问题，因此，这部分空间是Java垃圾收集器管理的主要区域，很多时候也被称作“GC堆”。根据Java虚拟机规范，Java堆可以
处于物理上不连续的内存空间，只要逻辑上时连续的即可，就像我们的磁盘空间一样。在实现时，既可以实现成固定大小的，也可以时可扩展的，不过当前主流的虚拟机都是安装可
扩展来实现的（JVM启动参数-Xmx及-Xms可用来控制堆内存大小）。如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。

方法区（Method Area）

    方法区与堆一样，是被线程共享的。方法区用于存储已被虚拟机加载的类信息（包括类的名称、方法信息、字段信息）、静态变量、常量、即时编译器编译后的代码等数据。

    在方法区中有一个非常重要的部分就是运行时常量池。在class文件中除了类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池（Constant Pool Table），用
来存储编译期间生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中存放。运行时常量池除了保存Class文件中描述的符号引用外，还会保存
翻译出来的直接引用。
    运行时常量池是每一个类或接口的常量池的运行时表示形式；在类和接口被加载到JVM后，对应的运行时常量池被创建出来。
    运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性,Java语言并不要求常量一定只有编译期才能产生,也就是并非预置入Class文件中常量池的内
容才能进入方法区运行时常量池,运行期间也可能将新的常量放入池中,这种特性被开发人员利用得比较多的便是String类的intern()方法。

    Java虚拟机规范，当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。例如：在Java程序调试时碰到的“java.lang.OutOfMemoryError:PermGen
Space”就发生在这个区域。

    这里看一个实例： 一个引用类型的实例化过程： Class a = new Class()；
（a）、Class a 的时候，生成一个空的引用指针，并把它压栈到栈中；（b）、new Class()生成一个类实例对象，并在堆上分配对应的内存；（c）、= 赋值的时候，a的引用指向新生成
的实例。

直接内存（Direct Memory）

    直接内存并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域。这部分内存也会被频繁地使用，也可能导致OutOfMemoryError异常。

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

    显然，本机直接内存的分配不会受到Java堆大小的限制，但是，既然是内存，肯定还是会受到本机总内存(包括RAM以及SWAP区或者分页文件)大小以及处理器寻址空间的限
制。服务器管理员在配置虚拟机参数时，会根据实际内存设置-Xmx等参数信息，但经常忽略直接内存，使得各个内存区域总和大于物理内存限制(包括物理的和操作系统级的限
制),从而导致动态扩展时出现OutOfMemoryError异常。

HotSpot虚拟机对象探秘

    根据上一节介绍的Java虚拟机的运行时数据区，大致知道了虚拟机内存的概况，下面进一步了解虚拟机内存中数据的其他细节，譬如他们是如何创建的、如何布局以及如何
访问的。对于这样涉及细节的问题，必须把讨论范围限定在具体的虚拟机和集中在某一个内存区域上才有意义。基于实用优先的原则，我们以常用的虚拟机HotSpot和常用的内存
区域Java堆为例，深入探讨HotSpot虚拟机在Java堆中对象分配、布局和访问的全过程。

对象的创建

    Java是一门面向对象的编程语言，在Java程序运行过程中无时无刻都有对象被创建出来。在语言层面上，创建对象通常仅仅是一个new关键字而已,而在虚拟机中,对象(限
于普通Java对象,不包括数组和Class对象等)的创建又是怎样一个过程呢?

    虚拟机遇到一条new指令时，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过；如
果没有，就必须先执行相应的类加载过程（后续介绍），在类加载检查通过后，接下来虚拟机将会为新生对象分配内存。
    对象所虚内存的大小在类加载完成后便可完全确定（如何确定将在下节介绍），为对象分配空间的任务等同于把一块确定大小的内存从Java堆中划分出来。假设Java堆中内
存是绝对规整的，所有用过的内存都放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，那所分配内存就仅仅是把那个指针向空闲空间那边挪动一段与对
象大小相等的距离，这种分配方式称为“指针碰撞”(Bump the Pointer)。如果Java堆中的内存并不是规整的，已使用的内存和空闲的内存相互交错,那就没有办法简单地进行
指针碰撞了，虚拟机就必须维护一个列表，记录上哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录，这种分配方式称为
“空闲列表”(FreeList)。选择哪种分配方式由Java堆是否规整决定，而Java堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定。因此，在使用Serial、ParNew等
带Compact过程的收集器时，系统采用的分配算法是指针碰撞，而使用CMS这种基于Mark-Sweep算法的收集器时，通常采用空闲列表。
    除如何划分可用空间之外，还有另外一个需要考虑的问题是对象创建在虚拟机中是非常频繁的行为，即使是仅仅修改一个指针所指向的位置，在并发情况下也并不是线程安
全的，可能出现正在给对象A分配内存，指针还没来得及修改，对象B又同时使用了原来的指针来分配内存的情况。解决这个问题有两种方案，一种是对分配内存空间的动作进行同
步处理--实际上虚拟机采用CAS配上失败重试的方式保证更新操作的原子性;另一种是把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在Java堆中预先分
配一小块内存,称为本地线程分配缓冲(Thread Local Allocation Buffer,TLAB)。哪个线程要分配内存，就在哪个线程的TLAB上分配，只有TLAB用完并分配新的TLAB时，
才需要同步锁定。虚拟机是否使用TLAB,可以通过-XX:+/-UseTLAB参数来设定。
    内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头），这一步操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用，程序能
访问到这些字段的数据类型所对应的零值。
    接下来，虚拟机要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息。这些信息存放在对象的
对象头(Object Header)之中（对象头的具体内容，稍后介绍）。在上面工作都完成之后，从虚拟机的视角来看，一个新的对象已经产生了。但从Java程序的视角来看,对象创建才
刚刚开始——<init>方法还没有执行，所有的字段都还为零。所以，一般来说(由字节码中是否跟随invokespecial指令所决定)，执行new指令之后会接着执行<init>方法，把对
象按照程序员的意愿进行初始化，这样一个真正可用的对象才算完全产生出来

对象的内存布局

        在HotSpot虚拟机中，对象在内存中存储的布局可以分为3块区域：对象头（Header）、实例数据（Instance Data）、对齐填充（Padding）。

        HotSpot虚拟机的对象头包括两部分信息，第一部分用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、所状态标志、线程持有的锁、偏向线程ID、偏向时
间戳等，这部分数据的长度在32位和64位的虚拟机(未开启压缩指针)中分别为32bit和64bit，官方称它为“Mark Word”。对象需要存储的运行时数据很多，其实已经超出了32位、64位Bitmap结构所能记录的限度，但是对象头信息是与对象自身定义的数据无关的额外存储成本，考虑到虚拟机的空间效率，Mark Word被设计成一个非固定的数据结构以便在极小的空间内存储尽量多的信息，它会根据对象的状态复用自己的存储空间。例如，在32位的HotSpot虚拟机中，如果对象处于未被锁定的状态下，那么Mark Word的32bit空间中的25bit用于存储对象哈希码，4bit用于存储对象分代年龄，2bit用于存储锁标志位，1bit固定为0，而在其他状态(轻量级锁定、重量级锁定、GC标记、可偏向)下对象的存储内容见下表。

        对象头的另外一部分是类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。 并不是所有的虚拟机实现都必须在对象数据上保留类型指针，换句话说，查找对象的元数据信息并不一定要经过对象本身。另外，如果对象是一个Java数组，那在对象头中还必须有一块用于记录数组长度的数据，因为虚拟机可以通过普通Java对象的元数据信息确定Java对象的大小，但是从数组的元数据中却无法确定数组的大小。

        实例数据部分是对象真正存储的有效信息，也是在程序代码中所定义的各种类型的字段内容。无论是从父类继承下来的，还是在子类中定义的，都需要记录起来。这部分的存储顺序会收到虚拟机分配策略参数（FieldsAllocationStyle）和字段在Java源码中定义顺序的影响。HotSpot虚拟机默认的分配策略为longs/doubles、ints、shorts/chars、bytes/booleans、oops(Ordinary Object Pointers)，从分配策略中可以看出，相同宽度的字段总是被分配到一起。在满足这个前提条件的情况下，在父类中定义的变量会出现在子类之前。如果CompactFields参数值为true(默认为true)，那么子类之中较窄的变量也可能会插入到父类变量的空隙之中。

        第三部分对齐填充并不是必然存在的，也没有特别的含义，它仅仅起着占位符的作用。由于HotSpot VM的自动内存管理系统要求对象起始地址必须是8字节的整数倍，换句话说，就是对象的大小必须是8字节的整数倍。而对象头部分正好是8字节的倍数(1倍或者2倍)，因此，当对象实例数据部分没有对齐时，就需要通过对齐填充来补全。

对象的访问定位

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

        如果使用句柄访问的话，那么Java堆中将会划分出一块内存来作为句柄池，reference中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自的具体地址信息，如下图：

        如果使用直接指针访问，那么Java堆对象的布局中就必须考虑如何放置访问类型数据的相关信息，而reference中存储的直接就是对象地址，如下图：

        这两种对象访问方式各有优势，使用句柄来访问的最大好处就是reference中存储的是稳定的句柄地址，在对象被移动(垃圾收集时移动对象是非常普遍的行为)时只会改变句柄中的实例数据指针，而reference本身不需要修改。使用直接指针访问方式的最大好处就是速度更快，它节省了一次指针定位的时间开销，由于对象的访问在Java中非常频繁，因此这类开销积少成多后也是一项非常可观的执行成本。HotSpot虚拟机是使用直接指针的访问方式进行对象访问的。

OutOfMemoryError异常

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

Java堆溢出

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

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

        Java堆内存的OOM异常是实际应用中常见的内存溢出异常情况。当出现Java堆内存溢出时，异常堆栈信息“java.lang.OutOfMemoryError”会跟着进一步提示“Java heap space”。

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

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

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

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

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

        关于虚拟机栈和本地方法栈,在Java虚拟机规范中描述了两种异常:

        如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError异常。如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常。

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

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

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

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

        运行时常量池溢出，在OutOfMemoryError后面跟随的提示信息是“PermGen space”，说明运行时常量池属于方法区(HotSpot虚拟机中的永久代)的一部分。

        通过-XX:PermSize和-XX:MaxPermSize限制方法区大小，从而间接限制其中常量池的容量。

本机直接内存溢出

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

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

关于Android的OOM，可参考：http://www.jianshu.com/p/f5d8d3066b36