深入了解J.V.M

线程私有
1.程序计数器
记录正在执行的虚拟机字节码指令的地址（如果正在执行的是本地方法则为空。
2.java虚拟机栈
虚拟机栈描述的是Java方法执行的内存模型 : 每个方法执行的同时都会创建一个栈帧用于存储局部变量表、操作数
栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程，就对应一个栈帧在虚拟机栈中入栈和出栈
的过程。声明周期与线程相同。
之前我们一直讲的栈区域实际上就是此处的虚拟机栈，再详细一点，是虚拟机栈中的局部变量表部分。
局部变量表 : 存放了编译器可知的各种基本数据类型(8大基本数据类型)、对象引用。局部变量表所需的内存空间在编
译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在执行期间不会
改变局部变量表大小。
此区域一共会产生以下两种异常:

1. 如果线程请求的栈深度大于虚拟机所允许的深度(-Xss设置栈容量)，将会抛出StackOverFlowError异常。
2. 虚拟机在动态扩展时无法申请到足够的内存，会抛出OOM(OutOfMemoryError)异常
   3.本地方法栈
   本地方法栈与虚拟机栈的作用完全一样，他俩的区别无非是本地方法栈为虚拟机使用的Native方法服务，而虚拟机栈
   为JVM执行的Java方法服务。
   在HotSpot虚拟机中，本地方法栈与虚拟机栈是同一块内存区域。

线程共享
1.堆
Java堆(Java Heap)是JVM所管理的最大内存区域。Java堆是所线程共享的一块区域，在JVM启动时创建。此内存区
域存放的都是对象实例。JVM规范中说到:“所的对象实例以及数组都要在堆上分配”。
Java堆是垃圾回收器管理的主要区域，因此很多时候可以称之为"GC堆"。根据JVM规范规定的内容，Java堆可以处于
物理上不连续的内存空间中。Java堆在主流的虚拟机中都是可扩展的(-Xmx设置最大值,-Xms设置最小值)。
如果在堆中没足够的内存完成实例分配并且堆也无法再拓展时，将会抛出OOM
现代的垃圾收集器基本都是采用分代收集算法，其主要的思想是针对不同类型的对象采取不同的垃圾回收算法。可以将堆分成两块：
新生代（Young Generation）
老年代（Old Generation）
堆不需要连续内存，并且可以动态增加其内存，增加失败会抛出 OutOfMemoryError 异常。
可以通过 -Xms 和 -Xmx 这两个虚拟机参数来指定一个程序的堆内存大小，第一个参数设置初始值，第二个参数设置最大值。
java -Xms1M -Xmx2M HackTheJava
2.方法区
方法区与Java堆一样，是各个线程共享的内存区域。它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编
译器编译后的代码等数据。在JDK8以前的HotSpot虚拟机中，方法区也被称为"永久代"(JDK8已经被元空间取代它位于本地内存中，而不是虚拟机内存中。)。 原来永久代的数据被分到了堆和元空间中。元空间存储类的元信息，静态变量和常量池等放入堆中。
永久代并不意味着数据进入方法区就永久存在，此区域的内存回收主要是针对常量池的回收以及对类型的卸载。
JVM规范规定：当方法区无法满足内存分配需求时，将抛出OOM(OutOfMemoryError)异常
3.运行时常量池(方法区的一部分)
运行时常量池是方法区的一部分，存放字面量与符号引用。
字面量 : 字符串(JDK1.7后移动到堆中) 、fifinal常量、基本数据类型的值。
符号引用 : 类和结构的完全限定名、字段的名称和描述符、方法的名称和描述符
4.直接内存
在 JDK 1.4 中新引入了 NIO 类，它可以使用 Native 函数库直接分配堆外内存，然后通过 Java 堆里的 DirectByteBuffer 对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在堆内存和堆外内存来回拷贝数据。
判断线程已死
1.引用计数法：给对象增加一个引用计数器，每当有一个地方引用它时，计数器就+1；当引用失效时，计数器就-1；任何时刻计数器
为0的对象就是不能再被使用的，即对象已"死"。

