Java面试题（八）：JVM

1. 内存结构

1. 程序计数器
2. 虚拟机栈
3. 本地方法栈
4. 堆
5. 方法区
   

1.1. 程序计数器

1.1. 作用

程序计数器的作用就是在指令执行的过程中，记住下一条指令的执行地址。

• 二进制字节码前面的数字就可以看作是内存地址
  当getstatic命令被解释器拿到的时候，程序计数器会记录下一条指令的地址，也就是astore_1的地址3，下一次解释器就是从程序计数器里拿到下一条指令的地址3，以此类推。

程序计数器的物理上是由寄存器实现的，寄存器是cpu里读取速度最快的单元。

1.2. 特点

1. 线程私有：每个线程都有自己的程序计数器，因为每个线程执行的代码是不一样的。
2. 不会存在内存溢出

1.2. 虚拟机栈

其实就是线程运行所需要的内存空间，一个线程，对应一个虚拟机栈。

一个栈帧就对应着一个方法的调用，每个方法运行所需要的内存被称为栈帧。方法开始运行的时候，将方法入栈，运行完成后，方法出栈。

我们来看三个问题

1. 垃圾回收是否涉及栈内存？
   答：不涉及，栈的每一个方法运行完成后会自动被弹出，不需要垃圾回收。
2. 栈内存分配越大越好吗？
   答：不一定，栈内存越大，会导致线程数变少，比如运行内存500M，每个栈1M，能有500个线程，而当每个栈5M的时候，只能有100个线程。
3. 方法内的局部变量是否线程安全？
   答：若这个局部变量的作用范围没有逃离方法的作用范围，就是线程安全的
   反之，就会存在线程安全问题。

1.2.1. 栈内存溢出（StackOverFlowErro）

1. 栈帧过多导致栈内存溢出（比如过多递归调用，方法一直入栈，没有出栈，就会导致栈内存溢出）。
2. 栈帧过大导致栈内存溢出。

栈内存可以通过 -Xss 值 的方式修改

1.3. 本地方法栈

本地方法栈是用来调用本地方法的。
本地方法：指不是用Java代码写的方法。

• 我们来看一看一些不是用Java代码实现的方法
  

1.4. 堆（Heap）

1. 通过new关键字创建对象都会使用堆内存。
2. 它是线程共享的，堆中的对象，需要考虑线程安全问题。
3. 有垃圾回收机制。

1.4.1. 堆内存溢出（OutOfMermoryErro）

当堆里的内存满了，但那些对象又不能被当成垃圾回收的时候，会出现这个错误。
设置堆内存大小的参数：-Xmx

1.4.2. 堆内存诊断

当堆内存很大的时候，短时间运行不会暴露堆内存溢出问题，所以在运行程序的时候，可以将堆内存设置小一点，这样会尽早暴露堆内存溢出的问题。

1.5. 方法区

• 在JVM启动的时候创建
• 在逻辑上是堆内存的一部分，但是并不强制方法区的位置。

1.5.1. 概念

存储类相关的东西，比如类的成员变量，类的方法，类加载器，还有一个运行时常量池。

1.5.2. 方法区内存溢出（OutOfMermoryErro）

以下代码会造成方法区溢出
设置元空间（方法区）大小：-XX

java的类加载器ClassLoader实际上也是由java语言编写而成,那么我们编译类既然要使用类加载器,那什么东西可以编译类加载器的类呢?有点类似与先有蛋还是先有鸡的问题,实际上jvm给我们提供了一个最基础的类加载器,就是BootStrap(判断一个类是不是它加载只要看返回是不是空如String。
Class。getClassLoader()==null就说明是它加载的)
除了BootStrap不是以外，其他所有的类加载器都继承于ClassLoader这个类

什么是类加载

1.5.3. 运行时常量池

常量池：是一张表，虚拟机指令根据这张表找到要执行的类名，方法名，参数类型，字面量等信息
运行时常量池：常量池是*.class文件中的，当该类被加载，它的常量池信息就会放入到运行时常量池，并且把里面的符号地址变成真实地址。
介绍一篇相关文章：常量池

1.5.4. 面试题

