Contents
  1. 1. 程序计数器(Program Counter Register)
  2. 2. Java虚拟机栈(Java Virtual Machine Stacks)
  3. 3. 本地方法栈(Native Method Stack)
  4. 4. Java堆(Heap)
  5. 5. 方法区(Method Area)
    1. 5.1. 运行时常量池(Runtime Constant Pool)
  6. 6. 参考链接

Java与C++之间有一堵由内存动态分配和垃圾收集技术所围成的“高墙”,墙外面的人想进去,墙里面的人却想出来。

Java虚拟机在执行Java程序的过程中会把它管理的内存划分为若干个不同的数据区域。

JVM内存结构

程序计数器(Program Counter Register)

  • 线程私有

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

程序计数器是一块“线程私有”的内存,如上文的图所示,每条线程都有一个独立的程序计数器,各条线程之间的计数器互不影响,独立存储。注意,Java虚拟机中的程序计数器指向正在执行的字节码地址,而不是下一条。这样设计使得在多线程环境下,线程切换后能恢复到正确的执行位置。

如果线程正在执行的是一个Java方法,这个计数器记录的是正在执行的虚拟机字节码指令的地址;若执行的是Native方法,则计数器为空(Undefined)(因为对于Native方法而言,它的方法体并不是由Java字节码构成的,自然无法应用上述的“字节码指令的地址”的概念)。程序计数器也是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的内存区域。

Java虚拟机栈(Java Virtual Machine Stacks)

  • 线程私有
  • 生命周期和线程相同
  • StackOverflowError
  • OutOfMemoryError

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

函数的调用有完美的嵌套关系——调用者的生命期总是长于被调用者的生命期,并且后者在前者的之内。这样,被调用者的局部信息所占空间的分配总是后于调用者的(后入),而其释放则总是先于调用者的(先出),所以正好可以满足栈的LIFO顺序,选用栈这种数据结构来实现调用栈是一种很自然的选择。

局部变量表中存放了编译期可知的各种:

  • 基本数据类型(boolen、byte、char、short、int、 float、 long、double)
  • 对象引用(reference类型,它不等于对象本身,可能是一个指向对象起始地址的指针,也可能是指向一个代表对象的句柄或其他与此对象相关的位置)
  • returnAddress类型(指向了一条字节码指令的地址)

其中64位长度的long和double类型的数据会占用2个局部变量空间(Slot),其余数据类型只占用1个。局部变量表所需的内存空间在编译期间完成分配,当进入一个方法时,这个方法需要在帧中分配多大的局部变量空间是完全确定的,在方法运行期间不会改变局部变量表的大小。

Java虚拟机规范中对这个区域规定了两种异常状况:

  • StackOverflowError:线程请求的栈深度大于虚拟机所允许的深度,将会抛出此异常。
  • OutOfMemoryError:当可动态扩展的虚拟机栈在扩展时无法申请到足够的内存,就会抛出该异常。

本地方法栈(Native Method Stack)

本地方法栈(Native Method Stack)与Java虚拟机栈作用很相似,它们的区别在于虚拟机栈为虚拟机执行Java方法(即字节码)服务,而本地方法栈则为虚拟机使用到的Native方法服务。

在虚拟机规范中对本地方法栈中使用的语言、方式和数据结构并无强制规定,因此具体的虚拟机可实现它。甚至有的虚拟机(Sun HotSpot虚拟机)直接把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样,本地方法栈会抛出StackOverflowError和OutOfMemoryError异常。

Java堆(Heap)

  • 所占空间大
  • 线程共享
  • OutOfMemoryError

Java堆是被所有的线程共享的一块内存区域,在虚拟机启动时创建。
Java堆的唯一目的就是存放对象实例,几乎所有对象实例都在这里分配内存,且每次分配的空间是不定长的。在Heap 中分配一定的内存来保存对象实例,实际上只是保存对象实例的属性值,属性的类型和对象本身的类型标记等,并不保存对象的方法(方法是指令,保存在Stack中),在Heap 中分配一定的内存保存对象实例和对象的序列化比较类似。对象实例在Heap 中分配好以后,需要在Stack中保存一个4字节的Heap 内存地址,用来定位该对象实例在Heap 中的位置,便于找到该对象实例。

Java堆是垃圾回收器管理的主要区域,因此也被称为”GC堆“。
从内存回收的角度看,由于现在收集器基本都采用分代收集算法,所以Java堆可以细分为:新生代、老生代;

