JVM内存结构

问题：JVM运行期内存空间、每块的作用？

Java 虚拟机在执⾏ Java 程序的过程中会把它管理的内存划分成若⼲个不同的数据区域。在JDK1.8之前，java运行时数据区域分为程序计数器、虚拟机栈、本地方法栈、堆和方法区5个部分。在JDK1.8之后，去掉了之前的方法区，而增加了元空间。
线程私有的：程序计数器、虚拟机栈、本地⽅法栈。
线程共享的：堆、⽅法区、直接内存 (⾮运⾏时数据区的⼀部分)。

下面分别介绍一下各部分：

1.程序计数器

程序计数器是⼀块较⼩的内存空间，可以看作是当前线程所执⾏的字节码的⾏号指示器。字节码解释器⼯作时通过改变这个计数器的值来选取下⼀条需要执⾏的字节码指令，分⽀、循环、跳转、异常处理、线程恢复等功能都需要依赖这个计数器来完成。另外，为了线程切换后能恢复到正确的执⾏位置，每条线程都需要有⼀个独⽴的程序计数器，各线程之间计数器互不影响，独⽴存储，我们称这类内存区域为“线程私有”的内存。

从上⾯的介绍中我们知道程序计数器主要有两个作⽤：
（1）字节码解释器通过改变程序计数器来依次读取指令，从⽽实现代码的流程控制，如：顺序执⾏、选择、循环、异常处理。（读取指令、流程控制）
（2）在多线程的情况下，程序计数器⽤于记录当前线程执⾏的位置，从⽽当线程被切换回来的时候能够知道该线程上次运⾏到哪⼉了。（记录位置、线程切换）
注意：程序计数器是唯⼀⼀个不会出现 OutOfMemoryError 的内存区域，它的⽣命周期随着线程的创建⽽创建，随着线程的结束⽽死亡。

2.Java虚拟机栈

首先，与程序计数器⼀样，Java 虚拟机栈也是线程私有的，它的⽣命周期和线程相同，描述的是 Java⽅法执⾏的内存模型，每次⽅法调⽤的数据都是通过栈传递的。
Java 内存可以粗糙的区分为堆内存（Heap）和栈内存 (Stack)，其中栈就是现在说的虚拟机栈，或者说是虚拟机栈中局部变量表部分。（实际上，Java 虚拟机栈是由⼀个个栈帧组成，⽽每个栈帧中都拥有：局部变量表、操作数栈、动态链接、⽅法出⼝信息。）
局部变量表主要存放了编译期可知的各种数据类型（boolean、byte、char、short、int、float、long、double）、对象引⽤（reference 类型，它不同于对象本身，可能是⼀个指向对象起始地址的引⽤指针，也可能是指向⼀个代表对象的句柄或其他与此对象相关的位置）。
注意，Java栈会出现两种错误：StackOverFlowError 和OutOfMemoryError 。

• StackOverFlowError ：若 Java 虚拟机栈的内存⼤⼩不允许动态扩展，那么当线程请求栈的深度超过当前 Java 虚拟机栈的最⼤深度的时候，就抛出该错误。
• OutOfMemoryError ：若 Java 虚拟机堆中没有空闲内存，并且垃圾回收器也⽆法提供更多内存的话，就会抛出该错误。

同时，Java 虚拟机栈也是线程私有的，每个线程都有各⾃的 Java 虚拟机栈，⽽且随着线程的创建⽽创建，随着线程的死亡⽽死亡。

扩展：那么⽅法/函数如何调⽤？
Java 栈可⽤类⽐数据结构中栈，Java 栈中保存的主要内容是栈帧，每⼀次函数调⽤都会有⼀个对应的栈帧被压⼊ Java 栈，每⼀个函数调⽤结束后，都会有⼀个栈帧被弹出。

Java ⽅法有两种返回⽅式：
（1）return 语句。
（2）抛出异常。
不管哪种返回⽅式都会导致栈帧被弹出。

3.本地方法栈

和虚拟机栈所发挥的作⽤⾮常相似，区别是： 虚拟机栈为虚拟机执⾏ Java ⽅法 （也就是字节码）服务，⽽本地⽅法栈则为虚拟机使⽤到的 Native ⽅法服务。 在 HotSpot 虚拟机中和 Java虚拟机栈合⼆为⼀。
本地⽅法被执⾏的时候，在本地⽅法栈也会创建⼀个栈帧，⽤于存放该本地⽅法的局部变量表、操作数栈、动态链接、出⼝信息。⽅法执⾏完毕后相应的栈帧也会出栈并释放内存空间，也会出现 StackOverFlowError 和OutOfMemoryError 两种错误。

4.堆

首先，Java 堆是虚拟机所管理的内存中最⼤的⼀块，Java 堆是所有线程共享的⼀块内存区域，在虚拟机启动时创建。此内存区域的唯⼀⽬的就是存放对象实例，⼏乎所有的对象实例以及数组都在这⾥分配内存。Java世界中“⼏乎”所有的对象都在堆中分配，但是，随着JIT编译期的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致⼀些微妙的变化，所有的对象都分配到堆上也渐渐变得不那么“绝对”了。从jdk 1.7开始已经默认开启逃逸分析，如果某些⽅法中的对象引⽤没有被返回或者未被外⾯使⽤（也就是未逃逸出去），那么对象可以直接在栈上分配内存。