public class Test { 
public Object instance = null; 
public static void testGC() { 
Test test1 = new Test(); 
Test test2 = new Test(); 
test1.instance = test2; 
test2.instance = test1; 
test1 = null; 
test2 = null;
}
}

在主流的JVM中没用引用计数法来管理内存，最主要的原因就是引用计数法无法解决对象的循环引用问题
2. 可达性分析算法
以 GC Roots 为起始点进行搜索，可达的对象都是存活的，不可达的对象可被回收。
Java 虚拟机使用该算法来判断对象是否可被回收，GC Roots 一般包含以下内容：
**

虚拟机栈中局部变量表中引用的对象
本地方法栈中 JNI 中引用的对象
方法区中类静态属性引用的对象
方法区中的常量引用的对象**

引用类型
无论是通过引用计数算法判断对象的引用数量，还是通过可达性分析算法判断对象是否可达，判定对象是否可被回收都与引用关。
我们希望能描述这一类对象 : 当内存空间还足够时，则能保存在内存中；如果内存空间在进行垃圾回收后还是非常紧
张，则可以抛弃这些对象。很多系统中的缓存对象都符合这样的场景。
Java 提供了四种强度不同的引用类型。
1. 强引用
被强引用关联的对象不会被回收。
使用 new 一个新对象的方式来创建强引用。

Object obj = new Object();

2. 软引用
被软引用关联的对象只在内存不够的情况下才会被回收。
使用 SoftReference 类来创建软引用。

Object obj = new Object();
SoftReference<Object> sf = new SoftReference<Object>(obj);
obj = null;  // 使对象只被软引用关联

3. 弱引用
被弱引用关联的对象一定会被回收，也就是说它只能存活到下一次垃圾回收发生之前。
使用 WeakReference 类来创建弱引用。

Object obj = new Object();
WeakReference<Object> wf = new WeakReference<Object>(obj);
obj = null;

4. 虚引用
又称为幽灵引用或者幻影引用，一个对象是否有虚引用的存在，不会对其生存时间造成影响，也无法通过虚引用得到一个对象。
为一个对象设置虚引用的唯一目的是能在这个对象被回收时收到一个系统通知。
使用 PhantomReference 来创建虚引用。

Object obj = new Object();
PhantomReference<Object> pf = new PhantomReference<Object>(obj, null);
obj = null;

对象的自我拯救
即使在可达性分析算法中不可达的对象，也并非"非死不可"的，这时候他们暂时处在"缓刑"阶段。要宣告一个对象的 真正死亡，至少要经历两次标记过程 : 如果对象在进行可达性分析之后发现没与GC Roots相连接的引用链，那它将 会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行fifinalize()方法。当对象没覆盖fifinalize()方 法或者fifinalize()方法已经被JVM调用过，虚拟机会将这两种情况都视为"没必要执行"，此时的对象才是真正"死"的 对象。 如果这个对象被判定为必要执行fifinalize()方法，那么这个对象将会被放置在一个叫做F-Queue的队列之中，并在稍 后由一个虚拟机自动建立的、低优先级的Finalizer线程去执行它（这里所说的执行指的是虚拟机会触发fifinalize()方 法。fifinalize()方法是对象逃脱死亡的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模标记，如果 对象在fifinalize()中成功拯救自己(只需要重新与引用链上的任何一个对象建立起关联关系即可)，那在第二次标记时它 将会被移除出"即将回收"的集合；如果对象这时候还是没逃脱，那基本上它就是真的被回收了。 范例:对象自我拯救 从上面代码示例我们发现，fifinalize方法确实被JVM触发，并且对象在被收集前成功逃脱。 但是从结果上我们发现，两个完全一样的代码片段，结果是一次逃脱成功，一次失败。这是因为，任何一个对象的 fifinalize()方法都只会被系统自动调用一次，如果相同的对象在逃脱一次后又面临一次回收，它的fifinalize()方法不会 被再次执行，因此第二段代码的自救行动失败。