内存空间划分

  • 新生代(Young): 新生成的对象优先存放在新生代中,新生代对象朝生夕死,存活率很低。在新生代中,常规应用进行一次垃圾收集一般可以回收70% ~ 95% 的空间,回收效率很高。新生代又可细分为Eden空间From Survivor空间To Survivor空间,默认比例为8:1:1。它们的具体作用将在下一篇文章讲解GC时介绍。
  • 老年代(Tenured/Old):在新生代中经历了多次(具体看虚拟机配置的阀值)GC后仍然存活下来的对象会进入老年代中。老年代中的对象生命周期较长,存活率比较高,在老年代中进行GC的频率相对而言较低,而且回收的速度也比较慢。
  • 永久代(Perm):永久代存储类信息、常量、静态变量、即时编译器编译后的代码等数据,对这一区域而言,Java虚拟机规范指出可以不进行垃圾收集,一般而言不会进行垃圾回收。

其中新生代和老年代组成了Java堆的全部内存区域,而永久代不属于堆空间,它在JDK 1.8以前被Sun HotSpot虚拟机用作方法区的实现,关于方法区的具体内容将在稍后介绍。

从内存分配的角度看,线程共享的Java堆可能划分出多个线程私有的分配缓冲区(TLAB);
不论如何划分,都与存放的内容无关,无论哪个区域,存储的仍然是对象实例。

Java虚拟机规范规定,Java堆可以处于物理上不连续的内存空间中,只要逻辑上是连续的即可,就像我们的磁盘空间一样。在实现上,既可以是固定大小的,也可以是可扩展的,不过当前主流JVM都是按照可扩展来实现的。

Java虚拟机规范规定,如果在堆上没有内存完成实例分配,并且堆上也无法再扩展时,将会抛出OutOfMemoryError异常。

内存泄露和内存溢出

Java堆内存的OOM异常是非常常见的异常情况,重点是根据内存中的对象是否是必要的,来弄清楚到底是出现了内存泄露(Memory Leak)还是内存溢出(Memory Overflow)。

  • 内存泄露:指程序中一些对象不会被GC所回收,它始终占用内存,即被分配的对象引用链可达但已无用。(可用内存减少)
  • 内存溢出:程序运行过程中无法申请到足够的内存而导致的一种错误。内存溢出通常发生于OLD段或Perm段垃圾回收后,仍然无内存空间容纳新的Java对象的情况。
    内存泄露是内存溢出的一种诱因,不是唯一因素。

方法区(Method Area)

方法区(Method Area)与Java堆一样,是各个线程共享的内存区域。用于存储已被虚拟机加载的类信息、常量、静态变量、JIT编译后的代码也存储在方法区。正因为方法区所存储的数据与堆有一种类比关系,所以它还被称为 Non-Heap

JDK 1.8以前的永久代(PermGen)

Java虚拟机规范对方法区的限制非常宽松,除了和Java堆一样不需要连续的内存和可以选择固定大小或者可扩展外,还可以选择不实现垃圾收集,也就是说,Java虚拟机规范只是规定了方法区的概念和它的作用,并没有规定如何去实现它。对于JDK 1.8之前的版本,HotSpot虚拟机设计团队选择把GC分代收集扩展至方法区,即用永久代来实现方法区,这样HotSpot的垃圾收集器可以像管理Java堆一样管理这部分内存,能够省去专门为方法区编写内存管理代码的工作。对于其他的虚拟机(如Oracle JRockit、IBM J9等)来说是不存在永久代的概念的。

如果运行时有大量的类产生,可能会导致方法区被填满,直至溢出。常见的应用场景如:

  • Spring和ORM框架使用CGLib操纵字节码对类进行增强,增强的类越多,就需要越大的方法区来保证动态生成的Class可以加载入内存。
  • 大量JSP或动态产生JSP文件的应用(JSP第一次运行时需要编译为Java类)。
  • 基于OSGi的应用(即使是同一个类文件,被不同的类加载器加载也会视为不同的类)。 ……
    这些都会导致方法区溢出,报出java.lang.OutOfMemoryError: PermGen space

JDK 1.8的元空间(Metaspace)

在JDK 1.8中,HotSpot虚拟机设计团队为了促进HotSpotJRockit的融合,修改了方法区的实现,移除了永久代,选择使用本地化的内存空间(而不是JVM的内存空间)存放类的元数据,这个空间叫做元空间(Metaspace)。

做了这个改动以后,java.lang.OutOfMemoryError: PermGen的空间问题将不复存在,并且不再需要调整和监控这个内存空间。且虚拟机需要为方法区设计额外的GC策略:如果类元数据的空间占用达到参数“MaxMetaspaceSize”设置的值,将会触发对死亡对象和类加载器的垃圾回收。 为了限制垃圾回收的频率和延迟,适当的监控和调优元空间是非常有必要的。元空间过多的垃圾收集可能表示类、类加载器内存泄漏或对你的应用程序来说空间太小了。

