JVM内存模型1 程序计数器2. Java虚拟机栈(JVM Stack)3. 本地方法栈(Native Method Stack)4 Java堆(Java Heap)5 方法区6 直接内存(Direc

JVM内存模型

1 程序计数器

1.1. 定义

程序计数器是一块较小的内存空间，可看作当前线程正在执行的字节码的行号指示器 如果当前线程正在执行的是

• Java方法 计数器记录的就是当前线程正在执行的字节码指令的地址
• 本地方法 那么程序计数器值为undefined

1.2. 作用

程序计数器有两个作用

• 字节码解释器通过改变程序计数器来依次读取指令，从而实现代码的流程控制，如：顺序执行、选择、循环、异常处理。
• 在多线程的情况下，程序计数器用于记录当前线程执行的位置，从而当线程被切换回来的时候能够知道该线程上次运行到哪儿了。

1.3. 特点

一块较小的内存空间 线程私有。每条线程都有一个独立的程序计数器。 是唯一一个不会出现OOM的内存区域。 生命周期随着线程的创建而创建，随着线程的结束而死亡。

2. Java虚拟机栈(JVM Stack)

2.1. 定义

Java虚拟机栈是描述Java方法运行过程的内存模型

Java虚拟机栈会为每一个即将运行的Java方法创建“栈帧” 用于存储该方法在运行过程中所需要的一些信息

• 局部变量表 存放基本数据类型变量、引用类型的变量、returnAddress类型的变量
• 操作数栈
• 动态链接
• 当前方法的常量池指针
• 当前方法的返回地址
• 方法出口等信息

每一个方法从被调用到执行完成的过程,都对应着一个个栈帧在JVM栈中的入栈和出栈过程

注意：人们常说，Java的内存空间分为“栈”和“堆”，栈中存放局部变量，堆中存放对象。 这句话不完全正确！这里的“堆”可以这么理解，但这里的“栈”就是现在讲的虚拟机栈,或者说Java虚拟机栈中的局部变量表部分. 真正的Java虚拟机栈是由一个个栈帧组成，而每个栈帧中都拥有：局部变量表、操作数栈、动态链接、方法出口信息.

2.2. 特点

局部变量表的创建是在方法被执行的时候,随着栈帧的创建而创建. 而且表的大小在编译期就确定,在创建的时候只需分配事先规定好的大小即可. 在方法运行过程中,表的大小不会改变

Java虚拟机栈会出现两种异常

• StackOverFlowError 若Java虚拟机栈的内存大小不允许动态扩展,那么当线程请求的栈深度大于虚拟机允许的最大深度时(但内存空间可能还有很多),就抛出此异常
• OutOfMemoryError 若Java虚拟机栈的内存大小允许动态扩展,且当线程请求栈时内存用完了,无法再动态扩展了,此时抛出OutOfMemoryError异常

Java虚拟机栈也是线程私有的,每个线程都有各自的Java虚拟机栈,而且随着线程的创建而创建,随着线程的死亡而死亡.

3. 本地方法栈(Native Method Stack)

本地方法栈和Java虚拟机栈实现的功能与抛出异常几乎相同 只不过虚拟机栈是为虚拟机执行Java方法(也就是字节码)服务,本地方法区则为虚拟机使用到的Native方法服务.

4 Java堆(Java Heap)

存放所有的类实例及数组对象 除了实例数据，还保存了对象的其他信息，如Mark Word（存储对象哈希码，GC标志，GC年龄，同步锁等信息），Klass Pointy(指向存储类型元数据的指针）及一些字节对齐补白的填充数据（若实例数据刚好满足8字节对齐，则可不存在补白）

特点

Java虚拟机所需要管理的内存中最大的一块.

堆内存物理上不一定要连续,只需要逻辑上连续即可,就像磁盘空间一样. 堆是垃圾回收的主要区域,所以也被称为GC堆.

堆的大小既可以固定也可以扩展,但主流的虚拟机堆的大小是可扩展的(通过-Xmx和-Xms控制),因此当线程请求分配内存,但堆已满,且内存已满无法再扩展时,就抛出OutOfMemoryError.

线程共享 整个Java虚拟机只有一个堆,所有的线程都访问同一个堆. 它是被所有线程共享的一块内存区域,在虚拟机启动时创建. 而程序计数器、Java虚拟机栈、本地方法栈都是一个线程对应一个

5 方法区

5.1 定义

Java虚拟机规范中定义方法区是堆的一个逻辑部分,但是别名Non-Heap(非堆),以与Java堆区分. 方法区中存放已经被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据.

5.2 特点

• 线程共享 方法区是堆的一个逻辑部分,因此和堆一样,都是线程共享的.整个虚拟机中只有一个方法区.
• 永久代 方法区中的信息一般需要长期存在，而且它又是堆的逻辑分区，因此用堆的划分方法，我们把方法区称为永久代.
• 内存回收效率低 Java虚拟机规范对方法区的要求比较宽松,可以不实现垃圾收集. 方法区中的信息一般需要长期存在,回收一遍内存之后可能只有少量信息无效. 对方法区的内存回收的主要目标是:对常量池的回收和对类型的卸载

和堆一样，允许固定大小，也允许可扩展的大小，还允许不实现垃圾回收。

当方法区内存空间无法满足内存分配需求时,将抛出OutOfMemoryError异常.

5.3 运行时常量池(Runtime Constant Pool)

5.3.1 定义

运行时常量池是方法区的一部分. 方法区中存放三种数据：类信息、常量、静态变量、即时编译器编译后的代码.其中常量存储在运行时常量池中.

我们知道，.java文件被编译之后生成的.class文件中除了包含：类的版本、字段、方法、接口等信息外，还有一项就是常量池 常量池中存放编译时期产生的各种字面量和符号引用，.class文件中的常量池中的所有的内容在类被加载后存放到方法区的运行时常量池中。 PS：int age = 21;//age是一个变量，可以被赋值；21就是一个字面值常量，不能被赋值； int final pai = 3.14;//pai就是一个符号常量，一旦被赋值之后就不能被修改。

Class文件中除了有类的版本、字段、方法、接口等描述信息外,还有一项信息是常量池( Constant pool table)，用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入运行时常量池中存放。运行时常量池相对于class文件常量池的另外一个特性是具备动态性，java语言并不要求常量一定只有编译器才产生，也就是并非预置入class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中。

在近三个JDK版本（6、7、8）中， 运行时常量池的所处区域一直在不断的变化， 在JDK6时它是方法区的一部分 7又把他放到了堆内存中 8之后出现了元空间，它又回到了方法区。 其实，这也说明了官方对“永久代”的优化从7就已经开始了

5.3.2 特性

class文件中的常量池具有动态性. Java并不要求常量只能在编译时候产生,Java允许在运行期间将新的常量放入方法区的运行时常量池中. String类中的intern()方法就是采用了运行时常量池的动态性.当调用 intern 方法时,如果池已经包含一个等于此 String 对象的字符串,则返回池中的字符串.否则,将此 String 对象添加到池中,并返回此 String 对象的引用.

5.3.3 可能抛出的异常

运行时常量池是方法区的一部分,所以会受到方法区内存的限制,因此当常量池无法再申请到内存时就会抛出OutOfMemoryError异常.

我们一般在一个类中通过public static final来声明一个常量。这个类被编译后便生成Class文件，这个类的所有信息都存储在这个class文件中。

当这个类被Java虚拟机加载后，class文件中的常量就存放在方法区的运行时常量池中。而且在运行期间，可以向常量池中添加新的常量。如：String类的intern()方法就能在运行期间向常量池中添加字符串常量。

当运行时常量池中的某些常量没有被对象引用，同时也没有被变量引用，那么就需要垃圾收集器回收。

6 直接内存(Direct Memory)

直接内存不是虚拟机运行时数据区的一部分,也不是JVM规范中定义的内存区域,但在JVM的实际运行过程中会频繁地使用这块区域.而且也会抛OOM

在JDK 1.4中加入了NIO(New Input／Output)类,引入了一种基于管道和缓冲区的IO方式,它可以使用Native函数库直接分配堆外内存,然后通过一个存储在堆里的DirectByteBuffer对象作为这块内存的引用来操作堆外内存中的数据. 这样能在一些场景中显著提升性能,因为避免了在Java堆和Native堆中来回复制数据.

综上看来 程序计数器、Java虚拟机栈、本地方法栈是线程私有的，即每个线程都拥有各自的程序计数器、Java虚拟机栈、本地方法区。并且他们的生命周期和所属的线程一样。 而堆、方法区是线程共享的，在Java虚拟机中只有一个堆、一个方法栈。并在JVM启动的时候就创建，JVM停止才销毁。

7 从GC角度看Java堆

堆和方法区都是线程共享的区域，主要用来存放对象的相关信息。我们知道，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序运行期间才能知道会创建哪些对象，因此， 这部分的内存和回收都是动态的，垃圾收集器所关注的就是这部分内存（本节后续所说的“内存”分配与回收也仅指这部分内存）。而在JDK1.7和1.8对这部分内存的分配也有所不同，下面我们来详细看一下

Java8中堆内存分配如下图：

从Java8开始，HotSpot完全将永久代（Permanent Generation）移除，取而代之的是一个新的区域—元空间（MetaSpace），它使用本地内存来存储类元数据信息。也就是说，只要本地内存足够，它不会出现像永久代中“java.lang.OutOfMemoryError: PermGen space”这种错误。同样的，对永久代的设置参数 PermSize 和 MaxPermSize 也会失效。默认情况下，“元空间”的大小可以动态调整，或者使用新参数MaxMetaspaceSize 来限制本地内存分配给类元数据的大小。

元空间特色

• 充分利用了Java语言规范：类及相关的元数据的生命周期与类加载器的一致。
• 每个类加载器都有它的内存区域-元空间
• 只进行线性分配
• 不会单独回收某个类（除了重定义类 RedefineClasses 或类加载失败）
• 没有GC扫描或压缩
• 元空间里的对象不会被转移
• 如果GC发现某个类加载器不再存活，会对整个元空间进行集体回收

GC

• Full GC时，指向元数据指针都不用再扫描，减少了Full GC的时间。
• 很多复杂的元数据扫描的代码（尤其是CMS里面的那些）都删除了。
• 元空间只有少量的指针指向Java堆。这包括：类的元数据中指向java.lang.Class实例的指针;数组类的元数据中，指向java.lang.Class集合的指针。
• 没有元数据压缩的开销
• 减少了GC Root的扫描（不再扫描虚拟机里面的已加载类的目录和其它的内部哈希表）
• G1回收器中，并发标记阶段完成后就可以进行类的卸载

元空间内存分配模型

• 绝大多数的类元数据的空间都从本地内存中分配
• 用来描述类元数据的对象也被移除
• 为元数据分配了多个映射的虚拟内存空间。
• 为每个类加载器分配一个内存块列表。
  • 块的大小取决于类加载器的类型
  • Java反射的字节码存取器（sun.reflect.DelegatingClassLoader ）占用内存更小
• 空闲块内存返还给块内存列表
• 当元空间为空，虚拟内存空间会被回收
• 减少了内存碎片

JVM关闭

• 正常关闭：当最后一个非守护线程结束或调用了System.exit或通过其他特定于平台的方式,比如ctrl+c。
• 强制关闭：调用Runtime.halt方法，或在操作系统中直接kill（发送single信号）掉JVM进程。
• 异常关闭：运行中遇到RuntimeException 异常等

在某些情况下，我们需要在JVM关闭时做一些扫尾的工作，比如删除临时文件、停止日志服务。为此JVM提供了关闭钩子（shutdown hocks）来做这些事件。

Runtime类封装java应用运行时的环境，每个java应用程序都有一个Runtime类实例，使用程序能与其运行环境相连。

关闭钩子本质上是一个线程（也称为hock线程），可以通过Runtime的addshutdownhock （Thread hock）向主jvm注册一个关闭钩子。hock线程在jvm正常关闭时执行，强制关闭不执行。

对于在jvm中注册的多个关闭钩子，他们会并发执行，jvm并不能保证他们的执行顺序。