JVM

所谓虚拟机（Virtual Machine），就是一台虚拟的计算机。它是一款软件，用来执行一系列虚拟计算机指令。大体上，虚拟机可以分为系统虚拟机和程序虚拟机

• 大名鼎鼎的Visual Box，VMware就属于系统虚拟机，它们完全是对物理计算机的仿真，提供了一个可运行完整操作系统的软件平台。
• 程序虚拟机的典型代表就是`Java虚拟机`，它专门为执行单个计算机程序而设计，`在Java虚拟机中执行的指令我们称为Java字节码指令

JAVA 编译器，也可以称为前端编译器

JIT（just in time 及时的）编译器  —— 即时编译器

市面上比较主流的虚拟机基本上都是 解释执行（翻译为字节码） 和 即时编译（JIT 编译期）并存的方式，解释器主要是来保证响应时间的，一开始就逐行的针对字节码指令进行解释执行，JIT编译器可以针对字节码指令，其中有一些代码是反复执行的，我们称之为`热点代码`，热点代码可以使用JIT编译器在编译成机器指令，这出现了二次编译`（第一次编译把源文件编译成字节码文件，第二次编译是把字节码文件中的字节码指令编译成机器指令），同时因为热点指令是反复执行的，还会将其放`在方法区中缓存起来` ，下次可以直接调用，`JIT编译期主要负责程序执行的性能

子主题

一个运行中的Java虚拟机有着一个清晰的任务：`执行Java程序`。

Java虚拟机的启动是通过引导类加载器（bootstrap class loader）创建一个初始类（initial class）(不是Object)来完成的就停止

执行一个所谓的Java程序的时候，真真正正在执行的是一个叫做Java虚拟机的进程

程序正常执行结束

程序在执行过程中遇到了异常或错误而异常终止

由于操作系统用现错误而导致Java虚拟机进程终止

某线程调用Runtime类或system类的exit方法，或`Runtime类的halt`方法，并且Java安全管理器也允许这次exit或halt操作。

除此之外，JNI（Java Native Interface）  native 方法规范描述了用JNI Invocation API来加载或卸载 Java虚拟机时，Java虚拟机的退出情况。

`class file`存在于本地硬盘上，可以理解为设计师画在纸上的模板，而最终这个模板在执行的时候是要加载到JVM当中来根据这个文件实例化出n个一模一样的实例。

class file`加载到JVM中，被称为`DNA元数据模板`，放在`方法区`。

-在`.class文件->JVM->最终成为元数据模板`，此过程就要一个运输工具（类装载器`Class Loader`），`扮演一个快递员的角色。`

• 从`本地系统`中直接加载
• 通过`网络`获取，典型场景：Web Applet
• 从`zip压缩包`中读取，成为日后`jar、war格式的基础`
• 运行时计算生成`，使用最多的是：`动态代理技术`
• 由其他文件生成，典型场景：`JSP应用从专有数据库中提取.class文件`，比较少见
• 从加密文件中获取，典型的防Class文件被反编译的保护措施

JVM采用的是懒加载机制，即只有类在被使用时才加载

确保Class文件的字节流中包含信息符合当前虚拟机要求，保证被加载类的正确性，不会危害虚拟机自身安全。
主要包括四种验证，文件格式验证，元数据验证，字节码验证，符号引用验证

为类变量分配内存并且设置该类变量的默认初始值，即零值。

不包含用final修饰的static，因为final在编译的时候就会分配了，准备阶段会显式初始化

这里不会为实例变量分配初始化，类变量会分配在方法区`中，而实例变量是会随着对象一起分配到Java堆中

将常量池内的符号引用转换为直接引用的过程

符号引用就是一组符号来描述所引用的目标`。符号引用的字面量形式明确定义在《java虚拟机规范》的class文件格式中。`直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄

解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的CONSTANT Class info、CONSTANT Fieldref info、CONSTANT Methodref info等

Java的核心类库都是使用根加载器（引导类加载器）进行加载的。

启动类加载器（引导类加载器，Bootstrap ClassLoader）

扩展类加载器（ Extension ClassLoader ）

应用程序类加载器（系统类加载器，AppClassLoader）

用户自定义类加载器

为什么要自定义类加载器？

用户自定义类加载器实现步骤

• - 获取当前ClassLoader：clazz.getClassLoader()
• - 获取当前线程上下文的ClassLoader：Thread.currentThread().getContextClassLoader()
• - 获取系统的ClassLoader：ClassLoader.getSystemClassLoader()
• - 获取调用者的ClassLoader：DriverManager.getCallerClassLoader()

• 避免类的重复加载
• 保护程序安全，防止核心API被随意篡改 【保护核心API】

