JVM思维导图（含面试问题整理）

类加载子系统：加载字节码文件到运行数据区的方法区

执行引擎：执行字节码文件中的指令

本地方法接口：java调用其他语言的接口，与本地资源交互

运行时数据区：JVM的内存

执行流程

java代码--编译器-->字节码文件--类加载器-->方法区

堆：java.lang.Class对象-->封装方法区内数据结构

每个语言都需要转换成字节码文件，最后转换的字节码文件都能通过Java虚拟机进行运行和处理

随着Java7的正式发布，Java虚拟机的设计者们通过JSR-292规范基本实现在Java虚拟机平台上运行非Java语言编写的程序。

Java虚拟机根本不关心运行在其内部的程序到底是使用何种编程语言编写的，它只关心“字节码”文件

VMware：完全对物理计算机的仿真

专门执行单个计算机程序，JVM：执行Java字节码指令

优点

缺点

地址、操作数

优点

缺点

典型应用是X86的二进制指令集，比如传统的PC以及安卓的Davlik虚拟机

大部分情况下，指令集往往以一地址指令，二地址指令和三地址指令为主。

-v输出附加信息

-l输出行号和本地变量表

-p显示所有类和成员

-c对代码进行反汇编

通过引导类加载器bootstrap class loader创建一个初始类来完成的，这个类是由虚拟机的具体实现指定的。

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

程序正常执行结束

执行过程遇到异常或错误而异常终止

操作系统错误导致Java虚拟机进程终止

Runtime类或System类的exit方法、runtime类的halt方法，并且Java安全管理器允许这次exit或halt操作

JNI(Java Native Interface)规范描述了用JNI Invocation API来加载或卸载Java虚拟机时，Java虚拟机退出的情况

常量池运行时加载到内存中，即运行时常量池

加载刚好是加载过程的一个阶段，二者意思不能混淆

通过一个类的全限定名获取定义此类的二进制字节流

将这个字节流所代表的的静态存储结果转化为方法区的运行时数据结构

在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据访问入口

验证

准备

解析

初始化阶段是执行类构造器方法<clinit>()的过程

此方法不需要定义，是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来

构造器方法中指令按照语句在源文中出现的顺序执行

<clinit>()不同于类的构造器（关联：构造器是虚拟机视角下的<init>()）

若该类具有父类，JVM会保证子类的<clinit>()执行前，父类的<clinit>()已经执行完毕

虚拟机必须保证一个类的<clinit>()方法在多线程下被同步加锁

加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的。

解析阶段不一定，在某些情况下可以在初始化阶段之后再开始，为了支持Java语言的运行时绑定特性（也称为动态绑定或晚期绑定）

Java虚拟机规范严格规定了，有且只有六种情况，必须立即对类进行初始化

除了以上几种情况，其他使用类的方式被看做是对类的被动使用，都不会导致类的初始化

启动类加载器(Bootstrap ClassLoader)：用来加载java核心类库，无法被java程序直接引用

扩展类加载器(extensions class loader)：它用来加载 Java 的扩展库。JVM的实现会提供一个扩展库目录。该类加载器在此目录里面查找并加载 Java 类

系统类加载器（system class loader）：它根据 Java 应用的类路径（CLASSPATH）来加载 Java 类。一般来说，Java 应用的类都是由它来完成加载的。可以通过 ClassLoader.getSystemClassLoader()来获取它。

用户自定义类加载器，通过继承 java.lang.ClassLoader类的方式实现

概念上，将所有派生于抽象类ClassLoader的类加载器都划分为自定义加载器

截图

对于用户来说定义器来说，默认使用系统类加载器进行加载

Java的核心类库，使用引导类加载器进行加载

C/C++语言实现，嵌套JVM内部

用来加载Java核心类库，rt.jar,resources.jar,sun.boot.class.path路径下的内容

并不继承java.lang.ClassLoader，没有父加载器

加载扩展类和应用程序类加载器，并指定为他们的父类加载器

出于安全考虑，Bootstrap启动类加载器只加载包名为java\javax\sun等开头的类

Java语言编写，由sun.misc.Launcher$ExtClassLoader实现

派生于ClassLoader类

父类加载器为启动类加载器

从java.ext.dirs系统属性所指定的目录中加载类库，或从jre/lib/ext子目录下加载类库

Java语言编写，由sun.misc.Launcher$AppClassLoader实现

派生于ClassLoader类

父类加载器为扩展类加载器

负责加载环境变量classpath或系统属性java.class.path指定路径下的类库

该类加载器是程序中默认的类加载器，一般来说，Java应用的类都是由它来完成加载

通过ClassLoader#getSystemClassLoader（）方法可以后去到改类加载器

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

实现步骤

是一个抽象类，除了启动类加载器，其他类加载器都继承自他

Java虚拟机对Class文件采用的是按需加载，而且加载class文件时，Java虚拟机使用的是双亲委派模式，即把请求交由父类处理，它是异种任务委派模式

1、如果一个类加载器收到了类加载请求，它并不会自己先去加载。而是把这个请求委托给父类的加载器去执行

2、如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将达到顶层的启动类加载器

3、如果父类的加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式

避免类的重复加载

保护程序安全，防止核心API被篡改

保证对Java核心源代码的保护

类的完整类名必须一致，包括包名

加载这个类的ClassLoader必须相同

堆：对象分配物理地址不连续，性能相对栈弱些。

栈：先进后出，物理地址连续，性能相对堆好些。

堆：在运行时分配，大小不固定

栈：在编译时分配，大小固定

堆：对象的实例和数组，更关注：数据存储

栈：局部变量，操作数，动态链接，方法返回地址等信息，更关注：程序方法的执行

堆：所有线程共享，可见

栈：线程私有，只对线程可见，生命周期和线程相同

因为线程是一个个的顺序执行流，CPU需要不停的切换各个线程，这时候切换回来以后，就得知道接着从哪开始继续执行

JVM的字节码解释器就需要通过改变PC寄存器的值来明确下一条应该执行什么样的字节码指令

记录下一条字节码执行的指令，实现分支循环跳转、异常处理、线程恢复等功能。

