JVM相关

不知道取舍的人不知道自己想要什么

---

JVM是个啥？
JVM是Java虚拟机的英文缩写，它是整个java实现跨平台的最核心的部分，所有的java程序会首先被编译为.class的类文件，这种类文件可以在虚拟机上执行，也就是说class并不直接与机器的操作系统相对应，而是经过虚拟机间接与操作系统交互，由虚拟机将程序解释给本地系统执行。JVM是Java平台的基础，和实际的机器一样，它也有自己的指令集，并且在运行时操作不同的内存区域。 JVM通过抽象操作系统和CPU结构，提供了一种与平台无关的代码执行方法，即与特殊的实现方法、主机硬件、主机操作系统无关。JVM的主要工作是解释自己的指令集（即字节码）到CPU的指令集或对应的系统调用。 JVM对上层的Java源文件是不关心的，它关注的只是由源文件生成的类文件（.class文件）

JVM的体系结构？
1、类装载器（ClassLoader）（用来装载.class文件）
2、执行引擎（执行字节码，或者执行本地方法）
3、运行时数据区（方法区、堆、java栈、PC寄存器、本地方法栈）（JDK1.8好像没方法区了）

---

JVM高能点分4大块
1、类的加载机制
2、JVM的内存结构
3、GC(包括GC算法，垃圾回收器)
4、JVM调优化

JVM的内存结构 运行时数据区👇

绿色线程隔离，白色非隔离👆

程序计数器啥意思？
内存空间小，线程私有。字节码解释器工作是就是通过改变这个计数器的值来选取下一条需要执行指令的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖计数器完成

Java 虚拟机栈？
线程私有，生命周期和线程一致。描述的是 Java 方法执行的内存模型：每个方法在执行时都会床创建一个栈帧(Stack Frame)用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行结束，就对应着一个栈帧从虚拟机栈中入栈到出栈的过程，栈的大小是有限的

本地方法栈？
区别于 Java 虚拟机栈的是，Java 虚拟机栈为虚拟机执行 Java 方法(也就是字节码)服务，而本地方法栈则为虚拟机使用到的 Native 方法服务(非java的本地C/C++ 库)也会有 StackOverflowError 和 OutOfMemoryError 异常。

Java 堆？
对于绝大多数应用来说，这块区域是 JVM 所管理的内存中最大的一块。线程共享，主要是存放对象实例和数组。内部会划分出多个线程私有的分配缓冲区(Thread Local Allocation Buffer, TLAB)。可以位于物理上不连续的空间，但是逻辑上要连续。

方法区？
属于共享内存区域，存储已被虚拟机加载的类信息、常量、静态变量、JIT即时编译器编译后的代码等数据，JDK7版本的改动是把字符串常量池移到了堆中，在JDK1.8已经被去掉了方法区

运行时常量池也属于方法区一部分，用于存放编译期生成的各种字面量和符号引用，具体放在哪里，不同的JVM实现可以放在不同的地方。编译器和运行期(String 的 intern() )都可以将常量放入池中。内存有限，无法申请时抛出 OutOfMemoryError

---

什么是永久代？永久代和方法区什么关系？
永久代是Hotspot虚拟机特有的概念(别的JVM都没有这个东西)，是方法区的一种实现，方法区只是JVM规范中定义的一个概念,永久代指物理上的堆内存的一块空间，不严谨的说，永久代方法区他俩是一个东西

方法区是一个概念，永久代是hotspot虚拟机特有的实现方式

JDK1.8方法区的变动？
JDK1.8开始方法区（HotSpot的永久代）被彻底删除了取而代之的是元空间，元空间直接使用的是内存。参数设置：
-XX:MetaspaceSize=N //设置Metaspace的初始（和最小大小）
-XX:MaxMetaspaceSize=N //设置Metaspace的最大大小

永久代和元空间内存使用上的差异？
永久代有一个JVM本身设置固定大小上线，无法进行调整，而元空间使用的是直接内存，受本机可用内存的限制。

而从jdk7中开始永久代经过对方法区的分裂后已经几乎只存储类和类加载器的元数据信息了，到了jdk8，元空间中也是存储这些信息，而符号引用、字符串常量等存储位置与jdk7一致，还是“分裂”的方法区，JDK7常量放到堆中