Tomcat是个web容器， 那么它要解决什么问题？

Tomcat 如果使用默认的双亲委派类加载机制行不行？

Tomcat自定义加载器详解

在一条活动线程中，一个时间点上，只会有一个活动的栈帧。即只有当前正在执行的方法的栈帧（栈顶栈帧）是有效的，这个栈帧被称为当前栈帧（Current Frame），与当前栈帧相对应的方法就是当前方法（Current Method），定义这个方法的类就是当前类（Current Class）
执行引擎运行的所有字节码指令只针对当前栈帧进行操作

不同线程中所包含的栈帧是不允许存在相互引用的，即不可能在一个栈帧之中引用另外一个线程的栈帧。（因为`栈是线程私有的`）

如果当前方法调用了其他方法，方法返回之际，当前栈帧会传回此方法的执行结果给前一个栈帧，接着，虚拟机会丢弃当前栈帧，使得前一个栈帧重新成为当前栈帧。

Java方法有两种返回函数的方式，一种是正常的函数返回，使用return指令；另外一种是抛出异常（未捕获）。不管使用哪种方式，都会导致栈帧被弹出

局部变量表（Local Variables）

操作数栈（operand Stack）

动态链接（DynamicLinking）【指向运行时常量池的方法引用】

方法返回地址（Return Address）【方法正常退出或者异常退出的定义】

附加信息

有时Java应用需要与Java外面的环境交互，这是本地方法存在的主要原因。你可以想想Java需要与一些底层系统，如操作系统或某些硬件交换信息时的情况。本地方法正是这样一种交流机制:它为我们提供了一个非常简洁的接口，而且我们无需去了解Java应用之外的繁琐的细节

JVM支持着Java语言本身和运行时库，它是Java程序赖以生存的平台，它由一个解释器(解释字节码)和一些连接到本地代码的库组成。然而不管怎样，它毕竟不是一个完整的系统，它经常依赖于一些底层系统的支持。这些底层系统常常是强大的操作系统。`通过使用本地方法，我们得以用Java实现了jre的与底层系统的交互，甚至JVM的一些部分就是用c写的`。还有，如果我们要使用一些Java语言本身没有提供封装的操作系统的特性时，我们也需要使用本地方法

JDK7: 新生代 + 老年代 + 永久代

JDK8： 新生代 + 老年代 + 元空间

-XX：NewRatio=2（默认）

-XX：SurvivorRatio=8 （默认）

实际默认是： 6:1:1

-Xmn

大对象就是需要大量连续内存空间的对象（比如：字符串、数组）。JVM参数 -XX:PretenureSizeThreshold 可以设置大对象的大小，如果对象超过设置大小会直接进入老年代，不会进入年轻代，这个参数只在 Serial 和ParNew两个收集器下有效。

为了避免为大对象分配内存时的复制操作而降低效率

详细流程

CMS收集器默认 -XX:MaxTenuringThresold =  6 

当前放对象的Survivor区域里(其中一块区域，放对象的那块s区)，一批对象的总大小大于这块Survivor区域内存大小的50%(-XX:TargetSurvivorRatio可以指定)，那么此时大于等于这批对象年龄最大值的对象，就可以直接进入老年代了，例如Survivor区域里现在有一批对象，年龄1+年龄2+年龄n的多个年龄对象总和超过了Survivor区域的50%，此时就会把年龄n(含)以上的对象都放入老年代。这个规则其实是希望那些可能是长期存活的对象，尽早进入老年代。对象动态年龄判断机制一般是在minor gc之后触发的。

• 当年轻代空间不足时，就会触发Minor GC，这里的年轻代满指的是Eden代满， Survivor满不会引发GC。(每次Minor GC会清理年轻代的内存。)
• 因为Java对象大多都具备朝生夕灭的特性，所以Minor GC非常频繁，一般回收速度也比较快。这一定义既清晰又易于理解。
• Minor GC会引发STW，暂停其它用户的线程，等垃圾回收结束，用户线程才恢复运行

•  指发生在老年代的GC，对象从老年代消失时，我们说"Major GC”或“Full GC”发生了。
• 出现了Major GC，经常会伴随至少一次的Minor GC（但非绝对的，在`ParallelScavenge收集器`的收集策略里就有直接进行Major GC的策略选择过程)也就是在老年代空间不足时，会先尝试触发Minor GC。如果之后空间还不足，则触发Major GC
• Major GC的速度一般会比Minor GC慢10倍以上， STW的时间更长。
• 如果Major GC后，内存还不足，就报OOM了。

触发Full GC 执行的情况有如下五种：

