JVM笔记：Java虚拟机的内存结构

前言

开始先说明一个知识点，Java虚拟机的内存结构和内存模型（JMM）其实是两个不一样的东西，前者是下面要讲的堆栈之类的内容，后者可以看这篇文章。

由于全局字符串常量池（string pool或string literal pool） 在Java不同的版本中存放在不同的位置，下面以Java8为例。

• 运行时数据区

  Java虚拟机在执行Java程序的过程中会把它管理的内存分为若干个数据区域，每个区域都有自己各自的用途和生命周期，有些区域岁虚拟机进程的启动而存在，有些区域则依赖用户线程的启动和结束而建立和销毁。
  根据 《Java虚拟机规范》的规定，Java虚拟机所管理的内存会包含以下几个运行时数据区域，如下图所示。但是要记住这里只是一种规范，例如方法区是JVM的规范，但Java 1.8以前的**永久代（PermGen space）**和Java 1.8的 **元空间（Metaspace）**则是对这种规范的 实现。
  

• Java堆

  对大多数应用来说，Java堆（Java Heap）是Java虚拟机所管理的内存中最大的一块。Java堆是所有线程共享的一块内存区域，在虚拟机启动的时候创建。改内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存，Java虚拟机规范中的描述是：所有对象以及数组都要在对上分配。但是随着JIT编译器的发展和逃逸技术分析技术逐渐成熟，站上非配、标量替换优化技术将会导致一些微妙的变化发生，所有的对象都分配在对上也渐渐的变得不是那么绝对了。

  Java堆也是垃圾收集器管理的主要区域，因此很多时候也被称为“GC堆”。目前内存回收基本都采用分带手机算法，所以Java堆还可以细分为新生代和老生代，再细一点还可以分为Eden空间、From Survivor空间、To Survivor空间等。

  因为Java堆是线程共享的，所以Java堆可能划分多个线程私有的分配缓存区（Thread Local Allocation Buffer =TLAB），不过无论怎么划分，其存放的还是对象实例，进一步划分的目的是为了更好的回收内存，或者更快的分配内存。（TODO:垃圾回收和内存分配）

  根据Java虚拟机规范的规定，Java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可，就像我们的磁盘空间一样。在实际操作室，我们可以通过-Xmx和-Xms实现大小扩展。
  如果堆中没有足够的内存来分配创建的实例，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。

• 方法区

  方法区同Java堆一样，是各个线程共享的内存区域，主要用于存储已被虚拟机加载的类信息，常量、静态变量、即时编译后的代码等数据。虽然Java虚拟机规范把方法区描述为对的一个逻辑部分，但是它有一个别名叫Non-Heap（非堆），目的应该是与堆区分开来。

  对于HosSpost来说，更多人把方法区称为“永久代（PermGen space)”,本质上两者并不相等，仅仅因为HotSpot虚拟机的设计团队选择把GC分带收集扩展到方法区，或者说永久代是方法区的一个实现方式。这样HotSpot的垃圾收集器可以像管理Java堆一样管理这部分内存，能够节省去专门写管理方法区内存的代码的工作，但是如何实现方法区属于虚拟机的实现细节，不受Java虚拟机规范约束，类似BEA、JRockit、IBM J9虚拟机就不存在永久代的概念。

  Java虚拟机规范对方法区的限制非常宽松，和Java堆一样不需要连续的内存，可以再JVM启动时设定固定的大小和可扩展，还可以选择不实现垃圾收集。但是并不意味着数据进入了方法区就如同永久代这个名字一样“永久”存在了，这个区域的回收目标主要针对常量池的回收和对类型的卸载（TODO）,一般来说，这部分区域的回收的能力相当弱，尤其是类型的卸载，条件相当苛刻，但是这部分区域回收也确实是必要的。

  永生代的移除从Java7就慢慢开始了，符号引用(Symbols)转移到了native heap，字面量(interned strings)转移到了java heap，类的静态变量(class statics)转移到了java heap。
  在Java8中，用元空间替代了永生代。不同于在堆上分配空间的永生代，元空间的数据存储在本地内存（Native Memory）中，并不存在于虚拟机中，这样也就不会出现OutOfMemoryError异常。

  这里说一个最重要的点，就是字符串常量池，在JDK6的时候存在于永生代中，其内存放对象。在JDK7以及以后存在于堆中，其内存放字面量(interned strings)和字符串在堆上的内存地址（也称字符串引用），但String对象是全部处于堆上。用存于本地内存的StringTale来保存字符串引用，在调用String.intern()时会检测该字符串，如果字符串常量池中未存在该字符串的引用，添加并保存改字符串在堆上的地址，如果字符串常量池中存在引用则直接返回，避免产生新的String的开销。其结构类似于我们常用的hashtable。

