深入理解JVM-Java内存区域

Java 内存区域

1.1 概述

  对于 C /C++ 程序的开发人员来说,在内存管理领域他们既是“皇帝”也是“劳动人民”——一方面确实的拥有每个对象的所有权,另一方面又肩负着每一个对象生命开始到终结的维护责任。

  对于 Java 程序的开发人员来说,在虚拟机自动内存管理机制的帮助下,不需再为每一个 new 操作去写配对的 delete/free 代码,不容易出现内存泄漏和内存溢出问题。不过,正是由于 Java 程序员将内存控制的权力交给了 Java 虚拟机,一旦出现内存泄漏的溢出方面的问题,排查错误将会成为异常艰难的过程,因此我们有必要去了解虚拟机是如何去使用内存的,现在让我们走出第一步。

1.2 运行时数据区域

  Java 虚拟机在执行 Java 程序的过程中会把它所管理的内存划分为若干个不同的数据区域,这些区域都有各自的用途、创建和销毁的时间,有的区域随着虚拟机进程的启动而存在,有些区域则依赖用户线程的启动和结束而建立与销毁。

1.2.1 程序计数器

  Program Counter Register ,它是一块较小的内存空间,它可以看作是 当前线程所执行的字节码的行号指示器 ,在虚拟机概念模型里(非具体落地实现),字节码解释器工作时便是通过改变这个歌计数器的值来选取下一条需要执行的字节码指令:分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。

  由于 Java 虚拟机的多线程是通过 线程轮流切换并分配处理器执行时间 的方式来实现的,在任何一个确定的时刻,一个处理器(核)都只会执行一条线程中的指令,因此,为了线程切换后能恢复到正确的执行位置,每条线程都需要有一个独立的程序计数器,各条线程之间计数器互不影响,独立存储,我们称这类内存区域为“线程私有”的内存。

  如果线程正在执行的是一个 Java 方法,这个计数器记录的是正在执行的虚拟机字节码指令的地址:如果正在执行的是 Native 方法,这个计数器则为 undefined。此内存区域是 唯一一个 在 Java 虚拟机规范中没有规定任何 OutOfMemoryError 的区域。

1.2.2 Java 虚拟机栈

  与程序计数器一样,Java 虚拟机栈的生命周期与线程相同,虚拟机描述的是 Java 方法执行的内存模型:每个方法在执行的时候都会创建一个栈帧(Stack Frame)用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程,就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。

  不要简单的把 Java 内存区分为堆内存(Heap)和栈内存(Stack),实际上 Java 的内存区域划分远比这个复杂的多。这种划分方式只能说明大多数程序员最关注的,与对象内存分配关系最密切的内存区域就是堆和栈。

  局部变量表存放了编译期可知的各种基本数据类型(boolean,byte,char,short,int,float,long,double),对象引用(reference 类型,不等同于对象本身,可能是一个指向对象起始地址的引用指针,也可能是指向一个代表对象的句柄或其他与此对象相关的位置)和 returnAddress 类型(指向一条字节码指令的地址)

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

  在虚拟机规范中对这个区域规定了两种异常状况:如果线程请求的栈深度大于虚拟机所运行的深度,将抛出StackOverflowError异常;如果虚拟机栈可以动态扩展,当扩展时无法申请到足够的内存,将抛出OutOfMemoryError异常。

1.2.3 本地方法栈

  Native Method Stack,它与虚拟机栈所发挥的作用是非常相似的,他们之间的区别不过是虚拟机栈为虚拟机执行 Java 方法(字节码)而服务,本地方法栈则为虚拟机使用到的 Native 方法服务,在虚拟机规范中对本地方法栈中方法使用的语言、使用方式与数据结构并没有强制规定,因此它的落地实现可以很自由,甚至可以把本地方法栈和虚拟机栈合二为一(HotSpot 虚拟机)。与虚拟机栈一样,它也会抛出StackOverflowError异常和OutOfMemoryError异常。