• 堆区是线程共享区域，任何线程都可以访问到堆区中的共享数据
• 由于对象实例的创建在JVM中非常频繁，因此在并发环境下从堆区中划分内存空间是线程不安全的
• 为避免多个线程操作同一地址，需要使用加锁等机制，进而影响分配速度。

• 从内存模型而不是垃圾收集的角度，对Eden区域继续进行划分， JVM为每个线程分配了一个私有缓存区域，它包含在Eden空间内。
• 多线程同时分配内存时，使用TLAB可以避免一系列的非线程安全问题，同时还能够提升内存分配的吞吐量，因此我们可以将这种内存分配方式称之为快速分配策略
• 据我所知所有OpenJDK衍生出来的JVM都提供了TLAB的设计

-XX: +DOEscapeAnalysis： 显式开启逃逸分析通过选项

-XX: +PrintEscapeAnalysis： 查看逃逸分析的筛I选结果。

栈上分配

同步省略

分离对象或标量替换

无法保证逃逸分析的性能消耗一定能高于他的消耗。虽然经过逃逸分析可以做标量替换、栈上分配、和锁消除。但是逃逸分析自身也是需要进行一系列复杂的分析的，这其实也是一个相对耗时的过程，一个极端的例子，就是经过逃逸分析之后，发现没有一个对象是不逃逸的。那这个逃逸分析的过程就白白浪费掉了。虽然这项技术并不十分成熟，但是它也是即时编译器优化技术中一个十分重要的手段

• 方法区看作是一块独立于Java堆的内存空间
• 方法区的大小，跟堆空间一样，可以选择固定大小或者可扩展。
• 物理内存空间中和Java堆区一样都可以是不连续的。
  方法区(Method Area)与Java堆一样，是各个线程共享的内存区域。
  

永久代（JDK7）

元空间（JDK8）

-XX:MetaspaceSize：设置初始的元空间大小。对于一个64位的服务器端JVM来说，其默认的-XX:MetaspaceSize值为21MB。这就是初始的高水位线，一旦触及这个水位线， Full GC将会被触发并卸载没用的类(即这些类对应的类加载器不再存活) ，然后这个高水位线将会重置。新的高水位线的值取决于GC后释放了多少元空间。如果释放的空间不足，那么在不超过MaxMetaspaceSize时，适当提高该值。如果释放空间过多，则适当降低该值。如果初始化的高水位线设置过低，上述高水位线调整情况会发生很多次。通过垃圾回收器的日志可以观察到Full GC多次调用。元空间大小的上调会引发Full GC，为了避免频繁地GC，建议将-XX:MetaspaceSize设置为一个相对较高的值

类型信息

域（Feild）信息

方法（Method）信息

non-final的类变量

方法区，内部包含了运行时常量池。字节码文件，内部包含了常量池

ClassFile中的常量池

运行时常量池

jdk7中将stringTable放到了堆空间中。因为永久代的回收效率很低，在full gc的时候才会触发。而full gc是老年代的空间不足、永久代不足时才会触发。这就导致StringTable回收效率不高。而我们开发中会有大量的字符串被创建，回收效率低，导致永久代内存不足。放到堆里，能及时回收内存。

静态引用对应的对象实体始终存储在堆空间，我们所谈论的静态变量和常量池在 jdk6/7/8上的变化是针对于符号引用来说

字面量

符号引用

判定一个常量是否“废弃”还是相对简单，而要判定一个类型是否属于“不再被使用的类”的条件就比较苛刻了。需要同时满足下面三个条件

• 该类所有的实例都已经被回收，也就是Java堆中不存在该类及其任何派生子类的实例。
• 加载该类的类加载器已经被回收，这个条件除非是经过精心设计的可替换类加载器的场景，如OSGi、JSP的重加载等，否则通常是很难达成的。
• 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

Java虚拟机被允许对满足上述三个条件的无用类进行回收，这里说的仅仅是“被允许”，而并不是和对象一样，没有引用了就必然会回收。关于是否要对类型进行回收，HotSpot虚拟机提供了`-Xnoclassgc`参数进行控制，还可以使用`-verbose:class`以及`-XX: +TraceClass - Loading`、 `-XX:+TraceClassUnLoading`查看类加载和卸载信息

在大量使用反射、动态代理、CGLib等字节码框架，动态生成JSP以及OSGi这类频繁自定义类加载器的场景中，通常都需要Java虚拟机具备类型卸载的能力，以保证不会对方法区造成过大的内存压力

虚拟机遇到一条new指令，首先去检查这个指令的参数能否在Metaspace的常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已经被加载、解析和初始化。（即判断类元信息是否存在）。如果没有，那么在双亲委派模式下，使用当前类加载器以ClassLoader+包名+类名为Key进行查询对应的.class文件。如果没有找到文件，则抛出ClassNotFoundException异常，如果找到则进行类加载，并生成Class类对象。

