JVM内存区域

包含：

• 程序计数器
• 虚拟机栈
• 本地方法栈
• 堆
• 方法区（包含运行时常量池）
• 直接内存

线程私有：程序计数器，虚拟机栈，本地方法栈
线程共享：堆，方法区

程序计数器

程序计数器是一块较小的内存空间，可以看作是当前线程执行的字节码行号指示器，JVM 通过改变这个计数器的值，来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能。
程序计数器空间是私有的，原因在于 Java 虚拟机是通过线程轮流切换并分配处理器时间来实现的多线程，为了线程切换后能恢复到正确的执行位置，每个线程都需要一个独立的程序计数器。
如果线程正在执行 Java 方法，则程序计数器记录的是虚拟机字节码指令地址
如果线程正在执行 Native 方法，则程序计数器值为空（Undefined）
程序计数器是唯一一个在 Java 虚拟机规范中不会发生 OutOfMemoryError 的区域。

简单说就是控制线程执行、切换的计数指示器。

虚拟机栈

每个方法在执行时都会创建一个栈帧（Stack Frame），用于存储局部变量表、操作数栈、动态链接、方法出口等信息。方法运行从开始到结束，对应的是栈帧在虚拟机栈中入栈及出栈的过程。以下着重介绍局部变量表。

局部变量表存放以下类型的变量，其中 64 位长度的 long 和 double 类型数据会占用 2 个局部变量空间（Slot），其余数据类型只占据 1 个。

编译期已知的各种基本数据类型：boolean、byte、char、short、int、float、long、double
对象引用：reference 类型，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置
returnAddress 类型：指向字节码指令地址
局部变量表所需的内促农建在编译期间完成分配，在方法运行期间不会更改局部变量表的大小。

在 Java 虚拟机规范中，对这个区域规定了两种异常情况：

StackOverflowError: 线程请求的栈深度大于虚拟机所允许的深度
OutOfMemoryError: 虚拟机栈进行动态扩展时无法申请到足够的内存

下面用一段简单的代码说明操作栈与局部变量表的交互

详细的字节码操作顺序如下:

简单说就是方法的局部变量和操做入栈和出栈的栈空间。

本地方法栈

虚拟机栈是为虚拟机执行Java方法(也就是字节码)服务,本地方法区则为虚拟机使用到的Native方法服务.

虚拟机栈“主内”，而本地方法栈“主外”
这个“内外”是针对JVM来说的，本地方法栈为Native方法服务。线程开始调用本地方法时，会进入一个不再受JVM约束的世界，本地方法可以通过JNI(Java Native Interface)来访问虚拟机运行时的数据区，甚至可以调用寄存器,具有和JVM相同的能力和权限，当大量本地方法出现时,势必会削弱JVM对系统的控制力,因为它的出错信息都比较黑盒.
对于内存不足的情况，本地方法栈还是会拋出native heap OutOfMemory、以及 StackOverflowError 和 OutOfMemoryError

最著名的本地方法应该是System.currentTimeMillis()

Java 堆（Heap）

虚拟机所管理的内存中最大的一块区域，被所有线程共享。堆存在的唯一意义是存放对象实例，在 Java 虚拟机规范中的表述是“所有的对象和数组都要在堆上分配”。但是随着 JIT 编译器的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致这一规则不再那么绝对。GC 就是对堆上的对象进行回收。堆区域空间不足会导致 OOM。
堆的内存空间既可以固定大小，也可运行时动态地调整，通过如下参数设定初始值和最大值，比如

-Xms256M. -Xmx1024M

• -X表示它是JVM运行参数
• ms是memorystart的简称 最小堆容量
• mx是memory max的简称 最大堆容量

但是在通常情况下，服务器在运行过程中，堆空间不断地扩容与回缩，势必形成不必要的系统压力，所以在线上生产环境中，JVM的Xms和Xmx设置成一样大小，避免在GC后调整堆大小时带来的额外压力。

堆分成两大块:新生代和老年代
对象产生之初在新生代，步入暮年时进入老年代，但是老年代也接纳在新生代无法容纳的超大对象

新生代= 1个Eden区+ 2个Survivor区
绝大部分对象在Eden区生成，当Eden区装填满的时候，会触发Young GC。垃圾回收的时候，在Eden区实现清除策略，没有被引用的对象则直接回收。依然存活的对象会被移送到Survivor区，这个区真是名副其实的存在。Survivor 区分为S0和S1两块内存空间，送到哪块空间呢?每次Young GC的时候，将存活的对象复制到未使用的那块空间，然后将当前正在使用的空间完全清除，交换两块空间的使用状态。如果YGC要移送的对象大于Survivor区容量上限，则直接移交给老年代。假如一些没有进取心的对象以为可以一直在新生代的Survivor区交换来交换去，那就错了。每个对象都有一个计数器，每次YGC都会加1。

-XX:MaxTenuringThreshold 