1.2.4 Java 堆

  Java Heap,对于大多数应用来说,这个区域将是 Java 虚拟机所管理的内存中最大的一块。Java 堆是 被所有线程共享的一块内存区域 ,在虚拟机启动时创建。此内存区域唯一目的就存放对象实例,几乎所有的对象实例都在这里分配内存。这一点在规范中的描述是:所有的对象实例及数组都要在堆上分配。但是随着逃逸分析技术的成熟,栈上分配、标量替换优化技术使得情况发生了一些微妙的变化。

  Java 堆也是 垃圾收集器管理的主要区域,因此很多时候也别称作“GC 堆”(Garbage Collected Heap,垃圾堆?)。从内存回收的角度来看,由于现在收集器基本都采用分代收集算法,所以 Java 堆中还可以细分为:新生代老年代。再细致一点的有 Eden 空间,From Survivor 空间、To Survivor 空间等。从内存分配的角度看,线程共享的 Java 堆中可能划分出多个线程私有的分配缓冲区(Thread Local Allowcation Buffer,YLAB)。不过无论如何划分,都与存放内容无关,无论哪个区域,存储的都仍然是对象实例,进一步划分的目的是为了更好地回收内存,或者更快地分配内存。

  根据 Java 虚拟机规范的约定,Java 堆可以处在不连续的内存空间中,只要逻辑上是连续的即可。就像我们的磁盘空间一样,在实现时,既可以实现成固定大小的,也可以是可扩展的。不过当前主流的虚拟机都是按可扩展实现的,如果在堆中没有内存完成实例分配,并且堆也无法再扩展时,将会抛出OutOfMemoryError异常。

1.2.5 方法区

  Method Area,与 Java 堆一样是线程共享的内存区域,它用来存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然 Java 虚拟机规范把方法区描述为堆的一个逻辑部分,但是他却有一个别名——Non Heap, 用来与 Java 堆区区分。

  很多人愿意把方法区称为“永久代”,但其实本质上这两者并不等价,仅仅是因为 HopSpot 虚拟机的设计团队选择把 GC 分代收集扩展至方法区,或者说使用永久代来实现方法区而已。原则上,如何实现方法区属于虚拟机实现细节,不受虚拟机规范约束,但使用永久代实现方法区在如今看来确非一个好主意:因为这样更容易遇到内存泄漏问题,而且极少数方法会因这个原因导致不同虚拟机下有不同的表现。(现在 HopSpot 已经将原本放在永久代的字符串常量池移出)

  规范对方法区的限制非常宽松,除了和 Java 堆一样不需要连续的内存和可以选择固定大小或者可扩展外,还可以选择不实现垃圾收集。相对而言,垃圾收集行为在这个区域是比较少出现的。

  根据规范规定:当方法区无法满足内存分配需求时,将抛出OutOfMemoryError异常。

1.2.6 运行时常量池

  Runtime Constant Pool,这个区域是方法区的一部分,Class 文件中定义了存放编译期生成的各种字面量和符号引用的常量池,这部分将在类加载后进入方法区的运行时常量池存放。

  Java 虚拟机对 Class 文件每一部分的格式都有严格规定,每一个字节用于存储哪种数据都必须符合规范上的要求才会被虚拟机认可,装载和执行,但对于运行时常量池,规范没有做任何细节的要求,不过一般来说,除了符号引用外,它还会把翻译出来的直接引用也存储在运行时常量池中。

  运行时常量池相对于 Class 文件常量池的另外一个重要特征是具备动态性,Java 语言并不要求常量一定只在编译期才能产生,运行期也可能将新的常量放入池中(String 类的 intern() 方法)

  当常量区无法再申请到内存时会抛出OutOfMemoryError异常。

1.2.7 直接内存

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

  在 JDK1.4 后,引入了一种基于通道(Channel)与缓冲区(Buffer)的 I / O 方式,它可以使用 Native 函数库直接分配堆外内存,然后通过一个存储在 Java 堆中的 DirectByteBuffer 对象作为这块内存的引用进行操作。

  服务器管理员在设置虚拟机参数时,会根据实际内存设置 -Xmx 等参数信息,但经常忽略直接内存,使得给个内存区域总和大于物理内存限制(这包括物理的和操作系统级别的限制),从而导致动态扩展时出现OutOfMemoryError异常。

1.3 HotSpot 虚拟机

  以 HotSpot 为例去探讨在 Java 堆中对象分配,布局和访问的全过程。