CPU为每个线程分配时间片，多线程在一个特定的时间段内只会执行某一个线程的方法，CPU会不停地进行任务切换，线程需要中断、恢复

CPU，多线程，分配时间片，只执行一个线程，CPU任务切换，线程中断恢复

各个线程、PC寄存器记录、当前字节码指令地址，各个线程之间可进行独立计算，防止相互干扰。

局部变量  vs  成员变量

基本数据类型   VS 引用类型变量（类，数组，接口）

每个方法执行，伴随着进栈（入栈，压栈）

执行结束的出栈

Java栈大小是动态或者固定不变的

截图

一种是正常的函数返回，使用return指令

另外一种是抛出异常，不管哪种方式，都会导致栈帧被弹出

定义为一个数字数组，主要用于存储方法参数，定义在方法体内部的局部变量，数据类型包括各类基本数据类型，对象引用，以及return address类型

局部变量表建立在线程的栈上，是线程私有的，因此不存在数据安全问题

局部变量表容量个数，容量大小（反编译查看locals的值）是在编译期确定下来的

局部变量表存放编译期可知的各种基本数据类型（8种），引用类型（reference）,return address 类型

最基本的存储单元是slot

局部变量表中的变量只有在当前方法调用中有效，虚拟机通过使用局部变量表完成参数值到参数变量列表的传递过程。

方法调用结束后，随着方法栈帧的销毁，局部变量表也会随之销毁

关于Slot的理解

静态变量与局部变量对比及小结

补充：

在方法执行的过程中，根据字节码指令，往栈中写入数据或提取数据，即入栈/出栈

作用：计算过程中变量临时存储空间，保存计算过程的中间结果

当一个方法刚开始执行的时候，一个新的栈帧也会随之被创建出来，这个方法的操作数栈是空的

每一个操作数栈会拥有一个明确的栈深度，用于存储数值，最大深度在编译期就定义好（反编译 Stack=2)

栈中，32bit类型占用一个栈单位深度，64bit类型占用两个栈单位深度

操作数栈并非采用访问索引方式进行数据访问，而是只能通过标准的入栈、出栈操作完成一次数据访问

栈中，32bit类型占用一个栈单位深度，64bit类型占用两个栈单位深度

如果被调用方法带有返回值的话，其返回值将会被压入当前栈帧的操作数栈中，并更新程序计数器中下一条需要执行的字节码指令

Java虚拟机的解释引擎是基于栈的执行引擎，其中栈就是操作数栈

i++和++i的区别

栈顶缓存技术

指向运行时常量池的方法引用

常量池、运行时常量池

存放调用该方法的pc寄存器的值

方法的结束

无论哪种方式退出，方法退出后，都会返回该方法被调用的位置。方法正常退出时，调用者的PC计数器的值作为返回地址，即调用该方法的指令的下一条指令的地址。

异常退出的，返回地址是通过异常表来确定，栈帧中一般不会保存这部分信息

执行引擎遇到任意一个方法返回的字节码指令（return）,会有返回值传递给上层的方法调用者，简称正常完成出口

本质上，方法的退出就是当前栈帧出栈的过程。此时需要恢复上层方法的局部变量表，操作数栈，将返回值压入调用者栈帧的操作数栈，设置PC寄存器值等，让调用者方法继续执行下去。

正常完成出口和异常完成出口的区别在于：通过异常完成出口退出的不会给他的上层调用者产生任何的返回值

允许携带与Java虚拟机实现相关的一些附加信息，例如对程序调试提供支持的信息。不确定有，可选情况

静态链接

动态链接

方法的绑定

Java中任何一个普通方法都具备虚函数的特征（运行期确认，具备晚期绑定的特点），C++中则使用关键字virtual来显式定义

如果在java程序中，不希望某个方法拥有虚函数的特征，则可以使用关键字final来标记这个方法

虚方法和非虚方法

方法调用指令

方法重写的本质

虚方法表（存在方法区）

例如与操作系统底层或硬件交换信息时的情况

例如启动一个线程

Java堆区在JVM启动的时候即被创建，其空间大小也就确认了。堆内存的大小是可调节的

《Java虚拟机规范》规定，堆可以处于物理上不连续的内存空间中，但在逻辑上它应该被视为连续的。

所有的线程共享Java堆，在这里还可以划分线程私有的缓冲区（TLAB：thread local allocation buffer）

《Java虚拟机规范》中对Java堆的描述是：所有的对象实例以及数组都应当在运行时分配在堆上。（The heap is the run-time data area from which memory for all class instances and arrays is allocated）《Java虚拟机规范》中对JavaL堆的描述是：所有的对象实例以及数组都应当在运行时分配在堆上。（The heap is the run-time data area from which memory for all class instances and arrays is allocated）

eden区满，触发GC，进行垃圾回收

如果堆中对象马上被回收，用户线程会受到影响，stop the world

Java7及之前

Java8及之后

目的：在Java垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小，从而提高性能。

初始内存大小

最大内存大小

分代的目的：优化GC的性能（不分代完全可以）

若不分代-->GC需要扫描整个堆空间，分代之后-->对具体某一区域进行适合的GC

不同代根据其特点进行不同的垃圾回收算法-->提高回收效率（分代收集算法）

-XX:NewRatio=2，表示新生代占1，老年代占2，新生代占整个堆的1/3

-XX:SurvivorRatio调整这个空间比例   Eden与Survivor区的比例

如果没有survivor区，Eden区进行一次MinorGC，存活对象-->老年代--满-->MajorGC

MajorGC消耗时间更长，影响程序执行和响应速度。

survivor存在意义：增加进入老年代的筛选条件，减少送到老年代的对象，减少FullGC的次数。

只有一个survivor区，在第一次Eden区满进行MinorGC，存活对象放到survivor区；第二次Eden区满MinorGC-->survivor区，会产生不连续的内存，无法存放更多的对象。

设置三个四个survivor区，则每个被分配的survivor空间相对较小，很快被填满。

设置两个survivor区，在MinorGC时可以将Eden区和S0存活的对象以连续存储的方式存入S1区。减少碎片化。（清除阶段的复制算法）