-XX:PermSize
方法区初始大小
-XX:MaxPermSize
方法区最大大小
超过这个值将会抛出OutOfMemoryError异常:java.lang.OutOfMemoryError: PermGen

-XX:MetaspaceSize 初始空间大小，达到该值就会触发垃圾收集进行类型卸载，同时GC会对该值进行调整：
如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过MaxMetaspaceSize时，适当提高该值。
-XX:MaxMetaspaceSize最大空间，默认是没有限制的。
-XX:MinMetaspaceFreeRatio在GC之后，最小的Metaspace剩余空间容量的百分比，减少为分配空间所导致的垃圾收集
-XX:MaxMetaspaceFreeRatio在GC之后，最大的Metaspace剩余空间容量的百分比，减少为释放空间所导致的垃圾收集

• 程序计数器

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

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

  如果线程正在执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址;如果正在执行的是Native方法，这个计数器值则为空（Undenfined）。此内存区域是唯一一个在Java虚拟机规范中没有规定任何OOM异常的区域。

• Java虚拟机栈

  同程序计数器一样，Java虚拟机栈也是线程私有的，听他的生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型：每个方法在执行的同事都会创建一个栈帧（Stack Frame）
  用于存储局部变量表、操作数栈、动态链接、方法出口灯信息。每一个方法从调用直至执行完成的过程，都对应着一个栈帧在虚拟机中入栈到出栈的过程。

  经常有人把Java内存区分为堆内存（Heap）和栈内存（Stack）,这种分法比较粗糙，Java内存区域的划分实际上远比这复杂。这种划分方式的流行只能说明大多数程序员最关注、与对象内存分配最密切的内存区域是这两块。其中所指的“堆”在上面的Java堆有简要描述，但其内容远远不止如此，而“栈”则就是现在所讲的虚拟机栈，或者说是虚拟机栈中局部变量表部分。

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

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

  在Java虚拟机规范中，对于这个区域规定了两种异常状况：如果线程请求的栈深度大于虚拟机多允许的深度，将抛出StackOverflowError异常（最典型的就是递归时没有设置好终止值）；如果虚拟机栈可以动态扩展（当前大部分的Java虚拟机都可动态扩展，只不过Java虚拟机规范中也允许固定长度的虚拟机栈），如果扩展时无法申请到足够的内存，就会抛出OutOfMemoryError异常。

• 本地方法栈

  本地方法栈与虚拟机栈所发挥的作用是非常相似的，他们的区别不过是虚拟机栈执行Java方法（也就是字节码）服务，而本地方法栈则为虚拟机使用到Native方法服务。虚拟机规范中没有对本地方法栈中使用的语言、方式和数据结构作强制规定，具体的内容由虚拟机自由实现。甚至有的虚拟机（Sun HotSpot）直接就把本地方法栈和虚拟机栈合二为一。

  与虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError和OutOfMemoryError异常。

• 直接内存

  直接内存(Direct Memory）并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域。但是这部分内存也被频繁使用，而且也可能导致OutOfMemoryError异常出现，所以这里简单描述下。

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

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

• 总结

  本片内容绝大部分来自于周志明版的深入理解Java虚拟机，看了一些系列的文章，发现还是书里讲的比较细且容易懂，这里只是搬运下，书中运行时常量池这一块并没有写下来，是因为后续想针对这个做一个更详细的总结。