为什么jdk1.8要把方法区从JVM里（永久代）移到直接内存（元空间）
原因一：因为直接内存，JVM将会在IO操作上具有更高的性能，因为它直接作用于本地系统的IO操作。而非直接内存，也就是堆内存中的数据，如果要作IO操作，会先复制到直接内存，再利用本地IO处理。
原因二：整个永久代有一个 JVM 本身设置固定大小上线，无法进行调整，而元空间使用的是直接内存，受本机可用内存的限制，元空间的出现就是为了解决突出的类和类加载器元数据过多导致的OOM问题，元空间永远不会得到java.lang.OutOfMemoryError。
可以使用 -XX：MaxMetaspaceSize 标志设置最大元空间大小，默认值为 unlimited，这意味着它只受系统内存的限制。

---

类加载机制👇

类加载器是如何找到指定的Class文件以及怎样将Class文件装载进内存？以便执行引擎执行Class文件中存在的数据和指令，从而使你的Java程序跑起来

Java有个特性就是依赖运行期动态加载和动态连接，这样实现了Java可以动态进行扩展。我们甚至可以从网络、数据库、从其他文件生成的（JSP应用）或者其他的地方加载一个二进制流作为程序的一部分。所以，我们通过编译器将我们写的Java文件代码编译成Class文件，程序跑起来的时候通过加载器。

---

JVM字节码文件加载过程

类的加载指的是将类的.class文件中的二进制数据读入到内存中，将其放在运行时数据区的方法区内，然后在堆区创建一个 java.lang.Class对象，用来封装类在方法区内的数据结构

类加载机制的层级

双亲委派模型
特点↓
当一个类的加载器收到了加载请求，不会自己先动手，而是委派给这个类的父类进行加载，如果找不到加载不了就反馈回来自己加载。这样的话，让Java的类一出生就有了很好的层次父子关系。当然也有一些手段去破坏这种关系而获得某种效果。

不过双亲委派模型可以被破坏，推荐重写findClass()方法，而不是loadClass(),重写loadClass()在热部署技术中有应用

破坏双亲委派模型？
打破双亲委派机制则不仅要继承ClassLoader类，还要重写loadClass和findClass方法
默认的loadClass方法是实现了双亲委派机制的逻辑，即会先让父类加载器加载，当无法加载时才由自己加载。这里为了破坏双亲委派机制必须重写loadClass方法，即这里先尝试交由System类加载器加载，加载失败才会由自己加载。它并没有优先交给父类加载器，这就打破了双亲委派机制。
破环双亲委派有时候是为了实现实现隔离性和热替换就像tomcat

双亲委派模型的好处？

虚拟机只有在两个类的类名相同且加载该类的加载器均相同的情况下才判定这是一个类。若不采用双亲委派机制，同一个类有可能被多个类加载器加载，这样该类会被识别为两个不同的类，相互赋值时会有问题。

双亲委派机制能保证多加载器加载某个类时，最终都是由一个加载器加载，确保最终加载结果相同。

一个可以避免类的重复加载，另外也避免了java的核心API被篡改。

Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存在在rt.jar中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的Bootstrap ClassLoader进行加载，因此Object类在程序的各种类加载器环境中都是同一个类

Java类加载器
Java自带有三个类加载器
Bootstrap ClassLoader ：最顶层的加载类，主要加载核心类库，也就是我们环境变量下面%JRE_HOME%\lib下的相应jar或class
Extention ClassLoader ：扩展的类加载器，加载目录%JRE_HOME%\lib\ext目录下的jar包和class文件。还可以加载-D java.ext.dirs选项指定的目录。
Appclass Loader：也称为SystemAppClass。 加载当前应用的classpath的所有类。

为何要自定义类加载器？
JVM提供的类加载器，只能加载指定目录的jar和class，如果我们想加载其他位置的类或jar时，例如加载网络上的一个class文件，默认的ClassLoader就不能满足我们的需求了，所以需要定义自己的类加载器。
自定义类加载器的作用如下
1、自定义类的加载方式
2、可以破坏双亲委派模型（实现隔离性和热替换）

怎么实现自定义类加载器?
继承ClassLoader 重写findClass()，从哪里获取class可以自定义实现

Java类什么时候会被卸载？

总结来说，当满足以下条件是，类可以被卸载

1. 该类所有的实例已经被回收
2. 加载该类的ClassLoder已经被回收
3. 该类对应的java.lang.Class对象没有任何对方被引用