public class Test { 
public static Test test; 
public void isAlive() { 
System.out.println("I am alive :)"); 
} 
@Override 
protected void finalize() throws Throwable { 
super.finalize(); 
System.out.println("finalize method executed!"); 
test = this; 
} 
public static void main(String[] args)throws Exception { 
test = new Test(); 
test = null; 
System.gc(); 
Thread.sleep(500); 
if (test != null) { 
test.isAlive(); 
}else { 
System.out.println("no,I am dead :("); 
} 
// 下面代码与上面完全一致，但是此次自救失败 
test = null; 
System.gc(); 
Thread.sleep(500); 
if (test != null) { 
test.isAlive(); 
}else { 
System.out.println("no,I am dead :("); 
} 
} 

}
从上面代码示例我们发现，fifinalize方法确实被JVM触发，并且对象在被收集前成功逃脱。
但是从结果上我们发现，两个完全一样的代码片段，结果是一次逃脱成功，一次失败。这是因为，任何一个对象的
fifinalize()方法都只会被系统自动调用一次，如果相同的对象在逃脱一次后又面临一次回收，它的fifinalize()方法不会
被再次执行，因此第二段代码的自救行动失败。

垃圾回收算法

2. 标记 - 整理（老年代回收算法）

让所存活的对象都向一端移动，然后直接清理掉端边界以外的内存。
优点:
不会产生内存碎片
不足:
需要移动大量对象，处理效率比较低。
3. 复制算法（新生代回收算法）

将内存划分为大小相等的两块，每次只使用其中一块，当这一块内存用完了就将还存活的对象复制到另一块上面，然后再把使用过的内存空间进行一次清理。
主要不足是只使用了内存的一半。
新生代中98%的对象都是"朝生夕死"的，所以并不需要按照1 : 1的比例来划分内存空间，而是将内存(新生代内存)分 为一块较大的Eden(伊甸园)空间和两块较小的Survivor(幸存者)空间，每次使用Eden和其中一块Survivor（两个 Survivor区域一个称为From区，另一个称为To区域。当回收时，将Eden和Survivor中还存活的对象一次性复制到 另一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。
当Survivor空间不够用时，需要依赖其他内存(老年代)进行分配担保。
HotSpot默认Eden与Survivor的大小比例是8 : 1，也就是说Eden:Survivor From : Survivor To = 8:1:1。所以每次新 生代可用内存空间为整个新生代容量的90%,而剩下的10%用来存放回收后存活的对象。
HotSpot实现的复制算法流程如下:

1. 当Eden区满的时候,会触发第一次Minor gc,把还活着的对象拷贝到Survivor From区；当Eden区再次触发
   Minor gc的时候,会扫描Eden区和From区域,对两个区域进行垃圾回收,经过这次回收后还存活的对象,则直
   接复制到To区域,并将Eden和From区域清空。
2. 当后续Eden又发生Minor gc的时候,会对Eden和To区域进行垃圾回收,存活的对象复制到From区域,并将
   Eden和To区域清空。
3. 部分对象会在From和To区域中复制来复制去,如此交换15次(由JVM参数MaxTenuringThreshold决定,这个
   参数默认是15),最终如果还是存活,就存入到老年代
4. 分代收集
   现在的商业虚拟机采用分代收集算法，它根据对象存活周期将内存划分为几块，不同块采用适当的收集算法。
   一般将堆分为新生代和老年代。
   新生代使用：复制算法
   老年代使用：标记 - 清除 或者 标记 - 整理 算法

面试题 : 请问了解Minor GC和Full GC么，这两种GC什么不一样吗 ？

1. Minor GC又称为新生代GC : 指的是发生在新生代的垃圾收集。因为Java对象大多都具备朝生夕灭的特 性，因此Minor GC(采用复制算法)非常频繁，一般回收速度也比较快。
2. Full GC 又称为 老年代GC或者Major GC : 指发生在老年代的垃圾收集。出现了Major GC，经常会伴随至 少一次的Minor GC(并非绝对，在Parallel Scavenge收集器中就直接进行Full GC的策略择过程)。 Major GC的速度一般会比Minor GC慢10倍以上。

垃圾回收器