参数能配置计数器的值到达某个阈值的时候，对象从新生代晋升至老年代。如果该参数配置为1,那么从新生代的Eden区直接移至老年代。默认值是15，可以在Survivor 区交换14次之后，晋升至老年代。若Survivor区无法放下，或者超大对象的阈值超过上限，则尝试在老年代中进行分配;如果老年代也无法放下，则会触发Full Garbage Collection(Full GC);
如果依然无法放下，则抛OOM.

堆出现OOM的概率是所有内存耗尽异常中最高的。出错时的堆内信息对解决问题非常有帮助，所以给JVM设置运行参数-

XX:+HeapDumpOnOutOfMemoryError

让JVM遇到OOM异常时能输出堆内信息。

方法区（Method Area）

存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。别名 Non-Heap。HotSpot 虚拟机设计团队选择把 GC 分代收集扩展至方法区，导致也有人称呼方法区为“永久代”（Permanent Generation），但这并不是一个好的实践，会导致内存溢出问题，而且极少数的方法会因为这个原因而在不同虚拟机上产生不同表现。

垃圾收集行为在方法区是较少出现的，而且回收率不高，回收目标主要是针对常量池的回收和对类型的卸载。

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

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

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

对每个加载的类型（类class、接口interface、枚举enum、注解annotation），JVM必须在方法区中存储以下类型信息：

• 类型的完整有效名称（全名=包名.类名）
• 类型直接父类的完整有效名称( java.lang.Object除外，其他类型若没有声明父类，默认父类是Object)
• 类型的修饰符(public、abstract、final的某个子集)
• 类型直接接口的一个有序列表
• 类型的常量池( constant pool)
• 域(Field)信息
• 方法(Method)信息
• 除了常量外的所有静态(static)变量

运行时常量池（Runtime Constant Pool） 是方法区的一部分，Class 文件除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池（Constant Pool Table），用于存放编译期间生成的各种字面量和符号引用。可能会抛出 OOM 异常。

移除永久代的工作从JDK1.7就开始了。JDK1.7中，存储在永久代的部分数据就已经转移到了Java Heap或者是 Native Heap。但永久代仍存在于JDK1.7中，并没完全移除，譬如符号引用(Symbols)转移到了native heap；字面量(interned strings)转移到了java heap；JDK 1.8中 PermSize 和 MaxPermGen 已经无效。因此，可以大致验证 JDK 1.7 和 1.8 将字符串常量由永久代转移到堆中，并且 JDK 1.8 中已经不存在永久代。

元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制，但可以通过以下参数来指定元空间的大小：

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

　　除了上面两个指定大小的选项以外，还有两个与 GC 相关的属性：
　　-XX:MinMetaspaceFreeRatio，在GC之后，最小的Metaspace剩余空间容量的百分比，减少为分配空间所导致的垃圾收集
　　-XX:MaxMetaspaceFreeRatio，在GC之后，最大的Metaspace剩余空间容量的百分比，减少为释放空间所导致的垃圾收集

直接内存（Direct Memory）

直接内存不是 JVM 运行时数据区的一部分，JDK 1.4 中新加入了 NIO（New Input/Output）类，引入了一种基于通道（Channel）与缓冲区（Buffer）的 I/O 方式，可以使用 Native 函数库直接分配堆外内存，然后通过一个存储在 Java 堆的 DirectByteBuffer 对象作为这块内存的引用进行操作。从而避免在 Java 堆和 Native 堆中来回复制护具，在一些场景中显著提高性能。使用不当会有 OOM 异常。

• 由于在 JDK 1.4 中引入了 NIO 机制，为此实现了一种通过 native 函数直接分配对外内存的，而这一切是通过以下两个概念实现的：
  • 通道（Channel）;
  • 缓冲区（Buffer）;
• 通过存储在 Java 堆里面的 DirectByteBuffer 对象对这块内存的引用进行操作；
• 因避免了 Java 堆和 Native 堆（native heap）中来回复制数据，所以在一些场景中显著提高了性能；
• 直接内存出现 OutOfMemoryError 异常的原因是物理机器的内存是受限的，但是我们通常会忘记需要为直接内存在物理机中预留相关内存空间；

直接内存的最大大小可以通过 -XX:MaxDirectMemorySize 来设置，默认是 64M。

 在 Java 中分配内存的方式一般是通过 sun.misc.Unsafe类的公共 native 方法实现的（比如 文件以及网络 IO 类，但是非常不建议开发者使用，使用时一定要确保安全），而类 DirectByteBuffer 类的也是借助于此向物理内存(比如 JVM 运行于 Linux 上，那么 Linux 的内存就被称为物理内存)。

 Unsafe 是位于 sun.misc 包下的一个类，主要提供一些用于执行低级别、不安全操作的方法，如直接访问系统内存资源、自主管理内存资源等，这些方法在提升 Java 运行效率、增强 Java 语言底层资源操作能力方面起到了很大的作用。但由于 Unsafe 类使 Java 语言拥有了类似 C 语言指针一样操作内存空间的能力，这无疑也增加了程序发生相关指针问题的风险。在程序中过度、不正确使用 Unsafe 类会使得程序出错的概率变大，使得 Java 这种安全的语言变得不再“安全”，因此对 Unsafe 的使用一定要慎重。