阿里面试官：请你聊一下JVM内存管理机制

前言

面试过阿里的同学都知道，阿里的面试官喜欢往深了怼，尤其是一些平时开发不怎么常用但非常重要的知识点，更受他们的青睐，而且往往他们喜欢以连环炮的形式无限火力轰炸，这谁顶得住啊！所以我们平时一定要有意识的去积累总结这些底层的基础的知识点，形成厚厚的盔甲，面试才能一往无前，游刃有余~

1. 什么是 JVM？

JVM总结成以下几点：

Java Virtual Machine（Java虚拟机）的缩写，主要是通过在实际计算机模仿各种计算机功能来实现的
由堆、方法区、栈、本地方法栈、程序计算器等部分组成
实现跨平台的最核心的部分
.class 文件会在 JVM 上执行，JVM 会解释给操作系统执行
有自己的指令集，解释自己的指令集到 CPU 指令集和系统资源的调用
JVM 只关注被编译的 .class 文件，不关心 .java 源文件

2. JVM内存区域划分

JVM的内部体系结构分为三部分，分别是：类装载器（ClassLoader）子系统，运行时数据区，和执行引擎。

类装载器

每一个Java虚拟机都由一个类加载器子系统（class loader subsystem），负责加载程序中的类型（类和接口），并赋予唯一的名字。每一个Java虚拟机都有一个执行引擎（execution engine）负责执行被加载类中包含的指令。JVM的两种类装载器包括：启动类装载器和用户自定义类装载器，启动类装载器是JVM实现的一部分，用户自定义类装载器则是Java程序的一部分，必须是ClassLoader类的子类。

执行引擎

它或者在执行字节码，或者执行本地方法

主要的执行技术有:解释，即时编译，自适应优化、芯片级直接执行其中解释属于第一代JVM，即时编译JIT属于第二代JVM，自适应优化（目前Sun的HotspotJVM采用这种技术）则吸取第一代JVM和第二代JVM的经验，采用两者结合的方式。

自适应优化：开始对所有的代码都采取解释执行的方式，并监视代码执行情况，然后对那些经常调用的方法启动一个后台线程，将其编译为本地代码，并进行仔细优化。若方法不再频繁使用，则取消编译过的代码，仍对其进行解释执行。

3.Java运行时数据区域划分

运行时的数据区域按照生命周期的不同可以分为两个部分，分别是

随着虚拟机进程的启动而一直存在：方法区+Java堆
随着用户线程的启动和结束而建立和销毁：虚拟机栈+本地方法栈+程序计数器

运行时的数据区域按照共享的不同可以分为两个部分，分别是：

由所有线程共享的数据区：方法区+Java堆
线程隔离的数据区：虚拟机栈+本地方法栈+程序计数器

Java虚拟机所管理的运行数据区域分布如下图：
JVM运行时数据模型

3.1 程序计数器

3.1.1 程序计数器的概念

程序计数器是一个记录着当前线程所执行的字节码的行号指示器。

JAVA代码编译后的字节码在未经过JIT（实时编译器）编译前，其执行方式是通过“字节码解释器”进行解释执行。简单的工作原理为解释器读取装载入内存的字节码，按照顺序读取字节码指令。读取一个指令后，将该指令“翻译”成固定的操作，并根据这些操作进行分支、循环、跳转等流程。

从上面的描述中，可能会产生程序计数器是否是多余的疑问。因为沿着指令的顺序执行下去，即使是分支跳转这样的流程，跳转到指定的指令处按顺序继续执行是完全能够保证程序的执行顺序的。假设程序永远只有一个线程，这个疑问没有任何问题，也就是说并不需要程序计数器。但实际上程序是通过多个线程协同合作执行的。

首先我们要搞清楚JVM的多线程实现方式。JVM的多线程是通过CPU时间片轮转（即线程轮流切换并分配处理器执行时间）算法来实现的。也就是说，某个线程在执行过程中可能会因为时间片耗尽而被挂起，而另一个线程获取到时间片开始执行。当被挂起的线程重新获取到时间片的时候，它要想从被挂起的地方继续执行，就必须知道它上次执行到哪个位置，在JVM中，通过程序计数器来记录某个线程的字节码执行位置。因此，程序计数器是具备线程隔离的特性，也就是说，每个线程工作时都有属于自己的独立计数器。

3.1.2 程序计数器的特点：