元空间的内存管理由元空间虚拟机来完成。先前,对于类的元数据我们需要不同的垃圾回收器进行处理,现在只需要执行元空间虚拟机的C++代码即可完成。在元空间中,类和其元数据的生命周期和其对应的类加载器是相同的。换句话说,只要类加载器存活,其加载的类的元数据也是存活的,因而不会被回收掉。

我们从行文到现在提到的元空间稍微有点不严谨。准确的来说,每一个类加载器的存储区域都称作一个元空间,所有的元空间合在一起就是我们一直说的元空间。当一个类加载器被垃圾回收器标记为不再存活,其对应的元空间会被回收。在元空间的回收过程中没有重定位和压缩等操作。但是元空间内的元数据会进行扫描来确定Java引用。

元空间虚拟机负责元空间的分配,其采用的形式为组块分配。组块的大小因类加载器的类型而异。在元空间虚拟机中存在一个全局的空闲组块列表。当一个类加载器需要组块时,它就会从这个全局的组块列表中获取并维持一个自己的组块列表。当一个类加载器不再存活,那么其持有的组块将会被释放,并返回给全局组块列表。类加载器持有的组块又会被分成多个块,每一个块存储一个单元的元信息。组块中的块是线性分配(指针碰撞分配形式)。组块分配自内存映射区域。这些全局的虚拟内存映射区域以链表形式连接,一旦某个虚拟内存映射区域清空,这部分内存就会返回给操作系统。

元组块的分配

上图展示的是虚拟内存映射区域如何进行元组块的分配。类加载器1和3表明使用了反射或者为匿名类加载器,他们使用了特定大小组块。 而类加载器2和4根据其内部条目的数量使用小型或者中型的组块。

运行时常量池(Runtime Constant Pool)

运行时常量池(Runtime Constant Pool) 是方法区的一部分。 Class文件 中除了有类的版本、字段、方法、接口等描述信息外,还有一项信息是 常量池(Constant Pool Table),用于存放编译期生成的各种字面量和符号引用,这部分内容将在类加载后进入方法区的运行时常量池存放

Java虚拟机对Class文件每一部分(自然包括常量池)的格式有严格规定,每一个字节用于存储那种数据都必须符合规范上的要求才会被虚拟机认可、装载和执行。但对于运行时常量池,Java虚拟机规范没有做任何有关细节的要求,不同的提供商实现的虚拟机可以按照自己的需求来实现此内存区域。不过一般而言,除了保存Class文件中的描述符号引用外,还会把翻译出的直接引用也存储在运行时常量池中。

运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性,Java语言并不要求常量一定只有编译器才能产生,也就是并非置入Class文件中的常量池的内容才能进入方法区运行时常量池,运行期间也可能将新的常量放入池中,此特性被开发人员利用得比较多的便是String类的intern()方法。

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

1
2
3
4
5
6
7
public static void main(String[] args) { 
String str1 = new StringBuilder("计算机").append("软件").toString();
System.out.println(str1.intern() == str1);

String str2 = new StringBuilder("ja").append("va").toString();
System.out.println(str2.intern() == str2);
}

这段代码在JDK1.6中运行,会得到两个false,而在JDK1.7中运行,会得到一个true和一个false。原因是:

  • 在JDK1.6中intern()方法会把首次遇到的字符串实例复制到永久代中,返回的也是永久代中这个字符串实例的引用,而由StringBuilder创建的字符串实例在Java堆上,所以必然不是一个引用。
  • 在JDK1.7中intern()方法不会复制实例,只是在常量池中记录首次出现的实例引用,因此intern()返回的引用和由StringBuilder创建的字符串实例是同一个。
  • str2返回false是因为Java这个字符串在执行 StringBuilder("ja").append("va").toString()之前已经出现过,字符串常量池中已经有它的引用了,不符合首次出现的原则,而"计算机软件"这个字符串是首次出现的。

参考链接

  1. 《深入理解Java虚拟机——JVM高级特性与最佳实践》-周志明
  2. crowhawk.github.io
  3. 梦工厂简书博客
Contents
  1. 1. 程序计数器(Program Counter Register)
  2. 2. Java虚拟机栈(Java Virtual Machine Stacks)
  3. 3. 本地方法栈(Native Method Stack)
  4. 4. Java堆(Heap)
  5. 5. 方法区(Method Area)
    1. 5.1. 运行时常量池(Runtime Constant Pool)
  6. 6. 参考链接