注：
1.由java虚拟机自带的三种类加载加载的类在虚拟机的整个生命周期中是不会被卸载的，由用户自定义的类加载器所加载的类才可以被卸载
2.通过虚拟机参数，可以打印日志，类的加载与卸载过程-verbose:class 跟踪类的加载和卸载-XX:+TraceClassLoading 跟踪类的加载-XX:+TraceClassUnloading 跟踪类的卸载
3…通过System.gc()来促进回收

---

GC垃圾回收

1、确定哪些对象需要回收
2、什么时候进行回收，回收哪些区域
3、怎么进行回收

GC之确定哪些对象需要回收？
有两种方式：引用计数算法 根搜索算法

引用计数法：
对象需要添加一个引用计数器，有地方引用它时，引用计数加1，如果引用失效，引用减1，如果计数为0，代表可以清除了。
存在的问题：循环引用

根搜索算法
这个算法的基本思路是通过一系列的名为 GC Roots 的对象作为起点，从这些对象开始往下搜索，搜索所走过的路径称为引用链，当一个对象到 GC Roots 没有任何引用链相连时，证明此对象是不可用的。
这时候有一个问题，那些对象可以作为 GC Roots ？

虚拟机栈（栈帧中的本地变量表）中引用的对象
方法区中的类静态属性引用的对象
方法区中的常量引用的对象
本地方法栈中JNI（即一般说的 Native 方法）中引用的对象

GC之什么时候进行回收，回收哪些区域？
GC 经常发生的区域是堆区，堆区还可以细分为新生代、老年代，新生代还分为一个 Eden 区和两个 Survivor 区（eden和survivor 是 8:1:1），
默认的，新生代 ( Young ) 与老年代 ( Old ) 的比例的值为 1:2 ( 该值可以通过参数 –XX:NewRatio 来指定 )。

对象优先在 Eden 中分配，当 Eden 中没有足够空间时，虚拟机将发生一次 Minor GC，因为 Java 大多数对象都是朝生夕灭，所以 Minor GC 非常频繁，而且速度也很快；

Full GC，发生在老年代的 GC，当老年代没有足够的空间时即发生 Full GC，发生 Full GC 一般都会有一次 Minor GC。

大对象直接进入老年代，如很长的字符串数组，虚拟机提供一个；XX:PretenureSizeThreadhold 参数，令大于这个参数值的对象直接在老年代中分配，避免在 Eden 区和两个 Survivor 区发生大量的内存拷贝；

发生 Minor GC 时，虚拟机会检测之前每次晋升到老年代的平均大小是否大于老年代的剩余空间大小，

如果大于，则进行一次 Full GC，

如果小于，则查看 HandlePromotionFailure 设置是否允许担保失败，如果允许，那只会进行一次 Minor GC，如果不允许，则改为进行一次 Full GC。

GC之怎么进行回收

IBM研究表明，新生代 98% 的对象都是朝生夕死的，所以并不需要 1:1 来划分内存空间，而是将内存分为一块较大的 Eden 空间和两块较小的 Survivor 空间，每次使用 Eden 和其中一块 Survivor 。当回收时，将 Eden 和 Survivor 中还存活的对象一次性拷贝到另一块 Survivor 空间上，最后清理掉 Eden 和刚才使用过的 Survivor 空间。 HotSpot 虚拟机默认 Eden 和 Survivor 大小比例为 : 8:1。当 Survivor 空间不够用时，需要依赖其他内存（老年代）进行分配担保（Handle Promotion）。

标记清除（Mark-Sweep）

优点：
简单
其他都是基于这个算法进行的改性。

缺点：
效率问题，标记的和清除的效率都不高

空间问题，标记清除会产生大量的内存碎片，内存碎片可能存在的问题是：当有大对象需要分配时，找不到足够大的连续内存而不得不提前触发另一次垃圾收集动作。

---

复制算法（Copying）
它将内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块内存用完了，就将还存活的对象复制到另一块上面，然后再把已使用过的空间一次清理掉。

优点：
简单高效

缺点：
可用内存缩小为原来的一半
当对象存活率较高率，效率较低
需要担保空间

---