Eden放不了的大对象，直接进入老年代了。

-XX:MaxTenuringThreshold=N进行设置

针对幸存者s0，s1区的总结：复制之后有交换，谁空谁是to。

频繁在新生区收集，很少在养老区收集，几乎不在永久区/元空间搜集

特别注意，在Eden区满了的时候，才会触发MinorGC，而幸存者区满了后，不会触发MinorGC操作

如果Survivor区满了后，新对象可能直接晋升老年代

用于对 JVM 中的内存、线程和类等进行监控

JDK 自带的全能分析工具，可以分析：内存快照、线程快照、程序死锁、监控内存的变化、gc 变化等。

GC按照内存回收区域分为

Eden区满，触发YGC，Survivor区满不触发GC。每次YGC会清理年轻代（eden＋survivor）的内存

因为Java对象大多朝生夕灭，所以YGC非常频繁

如果对象再Eden出生并经过第一次MinorGC后仍然存活，并且能被Survivor区容纳，则被移动到Survivor空间中，并将对象年龄设置为1，对象再Survivor区每熬过一次MinorGC，年龄就+1，当年龄增加到一定程度（默认为15，不同Jvm，GC都所有不同）时，就会被晋升到老年代中

YGC，To Survivor区不足以存放存活对象，直接进入老年代

大对象直接分配到老年代

动态对象年龄分配

老年代空间不足，会触发MinorGC，空间还不足，触发MajorGC或FullGC。还不足，OOM

MajorGC的速度比MinorGC慢10倍以上，STW的时间更长

JVM参数设置问题

大对象

内存泄漏

程序频繁生成一些长生命周期的对象，当这些对象的存活年龄超过分代年龄时便会进入老年代，最后引发FGC

程序BUG导致动态生成了很多新类，使得 Metaspace 不断被占用，先引发FGC，最后导致OOM

代码中显式调用了gc方法

老年代的内存使用率达到了一定阈值（可通过参数调整），直接触发FGC

空间分配担保

Metaspace（元空间）在空间不足时会进行扩容，当扩容到了-XX:MetaspaceSize 参数的指定值时，也会触发FGC

调用System.gc()时，系统建议执行FullGC，但是不必然执行

Eden区满，进行GC，将Eden+from区存活的对象移动到to区

清空 Eden 和 From Survivor 分区，from/to调换名称

对象到to区后，对象头的GC分代年龄加一，到达年龄阈值后进入老年代；to区满eden区的对象可能直接进入老年代；大对象可能直接进入老年代

老年代达到一定阈值时，进行老年代的垃圾回收（标记-压缩算法）

关注GC日志的哪个位置耗时长

原因分析：短周期对象过多

从内存模型而不是垃圾收集的角度，对Eden区域进行划分，JVM为每个线程分配了一个私有缓存区域，包含在Eden空间中

多线程同时分配内存时，使用TLAB可以避免一系列的非线程安全问题，同时还能够提升内存分配的吞吐量，因此我们将这种内存分配方式成为快速分配策略

openjdk衍生出来的JVM都提供了TLAB的设计

补充

对象引用范围分析，减少程序同步负载、内存堆分配压力

逃逸分析：代码优化

初始化堆大小为2g

最大堆内存为2g

设置新生区内存大小

设置新生代与老年代内存比例为1:2

设置eden区与survivor区内存比例为8:1:1

设置分代年龄阈值

指定使用 ParNew + Serial Old 垃圾回收器组合

指定年轻代使用Parallel scavenge+Parallel Old并行收集器执行内存回收任务

默认jdk8开启。默认开启一个，另一个也会被开启。（互相激活）

开启该参数后会自动将-XX:+UseParNewGC打开。即：ParNew（Young区）+CMS（Old区）+Serial Old（Old区备选方案）的组合。

《Java虚拟机规范》：尽管所有方法区在逻辑上属于堆一部分，但一些简单实现，可能不会进行垃圾收集或进行压缩。

对于HotSpot，方法区又名：Non-Heap（非堆），目的：区分堆。

方法区看作是一块独立于Java堆的内存空间

方法区主要存放Class，堆中主要存放实例化对象（堆和方法区的不同点）

方法区/Java堆，各个线程共享内存区域（同）

方法区/Java堆，在JVM启动时被创建，物理内存空间可以不连续，逻辑空间要连续（同）

方法区/Java堆，可以选择固定大小或者可扩展（同）

方法区大小决定了系统可以保存多少个类，如果类定义太多，导致方法区溢出，JVM同样抛出内存溢出异常 OOM

关闭JVM就会释放这个区域的内存（待）

加载大量的第三方的jar包

Tomcat部署的工程过多（30~50个）

大量动态的生成反射类

元空间永久代，都是对JVM规范中方法区的实现。

元空间永久代区别：元空间不在虚拟机中设置内存，使用本地内存（堆外内存）

根据Jvm规范，如果方法区无法满足新的内存分配需求，将抛出OOM异常

JDK7及之前设置永久代大小

JDK8设置元空间大小

大量引用指向某些对象，但是这些对象以后不会使用。这些对象还和GC ROOT有关联，所以也不会被回收

大量饮用-->对象，不去用又不能回收

用于存储已被虚拟机加载的类型信息，常量，静态变量，即时编译器编译后的代码缓存

对于每个加载的类型（类Class，接口Interface，枚举Enum，注解annotation）JVM必须在方法区中存储以下类型信息

域（Field）信息

方法信息

运行时常量池 VS 常量池

常量池

运行时常量池

jdk1.6及之前，有永久代，静态变量存放在永久代上。使用 JVM 虚拟机内存

jdk1.7，有永久代，但已经逐步去永久代，字符串常量池，静态变量移除，保存在堆中。使用 JVM 虚拟机内存

阿里：Java8的内存分代改进（问题同：为什么被替代）

jdk8，取消永久代，使用元空间实现方法区（保存类型信息，字段，方法，常量）     JVM内存-->本地内存。

永久代设置空间大小很难确定

存储在本地内存，仅受本地内存限制。