1.3.1 对象的创建

  Java 是一门面向对象的编程语言,在 Java 程序运行过程中无时无刻都有对象被创建出来,在语言层面上,创建对象通常仅仅是一个 new 关键字而已。

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

  在类加载检查通过后,接下来将虚拟机为新生对象分配内存。对象所需的内存在类加载完成后便可完全确定,为对象分配空间的任务等同于把一块确定大小的内存从 Java 堆中划分出来。假设 Java 堆中内存是绝对规整的,所有用过的内存都放在一边,空闲的放在另一边,中间放着一个指针作为分界点的指示器,那所有分配内存就仅仅是把 那个指针向空闲那边挪动一段与对象大小相等的距离。这种分配方式称为“指针碰撞”。

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

  选择哪种分配方式由 Java 堆是否规整决定,而 Java 堆是否规整是由所采用的垃圾收集器是否带有压缩整理功能决定。

  除如何划分可用空间外,还有另外一个需要考虑的问题是对象创建在虚拟机中是非常频繁的行为,即使是仅仅修改一个指针所指向的位置,在并发情况下也不是线程安全的,可能正在给对象 A 分配内存,指针还没来得及修改,对象 B 又同时使用了原来的指针来分配内存。解决这个问题有两种方案:一种是对分配内存空间的动作进行同步处理——实际上虚拟机采用 CAS 配色失败重试的方式保证更新操作的原子性,另一种是把内存分配的动作按照线程划分在不同的空间之中进行,即每个线程在 Java 堆中分配一小块内存,称为本地线程分配缓冲(TLAB)。哪个线程要分配内存,就在哪个 TLAB 上分配,只有 TLAB 用完并分配新的 TLAB 时,才需要同步锁定。虚拟机是否使用 TLAB,可以通过-XX:+/-UseTLAB参数决定。

  内存分配完成后,虚拟机需要将分配到的内存空间都初始化为零值(不包括对象头),如果使用 TLAB,这一工作也可以提前至 TLAB 分配时进行,这一步操作保证了对象的实例字段在 Java 代码中可以不赋初始值就直接使用,程序能访问到这些字段的数据类型所对应的零值。

  接下来,虚拟机要对对象进行必要的设置,例如这个对象是哪个类的实例,如何才能找到类的元数据信息,对象的哈希值,对象的 GC 分代年龄等信息。这些信息存放在对象的对象头中,根据虚拟机当前的运行状态的不同,如是否使用偏向锁等,对象头会有不同的设置方式。

  以上工作都完成后,从虚拟机的视角看,一个新的对象已经产生了,但从 Java 程序的视角看,对象创建才刚刚开始——<init> 方法还没有执行,所有的字段还都为零。直到执行<init>方法后,一个真正可用的对象才算完全产生出来。

1.3.2 对象的内存布局

  在 HopSpot 虚拟机中,对象在内存中存储的布局可以分为 3 块区域:对象头,实例数据和对齐填充。

  对象头包括两部分信息:第一部分用于存储对象自身的运行时数据,如 HashCode,GC 分代年龄,锁状态标志,线程持有的锁,偏向线程 ID,偏向时间戳等。这部分数据的长度在 32 位和 64 位的虚拟机中分别为 32bit 和 64bit。对象头的另一部分是类型指针,即对象指向它的类元数据的指针,虚拟机通过这个指针确定这个对象是哪个类的实例。并不是所有的虚拟机实现都必须在对象数据上保留类型指针,换句话说,查找对象的元数据信息并不一定要经过对象本身。

  实例数据部分是对象真正存储的有效信息:也是在程序代码中所定义的各种类型的字段内容,无论是从父类继承下来的,还是在子类中定义的,都需要记录起来,这部分的存储顺序会受到虚拟机分配策略参数和字段在 Java 源码中定义顺序的影响。

  对象填充部分不是必然存在的,也没有特别的含义,它仅仅起着占位符的作用(要求对象起始地址必须是 8 字节的整数倍)

1.3.3 对象的访问定位

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

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

1.4 OutOfMemoryError 异常

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

1.4.1 Java 堆溢出

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

  要解决这个区域的异常,首先要通过内存映射工具对 Dump 出来的堆转存储快照分析,重点是确认内存中的对象是否是必要的,也就是要先分清楚到底是出现了内存泄漏还是内存溢出

  如果是内存泄漏,可进一步通过工具查看泄漏对象到 GC Roots 的引用链,于是就能找到泄漏对象是通过怎样的路径与 GC Roots 相关联并导致垃圾回收器无法自动回他们的。

  如果不存在泄漏(内存中的对象确实都还必须存活),那就应当检查虚拟机的堆参数(-Xmx 与 -Xms),与物理机内存对比看是否还可以调大。

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

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

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

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

public class RuntimeConstantPoolOOm{
    public static void main(String[] args){
        String str1 = new StringBuilder("计算机").append("软件").toString();
        System.out.println(str1.intern() == str1);
        
         String str1 = new StringBuilder("ja").append("va").toString();
        System.out.println(str2.intern() == str2);
    }
}

  

  JDK1.6 中得两个 false,1.7 种得一个 true 和一个 false,这主要得字符串常量池从 1.7 后被从永久代中移除。

  方法区溢出也是一种常见的内存溢出异常,一个类要被垃圾收集器回收,判定条件是比较苛刻的。在经常动态生成大量 Class 应用中,需要特别注意类的回收情况。

1.4.4 本机直接内存溢出

  DirectMemory 容量可通过-XX:MaxDirectMemorySize指定,如果不指定,则默认与 Java 堆最大值(-Xmx 指定)一样。由 DIrectMemory 导致的内存溢出,一个明显的特征是 Heap Dump 文件中不会看见明显的异常。

1.5 小结

  没有小结,主要明白了虚拟机中的内存是如何划分的。