上图展示了7种作用于不同分代的收集器，如果两个收集器之间存在连线，就说明他们之间可以搭配使用。所处的区域，表示它是属于新生代收集器还是老年代收集器。在讲具体的收集器之前我们先来明确个概念:
**单线程与多线程：**单线程指的是垃圾收集器只使用一个线程，而多线程使用多个线程；
并行(Parallel) : 指多条垃圾收集线程并行工作，用户线程仍处于等待状态
**串行：**串行指的是垃圾收集器与用户程序交替执行，这意味着在执行垃圾收集的时候需要停顿用户程序；
并发(Concurrent) : 指用户线程与垃圾收集线程同时执行(不一定并行，可能会交替执行)，用户程序继续运行，
而垃圾收集程序在另外一个CPU上。
**吞吐量:**就是CPU用于运行用户代码的时间与CPU总消耗时间的比值。
吞 吐 量 运 行 用 户 代 码 时 间 运 行 用 户 代 码 时 间 垃 圾 收 集 时 间
例如：虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。
除了 CMS 和 G1 之外，其它垃圾收集器都是以串行的方式执行。
1. Serial 收集器

Serial 翻译为串行，也就是说它以串行的方式执行。
它是单线程的收集器，只会使用一个线程进行垃圾收集工作。
它的优点是简单高效，在单个 CPU 环境下，由于没有线程交互的开销，因此拥有最高的单线程收集效率。
它是 Client 场景下的默认新生代收集器，因为在该场景下内存一般来说不会很大。它收集一两百兆垃圾的停顿时间可以控制在一百多毫秒以内，只要不是太频繁，这点停顿时间是可以接受的。
2. ParNew 收集器

它是 Serial 收集器的多线程版本。
它是 Server 场景下默认的新生代收集器，除了性能原因外，主要是因为除了 Serial 收集器，只有它能与 CMS 收集器配合使用。

3. Parallel Scavenge 收集器
与 ParNew 一样是多线程收集器。
其它收集器目标是尽可能缩短垃圾收集时用户线程的停顿时间，而它的目标是达到一个可控制的吞吐量，因此它被称为“吞吐量优先”收集器。
停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验。而高吞吐量则可以高效率地利用 CPU 时间，尽快完成程序的运算任务，适合在后台运算而不需要太多交互的任务。
缩短停顿时间是以牺牲吞吐量和新生代空间来换取的：新生代空间变小，垃圾回收变得频繁，导致吞吐量下降。比如原来10秒收集一次，每次停顿100毫秒，现在变成5秒收集一次，每次停顿70毫秒。停顿时间下
降的同时，吞吐量也下降了，可以通过一个开关参数打开 GC 自适应的调节策略（GC Ergonomics）（与ParNew最重要区别），就不需要手工指定新生代的大小（-Xmn）、Eden 和 Survivor 区的比例、晋升老年代对象年龄等细节参数了。虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量。
Parallel Scavenge收集器 VS CMS等收集器： Parallel Scavenge收集器的特点是它的关注点与其他收集 器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput。 由于与吞吐量关系密切，Parallel Scavenge 收集器也经常称为“吞吐量优先”收集器。
4. Serial Old 收集器

是 Serial 收集器的老年代版本，也是给 Client 场景下的虚拟机使用。如果用在 Server 场景下，它有两大用途：
在 JDK 1.5 以及之前版本（Parallel Old 诞生以前）中与 Parallel Scavenge 收集器搭配使用。
作为 CMS 收集器的后备预案，在并发收集发生 Concurrent Mode Failure 时使用。

5. Parallel Old 收集器

是 Parallel Scavenge 收集器的老年代版本。
在注重吞吐量以及 CPU 资源敏感的场合，都可以优先考虑 Parallel Scavenge 加 Parallel Old 收集器。