对永久代进行调优很困难

JDK7中将StringTable从运行时常量池移到堆空间。Full GC执行永久代的垃圾回收，永久代回收效率低。Full GC触发条件：老年代空间不足、永久代空间不足

开发中会有大量字符串被创建，回收效率低，导致永久代内存不足。

移动到堆，提高回收效率

JDK7及其以后版本的HotSpot虚拟机选择把静态变量与类型在Java语言一端的映射Class对象存放在一起，存储于Java堆之中

HotSpot对常量池的回收策略很明确，只要常量池中的常量没有被任何地方引用，就可以被回收

回收废弃常量与回收Java堆中对象非常类似

方法区内常量池中主要存放两大类常量：

不再使用的类型，需要同时满足三个条件

满足以上三个条件后，并不是和对象一样立即被回收，仅仅是被允许。

HotSpot虚拟机提供了-Xnoclassgc参数进行控制

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

new

Class的newInstance

Constructor的newInstance

使用clone

使用反序列化

第三方库Objenesis

1、判断对象对应的类是否被常量池加载

2、（类加载通过后）为对象分配内存

3、处理并发安全问题

4、初始化分配到的空间

5、设置对象的对象头

6、执行init方法进行初始化

包含两部分

说明：如果是数组，还需要记录数组的长度

对象的实例数据部分，是对象的真正存储的有效信息，即我们在程序代码中定义的各种类型的字段内容，无论是父类继承下来，还是子类中定义的字段都要记录下来。

1、这部分的存储顺序会受到虚拟机分配策略参数和字段在Java源码中定义顺序的影响。
2、分配策略参数-XX:FieldsAllocationStyle
3、HotSpot虚拟机默认的分配顺序为longs/doubles、ints、shorts/chars、bytes/booleans、oops（Ordinary Object Pointers）
4、从默认的分配策略中可以看出，相同宽度的字段总被分配到一起存放。
5、在满足这个前提条件的情况下，在父类中定义的变量会出现在子类之前。
6、如果HotSpot虚拟机的+XX：CompactFields参数值为true（默认也是true），那么子类中较窄的变量也允许插入父类变量的空隙之间，以节省空间。

仅起占位符作用

直接指针：指向对象，代表一个对象在内存中的起始地址。

句柄：可以理解为指向指针的指针，维护着对象的指针。句柄不直接指向对象，而是指向对象的指针（句柄不发生变化，指向固定内存地址），再由对象的指针指向对象的真实内存地址。

句柄池：Java堆，reference中存储：对象的句柄地址，句柄包含对象实例数据、对象类型数据

reference中存储：对象地址，如果访问对象本身，不需要多一次的间接访问的开销。

使用句柄最大好处：reference中存放稳定句柄地址，在对象被移动时（垃圾收集）只改变句柄中实例数据指针，reference本身不改变。

使用指针最大好处：速度快，节省了一次指针定位的时间开销，由于对象访问在Java中非常频繁，所以积少成多也是一项可观的执行成本。

1、执行引擎在执行的过程中究竟需要执行什么样的字节码指令完全依赖于PC寄存器。

2、每当执行完一项指令操作后，PC寄存器就会更新下一条需要被执行的指令地址

3、当然方法在执行的过程中，执行引擎有可能会通过存储在局部变量表中的对象引用准确定位到存储在Java堆区中的对象实例信息，以及通过对象头中的元数据指针定位到目标对象的类型信息

JVM在执行Java代码的时候，通常会将解释执行与编译执行二者结合起来进行

各种采用二进制编码方式表示的指令，叫做机器指令码。机器语言。机器指令与CPU紧密相关，不同种类的CPU所对应的机器指令也就不同

由于机器码由01组成，可读性太差。于是人们发明了指令

指令就是把机器码特定的0和1序列，简化成对应的指令，一般为英文编写如mov，inc等，可读性稍好

由于不同的硬件平台，执行同一个操作，对应的机器码可能不同。所以不同的硬件平台的同一种指令，对应的机器码也可能不同

不同硬件平台，各自支持的指令，是有差别的。因此每个平台所支持的指令，称之为对应平台的指令集

x86指令集，对应的x86架构的平台

ARM指令集，对应的是ARM架构的平台

由于指令的可读性太差，于是又有了汇编语言

汇编语言用助记符代替机器指令的操作码，用地址符号或标号，代替指令或操作数的地址。

汇编语言要翻译成机器指令码，计算机才能识别和执行

模板解释器将每一条字节码和一个模板函数相关联，模板函数直接产生这条字节码执行时的机器码，提高解释器的性能

Interpreter模块

Code模块

把.java文件转换为.class文件的过程

把字节码转为机器码的过程

Ahead of Time Compliler AOT，直接把.java文件编译器本地机器代码的过程

需要根据代码被调用执行的频率而定，需要被编译为本地代码的字节码，也称之为热点代码。

JIT编译器会在运行时针对频繁调用的热点代码做出深度优化，将其直接编译为对应平台的本地机器指令。以此提升Java程序的执行性能

一个被多次调用的方法，后者一个方法体内部循环次数较多的循环体，都可以被称之为热点代码

因此可以通过JIT编译器编译为本地机器指令，由于这种编译方法发生在方法的执行过程中，因此也被称之为栈上替换，OSR On Statck Replacement

一个方法调用都少次才能达到标准？这个依靠热点探测功能

client 

server

大多情况下简称C1,C2

-client：指定Java虚拟机在Client模式下，并使用C1编译器

-server：指定虚拟机在server模式下，并使用C2编译器

String s1 = "mogublog" ; // 字面量的定义方式，声明在字符串常量池

String s2 = new String("moxi"); // new 对象的方式

char数组每个字符占两个字节16位，String是堆空间的主要部分，大部分是拉丁字符，占一个字节，节省空间

String再也不用char[] 来存储，改成了byte [] 加上编码标记

StringBuffer，StringBuilder同样做了修改

当字符串重新赋值，需要重写指定内存区域赋值，不能使用原有的value进行赋值

当调用String的replace方法修改指定字符或字符串时，也需要重新指定内存区域赋值，不能使用原有的value进行赋值。