线程私有，每个线程工作时都有属于自己的独立计数器
执行java方法时，程序计数器是有值的，且记录的是正在执行的字节码指令的地址
JVM规范中唯一没有规定OutOfMemoryError情况的区域
如果正在执行的是Native 方法，则这个计数器值为空（Undefined），因为native方法是java通过JNI直接调用本地C/C++库，可以近似的认为native方法相当于C/C++暴露给java的一个接口，java通过调用这个接口从而调用到C/C++方法。由于该方法是通过C/C++而不是java进行实现。那么自然无法产生相应的字节码，并且C/C++执行时的内存分配是由自己语言决定的，而不是由JVM决定的

3.2 Java虚拟机栈

Java虚拟机栈也是线程私有的，它的生命周期与线程相同（随线程而生，随线程而灭）
如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；如果虚拟机栈可以动态扩展，如果扩展时无法申请到足够的内存，就会抛出OutOfMemoryError异常；（当前大部分JVM都可以动态扩展，只不过JVM规范也允许固定长度的虚拟机栈）
Java虚拟机栈描述的是Java方法执行的内存模型:每个方法在执行的同时都会创建一个栈帧( Stack Framell )用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。

3.3 本地方法栈

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

3.4 Java堆

Java 中的堆是 JVM 所管理的最大的一块内存空间，主要用于存放各种类的实例对象。

在 Java 中，堆被划分成两个不同的区域：新生代 ( Young )、老年代 ( Old )。新生代 ( Young ) 又被划分为三个区域：Eden、From Survivor、To Survivor。这样划分的目的是为了使 JVM 能够更好的管理堆内存中的对象，包括内存的分配以及回收。
堆的内存模型大致为：
java堆
从图中可以看出：堆大小 = 新生代 + 老年代。其中，堆的大小可以通过参数 –Xms、-Xmx 来指定。

3.5 方法区

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

特点：

方法区是线程共享的；当有多个线程都用到一个类的时候，而这个类还未被加载，则应该只有一个线程去加载类，让其他线程等待；
方法区的大小不必是固定的，jvm可以根据应用的需要动态调整。jvm也可以允许用户和程序指定方法区的初始大小，最小和最大限制；
方法区同样存在垃圾收集，因为通过用户定义的类加载器可以动态扩展Java程序，这样可能会导致一些类，不再被使用，变为垃圾。这时候需要进行垃圾清理。

3.6 运行时常量池

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

运行时常量池与Class文件常量池区别

JVM对Class文件中每一部分的格式都有严格的要求，每一个字节用于存储那种数据都必须符合规范上的要求才会被虚拟机认可、装载和执行；但运行时常量池没有这些限制，除了保存Class文件中描述的符号引用，还会把翻译出来的直接引用也存储在运行时常量区
相较于Class文件常量池，运行时常量池更具动态性，在运行期间也可以将新的变量放入常量池中，而不是一定要在编译时确定的常量才能放入。最主要的运用便是String类的intern()方法
在方法区中，常量池有运行时常量池和Class文件常量池；但其中的内容是否完全不同，暂时还未得知

Class常量池图示：
在这里插入图片描述

3.7 直接内存

直接内存（Direct Memory）就是Java堆外内存

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

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

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

特点：

直接内存的读写操作比普通Buffer快，但它的创建、销毁比普通Buffer慢（猜测原因是DirectBuffer需向OS申请内存涉及到用户态内核态切换，而后者则直接从堆内存划内存即可）。

因此直接内存使用于需要大内存空间且频繁访问的场合，不适用于频繁申请释放内存的场合。

使用堆外内存的原因：

对垃圾回收停顿的改善。由于堆外内存是直接受操作系统管理而不是JVM，所以当我们使用堆外内存时，即可保持较小的堆内内存规模。从而在GC时减少回收停顿对于应用的影响。
提升程序I/O操作的性能。通常在I/O通信过程中，会存在堆内内存到堆外内存的数据拷贝操作，对于需要频繁进行内存间数据拷贝且生命周期较短的暂存数据，都建议存储到堆外内存。

为了方便大家交流学习，我建了一个QQ群，入群可领2020年最新Java基础进阶全套学习资料 + BAT大厂面试题，群号: 1080345378

创作不易，您的点赞和关注是对我最大的支持٩(๑❛ᴗ❛๑)۶
↓↓↓