6. CMS 收集器
   
   CMS（Concurrent Mark Sweep），Mark Sweep 指的是标记 - 清除算法。
   分为以下四个流程：
   **初始标记：**仅仅只是标记一下 GC Roots 能直接关联到的对象，速度很快，需要停顿。
   **并发标记：**进行 GC Roots Tracing 的过程，它在整个回收过程中耗时最长，不需要停顿。
   **重新标记：**为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，需要停顿。
   **并发清除：**不需要停顿。
   在整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，不需要进行停顿。
   具以下缺点：
   吞吐量低：低停顿时间是以牺牲吞吐量为代价的，导致 CPU 利用率不够高。
   无法处理浮动垃圾：可能出现 Concurrent Mode Failure。浮动垃圾是指并发清除阶段由于用户线程继续运行而产生的垃圾，这部分垃圾只能到下一次 GC 时才能进行回收。由于浮动垃圾的存在，因此需要预留出一部分内存，意味着 CMS 收集不能像其它收集器那样等待老年代快满的时候再回收。如果预留的内存不够存放浮动垃圾，就会出现 Concurrent Mode Failure，这时虚拟机将临时启用 Serial Old 来替代 CMS。
   标记 - 清除算法导致的空间碎片，往往出现老年代空间剩余，但无法找到足够大连续空间来分配当前对象，不得不提前触发一次 Full GC。
   7.G1收集器(唯一一款全区域的垃圾回收器)
   G1（Garbage First垃圾回收器是用在heap memory很大的情况下，把heap划分为很多很多的region块，然后并 行的对其进行垃圾回收。
   G1垃圾回收器在清除实例所占用的内存空间后，还会做内存压缩。
   G1垃圾回收器回收region的时候基本不会STW，而是基于 most garbage优先回收(整体来看是基于"标记-整理"算法，从局部(两个region之间)基于"复制"算法) 的策略来对region进行垃圾回收的。无论如何，G1收集器采用的算法都意味着一个region可能属于Eden，Survivor或者Tenured内存区域。图中的E表示该region属于Eden内存区域，S表示属 于Survivor内存区域，T表示属于Tenured内存区域。图中空白的表示未使用的内存空间。G1垃圾收集器还增加了一 种新的内存区域，叫做Humongous内存区域，如图中的H块。这种内存区域主要用于存储大对象-即大小超过一个region大小的50%的对象。
   
   年轻代垃圾收集
   在G1垃圾收集器中，年轻代的垃圾回收过程使用复制算法。把Eden区和Survivor区的对象复制到新的Survivor区域。
   
   老年代垃收集
   对于老年代上的垃圾收集，G1垃圾收集器也分为4个阶段，基本跟CMS垃圾收集器一样，但略有不同：
   初始标记(Initial Mark)阶段 - 同CMS垃圾收集器的Initial Mark阶段一样，G1也需要暂停应用程序的执
   行，它会标记从根对象出发，在根对象的第一层孩子节点中标记所有可达的对象。但是G1的垃圾收集器
   的Initial Mark阶段是跟minor gc一同发生的。也就是说，在G1中，你不用像在CMS那样，单独暂停应用
   程序的执行来运行Initial Mark阶段，而是在G1触发minor gc的时候一并将年老代上的Initial Mark给做了。
   并发标记(Concurrent Mark)阶段 - 在这个阶段G1做的事情跟CMS一样。但G1同时还多做了一件事情，就是如果在Concurrent Mark阶段中，发现哪些Tenured region中对象的存活率很小或者基本没对象存活，那么G1就会在这个阶段将其回收掉，而不用等到后面的clean up阶段。这也是Garbage First名字的由来。同时,在该阶段，G1会计算每个 region的对象存活率，方便后面的clean up阶段使用 。
   最终标记(CMS中的Remark阶段) - 在这个阶段G1做的事情跟CMS一样, 但是采用的算法不同，G1采用一种叫做SATB(snapshot-at-the-begining)的算法能够在Remark阶段更快的标记可达对象。
   筛选回收(Clean up/Copy)阶段 - 在G1中，没CMS中对应的Sweep阶段。相反 它有一个Clean up/Copy阶段，在这个阶段中,G1会挑出那些对象存活率低的region进行回收，这个阶段也是和minor gc一同发
   生的,如下图所示：
   
   G1（Garbage-First是一款面向服务端应用的垃圾收集器。HotSpot开发团队赋予它的使命是未来可以替换掉JDK1.5中发布的CMS收集器。 如果你的应用追求低停顿，G1可以作为择；如果你的应用追求吞吐量，G1并不带来特别明显的好处。

内存分配与回收策略