new 的对象都是在堆中的。

2. 类加载机制和类加载器

2.1. 类加载流程

2.1.1. 加载

2.1.2. 链接

2.1.3. 初始化

2.1.4. 卸载

条件：

1. JVM停止运行
2. 加载这个类的加载器被卸载

类卸载的条件比较苛刻，所以我们可以理解为类只加载一次，可以多次使用。

2.2. 类的加载机制（双亲委派机制模型）

2.2.1. 为什么要用这种加载机制？

保证每一个类的加载都是用启动类加载器的，提高了程序的安全性。
例如，当我定义了一个java.lang.Object自定义的类的时候，若没有这种机制，那么所有的Object类都会用应用类加载器进行加载，会破坏程序。
所以当自定义类和系统类重名的时候，按照这个机制会自动加载系统的类，而不是自定义的类。
注意：类的加载是用的类的全限定名

2.2.2. 双亲委派模型的优缺点

3. 垃圾回收机制（GC）

3.1. 对象回收的标志–可达性分析

此算法的核心思想：通过一系列称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称为“引用链”，当一个对象到 GC Roots 没有任何的引用链相连时(从 GC Roots 到这个对象不可达)时，证明此对象不可用。

3.2. 垃圾回收算法

当JVM通过可达性分析发现垃圾的时候，会使用垃圾回收算法对垃圾进行回收

3.2.1. 标记清除法

优点：回收效率较高
缺点：容易造成空间浪费

3.2.2. 复制算法

优点：空间利用率较高
缺点：二倍内存开销，回收效率略低

3.2.3. 标记压缩法

优点：既保证了内存连续，也不会有二倍的内存开销
缺点：回收效率很低

3.3. 堆的分代管理以及分代垃圾回收算法

3.3.1. 堆的分代管理

3.3.2. 分代垃圾回收算法

当free越来越小的时候，total会扩大，当total扩大到MAX的时候，若内存还不足，那么会报出错误OutOfMermoryErro

当From和To交换一次，其中的对象年龄代会+1，当对象的年龄代等于15的时候，就会将这个对象移动到老年代，而老年代不会收MinorGC的影响。
当老年代堆满的时候会调用FULL GC，会对所有的堆内存的对象都进行一次垃圾回收，这个时候的程序相当于触发半暂停状态，效率很低。
而System.gc()是提示启动FULL GC，这样程序的运行会变得很慢。
MinorGC：主要是标记清除和复制算法
FULLGC：主要是标记压缩法

4. 垃圾收集器

4.1. Serial 收集器

是一个单线程收集器，。它的 “单线程” 的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集工作的时候必须暂停其他所有的工作线程（ “StopThe World” ），直到它收集结束，在以后的垃圾回收器的设计中，会无限的缩短这个暂停的时间。新生代采用复制算法，老年代采用标记压缩算法。
优点：简单高效
缺点：停顿时间较长，会对用户造成不好的体验

4.2. Serial Old 收集器

Serial 收集器的老年代版本，它同样是一个单线程收集器。它主要有两大用途：一种用途是在JDK1.5 以及以前的版本中与 Parallel Scavenge 收集器搭配使用，另一种用途是作为 CMS 收集器的后备方案。

4.3. Parallel Scavenge 收集器

Parallel Scavenge 收集器也是使用复制算法的多线程收集器，。CMS 等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。所谓吞吐量就是 CPU 中用于运行用户代码的时间与 CPU 总消耗时间的比值。 Parallel Scavenge 收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量，如果对于收集器运作不太了解，手工优化存在困难的时候，使用Parallel Scavenge 收集器配合自适应调节策略，把内存管理优化交给虚拟机去完成也是一个不错的选择。新生代采用复制算法，老年代采用标记压缩算法。
JDK1.8 默认使用的是 Parallel Scavenge + Parallel Old

4.4. Parallel Old 收集器

Parallel Scavenge 收集器的老年代版本。使用多线程和“标记-压缩”算法。在注重吞吐量以及CPU 资源的场合，都可以优先考虑 Parallel Scavenge 收集器和 Parallel Old 收集器。

4.5. ParNew 收集器