当对现有的字符串进行连接操作时，也需要重新指定内存区域赋值，不能对使用原有的value进行赋值

String的String Pool是一个固定大小的Hashtable，默认值大小长度是1009。如果放进String Pool的String非常多，就会造成Hash冲突严重，从而导致链表会很长，而链表长了后直接会造成的影响就是当调用String.intern()方法时性能会大幅下降。

使用-XX:StringTablesize可设置StringTable的长度

在JDK6中StringTable是固定的，就是1009的长度，所以如果常量池中的字符串过多就会导致效率下降很快，StringTablesize设置没有要求

在JDK7中，StringTable的长度默认值是60013，StringTablesize设置没有要求

在JDK8中，StringTable的长度默认值是60013，StringTable可以设置的最小值为1009

String的常量池比较特殊，主要使用方法有两种

调优时仅需调整堆大小就可以

永久代默认情况下比较小，大量字符串容易导致OOM。

永久代垃圾回收频率低

堆中空间足够大，字符串可被及时回收

+ ：字符串拼接底层

拼接10万次，+号4000，append用了7毫秒，原因是+号每次循环创建一个StringBuilder，还要通过toString创建一个String对象

内存中由于创建了较多的对象，内存占用更大，如果需要GC需要花费额外的时间

改进空间：StringBuilder默认是16长度的char型数组，不够的时候会扩容，可以一次建一个比较大长度的数组。

原因 ① StringBuilder的append()的方式： 自始至终中只创建过一个StringBuilder的对象；使用String的字符串拼接方式：创建过多个StringBuilder和String的对象

原因② 使用String的字符串拼接方式（+）： 内存中由于创建了较多的StringBuilder和String对象，内存占用更大； 如果进行GC，需要花费额外的时间。

改进的空间： 在实际开发中，如果基本确定要前前后后添加的字符串长度不高于某个限定值highLevel的情况下，建议使用构造器实例化

String s = new String("shkstart").intern();

String s = new StringBuilder("shkstart").toString().intern();

一个对象是：new关键字在堆空间创建的

另一个对象是：字符串常量池中的对象"ab"。 字节码指令：ldc

对象1，new StringBuilder()   （有拼接操作）

对象2，new String("a")

对象3，常量池中的"a"

对象4，new String("b")

对象5，常量池中的"b"

对象6，StringBuilder的toString()   new String("ab")

截图（一定要在main方法中测试，@test方式，第二个为false）

jdk1.6中，s.intern()   将这个字符串对象放入串池

jdk1.7起，s.intern()   将这个字符串对象尝试放入串池

案例1

直接 new String ：由于每个 String 对象都是 new 出来的，所以程序需要维护大量存放在堆空间中的 String 实例，程序内存占用也会变高

使用 intern() 方法：由于数组中字符串的引用都指向字符串常量池中的字符串，所以程序需要维护的 String 对象更少，内存占用也更低

对于程序中大量使用存在的字符串时，尤其存在很多已经重复的字符串时，使用intern()方法能够节省内存空间。

大的网站平台，需要内存中存储大量的字符串。比如社交网站，很多人都存储：北京市、海淀区等信息。这时候如果字符串都调用intern() 方法，就会很明显降低内存的大小。

堆存活数据集合里面String对象占了25%

堆存活数据集合里面重复的String对象有13.5%

String对象的平均长度是45

哪些内存需要回收？

什么时候回收？

如何回收？

无需手动分配回收内存，降低内存泄漏、内存溢出的风险

没有垃圾回收器，java也会和cpp一样，各种悬垂指针，野指针，泄露问题需要自己管理

自动内存管理机制，将程序员从繁重的内存管理中释放出来，可以更专注于业务开发

对于Java开发人员而言，自动内存管理就像是一个黑匣子，如果过度依赖于“自动”，那么这将会是一场灾难，最严重的就会弱化Java开发人员在程序出现内存溢出时定位问题和解决问题的能力。

此时，了解JVM的自动内存分配和内存回收原理就显得非常重要，只有在真正了解JVM是如何管理内存后，我们才能够在遇见OutofMemoryError时，快速地根据错误异常日志定位问题和解决问题。

当需要排查各种内存溢出、内存泄漏问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就必须对这些“自动化”的技术实施必要的监控和调节。

频繁收集年轻代

较少收集老年代

基本不收集永久代（元空间 matespace）

代码测试证明java不是使用的引用计数算法

结果：垃圾回收日志：Eden 区占用率为1% ，说明进行了垃圾回收（未用：引用计数）

根对象集合为起点，向下搜索直接或间接连接的对象为存活对象

无法建立连接，即不可达对象标记为可回收对象

虚拟机栈中引用的对象，比如：各个线程被调用的方法中使用到的参数、局部变量等。

本地方法栈内JNI（通常说的本地方法）引用的对象方法区中类静态属性引用的对象，比如：Java类的引用类型静态变量

方法区中常量引用的对象，比如：字符串常量池（StringTable）里的引用

所有被同步锁synchronized持有的对象

Java虚拟机内部的引用。

基本数据类型对应的Class对象，一些常驻的异常对象（如：NullPointerException、OutofMemoryError），系统类加载器。

反映java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。

总结一句话就是，除了堆空间外的一些结构，比如：虚拟机栈、本地方法栈、方法区、字符串常量池等地方对堆空间进行引用的，都可以作为GC Roots进行可达性分析

除了这些固定的GC Roots集合以外，根据用户所选用的垃圾收集器以及当前回收的内存区域不同，还可以有其他对象“临时性”地加入，共同构成完整GC Roots集合。比如：分代收集和局部回收（PartialGC）。

如果只针对Java堆中的某一块区域进行垃圾回收（比如：典型的只针对新生代），必须考虑到内存区域是虚拟机自己的实现细节，更不是孤立封闭的，这个区域的对象完全有可能被其他区域的对象所引用，这时候就需要一并将关联的区域对象也加入GC Roots集合中去考虑，才能保证可达性分析的准确性。