内存归整——指针碰撞法

内存不归整

选择哪种分配方式由Java堆是否规整决定，而Java堆是否规整又由所采用的的垃圾回收器是否带着有压缩整理功能所决定

采用CAS配上失败重试保证更新的原子性

每个线程预先分配一块TLAB

所有属性设置默认值（零值初始化），保证对象实例字段在不赋值可以直接使用。

将对象的所属类（即类的元数据信息）、对象的HashCode和对象的GC信息、锁信息等数据存储在对象的对象头中。这个过程的具体设置方式取决于JVM实现。

在Java程序的视角看来，初始化才正式开始。初始化成员变量，执行实例化代码块，调用类的构造方法，并把堆内对象的首地址赋值给引用变量。因此一般来说（由字节码中是否跟随有`invokespecial`指令所决定），new 指令之后会接着就是执行方法，把对象按照程序员的意愿进行初始化，这样一个真正可用的对象才算完全创建出来。

运行时元数据【Mark World】

类型指针【Klass Pointer】

数组长度（只有数组对象有 4个字节）

例子

规则

由于虚拟机要求对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐

句柄访问

直接访问（Hotspot默认）

各种用二进制编码方式表示的指令，叫做机器指令码。开始，人们就用它采编写程序，这就是机器语言。机器语言虽然能够被计算机理解和接受，但和人们的语言差别太大，不易被人们理解和记忆，并且用它编程容易出差错。用它编写的程序一经输入计算机， CPU直接读取运行，因此和其他语言编的程序相比，执行速度最快。机器指令与CPU紧密相关，所以不同种类的CPU所对应的机器指令也就不同。

由于机器码是有0和1组成的二进制序列，可读性实在太差，于是人们发明了指令。指令就是把机器码中特定的0和1序列，简化成对应的指令(一般为英文简写，如mov，inc等)，可读性稍好由于不同的硬件平台，执行同一个操作，对应的机器码可能不同，所以不同的硬件平台的同一种指令(比如mov)，对应的机器码也可能不同。

不同的硬件平台，各自支持的指令，是有差别的。因此每个平台所支持的指令，称之为对应平台的指令集。如常见的 x86指令集，对应的是x86架构的平台；ARM指令集，对应的是ARM架构的平台

由于指令的可读性还是太差，于是人们又发明了汇编语言。在汇编语言中，用助记符(Mnemonics)代替机器指令的操作码，用地址符号(Symbol)或标号(Label)代替指令或操作数的地址。在不同的硬件平台，汇编语言对应着不同的机器语言指令集，通过汇编过程转换成机器指令。由于计算机只认识指令码，所以用汇编语言编写的程序还必须翻译成机器指令码，计算机才能识别和执行

解释器真正意义上所承担的角色就是一个运行时“实时翻译者”，将字节码文件中的内容“翻译”为对应平台的本地机器指令执行。当一条字节码指令被解释执行完成后，接着再根据PC寄存器中记录的下一条需要被执行的字节码指令执行解释操作，

字节码解释器：在执行时通过`纯软件代码`模拟字节码的执行，效率非常低下。

模板解释器将：`每一条字节码和一个模板函数相关联，`模板函数中直接产生这条字节码执行时的机器码，从而很大程度上提高了解释器的性能。