ParNew 收集器其实就是 Serial 收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为（控制参数、收集算法、回收策略等等）和 Serial 收集器完全一样。新生代采用复制算法，老年代采用标记压缩算法。

4.6. CMS 收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验的应用上使用。

• CMS 收集器是一种 “标记-清除”算法实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤：

1. 初始标记： 暂停所有的其他线程，并记录下直接与 root 相连的对象，速度很快 ；
2. 并发标记： 同时开启 GC 和用户线程，用一个闭包结构去记录可达对象。
3. 重新标记： 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短
4. 并发清除： 开启用户线程，同时 GC 线程开始对未标记的区域做清扫。

缺点：

1. 对CPU资源敏感
   由于GC线程是CPU密集型线程，且它与用户线程在“并发标记”与“并发清除”阶段是并发执行的，所以GC线程会与用户线程竞争CPU资源，使得部分用户线程得不到执行，导致应用程序的总吞吐量降低。机器的CPU核数越少，该问题越明显。
   CMS默认启动回收线程数为(CPU+3)/4。对于一个4核CPU来说，并发过程中GC线程会占用不超过25%的CPU资源，对于2核CPU则为不超过50%，即核数越多影响越小。

2. 浮动垃圾
   由于“清除阶段”与用户线程是并发执行的，所以该过程产生的新的垃圾对象（浮动垃圾）是无法在当前这次GC中进行清理的，只能等到下一次GC。如果该过程中产生的新的垃圾对象太多了，则会使当前这次CMS GC抛出“Concurrent Mode Failure”失败，进而导致另外一次完全STW的Full GC（Serial Old）的产生，此时将严重影响用户程序性能。
   考虑到浮动垃圾的产生，CMS必须在GC时预留足够空间，而不能等到内存空间被完全填满时才进行GC。可以通过自定义-XX:CMSInitiatingOccu-pancyFraction（默认92%）的值来调整CMS GC的触发阈值。该值设置得过低则会因频繁进行CMS GC导致应用程序吞吐量下降，设置得过高则会因“Concurrent Mode Failure”而频繁触发Full GC导致应用程序停顿。

3. 内存碎片
   由于CMS 采用的是“标记-清除”算法，该GC算法不会对内存空间进行整理，所以会产生内存碎片，可能无法正常为大对象分配连续的内存空间，导致不得不提前触发一次Full GC。
   CMS收集器提供-XX:+UseCMS-CompactAtFullCollection开关（默认打开）参数，用于在CMS不得不进行Full GC时开启内存碎片的合并整理过程，因为涉及移动存活对象，该过程需要STW。

4.7. G1 收集器

G1 (Garbage-First) 是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足 GC 停顿时间要求的同时,还具备高吞吐量性能特征.

• 优点：

1. 并行与并发：G1 能充分利用 CPU、多核环境下的硬件优势，使用多个 CPU来缩短 Stop-The-World 停顿时间。
2. 分代收集：虽然 G1 可以不需要其他收集器配合就能独立管理整个 GC 堆，但是还是保留了分代的概念。
3. 空间整合：G1 从整体来看是基于“标记压缩”算法实现的收集器；从局部上来看是基于“复制”算法实现的。
4. 可预测的停顿：这是 G1 相对于 CMS 的另一个大优势，降低停顿时间是 G1 和CMS 共同的关注点，但 G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为 M 毫秒的时间片段内。

• 缺点：

1. 相较于CMS,G1还不具备全方位、压倒性优势。比如在用户程序运行过程中,G1无论是为了垃圾收集产生的内存占用(Footprint)还是程序运行时的额外执行负载(Overload)都要比CMS要高。
2. 在小内存应用上CMS的表现大概率会优于G1,而G1在大内存应用上则发挥其优势。平衡点在6-8GB之间

G1 收集器的运作大致分为以下几个步骤：
• 初始标记
• 并发标记
• 最终标记
• 筛选回收

G1 收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的Region(这也就是它的名字 Garbage-First 的由来)。这种使用 Region 划分内存空间以及有优先级的区域回收方式，保证了 G1 收集器在有限时间内可以尽可能高的收集效率（把内存化整为零）。