分代收集（Generational Collection）
针对对象的存活周期将内存划分为几块，一般为 新生代 和 老年代，根据不同快对象的存活特点，选择合适的收集算法。新生代的算法存活率比较低，可以选择 Copying，老年代 的对象存活率高，并且没有担保空间，可以选择 Mark-Compact算法。

垃圾收集器都有哪些？

图中如果两个垃圾收集器之间存在连线，表明它们可以搭配使用。👆

Serial 收集器
是JDK 1.3.1 之前虚拟机新生代收集的唯一选择。单线程收集，它在收集时，会STW（Stop The World暂停其他所有工作工作线程）

缺点：
多核时效率低
用户体验不好

优点：
对于单核，省去了线程上下文切换的开销

---

ParNew 收集器
ParNew 收集器 是 Serial 收集器的多线程版本，其余行为完全一样（包括：控制参数、收集算法、Stop The World、对象分配规则、回收策略等）。

ParNew 收集器 是并行收集器，ParNew 收集器 也是使用 -XX:+UseConcMarkSweepGC 选项后的默认新生代收集器，也可以使用 -XX+UseParNewGC 选项强制指定它。
默认 ParNew 收集器 开启的收集线程与 CPU 的数量相同，也可以通过 -XX:ParallelGCThreads 指定

Parallel Scavenge 收集器
Parallel Scavenge 收集器 也是一个新生代收集器，使用复制算法，也是并行多线程收集。不过它的一个显著的特点是：其他垃圾收集器关注的是尽量缩短用户线程的停顿时间，而它关注的是吞吐量。所谓吞吐量就是CPU用于执行用户线程所用时间与CPU总消耗时间的比值（吞吐量=运行用户代码时间 / （运行用户代码时间+垃圾收集时间））。

Parallel Scavenge 收集器 提供了两个参数用于精确控制吞吐量，分别是：-XX:MaxGCPauseMillis 和 -XX:GCTimeRatio 。
除了上面的两个参数外，有另外一个参数比较重要 ：-XX"+UseAdptiveSizePolicy ，当这个参数打开以后，就不需要手动指定新生代的大小（-Xmn） 、Eden 和 Survivoer 的比例（-XX:SurvivorRatio）以及晋升老年代的对象年龄（-XX:PrertenureSizeThreshold）等细节参数。虚拟机将会根据设定的最大GC停顿时间或者吞吐量，自动调整。

Serial Old 收集器
Serial Old 收集器 是 Serial 收集器的老年代版本，同样是单线程的，使用标记整理算法。主要适用于 Client 模式下的虚拟机，在 Server 模式下，主要有两个用途：1. 在 JDK 1.5 以及之前的版本中，与 Parallel Scavenge 收集器 搭配使用。2. 作为 CMS 收集器的后备预案，在并发收集发生 Concurrent Mode Failure 的时候使用。

Paralledl Old 收集器
是 Parallel Scavenge 收集器 的老年代版本。多线程标记整理吞吐量优先收集器

CMS 收集器
CMS 收集器 是一种以获取最大回收停顿时间为目标的收集器。是基于 标记-清除算法实现的，收集过程分为四个阶段：

初始标记（CMS initial mark）
并发标记（CMS concurrent mark）
重新标记（CMS remark）
并发清除（CMS concurrent sweep）

其中初始标记和重新标记阶段仍然需要 Stop The World 。
初始阶段：只是记录一下 GC Roots 直接关联的对象，速度很快。
并发标记：进行 GC Tracing 过程。
重新标记：为了修正并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段停顿时间一般会比初始标记阶段稍微长一点，但远比并发标记时间段。

优点：
并发标记和并发清除，收集器线程可以与用户线程一起进行，尽可能不堵塞用户线程，降低停顿时间

缺点：

1、对CPU资源非常敏感。在并发阶段，它虽然不会导致用户线程停止，但是会因为占用了一部分CPU资源，导致应用程序变慢，总吞吐量降低。
2、无法处理浮动的垃圾（Floating Garbage），可能出现 Concurrent Mode Failure 失败而导致另一次Full GC的产生。由于 CMS 并发清理阶段用户线程还在运行着，伴随着程序的运行自然还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法再本地收集中处理它们，只好留在下一次GC时清理掉。在默认设置下，CMS收集器的老年代使用68%的空间后会触发GC，可以调高-XX:CMSInitiatingOccupancyFraction 参数，降低GC次数。
3、产生大量的空间碎片，这是使用 标记-清理算法固有的缺点。为了解决这个问题，CMS收集器提供了一个 -XX:+UseCMSCompactAtFullCollection 开关参数，在每次Full GC以后进行一次碎片整理。这样停顿时间不得不变长了。接着又出现另外一个参数：-XX:GMSFullGCsBeforeCompaction ，表示执行多少次 Full GC以后执行一次碎片整理，默认0也就是在默认配置下每次CMS GC顶不住了而要转入full GC的时候都会做压缩