由于Root采用栈方式存放变量和指针，所以如果一个指针，它保存了堆内存里面的对象，但是自己又不存放在堆内存里面，那它就是一个Root。

如果要使用可达性分析算法来判断内存是否可回收，那么分析工作必须在一个能保障一致性的快照中进行。这点不满足的话分析结果的准确性就无法保证。

一致性-->准确性

这点也是导致GC进行时必须“Stop The World”的一个重要原因。即使是号称（几乎）不会发生停顿的CMS收集器中，枚举根节点时也是必须要停顿的。

枚举根节点停顿

Java语言提供了对象终止（finalization）机制来允许开发人员提供对象被销毁之前的自定义处理逻辑。

当垃圾回收器发现没有引用指向一个对象，即：垃圾回收此对象之前，总会先调用这个对象的finalize()方法。

finalize() 方法允许在子类中被重写，用于在对象被回收时进行资源释放。通常在这个方法中进行一些资源释放和清理的工作，比如关闭文件、套接字和数据库连接等。

永远不要主动调用某个对象的finalize()方法应该交给垃圾回收机制调用。理由包括三点

一个糟糕的finalize()会严重影响GC的性能。

从功能上来说，finalize()方法与C++中的析构函数比较相似，但是Java采用的是基于垃圾回收器的自动内存管理机制，所以finalize()方法在本质上不同于C++中的析构函数。

可触及：从根节点开始，可以到达这个对象。

可复活：对象的所有引用都被释放，但是对象有可能在finalize()中复活。

不可触及的：对象的finalize()被调用，并且没有复活，那么就会进入不可触及状态。不可触及的对象不可能被复活，因为finalize()只会被调用一次。

判定一个对象objA是否可回收，至少要经历两次标记过程

如果对象objA到GC Roots没有引用链，则进行第一次标记。

进行筛选，判断此对象是否有必要执行finalize()方法

finalize()方法是对象逃脱死亡的最后机会，稍后GC会对F-Queue队列中的对象进行第二次标记。如果objA在finalize()方法中与引用链上的任何一个对象建立了联系，那么在第二次标记时，objA会被移出“即将回收”集合。

之后，对象会再次出现没有引用存在的情况。在这个情况下，finalize()方法不会被再次调用，对象会直接变成不可触及的状态，注：一个对象的finalize()方法只会被调用一次。

当堆中的有效内存空间（available memory）被耗尽时，就会停止整个程序（stop the world），然后进行两项工作，标记、清除

把需要清除的对象地址保存在空闲地址列表里。下次有新对象需要加载时，判断垃圾的位置空间是否够，如果够，就存放并覆盖原有地址内容

如果内存规整

如果内存不规整

效率不高

在进行GC时，需要停止整个应用程序，用户体验差

空闲内存不连续，产生内碎片

需要维护一个空闲列表

没有标记和清除过程，实现简单，运行高效

复制过去以后保证空间的连续性，不会出现“碎片”问题。

需要两倍内存空间

对于G1这种分拆成大量region的GC，复制而不是移动，意味着GC需要维护region之间对象引用关系，内存占用、时间开销都很大

第一阶段和标记清除算法一样，从根节点开始标记所有被引用对象

第二阶段将所有的存活对象压缩到内存一端，按顺序排放。之后，清理边界外所有空间。

消除了标记-清除算法当中，内存区域分散的缺点，我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可。

消除了复制算法当中，内存减半的高额代价。

从效率上来说，标记-整理算法要低于复制算法。

移动对象的同时，如果对象被其他对象引用，则还需要调整引用的地址

移动过程中，需要全程暂停用户应用程序。即：STW

区域相对老年代较小，对象生命周期短、存活率低，回收频繁。

这种情况复制算法的回收整理，速度是最快的。复制算法的效率只和当前存活对象大小有关，因此很适用于年轻代的回收。而复制算法内存利用率不高的问题，通过hotspot中的两个survivor的设计得到缓解。

区域较大，对象生命周期长、存活率高，回收不及年轻代频繁。

这种情况存在大量存活率高的对象，复制算法明显变得不合适。一般是由标记-清除或者是标记-清除与标记-整理的混合实现。

如果一次性将所有的垃圾进行处理，需要造成系统长时间的停顿，那么就可以让垃圾收集线程和应用程序线程交替执行。每次，垃圾收集线程只收集一小片区域的内存空间，接着切换到应用程序线程。依次反复，直到垃圾收集完成。

总的来说，增量收集算法的基础仍是传统的标记-清除和复制算法。增量收集算法通过对线程间冲突的妥善处理，允许垃圾收集线程以分阶段的方式完成标记、清理或复制工作

使用这种方式，由于在垃圾回收过程中，间断性地还执行了应用程序代码，所以能减少系统的停顿时间。

但是，因为线程切换和上下文转换的消耗，会使得垃圾回收的总体成本上升，造成系统吞吐量的下降。

Java虚拟机的堆内存设置不够。

代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）

一般设置256M

长生命周期对象持有短生命周期对象的引用

左边的图：Java使用可达性分析算法，最上面的数据不可达，需要被回收。

右边的图：后期一些短生命周期对象不用，应断开引用，但长生命周期对象持有引用，导致短生命周期对象无法回收。

单例模式

一些提供close()的资源未关闭导致内存泄漏

分析工作必须在一个能确保一致性的快照中进行

一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上

如果出现分析过程中对象引用关系还在不断变化，则分析结果的准确性无法保证

STW事件和采用哪款GC无关，所有的GC都有这个事件。

哪怕是G1也不能完全避免Stop-the-world情况发生，只能说回收效率越来越高，尽可能地缩短了暂停时间。

STW是JVM在后台自动发起和自动完成的。在用户不可见的情况下，把用户正常的工作线程全部停掉。

开发中不要用System.gc() ，会导致Stop-the-World的发生。

在操作系统中，是指一个时间段中有几个程序都处于已启动运行到运行完毕之间，且这几个程序都是在同一个处理器上运行

并发不是真正意义上的“同时进行”，只是CPU把一个时间段划分成几个时间片段（时间区间），然后在这几个时间区间之间来回切换