另外，Java 堆是垃圾收集器管理的主要区域，因此也被称作GC 堆（Garbage Collected Heap）。从垃圾回收的⻆度，由于现在收集器基本都采⽤分代垃圾收集算法，所以 Java 堆还可以细分为：新⽣代和⽼年代，再细致⼀点有：新生代又被分为Eden 空间、From Survivor、To Survivor 空间。进⼀步划分的⽬的是更好地回收内存，或者更快地分配内存。⼤部分情况，对象都会⾸先在 Eden 区域分配，在⼀次新⽣代垃圾回收后，如果对象还存活，则会进⼊ s0 或者 s1，并且对象的年龄还会加 1(Eden 区->Survivor 区后对象的初始年龄变为 1)，当它的年龄增加到⼀定程度（默认为 15 岁），就会被晋升到⽼年代中。对象晋升到⽼年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 来设置。

还有，在 JDK 7 版本及JDK 7 版本之前，堆内存被通常被分为新⽣代(Young Generation)、⽼年代(Old Generation)和永久代(Permanent Generation)；而在JDK 8 版本之后⽅法区（HotSpot 的永久代）被彻底移除了（JDK1.7 就已经开始了），取⽽代之是元空间，元空间使⽤的是直接内存。

注意的是，堆这⾥最容易出现的就是 OutOfMemoryError 错误，并且出现这种错误之后的表现形式还会有⼏种，⽐如：
（1）OutOfMemoryError: GC Overhead Limit Exceeded ： 当JVM花太多时间执⾏垃圾回收并且只能回收很少的堆空间时，就会发⽣此错误。
（2） java.lang.OutOfMemoryError: Java heap space ：假如在创建新的对象时, 堆内存中的空间不⾜以存放新创建的对象, 就会引发该错误。(和本机物
理内存⽆关，和你配置的内存⼤⼩有关！)
（3） …

5.方法区

⽅法区与 Java 堆⼀样，是各个线程共享的内存区域，它⽤于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。⽅法区也被称为永久代。很多⼈都会分不清⽅法区和永久代的关系，为此我也查阅了⽂献。

《Java 虚拟机规范》只是规定了有⽅法区这么个概念和它的作⽤，并没有规定如何去实现它。那么，在不同的 JVM 上⽅法区的实现肯定是不同的了。 ⽅法区和永久代的关系很像Java 中接⼝和类的关系，类实现了接⼝，⽽永久代就是 HotSpot 虚拟机对虚拟机规范中⽅法区的⼀种实现⽅式。 也就是说，永久代是 HotSpot 的概念，⽅法区是 Java 虚拟机规范中的定义，是⼀种规范，⽽永久代是⼀种实现，⼀个是标准⼀个是实现，其他的虚拟机实现并没有永久代这⼀说法。

JDK8，为什么要将永久代 (PermGen) 替换为元空间 (MetaSpace) 呢?

• （1）整个永久代有⼀个 JVM 本身设置固定⼤⼩上限，⽆法进⾏调整，⽽元空间使⽤的是直接内存，受本机可⽤内存的限制，虽然元空间仍旧可能溢出，但是⽐原来出现的⼏率会更⼩。
  当你元空间溢出时会得到如下错误： java.lang.OutOfMemoryError:MetaSpace

-XX:PermSize=N //⽅法区 (永久代) 初始⼤⼩
-XX:MaxPermSize=N //⽅法区 (永久代) 最⼤⼤⼩,超过这个值将会抛出 OutOfMemoryError 异常
java.lang.OutOfMemoryError: PermGen
-XX:MetaspaceSize=N //设置 Metaspace 的初始（和最⼩⼤⼩）
-XX:MaxMetaspaceSize=N //设置 Metaspace 的最⼤⼤⼩
你可以使⽤ -XX MaxMetaspaceSize 标志设置最⼤元空间⼤⼩，默认值为 unlimited，这意味着它只受系统内存的限制。 -XX MetaspaceSize 调整标志定义元空间的初始⼤⼩如果未指定此标志，则 Metaspace 将根据运⾏时的应⽤程序需求动态地重新调整⼤⼩。

• （2）元空间⾥⾯存放的是类的元数据，这样加载多少类的元数据就不由 MaxPermSize 控制了，⽽由系统的实际可⽤空间来控制，这样能加载的类就更多了。
• （3）在 JDK8，合并 HotSpot 和 JRockit 的代码时, JRockit 从来没有⼀个叫永久代的东⻄, 合并之后就没有必要额外的设置这么⼀个永久代的地⽅了。

问题：说一下你知道的Java虚拟机？

（1）HotSpot VM
HotSpot VM是目前主流的虚拟机。像Oracle / Sun JDK、OpenJDK的各种变种（例如IcedTea、Zulu），用的都是相同核心的HotSpot VM。从Java SE 7开始，HotSpot VM就是Java规范的“参考实现”，JDK8的HotSpot VM已经是以前的HotSpot VM与JRockit VM的合并版，也就是传说中的“HotRockit”，只是产品里名字还是叫HotSpot VM。这个合并并不是要把JRockit的部分代码插进HotSpot里，而是把前者一些有价值的功能在后者里重新实现一遍。移除PermGen、Java Flight Recorder、jcmd等都属于合并项目的一部分。
（2）J9 VM
J9是IBM开发的一个高度模块化的JVM。J9 VM的性能水平大致跟HotSpot VM是一个档次的。
（3）JRockit
以前Java SE的主流JVM中还有JRockit，跟HotSpot与J9一起并称三大主流JVM。这三家的性能水平基本都在一个水平上，竞争很激烈。自从Oracle把BEA和Sun都收购了之后，Java SE JVM只能二选一，JRockit就炮灰了。JRockit最后发布的大版本是R28，只到JDK6，原本在开发中的R29及JDK7的对应功能都没来得及完成项目就被终止了。