• 第一种是将源代码编译成字节码文件，然后在运行时通过解释器将字节码文件转为机器码执行。
• 第二种是编译执行(直接编译成机器码)。现代虚机为了提高执行效率，会使用即时编译技术(JIT，Just In Time）将方法编译成机器码后再执行。

当虚拟机启动的时候，解释器可以首先发挥作用，而不必等待即时编译器全部编译完成再执行，这样可以省去许多不必要的编译时间。并且随着程序运行时间的推移，即时编译器逐渐发挥作用，根据热点探测功能，将有价值的字节码编译为本地机器指令，以换取更高的程序执行效率

什么是？

怎么选择？

缺省情况下HotSpot VM是采用解释器与即时编译器并存的架构，当然开发人员可以根据具体的应用场景，通过命令显式地为Java虚拟机指定在运行时到底是完全采用解释器执行，还是完全采用即时编译器执行。如下所示:

• -Xint：完全采用解释器模式执行程序
• -Xcomp：完全采用即时编译器模式执行程序。如果即时编译出现问题，解释器会介入执行。
• -Xmixed：采用解释器+即时编译器的混合模式共同执行程序。

在HotSpot VM中内嵌有两个JIT编译器，分别为Client Compiler和ServerCompiler，但大多数情况下我们简称为c1编译器和C2编译器。开发人员可以通过如下命令显式指定Java虚拟机在运行时到底使用哪一种即时编译器

• -client：指定Java虚拟机运行在Client模式下，并使用c1编译器；C1编译器会对字节码进行`简单和可靠的优化，耗时短`。以达到`更快的编译速度`。
• -server：指定Java虚拟机运行在Server模式下，并使用C2编译器。C2进行`耗时较长的优化，以及激进优化`。但`优化的代码执行效率更高`。

程序解释执行(不开启性能监控)可以触发c1编译，将字节码编译成机器码，可以进行简单优化，也可以加上性能监控，C2编译会根据性能监控信息进行激进优化。

C1编译器上主要有方法内联，去虚拟化、冗余消除

C2的优化主要是在全局层面，逃逸分析是优化的基础。基于逃逸分析在C2上有如下几种优化

案例：注意解释执行与编译执行在线上环境微妙的辩证关系。机器在热机状态可以承受的负载要大于冷机状态。如果以热机状态时的流量进行切流，可能使处于冷机状态的服务器因无法承载流量而假死。
在生产环境发布过程中，以分批的方式进行发布，根据机器数量划分成多个批次，每个批次的机器数至多占到整个集群的1/8。曾经有这样的故障案例：某程序员在发布平台进行分批发布，在输入发布总批数时，误填写成分为两批发布。如果是热机状态，在正常情况下一半的机器可以勉强承载流量，但由于刚启动的JVM均是解释执行，还没有进行热点代码统计和JIT动态编译，导致机器启动之后，当前1/2发布成功的服务器马上全部启机，此故障说明了JIT的存在。——阿里团队

JDK 8：char [] value      jdk9：byte []

为什么要变更？

StringTable 为什么要调整位置？

针对于 final 修饰类、方法、基本数据类型、引用数据类型的变量的结构能使用上 final 的时候建议加上

• ① StringBuilder的 append() 的方式自始至终只创建过一个StringBuiilder的对象，使用String的字符串拼接的方式：创建过多个StringBuilder 和 String的对象。
• ② 使用String的字符串拼接方式：内存中由于创建了较多的StringBuilder和String对象，内存占用更大，如果进行了GC，就需要花费额外的时间

改进的空间：在实际开发中，如果基本确定要前前后后添加的字符串长度不高于某个限定值 highLevel的情况下，建议使用构造器 StringBuilder sb = new StringBuilder(highLevel)     避免底层进行扩容

• - 如果串池中有，则并不会放入。返回已有的串池中的对象的地址
• - 如果没有，会把此对象复制一份，放入串池，并返回串池中的对象地址

• - 如果串池中有，则并不会放入。返回已有的串池中的对象的地址
• - 如果没有，则会把对象的引用地址复制一份，放入串池，`并返回串池中的引用地址`

当垃圾收集器工作的时候，会访问堆上存活的对象。对每一个访问的对象都会检查是否是候选的要去重的String对象。如果是，把这个对象的一个引用插入到队列中等待后续的处理。一个去重的线程在后台运行，处理这个队列。处理队列的一个元素意味着从队列删除这个元素，然后尝试去重它引用的String对象。使用一个hashtable来记录所有的被string对象使用的不重复的char数组。当去重的时候，会查这个hashtable，来看堆上是否已经存在一个一模一样的char数组。如果存在， String对象会被调整引用那个数组，释放对原来的数组的引用，最终会被垃圾收集器回收掉。如果查找失败， char数组会被插入到hashtable，这样以后的时候就可以共享这个数组了

UsestringDeduplication (bool) ：开启String去重，默认是不开启的，需要手动开启。

PrintStringDeduplicationstatistics (bool)：打印详细的去重统计信息

StringDeduplicationAgeThreshold (uintx) ：达到这个年龄的String对象被认为是去重的候选对象

优点： 自动管理

缺点： 黑匣子

• 频繁收集Young区（新生代）
• 较少收集0ld区（老年区）
• 基本不动Perm区（方法区）

引用计数法

可达性分析

标记-清除算法（Makr-Sweep）

复制算法（copying）

标记-压缩算法（Mark-Compact）

Java语言提供了对象终止(finalization)机制来允许开发人员提供对象被销毁之前的自定义处理逻辑。当垃圾回收器发现没有引用指向一个对象，即：垃圾回收此对象之前，总会先调用这个对象的finalize()方法。finalize ()方法允许在子类中被重写，用于在对象被回收时进行资源释放。通常在这个方法中进行一些资源释放和清理的工作，比如关闭文件、套接字和数据库连接等。

永远不要主动调用某个对象的finalize ()方法，应该交给垃圾回收机制调用

对象状态

判断一个对象是否被回收

年轻代

老年代

基本思想

缺点

没有空闲内存，并且垃圾收集器也无法提供更多内存。

• Java虚拟机的堆内存设置不够
• 代码中创建了大量大对象，并且长时间不能被垃圾收集器收集(存在被引用)

严格来说，只有对象不会再被程序用到了，但是GC又不能回收他们的情况，才叫内存泄漏。但实际情况很多时候一些不太好的实践(或疏忽)会导致对象的生命周期变得很长甚至导致OOM，也可以叫做宽泛意义上的“内存泄漏

• 1、单例模式单例的生命周期和应用程序是一样长的，所以单例程序中，如果持有对外部对象的引用的话，那么这个外部对象是不能被回收的，则会导致内存泄漏的产生。（加长了对象的生命周期）
• 2、一些提供close的资源未关闭导致内存泄漏数据库连接（dataSourse.getConnection()） ，网络连接(socket)和io连接必须手动close，否则是不能被回收的。

• 并行(Parallel) ：指多条垃圾收集线程并行工作，但此时用户线程仍处于等待状态。如ParNew、 Parallel Scavenge， Parallel 0ld
• 串行(Serial)：相较于并行的概念，单线程执行。如果内存不够，则程序暂停，启动JVM垃圾回收器进行垃圾回收。回收完，再启动程序的线程。

并发Concurrent) ：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），垃圾回收线程在执行时不会停顿用户程序的运行