由于CPU处理的速度非常快，只要时间间隔处理得当，即可让用户感觉是多个应用程序同时在进行

当系统有一个以上CPU时，当一个CPU执行一个进程时，另一个CPU可以执行另一个进程，两个进程互不抢占CPU资源，可以同时进行，我们称之为并行（Parallel）

决定并行的因素不是CPU的数量，而是CPU的核心数量，比如一个CPU多个核也可以并行

并发，指的是多个事情，在同一时间段内同时发生。

并行，指的是多个事情，在同一时间点上同时发生。

并发的多个任务之间是互相抢占资源的。并行的多个任务之间不互相抢占资源。

只有在多CPU或者一个CPU多核的情况中，才会发生并行。否则，看似同时发生的事情，其实都是并发执行的。

并行（Parallel）

串行（Serial）

垃圾回收的并发（Concurrent）

程序执行时并非在所有地方都能停顿下来开始GC，只有在特定的位置才能停顿下来开始GC，这些位置称为“安全点（Safepoint）”。

Safe Point的选择很重要，如果太少可能导致GC等待的时间太长，如果太频繁可能导致运行时的性能问题。

大部分指令执行时间都非常短暂，通常会根据“是否具有让程序长时间执行的特征”为标准。如：选择一些执行时间较长的指令作为Safe Point，如方法调用、循环跳转和异常跳转等。

如何在GC发生时，检查所有线程都跑到最近的安全点停顿下来呢？

主动式中断：设置一个中断标志，各个线程运行到Safe Point的时候主动轮询这个标志，如果中断标志为真，则将自己进行中断挂起。（有轮询的机制）

Safepoint 机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的Safepoint。但是，程序“不执行”的时候呢？

例如线程处于Sleep状态或Blocked 状态，这时候线程无法响应JVM的中断请求，“走”到安全点去中断挂起，JVM也不太可能等待线程被唤醒。

对于这种情况，就需要安全区域（Safe Region）来解决。

安全区域是指在一段代码片段中，对象的引用关系不会发生变化，在这个区域中的任何位置开始GC都是安全的。我们也可以把Safe Region看做是被扩展了的Safepoint。

当线程运行到Safe Region的代码时，首先标识已经进入了Safe Region，如果这段时间内发生GC，JVM会忽略标识为Safe Region状态的线程

当线程即将离开Safe Region时，会检查JVM是否已经完成GC，如果完成了，则继续运行，否则线程必须等待直到收到可以安全离开Safe Region的信号为止；

强引用（StrongReference）：发生 gc 的时候不会被回收

软引用（SoftReference）：内存不足即回收

弱引用（WeakReference）：发现即回收

虚引用（PhantomReference）：对象回收跟踪

终结器引用

串行回收指的是在同一时间段内只允许有一个CPU用于执行垃圾回收操作，此时工作线程被暂停，直至垃圾收集工作结束。

并行收集可以运用多个CPU同时执行垃圾回收，因此提升了应用的吞吐量，不过并行回收仍然与串行回收一样，采用独占式，使用了“Stop-the-World”机制。

适用场景

并发式垃圾回收器与应用程序线程交替工作，以尽可能减少应用程序的停顿时间

独占式垃圾回收器（Stop the World）一旦运行，就停止应用程序中的所有用户线程，直到垃圾回收过程完全结束

压缩式垃圾回收器会在回收完成后，对存活对象进行压缩整理，消除回收后的碎片，分配对象空间使用指针碰撞

非压缩式的垃圾回收器不进行这步操作，分配对象空间使用空闲列表

虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%

吞吐量优先，意味着在单位时间内，STW的时间最短

高吞吐量较好因为这会让应用程序的最终用户感觉只有应用程序线程在做“生产性”工作。直觉上，吞吐量越高程序运行越快

因为如果选择以吞吐量优先，那么必然需要降低内存回收的执行频率，但是这样会导致GC需要更长的暂停时间来执行内存回收。

若吞吐量低，50%用于执行程序，50%用于垃圾回收，程序执行会很久

GC期间100毫秒的暂停时间意味着在这100毫秒期间内没有应用程序线程是活动的

暂停时间优先，意味着尽可能让单次STW的时间最短

低暂停时间（低延迟）较好，因为从最终用户的角度来看，不管是GC还是其他原因导致一个应用被挂起始终是不好的。这取决于应用程序的类型，有时候甚至短暂的200毫秒暂停都可能打断终端用户体验。因此，具有较低的暂停时间是非常重要的，特别是对于一个交互式应用程序。

如果选择以低延迟优先为原则，那么为了降低每次执行内存回收时的暂停时间，也只能频繁地执行内存回收，但这又引起了年轻代内存的缩减和导致程序吞吐量的下降。

针对不同的场景，提供不同的垃圾收集器，提高垃圾收集的性能。

-XX:+PrintCommandLineFlags：查看命令行相关参数（包含使用的垃圾收集器）

使用命令行指令：jinfo -flag 相关垃圾回收器参数 进程ID

Server模式下

与新生代的Parallel Scavenge配合使用

作为老年代CMS收集器的后备垃圾收集方案

它只会使用一个CPU或一条收集线程去完成垃圾收集工作

在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束（STW）

ParNew收集器运行在多CPU的环境下，可以充分利用多CPU、多核心等物理硬件资源优势，可以更快速地完成垃圾收集，提升程序的吞吐量。

单CPU：Serial GC

-XX:+UseParNewGC：指定使用ParNew收集器执行内存回收任务。它表示年轻代使用并行收集器，不影响老年代

-XX:ParallelGCThreads：限制线程数量，默认开启和CPU相同线程数

Parallel Scavenge收集器的目标：达到一个可控制的吞吐量

自适应调节策略

高吞吐量可以高效率利用CPU时间，尽快完成程序的运算任务，主要适用于后台运算而不需要太多交互任务。因此，常见在服务器环境中使用。例如，执行批量处理、订单处理、工资支付、科学计算的应用程序。

-XX:+UseParallelGC ：指定年轻代使用Parallel并行收集器执行内存回收任务