full gc的时机

1. 调用 System.gc()
2. 老年代空间不足（老年代空间不足的常见场景比如大对象、大数组直接进入老年代）
3. 空间分配担保失败(判断老年代最大的可用连续空间是否大于新生代的所有对象总空间)
4. 老年代连续空间不足

G1垃圾回收器（JDK9 默认的垃圾回收器）👍
G1是一个面向服务端的JVM垃圾收集器，适用于多核处理器、大内存容量的服务端系统。 它满足短时间停顿的同时达到一个高的吞吐量。从JDK 9开始，G1成为默认的垃圾回收器。
当应用有以下任何一种特性时非常适合用G1：

1、Full GC持续时间太长或者太频繁
2、对象的创建速率和存活率变动很大
3、应用不希望停顿时间长(长于0.5s甚至1s)

G1对Heap的划分

旧的垃圾收集器（串行的：serial，并行的：parallel，并发标记清除：CMS）都把堆结构化为三个部分：年轻代、年老代和固定大小的永久代。👇❌

G1按固定大小把内存划分为很多小区域(region)，这个堆大概有2000多块；在逻辑上，某些小区域构成Eden，某些构成Survivor，某些构成老年代，这些小区域物理上是不相连的，并且构成新生代和老年代的区域可以动态改变。

Young GC
当Eden区的空间占满之后，会触发Young GC，G1将Eden和Survivor中存活的对象拷贝到Survivor，或者直接晋升到Old Region中。Young GC的执行是多线程并发的，期间会停顿所有的用户线程（STW）。

Old GC
当堆空间的占用率达到一定阈值后会触发Old GC（阈值由命令参数-XX:InitiatingHeapOccupancyPercent设定，默认值45），Old GC分五个步骤完成：

与其他GC收集器相比，G1具备如下特点：

1、并行于并发：G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短stop-The-World停顿时间。部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让java程序继续执行。

2、分代收集：虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念。它能够采用不同的方式去处理新创建的对象和已经存活了一段时间，熬过多次GC的旧对象以获取更好的收集效果。

3、空间整合：与CMS的“标记–清理”算法不同，G1从整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的。

4、可预测的停顿：这是G1相对于CMS的另一个大优势，降低停顿时间是G1和ＣＭＳ共同的关注点，但Ｇ１除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内

G1的优点？
G1作为CMS的长期替代品，有若干点优势：
1、G1是一个压缩收集器，提供足够强的压缩来完全避免狭小的内存分配
2、依赖Regions概念，大大简化收集器逻辑，大部分情况下规避潜在的内存碎片问题
3、比CMS的GC停顿时长更加可预测，并允许用户指定停顿时长

G1的坏处？
如果应用的内存非常吃紧，对内存进行部分回收根本不够，始终要进行整个Heap的回收，那么G1要做的工作量就一点也不会比其它垃圾回收器少，而且因为本身算法复杂了一点，可能比其它回收器还要差。因此G1比较适合内存稍大一点的应用(一般来说至少4G以上)，小内存的应用还是用传统的垃圾回收器比如CMS比较合适。

G1如何做到可预测GC暂停时间？
G1的另一个显著特点他能够让用户设置应用的暂停时间，为什么G1能做到这一点呢？也许你已经注意到了，G1回收的第4步，它是“选择一些内存块”，而不是整代内存来回收，这是G1跟其它GC非常不同的一点，其它GC每次回收都会回收整个Generation的内存(Eden, Old), 而回收内存所需的时间就取决于内存的大小，以及实际垃圾的多少，所以垃圾回收时间是不可控的；而G1每次并不会回收整代内存，到底回收多少内存就看用户配置的暂停时间，配置的时间短就少回收点，配置的时间长就多回收点，伸缩自如。

JVM 调优

G1垃圾回收器调优
https://blog.csdn.net/jbiao5201314/article/details/82818408