• 用户程序在继续运行，而垃圾收集程序线程运行于另一个CPU上;
• 如: CMS、G1

安全点（safe point）

安全区域（Safe Region）

强

软

弱

虚

终结器引用

按照线程数来分

按照工作模式分

按碎片处理方式分

按工作的内存区间分

吞吐量

暂停时间

内存占用

垃圾收集开销

收集频率

• -XX:+PrintCommandLineFlags：查看命令行相关参数(包含使用的垃圾收集器)
• - 使用命令行指令: `jino -flag 相关垃圾回收器参数 进程ID`

"[GC"和" [Full GC"说明了这次垃圾收集的停顿类型，如果有"Full"则说明GC发生了"StopThe World"

使用Serial收集器在新生代的名字是`Default New Generation`，因此显示的是"`[DefNew`"

使用ParNew收集器在新生代的名字会变成"`[ParNew`"，意思是"`Parallel New Generation`

使用Parallel Scavenge收集器在新生代的名字是"[PSYoungGen"老年代的收集和新生代道理一样，名字也是收集器决定的

使用G1收集器的话，会显示为"`garbage-first heap`"

Allocation Failure  表明本次引起GC的原因是因为在年轻代中没有足够的空间能够存储新的数据了。

[PSYoungGen: 5986K->696K (8704K) ] 5986K->704K(9216K)`     
括号内:  GC回收前年轻代大小，回收后大小， (年轻代总大小)    
括号外:  GC回收前年轻代和老年代大小，回收后大小，(年轻代和老年代总大小)

user代表用户态回收耗时，sys内核态回收耗时，real实际耗时。由于多核的原因，时间总和可能会超过real时间

可以用一些工具去分析这些gc日志。常用的日志分析工具有: GCViewer、GCEasy、GCHisto、GCLogViewer、Hpjmeter， garbagecat等

Shenandoah，无疑是众多GC中最孤独的一个。是第一款不由oracle公司团队领导开发的HotSpot垃圾收集器。不可避免的受到官方的排挤。比如号称OpenJDK和OracleJDK没有区别的oracle公司仍拒绝在OracleJDK12中支持Shenandoah。Shenandoah垃圾回收器最初由**RedHat**进行的一项垃圾收集器研究项目PauselessGC的实现，旨在针对JVM上的内存回收实现低停顿的需求。在2014年贡献给OpenJDKRed Hat研发Shenandoah团队对外宣称， Shenandoah垃圾回收器的暂停时间与堆大小无关，这意味着无论将堆设置为200 MB还是200GB， 99.9%的目标都可以把垃圾收集的停顿时间限制在十毫秒以内。不过实际使用性能将取决于实际工作堆的大小和工作负载

• Shenandoah GC 的强项： 低延迟时间
• Shenandoah GC 的弱项： 高运行负担下的吞吐量下降

ZGC与Shenandoah目标高度相似，在尽可能对吞吐量影响不大的前提下，实现在任意堆内存大小下都可以把垃圾收集的停顿时间限制在十毫秒以内的低延迟。《深入理解Java虚拟机》一书中这样定义ZGC：ZGC收集器是一款基于Region内存布局的， (暂时)不设分代的，使用了读屏障、染色指针和内存多重映射等技术来实现可并发的标记-压缩算法，以低延迟为首要目标的一款垃圾收集器

ZGC的工作过程可以分为4个阶段：并发标记-并发预备重分配-并发重分配-并发重映射等。ZGC几乎在所有地方并发执行的，除了初始标记的是STW的。所以停顿时间几乎就耗费在初始标记上，这部分的实际时间是非常少的

Serial 0ld是运行在Client模式下默认的老年代的垃圾回收器Serial old在Server模式下主要有两个用途

• ① 与新生代的ParallelScavenge配合使用
• ② 作为老年代CMS收集器的后备垃圾收集方案

简单而高效(与其他收集器的单线程比)，对于限定单个CPU的环境来说， Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。运行在Client模式下的虚拟机是个不错的选择

限制线程数量，默认开启和CPU数据相同的线程数。

由于ParNew收集器是基于并行回收，那么是否可以断定ParNew收集器的回收效率在任何场景下都会比serial收集器更高效？ParNew收集器运行在多CPU的环境下，由于可以充分利用多CPU、多核心等物理硬件资源优势，可以更快速地完成垃圾收集，提升程序的吞吐量。但是在单个CPU的环境下， ParNew收集器不比serial收集器更高效。虽然Serial收集器是基于串行回收，但是由于CPU不需要频繁地做任务切换，因此可以有效避免多线程交互过程中产生的一些额外开销

复制算法

标记压缩算法

XX:+UseParallelGC

-XX: +UseParallelOldGC

-XX: ParallelGCThreads

-XX: MaxGCPauseMillis

-XX:GCTimeRatio

-XX:+UseAdaptiveSizePolicy

并发标记过程占用整个过程的一大半（80%）

尽管CMS收集器采用的是并发回收(非独占式)，但是在其初始化标记和再次标记这两个阶段中仍然需要执行"Stop-the-World”机制暂停程序中的工作线程，不过暂停时间并不会太长，因此可以说明目前所有的垃圾收集器都做不到完全不需要"Stop-theWorld” ，只是尽可能地缩短暂停时间。由于最耗费时间的并发标记与并发清除阶段都不需要暂停工作，所以整体的回收是低停顿的

由于在垃圾收集阶段用户线程没有中断，所以在CMS回收过程中，还应该确保应用程序用户线程有足够的内存可用。因此，CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，而是当堆内存使用率达到某一阔值时，便开始进行回收，以确保应用程序在CMS工作过程中依然有足够的空间支持应用程序运行。要是CMS运行期间预留的内存无法满足程序需要，就会出现一次"Concurrent Mode Failure"失败，这时虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。

CMS收集器的垃圾收集算法采用的是标记-清除算法，这意味着每次执行完内存回收后，由于被执行内存回收的无用对象所占用的内存空间极有可能是不连续的一些内存块，不可避免地将会产生一些内存碎片。那么CMS在为新对象分配内存空间时，将无法使用指针碰撞(Bump the Pointer)技术，而只能够选择空闲列表(Free List)执行内存分配。

因为当并发清除的时候，用Compact整理内存的话，原来的用户线程使用的内存还怎么用呢?要保证用户线程能继续执行，前提的它运行的资源不受影响嘛。Mark Compact更适合"Stop the World”这种场景下使用

并发收集、低延迟

产生内存碎片，导致并发清除后，用户线程可用的空间不足。在无法分配大对象的情况下，不得不提前触发Full GC

CMS收集器对CPU资源非常敏感，在并发阶段，它虽然不会导致用户停顿，但是会因为占用了一部分线程而导致应用程序变慢，总吞吐量会降低。

CMS收集器无法处理浮动垃圾。可能出现"Concurrent Mode Failure"失败而导致另一次Full GC的产生【会临时启用 SerialOld 收集器来进行垃圾收集】。在并发标记阶段由于程序的工作线程和垃圾收集线程是同时运行或者交叉运行的，那么在并发标记阶段如果产生新的垃圾对象，CMS将无法对这些垃圾对象进行标记，最终会导致这些新产生的垃圾对象没有被及时回收，从而只能在下一次执行GC时释放这些之前未被回收的内存空间

-XX: +UseConcMarkSweepGC

-XX: CMSlnitiatingOccupanyFraction

XX:+UseCMSInitiatingOccupancyOnly

-XX: CMSFullGCsBeforeCompaction

-XX: +UseCMSCompactAtFullCollection

-XX: ParallelCMSThreads

-XX:ConcGCThreads

-XX:+CMSScavengeBeforeRemark

-XX:+CMSParallellnitialMarkEnabled

-XX:+CMSParallelRemarkEnabled

三色标记（可达性分析底层算法）

记忆集与卡表

并发 & 并行

分代收集

空间整合

可预测的停顿时间模型

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

G1的设计原则就是简化JVM性能调优，开发人员只需要简单的三步即可完成调优：

• 第一步：开启G1垃圾收集器
• 第二步：设置堆的最大内存
• 第三步：设置最大的停顿时间
  

G1中提供了三种垃圾回收模式： YoungGC、Mixed GC和Full GC，在不同的条件下被触发。

面向服务端应用，针对具有大内存、多处理器的机器

最主要的应用是需要低GC延迟，并具有大堆的应用程序提供解决方案

在下面的情况时，使用G1可能比CMS好

• ①  超过50%的Java堆被活动数据占用 
• ②  对象分配频率或年代提升频率变化很大;
• ③  GC停顿时间过长(长于0.5至1秒)

HotSpot垃圾收集器里，除了G1以外，其他的垃圾收集器使用内置的JVM线程执行GC的多线程操作，而G1 GC可以采用应用线程承担后台运行的GC工作，即当JVM的GC线程处理速度慢时，系统会调用应用程序线程帮助加速垃圾回收过程

使用G1收集器时，它将整个Java堆划分成约2048个大小相同的独立Region块，每个Region块大小根据堆空间的实际大小而定，整体被控制在1MB到32MB之间，且为2的N次幕，即1MB， 2MB， 4MB， 8MB， 16MB， 32MB。可以通过-XX:G1HeapRegionSize设定。所有的Region大小相同，且在JVM生命周期内不会被改变。虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region(不需要连续)的集合。通过Region的动态分配方式实现逻辑上的连续。

默认年轻代对堆内存的占比是5%，如果堆大小为4096M，那么年轻代占据200MB左右的内存，对应大概是100个Region，可以通过“-XX:G1NewSizePercent”设置新生代初始占比，在系统运行中，JVM会不停的给年轻代增加更多的Region，但是最多新生代的占比不会超过60%，可以通过“-XX:G1MaxNewSizePercent”调整。年轻代中的Eden和Survivor对应的region也跟之前一样，默认8:1:1

一个region有可能属于Eden， Survivor 或者old/Tenured内存区域。但是一个region只可能属于一个角色。图中的E表示该region属于Eden内存区域， S表示属于Survivor内存区域，O表示属于Old内存区域。图中空白的表示未使用的内存空间。G1垃圾收集器还增加了一种新的内存区域，叫做Humongous内存区域，如图中的H块，主要用于存储大对象，如果超过1.5个region，就放到H（在G1中，大对象的判定规则就是一个大对象超过了一个Region大小的50%）

设置H的原因：对于堆中的大对象，默认直接会被分配到老年代，但是如果它是一个短期存在的大对象，就会对垃圾收集器造成负面影响。为了解决这个问题， G1划分了一个Humongous区，它用来专门存放大对象。如果一个H区装不下一个大对象，那么G1会寻找连续的H区来存储。为了能找到连续的H区，有时候不得不启动Full GC。G1的大多数行为都把H区作为老年代的一部分来看待

Remembered Set

G1 回收过程一： 年轻代 GC

G1 回收过程二： 并发标记过程

G1 回收过程三： 混合回收（Fixed GC）

G1 回收可选的过程四： Full GC （兜底）

-XX:ParallelGCThreads：指定GC工作的线程数量

-XX:G1HeapRegionSize：指定分区大小(1MB~32MB，且必须是2的N次幂)，默认将整堆划分为2048个分区

-XX:MaxGCPauseMillis：目标暂停时间(默认200ms)

-XX:G1NewSizePercent：新生代内存初始空间(默认整堆5%，值配置整数，默认就是百分比)

-XX:G1MaxNewSizePercent：新生代内存最大空间（默认60%）

-XX:TargetSurvivorRatio：Survivor区的填充容量(默认50%)，Survivor区域里的一批对象(年龄1+年龄2+年龄n的多个年龄对象)总和超过了Survivor区域的50%，此时就会把年龄n(含)以上的对象都放入老年代

-XX:MaxTenuringThreshold：最大年龄阈值(默认15)

-XX:InitiatingHeapOccupancyPercent：老年代占用空间达到整堆内存阈值(默认45%)，则执行新生代和老年代的混合收集(MixedGC)，比如我们之前说的堆默认有2048个region，如果有接近1000个region都是老年代的region，则可能就要触发MixedGC了

-XX:G1MixedGCLiveThresholdPercent：(默认85%)  region中的存活对象低于这个值时才会回收该region，如果超过这个值，存活对象过多，回收的的意义不大。

-XX:G1MixedGCCountTarget：在一次回收过程中指定做几次筛选回收(默认8次)，在最后一个筛选回收阶段可以回收一会，然后暂停回收，恢复系统运行，一会再开始回收，这样可以让系统不至于单次停顿时间过长。

年轻代大小

暂停时间目标不要太过严苛