-XX:+UseParallelOldGC：指定老年代使用并行回收收集器

默认jdk8开启。默认开启一个，另一个也会被开启。（互相激活）

-XX:ParallelGCThreads：设置年轻代并行收集器的线程数

-XX:MaxGCPauseMillis：设置垃圾收集器最大停顿时间（即STW的时间）单位：毫秒

-XX:GCTimeRatio：垃圾收集时间占总时间的比例，用于衡量吞吐量的大小

-XX:+UseAdaptiveSizePolicy ：设置Parallel Scavenge收集器具有自适应调节策略

初始标记（Initial-Mark）阶段：STW

并发标记（Concurrent-Mark）阶段

重新标记（Remark）阶段：STW

并发清除（Concurrent-Sweep）阶段

最耗时：并发标记、并发清除阶段都不需要暂停工作，所以整体的回收是低停顿的

由于在垃圾收集阶段用户线程没有中断，所以在CMS回收过程中，还应该确保应用程序用户线程有足够的内存可用-->堆内存使用率达到某一阈值时，便开始进行回收

CMS运行期间预留的内存无法满足程序需求：出现“Concurrent Mode Failure”失败，这时虚拟机将启动后备预案：临时启用Serial old收集器来重新进行老年代的垃圾收集，这样停顿时间更长

并发清除阶段：标记-清除算法、内存碎片、×指针碰撞技术、空闲列表执行内存分配

未用标签-压缩算法原因：

缺点总结

-XX:+UseConcMarkSweepGC：手动指定使用CMS收集器执行内存回收任务。

-XX:CMSInitiatingOccupanyFraction：设置堆内存使用率的阈值，一旦达到该阈值，便开始进行回收。

-XX:+UseCMSCompactAtFullCollection：用于指定在执行完Full GC后对内存空间进行压缩整理，以此避免内存碎片的产生。不过由于内存压缩整理过程无法并发执行，所带来的问题就是停顿时间变得更长了。

-XX:CMSFullGCsBeforeCompaction：设置执行多少次Full GC后对内存空间进行压缩整理

-XX:ParallelCMSThreads：设置CMS的线程数

CPU核数少，适用于客户端

吞吐量高，垃圾回收的延迟更高

低延迟，吞吐量不高，垃圾回收线程在并发执行

区分年轻代和老年代，年轻代依然有Eden区和Survivor区

但从堆的结构上看，它不要求整个Eden区、年轻代或者老年代都是物理连续的，也不再坚持固定大小和固定数量。

设定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。

G1可以只选取部分区域进行内存回收，这样缩小了回收的范围，因此对于全局停顿情况的发生也能得到较好的控制。

G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。保证了G1收集器在有限的时间内可以获取尽可能高的收集效率

用户程序运行过程中，G1无论是为了垃圾收集产生的内存占用（Footprint）还是程序运行时的额外执行负载（overload）都要比CMS要高。

从经验上来说，在小内存应用上CMS的表现大概率会优于G1，而G1在大内存应用上则发挥其优势。平衡点在6-8GB之间。

-XX:+UseG1GC：手动指定使用G1垃圾收集器执行内存回收任务

-XX:G1HeapRegionSize：设置每个Region的大小

-XX:MaxGCPauseMillis：设置期望达到的最大GC停顿时间指标，默认值：200ms

-XX:+ParallelGCThread：设置STW工作线程数。最多设置为8

-XX:ConcGCThreads：设置并发标记的线程数

-XX:InitiatingHeapOccupancyPercent：设置触发并发GC周期的Java堆占用率阈值

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

第一步：开启G1垃圾收集器

第二步：设置堆的最大内存

第三步：设置最大的停顿时间

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

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

用来替换掉JDK1.5中的CMS收集器；在下面的情况时，使用G1可能比CMS好

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的动态分配方式实现逻辑上的连续。

一个Region有可能属于Eden，Survivor或者Old/Tenured内存区域。但是一个Region只可能属于一个角色。图中的E表示该Region属于Eden内存区域，S表示属于Survivor内存区域，O表示属于Old内存区域。图中空白的表示未使用的内存空间。

G1垃圾收集器还增加了一种新的内存区域，叫做Humongous内存区域，如图中的H块。主要用于存储大对象，如果超过0.5个Region，就放到H。

Region的内部结构

G1 GC的垃圾回收过程主要包括如下三个环节

年轻代GC（Young GC）

老年代并发标记过程（Concurrent Marking）

混合回收过程（Mixed GC）

（如果需要，单线程、独占式、高强度的Full GC还是继续存在的。它针对GC的评估失败提供了一种失败保护机制，即强力回收。）

顺时针，Young GC --> Young GC+Concurrent Marking --> Mixed GC，进行垃圾回收

大致的回收流程

G1 回收器垃圾回收过程：Remembered Set（记忆集）

总结

G1 的注意事项

采用：复制算法，优点：效率高，缺点：内存利用率低（to区永远是空）；适用生命周期短的对象收集

采用：标记-清除-压缩算法

优先调整堆的大小让JVM自适应完成

如果内存小于100M，使用串行收集器

如果是单核、单机程序，并且没有停顿时间的要求，串行收集器

如果是多CPU、需要高吞吐量、允许停顿时间超过1秒，选择并行或者JVM自己选择

如果是多CPU、追求低停顿时间，需快速响应（比如延迟不能超过1秒，如互联网应用），使用并发收集器

官方推荐G1，性能高。现在互联网的项目，基本都是使用G1

-XX:+PrintGC ：输出GC日志，类似：-verbose:gc

-XX:+PrintGCDetails ：输出GC的详细日志

-XX:+PrintGCTimestamps ：输出GC的时间戳（以基准时间的形式）

-XX:+PrintGCDatestamps ：输出GC的时间戳

-XX:+PrintHeapAtGC ：在进行GC的前后打印出堆的信息

-XLoggc:./Logs/gc.Log：日志文件的输出路径

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

使用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)

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

GCViewer

GCEasy

垃圾收集的算法有哪些？

如何判断一个对象是否可以回收？

垃圾收集器工作的基本流程

垃圾回收器各种常用参数