Minor GC 和 Full GC
Minor GC：回收新生代，因为新生代对象存活时间很短，因此 Minor GC 会频繁执行，执行的速度一般也会比较快。
Full GC：回收老年代和新生代，老年代对象其存活时间长，因此 Full GC 很少执行，执行速度会比 Minor GC 慢很多。
内存分配策略

1. 对象优先在 Eden 分配
   大多数情况下，对象在新生代 Eden 上分配，当 Eden 空间不够时，发起 Minor GC。
2. 大对象直接进入老年代
   大对象是指需要连续内存空间的对象，最典型的大对象是那种很长的字符串以及数组。
   经常出现大对象会提前触发垃圾收集以获取足够的连续空间分配给大对象。
   -XX:PretenureSizeThreshold，大于此值的对象直接在老年代分配，避免在 Eden 和 Survivor 之间的大量内存复制。
3. 长期存活的对象进入老年代
   为对象定义年龄计数器，对象在 Eden 出生并经过 Minor GC 依然存活，将移动到 Survivor 中，年龄就增加 1 岁，增加到一定年龄则移动到老年代中。
   -XX:MaxTenuringThreshold 用来定义年龄的阈值。
4. 动态对象年龄判定
   虚拟机并不是永远要求对象的年龄必须达到 MaxTenuringThreshold 才能晋升老年代，如果在 Survivor 中相同年龄所有对象大小的总和大于 Survivor 空间的一半，则年龄大于或等于该年龄的对象可以直接进入老年代，无需等到 MaxTenuringThreshold 中要求的年龄。
5. 空间分配担保
   在发生 Minor GC 之前，虚拟机先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果条件成立的话，那么 Minor GC 可以确认是安全的。
   如果不成立的话虚拟机会查看 HandlePromotionFailure 的值是否允许担保失败，如果允许那么就会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次 Minor GC；如果小于，或者 HandlePromotionFailure 的值不允许冒险，那么就要进行一次 Full GC。
   Full GC 的触发条件
   对于 Minor GC，其触发条件非常简单，当 Eden 空间满时，就将触发一次 Minor GC。而 Full GC 则相对复杂，有以下条件：
6. 调用 System.gc()
   只是建议虚拟机执行 Full GC，但是虚拟机不一定真正去执行。不建议使用这种方式，而是让虚拟机管理内存。
7. 老年代空间不足
   老年代空间不足的常见场景为前文所讲的大对象直接进入老年代、长期存活的对象进入老年代等。
   为了避免以上原因引起的 Full GC，应当尽量不要创建过大的对象以及数组。除此之外，可以通过 -Xmn 虚拟机参数调大新生代的大小，让对象尽量在新生代被回收掉，不进入老年代。还可以通过 -XX:MaxTenuringThreshold 调大对象进入老年代的年龄，让对象在新生代多存活一段时间。
8. 空间分配担保失败
   使用复制算法的 Minor GC 需要老年代的内存空间作担保，如果担保失败会执行一次 Full GC。
9. JDK 1.7 及以前的永久代空间不足
   在 JDK 1.7 及以前，HotSpot 虚拟机中的方法区是用永久代实现的，永久代中存放的为一些 Class 的信息、常量、静态变量等数据。
   当系统中要加载的类、反射的类和调用的方法较多时，永久代可能会被占满，在未配置为采用 CMS GC 的情况下也会执行 Full GC。如果经过 Full GC 仍然回收不了，那么虚拟机会抛出 java.lang.OutOfMemoryError。
   为避免以上原因引起的 Full GC，可采用的方法为增大永久代空间或转为使用 CMS GC。
10. Concurrent Mode Failure
    执行 CMS GC 的过程中同时有对象要放入老年代，而此时老年代空间不足（可能是 GC 过程中浮动垃圾过多导致暂时性的空间不足），便会报 Concurrent Mode Failure 错误，并触发 Full GC。

**

jps : 虚拟机进程状态工具

**
jps是使用频率最高的JDK命令行工具，它可以列出正在运行的虚拟机进程，并显示虚拟机执行主类(main函数所在的
类)名称以及这些进程的本地虚拟机唯一ID(Local Virtual Machine Identififier,LVMID)。


jmap：生成jvm内存快照
jstack：生成当前jvm的线程快照