1.垃圾收集的经典问题

• 1.哪些内存需要回收
• 2.什么时候回收
• 3.如何回收
• 1.你知道哪几种垃圾回收器，各自的优缺点，重点讲一下cms和g1
• 2.JVM GC算法有哪些，目前的JDK版本采用什么回收算法
• 3.G1回收器的回收过程

1.Java中垃圾的定义（Garbage）

• 1.垃圾是指在运行程序中没有任何指针指向的对象，这个对象就是需要被回收的垃圾

1.垃圾的危害

• 1.如果不及时对内存中的垃圾进行清理，那么这些垃圾对象所占的内存空间会一直保留到应用程序结束，被保留的空间无法被其他对象使用，甚至可能导致内存溢出

2.磁盘碎片整理

• 1.机械硬盘：需要碎片整理，通过改变磁极，用于表示0，1，机械硬盘会有坏点
• 2.固态硬盘：不断添加电子表示数据，剩余檫取次数，如果没有了会丢失数据

3.为什么需要GC

• 1.对于高级语言来说，一个基本认知是如果不进行垃圾回收，内存迟早都会被消耗完
• 2.除了释放1没用的对象，垃圾回收也可以清除内存里的记录碎片，碎片整理将所占用的堆内存移到堆的一端，以便JVM将整理出的内存分配给新的对象
• 3.随着应用程序所应付的业务越来越庞大，复杂，用户越来越多，没有GC就不能保证应用程序的正常优化

4.自动内存管理

• 1.无需开发人员手动参与内存的分配与回收，这样降低内存泄漏和内存溢出的风险，自动内存管理机制，将程序员从繁重的内存管理中释放出来，可以更专心地专注于业务开发
• 2.问题：对于Java开发人员而已，如果过度依赖于自动，会弱化Java开发人员在程序出现内存溢出时定位问题和解决问题的能力
• 3.只有真正了解JVM的自动内存分配和内存回收原理才能在遇到OutOfMemoryError时，快速地根据错误异常日志定位问题和解决问题

1.对象的finalization机制

• 1.Java语言提供了对象终止机制(finalization)来允许开发人员提供对象被销毁之前的自定义处理逻辑
• 2.当垃圾回收器发现一个对象没有引用指向，即垃圾回收对象之前，总会先调用这个对象的finalize()方法
• 3.finalize()方法允许在子类中被重写，用于在对象被回收时进行资源释放，通常在该方法中进行一些资源释放和清理的工作（如关闭文件，套接字和数据连接等）
• 4.永远不要主动调用某个对象的finalize()方法，应该交给垃圾回收机制调用
  • 1.finalize()时可能会导致对象复活
  • 2.finalize()方法的执行时间是没有保障的，它完全由GC线程决定，极端情况下若不发生GC，则finalize()方法将没有执行机会
  • 3.一个糟糕的finalize()会引用影响GC的性能
• 从功能上来说，finalize()方法与C++中的析构函数比较相似，但是Java采用的是基于垃圾回收器的自动内存管理机制，所以finalize()方法在本质上不同于C++的析构函数
• 由于finalize()方法的存在，虚拟机中的对象一般处于三种可能的状态
• 如果从所有的根节点都无法访问到某个对象，说明对象已经不再使用了，一般来说。此对象需要被回收，但事实上，也并非是非死不可的，这时候他们暂时处于缓刑阶段，一个无法触及的对象有可能在某一个条件下复活自己，如果这样，那么对它的回收就是不合理的，为此，定义虚拟机中对象可能的三种状态
• 可触及的：从根节点开始，可以到达这个对象
• 可复活的：对象的所有引用都被释放，但是对象有可能在finalize()中复活
• 不可触及的：对象的finalize()被调用，并且没有复活，那么就会进入不可触及状态，不可触及状态的对象不可能被复活，因为finalize()只会被调用一次
• 以上3种状态中，是由于finalize()方法的存在，进行的区分，只有在对象不可触及时才可以被回收
• 具体过程
• 判定一个对象ObjA是否可回收，至少要经历两次标记过程：
• 1.如果对象objA到GCRoots没有引用链，则进行第一次标记，
• 2.进行筛选，判断此对象是否有必要执行finalize()方法
• 1.如果对象objA没有重写finalize()方法，或者finalize()方法已经被虚拟机调用过，则虚拟机视为没有必要执行，objA被判定为不可触及的
• 2.如果对象objA重写了finalize()方法，且还未执行过，那么objA会被插入到F-Queue队列中，由一个虚拟机自动创建的，低优先级的Finalizer线程触发其finalize()方法执行
• 3.finalize()方法是对象逃脱死亡的最后就会，稍后GC会对F-Queue队列中的对象进行第二次标记，如果objA在finalize()方法中与引用链上的任何一个对象建立了联系，那么在第二次标记时，objA会被处于即将回收集合。之后，对象会再次出现没有引用存在的情况，在这个情况下，finalize方法不会被再次调用，对象会直接变成不可触及的状态，也就是说，一个对象的iinalize方法只会内调用一次
  

1.MAT与JProfiler的GC Roots溯源

• MAT是Memory Analyer的简称，它是一款功能强大的Java堆内存分析器，用于查找内存泄露以及查看内存消耗情况
• MAT是基于Eclipse开发的，是一块免费的性能分析工具
• 获取dump文件
• 方式1：命令行使用jmap
  
  

2.GC的作用区域

• 1.GC的作用区域
  • 1.方法区（并不要求具体的垃圾回收器一定要回收方法区）
  • 2.堆（主要：存放对象）
• 2.垃圾回收期间可对年轻代回收，也可对老年代回收，甚至是全堆和方法区的回收
• 3.其中Java堆是垃圾回收器的工作重点,，从次数上讲
  • 1.频繁收集Young区(新生代)
  • 2.较少收集old区(老年代)
  • 3.基本不动方法区(JDK1.7永久代/JDK1.8元空间)

3.垃圾回收相关算法

• 1.GC的过程分为两个阶段
  • 1.标记阶段：标记出哪些对象不再使用
  • 2.清除阶段：清除标记的对象

1.标记阶段

• 1.垃圾标记阶段：即判断对象是否存活
• 2.JVM的堆中存放着几乎所有的Java对象实例，GC执行垃圾回收之前，首先要区分出内存中哪些是存活对象，哪些是已经死亡的对象
• 3.只有被标记为已经死亡的对象，GC才会在执行垃圾回收时释放掉其所占用的内存空间，因此这个过程可称为垃圾标记阶段
• 4.JVM中标记死亡对象：即当一个对象已不再被任何的存活对象（引用指针）继续引用时，即可宣判为已死亡
• 5.判断对象存活一般有两种方式
  • 1.引用计数算法
  • 2.可达性分析算法

1.引用计数算法（未使用）

• 1.引用计数算法(Reference Counting)：
  • 1.为每个对象保存一个整型的引用计数器属性，用于记录对象被引用的情况
  • 2.对于一个对象A，只要有任何一个对象引用了A，则A的引用计数器就加1，当引用失效时，引用计数器就减1，只要对象A的引用计数器值为0，即表示对象A不可再被使用，可进行回收
• 2.优点：实现简单，垃圾对象便于辨识，判定效率高，回收没有延迟性(随时可回收)
• 3.缺点
  • 1.需要单独的字段存储计数器，增加了存储空间的开销
  • 2.每次赋值都需要更新计数器，伴随着加法和减法操作，这增加了时间开销
  • 3.引用计数器有一个严重的问题，即无法处理循环引用的情况，这是一条致命缺陷，导致在Java的垃圾回收器中没有使用这类算法
    
• 4.证明：Java未使用引用计算算法
  • -XX：+PrintGCDetails查看垃圾回收的细节
  • 证明：java使用的不是引用计数算法
• 5.应用范围：引用计数算法是很多语言的资源回收选择，其中Python支持垃圾收集机制，且使用了引用计数算法（以提高吞吐量）
• 6.解决方式：Java没有选择引用计数，是因为其存在一个基本的难题，即很难处理循环引用关系，Python采用以下方式解决循环引用的问题
  • 1.手动解除：合适的时机，解除引用关系
  • 2.使用弱引用weakref：只要发现弱引用无论内存空间是否足够都进行回收，weakref是Python提供的标准库，旨在解决循环引用

2.可达性分析算法（使用中）

• 1.可达性分析算法也叫根搜索算法/追踪性垃圾收集(Tracing Garbage Collection)（Java，C#）
  
  • 1.根对象集合(GC Roots)：即一组必须活跃的引用
  • 2.可达性分析算法是以根对象集合(GC Roots)为起始点，按照从上至下的方式搜索被根对象集合所连接的目标对象是否可达
  • 3.使用可达性分析算法后，内存中的存活对象都会被根对象集合直接或间接连接着，搜索所走过的路径称为引用链(Reference Chain)
  • 4.如果目标对象没有与任何引用链相连，则是不可达的，即意味着该对象已死亡可标记为垃圾对象
• 2.相对于引用计数算法：可达性分析算法不仅同样具备实现简单和执行高效等特点，更重要该算法可有效解决在引用计数算法中循环引用的问题，防止内存泄露的发生
• 3.可达性分析算法中只有能够被根对象集合直接或间接连接的对象才是存活对象，Java语言中GC Roots包括以下几类元素
  
  • 1.虚拟机栈中引用的对象：如各个线程被调用的方法中使用到的参数，局部变量等
  • 2.本地方法栈内(说的本地方法(JNI)引用的对象
  • 3.方法区中类静态属性引用的对象：如Java类的引用型静态变量
  • 4.方法区中常量引用的对象：如字符串常量池(String Table)里的引用
  • 5.所有被同步锁synchronized持有的对象
  • 6.Java虚拟机内部的引用：基本数据类型对应的Class对象，一些常驻的异常对象(如NullPointerException，OutOfMemoryError)，系统类加载器
  • 7.反映java虚拟机内部情况的JMXBean，JVMTI中注册的回调，本地代码缓存等
  • 8.除了上述固定的GC Roots集合以外，根据用户所选用的垃圾收集器以及当前回收的内存区域不同，还可有其他对象临时性地加入，共同构成完整的GC Roots集合，如分代收集和局部回收(Partial GC)
• 4.局部回收：如果只针对Java堆中的某一块区域进行垃圾回收(例只针对新生代)，须考虑到内存区域是虚拟机自己的实现细节，一个区域的对象完全有可能被其他区域的对象所引用，这时需要一并将关联的区域对象也加入GC Roots集合中去考虑，才能保证可达性分析的准确性
• 5.总结： 由于Root采用栈方式存放变量和指针，所以如果一个指针，其保存了堆内存中的对象，但是本身又不存放堆内存里面，那其就是一个Root
• 6.注意：
  • 1.如果使用可达性分析算法来判断内存是否可回收，那么分析工作必须在一个能保障一致性（分析过程中引用关系不能变化）的快照中进行，这点不满足的话分析结果的准确性就无法保证
  • 2.这点也是导致GC时必须Stop The World的一个重要原因，即使是几乎不会发生停顿的CMS收集器中，枚举根节点时也必须要停顿

2.清除阶段

1.标记-清除算法

• 垃圾清除阶段
• 当成功区分出内存中存活对象和死亡对象后，GC接下来的任务就是执行垃圾回收，释放掉无用对象所占用的内存空间，以便有足够的可用内存空间对新对象分配内存
• 目前在JVM中比较常见的三种垃圾收集算法是标记-清除算法(Mark-Sweep)，复制算法(Copying),标记-压缩算法(Mark-Compact)
• 背景：
• 标记-清除suanfa(Mark-Sweep)是一种非常基础和常见的垃圾收集算法，该算法被J.McCarthy等人在1960年提出并应用于Lisp语言
• 执行过程：
  当堆中的有效内存空间(available memory)被耗尽的时候，就会停止整个程序(也被成为stop the world)，然后进行两项工作，第一项则是标记，第二项则是清除
• 标记：Collection从引用根节点开始遍历，标记所有被引用的对象，一般是在对象的Header中记录为可达对象
• 清除：Collector对堆内存从头到尾进行线性遍历，如果发现某个对象在其Header中没有标记为可达对象，则将其回收
  
• 缺点：
• 效率不高
• 在进行GC的时候，需要停止整个应用程序，导致用户体验差
• 这种方式清理出来的空间内存是不连续的，产生内存碎片，需要维护一个空闲列表
• 注意，何为清除
• 这里所谓的清除并不是真的置空，而是把需要清除的对象地址保存在空间的地址列表里，下次有新对象需要加载时，判断垃圾的位置空间是否够，如果够，就存放(覆盖)

清除阶段：复制算法

• 为了解决标记-清除算法在垃圾收集效率方面的缺陷
• 核心思想：将活着的内存空间分为两块，每次只使用其中一块，在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中，之后清除正在使用的内存块中的所有对象，交换两个内存的角色，最后完成垃圾回收
  
• 优点：没有标记和清除的过程，实现简单，运行高效
• 复制过去以后保证空间的连续性，不会出现碎片问题
• 缺点：需要两倍的内存空间
• 对于G1这种分拆成为大量region(分区)的GC，复制而不是移动，意味着GC需要维护region之间对象引用关系(指针位置)，不管是内存占用或者时间开销也不小
• 特别：
• 如果系统中的垃圾对象很少，复制算法不会很理想，复制算法需要复制的存活对象数量并不会太大，或者说非常低才行(否则就会造成额外的复制)
• 应用场景：
• 在新生代，对常规应用的垃圾回收，一次通常可以回收70%-99%的内存空间，回收性价比很高，所以现在的商业虚拟机都是用这种收集算法回收新生代
  

清除阶段：标记-压缩算法

• 或者叫标记整理
• 背景：复制算法的高效性是建立在存活对象少，垃圾对象多的前提下的，这种情况在新生代经常发生，但是在老年代，更常见的情况是大部分对象都是存活对象，如果依然使用复制算法，由于存活对象较多，复制的成本也将很高，因此，基于老年代垃圾回收的特性，需要使用其他的算法
• 标记-清除算法的确可以应用在老年代，但是该算法不仅执行效率低下，而且在执行完内存回收后还会产生内存碎片，所以JVM的设计者需要在此基础上进行改进，标记-压缩(Mark-Compact)算法由此诞生
• 执行过程：
• 第一阶段和标记-清除算法一样，从根节点开始标记所有被引用对象
• 第二阶段将所有的存活对象压缩到内存的一端，按顺序排放，之后清理边界外所有的空间
  
• 标记-压缩算法的最终效果等同于标记-清除算法执行完成后，再进行一次内存碎片整理，因此也可以把它称为标记-清除-压缩(Mark-Sweep-Compact)算法
• 二者的本质差异在于标记-清除算法是一种非移动式的回收算法，标记压缩是移动式的，是否移动回收后的存活对象是项优缺点并存的风险决策
• 可以看到，标记的存活对象将会被整理，按照内存地址依次排列，而未被标记的内存会被清理掉，如此一来，当我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了许多开销
• 指针碰撞(Bump the Pointer)
• 如果内存空间以规整和有序的方式分布，即已用和未用的内存都各自一边，彼此之间维系着一个记录下一次分配起始点的标记指针，当为新对象分配内存时，只需要通过修改指针的偏移量将新对象分配在第一个空闲内存位置上，这种分配方式就叫做指针碰撞
• 标记压缩的优点：
• 消除了标记-清除算法当中，内存区域分散的缺点，我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可
• 消除了复制算法当中，内存减半的高额代价
• 缺点
• 从效率上来说，标记整理算法要低于复制算法
• 移动对象的同时，如果对象被其他对象引用，则还需要调整引用的地址
• 移动过程中，需要全程暂停用户应用程序，即：STW（Stop the world）

小结

• 
• 效率上：复制算法最快，但是却浪费了太多内存
• 兼顾三个指标，标记整理算法相对来说更平滑一些，但是效率上不高，它比复制算法多了一个标记的阶段，比标记-清除多了一个整理内存的阶段

分代收集算法

• 前面所有这些算法中，并没有一种算法可以完全替代其他算法，它们都具有自己独特的优势和特点，分代收集算法应运而生
• 分代收集算法，是基于这样一个事实：不同的对象的生命周期是不一样的，因此，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率，一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点使用不同的回收算法，以提高垃圾回收的效率
• 在Java程序运行的过程中，会产生大量的对象，其中有些对象是与业务信息相关，比如Http请求中的Session对象，线程，Socket连接，这类对象根业务直接挂钩，因此生命周期比较长，但是还有一些对象，主要是程序运行过程中生成的临时变量，这些对象生命周期会比较短，，比如：String对象，由于其不变类的特性，系统会产生大量的这些对象，有效对象甚至只用回收一次即可回收
• 目前几乎所有的GC都是采用分代收集(Generational Collecting)算法执行垃圾回收的
• 在HostSpot中，基于分代的概念，GC所使用的内存回收算法必须节后年轻代和老年代各自的特点
• 年轻代(Young Gen)
• 年轻代特点：区域相对老年代较小，对象生命周期短，存活率低，回收频繁
• 这种情况复制算法的回收整理，速度是最快的，复制算法的效率只和当前存活对象大小有关，因此很合适年轻代的回收，而复制算法内存利用率不高的问题，通过HotSpot中的两个survivor的设计得到缓解
• 老年代(Tenured Gen)
• 老年代特点：区域较大，对象生命周期长，存活率高，回收不及年轻代频繁
• 这种情况存在大量存活率高的对象，复制算法明显变得不合适，一般是由标记-清除或者是标记-清除与标记整理的混合实现
• Mark阶段的开销与存活对象的数量成正比
• Sweep阶段的开销与所管理区域的大小成正相关
• Compact阶段的开销与存活对象的数据成正比
• 以HotSpot中的CMS回收器为例，CMS是基于Mark-Sweep实现的，对于对象的回收效率很高。
• 而对于碎片问题，CMS采用基于Mark-Compact算法的Serial Old 回收器作为补偿措施：当内存回收不佳(碎片导致的Concurrent Mode Failure时)，将采用Serial Old执行Full GC以达到对老年代内存的整理
• 分代的思想被现有的虚拟机广泛使用，几乎所有的垃圾回收器都区分新生代和老年代

增量收集算法

• 上述现有的算法，在垃圾回收过程中，应用软件将处于一种stop the world的状态，在stop the world状态下，应用程序所有的线程都会挂起，暂停一起正常的工作，等待垃圾回收的完成，如果垃圾回收时间过长，应用程序会被挂起很久，将严重影响用户体验或者系统的稳定性，为了解决这个问题，即对实时垃圾收集算法的研究直接导致了增量收集(Incremental Collecting)算法的诞生
• 基本思想
• 如果一次性将所有的垃圾进行处理，需要造成系统长时间的停顿，那么就可以让垃圾收集线程和应用程序线程交替执行，每次垃圾收集线程只收集一小片区域的内存空间，接着切换到应用程序线程，依次反复，直到垃圾收集完成
• 总的来说，增量收集算法的基础仍是传统的标记-清除和复制算法。增量收集算法通过对线程间冲突的妥善处理，允许垃圾收集线程以分阶段的方式完成标记，清理或复制工作
• 缺点：使用这种方式，由于在垃圾回收过程中，间断性还执行了应用程序代码，所以能减少系统的停顿时间，但是因为线程切换和上下文切换的消耗，会使得垃圾回收的总体成本上升，造成系统吞吐量的下降

分区算法

• 一般来说，在相同条件下，堆空间越大，一次GC时所需要的时间就越长，有关GC产生的停顿也越长，为了更好地控制GC产生的停顿时间，将一块大的内存区域分割成多个小块，根据目标的停顿时间，每次合理地回收若干个小区间，而不是整个堆空间，从而减少一次GC所产生的停顿
• 分代算法将安装对象的生命周期长短划分成两个部分，分区算法将整个堆空间划分成连续的不同小区间
• 每一个小区间都独立使用，独立回收，这种算法的好处时可以控制一次回收多少个小区间

垃圾回收概念

System.gc()的理解

• 在默认情况下，通过System.gc()或者Runtime.getRuntime().gc()的调用，会显示触发Full GC,同时对老年代和新生代进行回收，尝试释放被丢弃对象占用的内存
• 然而System.gc()调用附带一个免责声明，无法保证对垃圾收集器的调用（不一定立马执行）
• JVM实现者可以通过System.gc()调用来决定JVM的GC行为，而一般情况下，垃圾回收应该是自动进行的，无需手动触发，否则就太过麻烦了，在一些特殊情况下，如我们在编写一个性能基准(测试)，我们可以在运行之间调用System.gc()
  

内存溢出

• 内存溢出(OOM)相对于内存泄露来说，尽管更容易被理解，但是同样的，内存溢出也是引发程序崩溃的罪魁祸首之一
• Java doc中对OutOfMemortyError的解释是：没有空闲内存，并且垃圾收集器也无法提供更多内存
• 首先说没有空闲内存的情况，说明Java虚拟机的堆内存不够，原因有二：
• 1.Java虚拟机的堆内存设置不够：比如，可能存在内存泄露问题，也很有可能就是堆的大小不合理，比如我们要处理比较可观的数据量，但是没有显示指定JVM堆大小或者指定数值偏小，我们可以通过参数-Xms,-Xmx来调整
• 2.代码中创建了大量大对象，并且长时间不同被垃圾收集器收集(存在被引用)
• 对于老版本的Oracle JDK,因为永久代的大小是有限的，并且JVM对永久代垃圾回收(如：常量池回收，卸载不再需要的类型)非常不积极，所以当我们不断添加新类型的时候，永久代出现OutOfMemoryError非常多见，尤其是在运行时存在大量动态类型生成的场合，类似intern字符串缓存占用太多空间，也会导致OOM问题，对应的异常信息，会标记出来和永久代相关：java.lang.OutOfMemoryError：PermGen space
• 随着元数据的引入，方法区内存已经不再那么窘迫，所以相应的OOM有所改观，出现OOM，异常信息则变成了：java.lang.OutOfMemoryError:Metaspace.直接内存不足，也会导致OOM
• 这里隐含着一层意思是，在抛出OutOfMemoryError之前，通常垃圾收集器会被触发，尽其所能去清理出空间
• 例如：在引用机制分析中，涉及到JVM会去尝试回收软引用指向的对象等
• 在java.nio.BIts.reserveMemory()方法中，我们能清除的看到，System.gc()会被调用，以清理空间
• 当然，也不是在任何情况下垃圾收集器都会被触发的
• 如果，我们去分配一个超大对象，类似一个超大数组超过堆的最大值，JVM可以判断出垃圾收集并不能解决这个问题，所以直接抛出OutOfMemoryError

内存泄露(Memory Leak)

• 也称作：存储泄露。严格来说，只有对象不会再被程序用到了(自己的代码无法再被引用了)，但是GC又不能回收他们的情况，才叫内存泄露
• 但实际情况很多时候一些不太好的实践会导致对象的生命周期变得很长甚至导致OOM，也可以叫做宽泛意义上的内存泄露
• 尽管内存泄露并不会立即引起程序崩溃，但是一旦发生内存泄露，程序中可用内存就会逐步蚕食，直至耗尽所有内存，最终出现OutOfMemory异常，导致程序崩溃
• 注意：这里的存储空间并不是指物理内存，而是指虚拟内存大小，这个虚拟内存大小取决于磁盘交换区设定的大小
  
• 举例
• 1.单例模式
• 单例的生命周期和应用程序是一样长的，所以单例程序中，如果持有对外部对象的引用的话，那么这个外部对象是不能被回收的，则会导致内存泄露的产生(例：runtime)
• 2.一些提供close的资源未关闭导致内存泄露
• 数据库连接(dataSource.getConnection())，网络连接(socket)和io连接必须手动close，否则是不能被回收的

Stop The World

• Stop the world简称STW，指的是GC时间发生过程中，会产生应用程序的停顿，停顿产生时整个应用程序线程都会被暂停，没有任何响应，优点像卡死的感觉，这个停顿称为STW
• 可达性分析算法中枚举根节点(GC Roots)会导致所有Java执行线程停顿
• 分析工作必须在一个能确保一致性的快照中进行
• 一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上
• 如果出现分析过程中对象引用关系还不断变化，则分析结果的准确性无法保证
• 被STW中断的应用程序线程会在完成GC后恢复，频繁中断会让用户感觉像是网速不快造成电影卡带一样，所以我们需要减少STW的发生
• STW事件和采用哪款GC无关，所有的GC都有这个事件
• 哪怕是G1也不能完全避免Stop-the-world情况发生，只能说垃圾回收器越来越优秀，回收效率越来越高，尽可能地缩短了暂停时间
• STW是JVM在后台自动发起和自动完成的，在用户不可见的情况下，把用户正常的工作线程全部停掉
• 开发中不要用System.gc()；会导致Stop-the-world的发生
  

程序的并行与并发

• 并发(Concurrent)
• 在操作系统中，是指一个时间段中有几个程序都处于已启动运行到运行完毕之间，且这几个程序都是在同一个处理器上运行
• 并发不是真正意义上的同时进行，只是CPU把一个时间段划分成几个时间片段(时间区间)，然后在这几个时间区间之间来回切换，由于CPU处理的速度非常快，只要时间间隔处理得当，即可让用户感觉是多个应用程序同时在进行
• 并行(Parallel)
• 当系统有一个以上CPU时，当一个CPU执行一个进程时，另一个CPU可以执行另一个进程，两个进程互不抢占CPU资源，可以同时进行，我们称之为并行(Parallel)
• 其实决定并行的因素不是CPU的数量，而是CPU的核心数量，比如一个CPU有多个核也可以并行
• 并发：指多个事情在同一时间段内同时发生
• 并行：指多个事情在同一时间点上同时发生了
• 并发的多个任务之间是互相抢占资源的
• 并行的多个任务之间是不互相抢占资源的
• 只有在多CPU或者一个CPU多核才会发生并行

垃圾回收的并行与并发

• 并行(Paralle)：指多条垃圾收集线程并行工作，但此时用户线程仍处于等待状态，如ParNew,Paralel Scavenge,Parallel Old
• 串行(Serial)：相比较并行的概念，单线程执行
• 如果内存不够，则程序暂停，启动JVM垃圾回收器进行垃圾回收，回收完，再启动程序的线程
• 并发(Concurrent):：指用户线程与垃圾收集线程同时执行(但不一定是并行的，可能交替执行)，垃圾首先线程在执行时不会停顿用户程序的运行
• 例如：CMS,G1

安全点与安全区域

• 安全点(Safepoint):：程序执行时并非在所有地方都能停顿下来开始GC，只有在特定的位置才能停顿下来开始GC，这些位置成为安全点(Safepoint)
• Safe Point的选择很重要，如果太少可能导致GC等待的时间太长，如果太频繁可能导致运行时的性能问题，大部分指令的执行时间都非常短暂，通常会根据“是否具有让程序长时间”为标准，比如：选择一些执行时间较长的指令作为Safe Point,如方法调用，循环跳转和异常跳转等
• 如何在GC发生时，检查所有线程都跑到最近的安全点停顿下来呢？
• 抢先式中断(目前没有虚拟机采用)
• 首先中断所有线程，如果还有线程不再安全点，就恢复线程，让线程跑到安全点
• 主动式中断
• 设置一个中断标志，各个线程运行到Safe Point的时候主动轮询这个标志，如果中断标志为真，则将自己进行中断挂起
• 安全区域(Safe Region)
• Safepoint机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的SafePoint。但是程序不执行的时候呢，例如线程处于Sleep状态或Blocked状态，这时候线程无法响应JVM的中断请求，“走”到安全点去中断挂起，JVM也不太可能等待线程被唤醒。对于这种情况，就需要安全区域(Safe Refion)来解决
• 安全区域是指在一段代码片段中，对象的引用的关系不会发生变化，，在这个区域中的任何位置开始GC都是安全的，我们也可以把Safe Region看做是被扩展了的Safe Point
• 实际执行时
• 1.当线程运行到Safe Region的代码时，首先标识已经进入了Safe Region,如果这段时间内发生GC，JVM会忽略标识为Safe Region状态的线程
• 2.当线程即将离开Safe Region时，会检查JVM是否已经完成GC，如果完成了，则继续运行，否则线程必须等待直到收到可以安全离开Safe Region的信号为止

JAVA中集中不同引用

• 我们希望能描述这一类对象，当内存空间还足够时，则能保留在内存中，如果内存空间在进行垃圾收集后还是很紧张，则可以抛弃这些对象
• JDK1.2版本之后，Java对引用的概念进行了扩充，将引用分为强引用(Strong Reference)，软引用(Soft Reference)，弱引用(Weak Reference)，虚引用(Phantom Reference)4种，这4种引用强度依次逐渐减弱
• 除了强引用外，其他3种引用均可以在java.lang.ref包中找到他们的身影，如下图，显示了3种引用类型对应的类，开发人员可以在应用程序中直接使用它们
  
• Reference子类只有终结器引用时包内可见的，其他3种引用类型均为pulic,可以在应用程序中直接使用
• 强引用(StrongReference)：最传统的引用的定义，是指在程序代码之中普遍存在的引用赋值，即类似Object obj = new Object()这种引用关系，无论任何情况下，只要强引用关系还存在，垃圾收集器就永远不会回收掉被引用的对象
• 软引用(SoftReference)：在系统将要发生内存溢出之前，将会吧这些对象列入回收，范围之中进行第二次回收，如果这次回收后还没有足够的内存，才会抛出内存溢出异常
• 弱引用(WeakReference)：被弱引用关联的对象只能生存到下一次垃圾收集之前，当垃圾收集器工作时，无论内存空间是否足够，都会回收掉被弱引用关联的对象
• 虚引用(PhantomReference)：一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来获得一个对象的实例，为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知

强引用（不回收）

• 在Java程序中，最常见的引用类型是强引用，也就是普通对象引用，即默认的引用类型
• 当在Java语言中使用new操作符创建一个新的对象，并将其赋值给一个变量的时候，这个变量就成为指向该对象的一个强引用
• 强引用的对象是可触及的，垃圾收集器就永远不会回收掉被引用的对象
• 对于一个普通的对象，如果没有其他的引用关系，只要超过了引用的作用域或者显示地将相应强引用赋值为null，就是可以当做垃圾被收集了，当然具体的回收时机还是地看垃圾收集策略
• 相对的，软引用，弱引用和虚引用的对象是软可触及的，弱可触及的和虚可触及的，在一定条件下，都是可以被回收的，所以，强引用时造成Java内存泄露的主要原因之一
  
• 特点
• 强引用可以直接访问目标对象
• 强引用所指向的对象在任何时候都不会被系统回收，虚拟机宁愿抛出OOM异常，也不会回收强引用所指向对象
• 强引用可能导致内存泄露(其他引用不会导致)

软引用(内存不足即回收)

• 软引用时用来描述一些还有用，但非必须的对象，只被软引用关联着的对象，在系统将要发生内存溢出的异常前，会把这些对象列进回收范围之中进行第二次回收，如果这次回收还没有足够的内存，才会抛出内存异常
• 软引用通常用来实现内存敏感的缓存，比如：高速缓存就有用到软引用，如果还有空闲内存，就可以暂时保存缓存，当内存不足时清理掉，这样就保证了使用缓存的同时，不会耗尽内存
• 垃圾回收器在某个时刻决定回收软可达的对象的时候，会清理软引用，并可选地把引用存放到一个引用队列(Reference Queue)
• 类似弱引用，只不过Java虚拟机尽量让软引用的存活时间长一些，迫不得已才清理
• 总结：当内存足够，不会回收软引用的可达对象，当内存不够，会回收软引用对象
  
  
  
  

弱引用(一发现即回收)

• 弱引用也是用来描述哪些非必须对象，只被弱引用关联的对象只能生存到下一次垃圾收集发生为止，在系统GC时，只要发现弱引用，不管系统堆空间使用是否充足，都会回收掉只被弱引用关联的对象
• 但是，由于垃圾回收器的线程通常优先级很低，因此，并不一定能很快地发现持有弱引用的对象，在这种情况下，弱引用对象可以存在较长的时间
• 弱引用和软引用一样，在构造弱引用时，也可以指定一个引用队列，当弱引用对象被回收时，就会加入指定的引用队列，通过这个队列可以跟踪对象的回收情况
• 软引用，弱引用都非常适合来保存那些可有可无的缓存数据，如果这么做，当系统内存不足时，这些缓存数据会被回收，不会导致内存溢出，而到内存资源充足时，这些缓存数据又可有存在相当长的时间，从而起到加速系统的作用
  
• Entry是weakReference类型的

虚引用(对象回收跟踪)

• 也称为幽林引用或者幻影引用，是所有引用类型中最弱的一个
• 一个对象是否有虚引用的存在，完全不会决定对象的生命周期，如果一个对象仅持有虚引用，那么它和没有引用几乎是一样的，随时都可能被垃圾回收
• 他不能单独使用，也无法通过虚引用来获取被引用的对象，当试图通过虚引用的get()方法取得对象时，总是null
• 为一个对象设置虚引用关联的唯一目的在于跟踪垃圾回收的过程，比如：能在这个对象被收集器回收时收到一个系统通知
• 虚引用必须和引用队列一起使用，虚引用在创建时必须提供一个引用队列作为参数，当垃圾回收准备回收一个对象时，如果发现它还有虚引用，就会在回收对象后，将这个虚引用加入引用队列，以通知应用程序对象的回收情况
• 在JDK1.2版之后，提供了PhantomReference类来实现虚引用
  
  

终结器引用

• FinalReference
• 它用以实现对象的finalize()方法，也可以成为终结器引用
• 无需手动编码，其内部配合引用队列使用
• 3.在GC时，终结器引用入队，由Finalizer线程通过终结器引用找到被引用对象并调用它的finalize()方法，第二次GC时才能回收被引用对象

垃圾回收器

GC分类与性能指标

• 按线程数分，可以分为串行垃圾回收器和并行垃圾回收器
• 串行回收指的是在同一时间段内只允许有一个CPU用于执行垃圾回收操作，此时工作线程被暂停，直至垃圾收集工作结束
• 在诸如单CPU处理器或者较小的应用内存等硬件平台不是特别优越的场合，串行回收器的性能表现可以超过并行回收器和并发回收器，所以，串行回收默认被应用在客户端的client模式下的JVM中
• 在并发能力比较强的CPU上，并行回收器产生的停顿时间要短于串行回收器
• 和串行回收相反，并行收集可以运用多个CPU同时执行垃圾回收，因此提升了应用的吞吐量，不过并行回收仍然与串行回收一样，采用独占式，使用Stop-the-world机制
• 按照工作模式分，可以分为并发式垃圾回收器和独占式垃圾回收器
• 并发式垃圾回收器与应用程序线程交替工作，以尽可能减少引用程序的停顿时间
• 独占式垃圾回收器(Stop the world)一旦运行，就停止应用程序中的所有用户线程，知道垃圾回收过程完全结束
• 按碎片处理方式分，可分为压缩式垃圾回收器和非压缩式垃圾回收器
• 压缩式垃圾回收器会在回收完成后，对存活对象进行压缩整理，消除回收后的碎片（再分配对象空间使用：指针碰撞）
• 非压缩式的垃圾回收器不进行这步操作（再分配对象空间使用：空闲列表）
• 按工作的内存区间分，又可分为年轻代垃圾回收器和老年代垃圾回收器

评估GC的性能指标

• 吞吐量：运行用户代码的时间占总运行时间的比例
  • （总运行时间=程序的运行时间+内存回收时间）
• 垃圾收集开销：吞吐量的补数，垃圾收集所用时间与总运行时间的比例
• 暂停时间：执行垃圾收集时，程序的工作线程被暂停的时间
• 收集频率：相对于应用程序的执行，收集操作发生的频率
• 内存占用：Java堆区所占的内存大小
• 快速：一个对象诞生到被回收所经历的时间
• 主要的是吞吐量和暂停时间

吞吐量与暂停时间

• 吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)
• 暂停时间是指一个时间段内应用程序线程暂停，让GC线程执行的状态
• 暂停时间优先，意味着尽可能让单次STW的时间最短
  
• 高吞吐量较好因为这会让应用程序的最终用户感觉只有应用程序线程在做生产性工作，直觉上，吞吐量越高程序运行越快
• 低暂停时间(低延迟)较好因为从最终用户的角度来看不管事GC还是其他原因导致一个应用被挂起始终是不好的
• 标准：在最大吞吐量优先的情况下，降低停顿时间

历史

7款经典收集器与垃圾分代之间的关系

• CMS并发收集，如果用户线程速度大于垃圾回收速度，可会会回收失败，需要使用Serial Old GC配合回收(后备方案)
• 两个收集器间有连线，表明他们可以搭配使用
• 其中Serial Old作为CMS出现Concurrent Mode Failure失败的后备预案
• (红色虚线)由于维护和兼容性测试的成本，在JDK 8 时将Serial+CMS，ParNew+Serial Old这两个组合声明为废弃,并在JDK 9中完全取消了这些组合的支持
• (绿色虚线)，JDK 14中，弃用Parallel Scanvenge和SerialOld GC组合
• (青色虚线)，JDK 14中，删除CMS垃圾回收器
• 为什么要有很多收集器：因为Java的使用场景很多，需要针对不同的场景提供不同的垃圾收集器，提高垃圾收集的性能

###如何查看默认的垃圾回收器

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

Serial回收器：串行回收

• Serial收集器是最基本，历史最悠久的垃圾收集器了，JDK1.3之前回收新生代唯一的选择
• Serial收集器作为HotSpot中Client模式下的默认新生代垃圾收集器
• Serial收集器采用复制算法，串行回收和Stoptheworld机制的方式执行内存回收
• 除了年轻代之外，Serial收集器还提供用于执行老年代垃圾收集的Serial Old收集器。Serial Old收集器同样也采用了串行回收和Stop the World机制，只不过内存回收算法使用的是标记-压缩算法
• Serial Old是运行在Client模式下默认的老年代的垃圾回收器
• Serial Old在Server模式下主要有两个用途：1.与新生代Parallel Scanvenge配合使用2.作为老年代CMS收集器的后备垃圾收集方案
  
• 优势：简单而高效(与其他收集器的单线程比)，对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率
• 在用户的桌面应用场景中，可用内存一般不大(几十MB至一两百MB)，可以在较短时间内完成垃圾收集，只要不频繁发送，使用串行回收器可以接收
• 在HotSpot虚拟机中，使用-XX：+UseSerialGC参数可以指定年代和老年代都使用串行收集器
• 等价于新生代用Serial GC，且老年代用Serial Old GC
  
  
  
• 了解即可，限定单核CPU在使用，现在一般都不是单核

ParNew回收器：并行回收

• 如果说Serial GC是年轻代中的单线程垃圾收集器，那么ParNew收集器则是Serial收集器的多线程版本
• ParNew收集器除了采用并行回收的方式执行内存回收外，两款垃圾收集器之间几乎没有任何区别，ParNew收集器在年轻代中同样也是采用复制算法，Stop-the-World机制
• ParNew是很多JVM运行在Server模式下新生代的默认垃圾收集器
  
• 由于ParNew收集器是基于并行回收的，那么是否可以断定ParNew收集器的回收效率在任何场景下都会比Serial收集器更高效
• ParNew收集器运行在多CPU的环境下，由于可以充分利用多CPU，多核心等物理硬件资源优势，可以更快速地完成垃圾收集，提升程序的吞吐量
• 但是在单个CPU的环境下，ParNew收集器不比Serial收集器更高效，虽然Serial收集器是基于串行回收，但是由于CPU不需要频繁地做任务切换，因此可以有效避免多线程交互过程中产生的一些额外开销
• 因为除Serial外，目前只有ParNew GC能与CMS收集器配合工作
• 在程序中，开发人员可以通过选项-XX：+UseParNewGC 手动指定使用ParNew收集器执行内存回收任务，它表示年轻代使用并行收集器，不影响老年代
• -XX：ParallelGCThreads 限制线程数量，默认开启和CPU数据相同的线程数
  
  

Parallel回收器：吞吐量优先

• HotSpot的年轻代中除了拥有ParNew收集器是基于并行回收的以外，Parallel Scavenge收集器同样也采用了复制算法，并行回收和Stop the World机制
• 那么Parallel收集器的出现是否多此一举
• 和ParNew收集器不同，Parallel Scavenge收集器的目标是达到一个可控制的吞吐量(Throughput),它也被称为吞吐量优先的垃圾收集器
• 自适应调节策略也是Parallel Scavenge与ParNew一个重要区别
• 高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后天运算而不需要太多交互(低延迟)的任务，因此常见在服务器环境中使用，例如批量处理，订单处理，工资支付等
• Paralel收集器在JDK1.6时提供了用户执行老年代垃圾收集的Paralel Old收集器，用来代替老年代的Serial Old收集器
• Paralel Old收集器采用了标记-压缩算法，但同样也是基于并行回收和Stop-the-World机制
• 在程序吞吐量优先的应用场景中，Parallel 收集器和Parallel Old收集器的组合，在Server模式下的内存回收性能很不错
• 在Java8中，默认是此垃圾收集器
• 参数配置
• -XX：+UseParallelGC 手动指定年轻代使用Paralel并行收集器执行内存回收任务
• -XX：+UseParalelOldGC 手动指定老年代都是使用并行回收收集器
  • 分别适用于新生代和老年代，默认是jdk8是开启的
  • 上面两个参数，默认开启一个，另一个也会被开启(互相激活)
• -XX:：ParalerGCThreads 设置年轻代并行收集器的线程数。一般地最好与CPU数量相等，以避免过多的线程数影响垃圾收集性能
  • 在默认情况下，当CPU数量小于8个，ParallelGCThread的值等于CPU数量
  • 当CPU数量大于8个，ParalelGCThreads的值等于3+{[5*CPU_count]/8}
• -XX：MaxGCPauseMillis 设置垃圾收集器最大停顿时间(即STW的时间，单位是毫秒)
  • 为了尽可能地把停顿时间控制在MaxGCPauseMills以内，收集器在工作时会调整Java堆大小或者其他一些参数
• 对于用户来讲，停顿时间越短体验越好，但是在服务器端，我们注重高并发，整体的吞吐量，所以服务端适合Parallel，进行控制
  • 该参数使用需谨慎
• -XX：GCTimeRatio 垃圾收集时间占总时间的比例(i/(N+1))。用于衡量吞吐量的大小
• 取值范围(0,100)，默认值99，也就是垃圾回收时间不超过1%
• 与前一个-XX：MaxGCPauseMillis参数有一定矛盾性，暂停时间越长，Radio参数就越容易超过设定的比例
• -XX：+UseAdaptiveSizePolicy 设置Parallel Scanvenge收集器具有自适应调节策略
  • 在这种模式下，年轻代的大小，Eden和Survivor的比列，晋升老年代的对象年龄等参数会被自动调整，已达到在堆大小，吞吐量和停顿时间之间的平衡点
• 在手动调优比较困难的场合，可以直接使用这种自适应的方式，仅指定虚拟机的最大堆，目标的吞吐量(GCTimeRatioo)和停顿时间(MaxGCPauseMills),让虚拟机自己完成调优工作
  
• +表示使用，-表示不使用

CMS回收器：低延迟

• 在JDK1.5时期，HotSpot推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器：CMS(Concurrent-Mark-Sweep)收集器，这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程同时工作
• CMS收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间，停顿时间越短(低延迟)就越适合与用户交互的程序，良好的响应速度能提高用户体验
• 目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验，CMS收集器就非常符合这类应用的需求
• CMS的垃圾收集算法采用标记-清除算法，并且也会Stop-the-world
• 不幸的是，CMS作为老年代的收集器，却无法与JDK1.4.0中已经存在的新生代收集器Parallel Scavenge配合工作
• 所以在JDK1.5中使用CMS来收集老年代的时候，新生代只能选择ParNew或者Serial收集器中的一个
• 在G1出现之前，CMS使用还是非常广泛的
  
• CMS整个过程比之前的收集器要复杂，整个过程分为4个主要阶段，即初始标记阶段，并发标记阶段，重新标记阶段和并发清除阶段
• 初始阶段(initial-Mark)阶段，在这个阶段中，程序中所有的工作线程都将会因为Stop-the-World机制而出现短暂的暂停，这个阶段的主要任务仅仅只是标记出GCRoots能直接关联的对象，一旦标记完成之后就会恢复之前被暂停的所有应用线程，由于直接关联对象比较小，所以这里的速度非常快
• 并发标记(Concurrent-Mark)阶段：从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行
• 重新标记(Remark)阶段：由于在并发标记阶段中，程序的工作线程会和垃圾收集线程同时运行或者交叉运行，因此为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短
• 并发清除(Concurrent-Sweep)阶段：此阶段清除删除掉标记阶段判断的已经死亡的对象，释放内存空间，由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的
• 尽管CMS收集器采用的是并发回收(非独占式)，但是在其初始化标记和再次标记这两个阶段中仍然需要执行Stop-the-World机制暂停程序中的工作线程，不过暂停时间并不会太长，因此可以说明目前所有的垃圾收集器都做不到完全不需要Stop-the-World,只是尽可能地缩短暂停时间
• 由于最耗费时间的并发标记与并发清除阶段都不需要暂停工作，所以整体的回收时低停顿的
• 另外，由于在垃圾收集阶段用户线程没有中断，所以在CMS回收过程中，还应该确保应用程序用户线程有足够的内存可用，因CMS收集器不能像其他收集器那样等到老年代机会完全被填满再进行收集，而是当堆内存使用率达到某一阈值时，便开始进行回收，以确保应用程序在CMS工作过程中依然有足够的空间支持应用程序运行，要死CMS“运行期间预留的内存无法满足程序需要，就会出现一次Concurrent Mode Failure失败，这时虚拟机将启动后备预案，临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样就停顿时间就很长了
• CMS收集器的垃圾收集算法采用的是标记-清除算法，这意味着每次执行完内存回收后，由于被执行的内存回收的无用对象所占用的内存空间极有可能是不连续的一些内存块，不可避免地将产生一些内存碎片，那么CMS在为新对象分配内存空间时，将无法使用指针碰撞技术，而只能够选择空闲列表执行内存分配
• 为什么不使用Mark-Compact算法：因为当并发清除时，用Compact整理内存的话，原来的用户线程使用的内存没法用，要保证用户线程能继续执行，前提的它运行的资源不受影响，Mark-Compact更适合STW场景使用
• CMS的优点
  • 低延迟
  • 并发收集
• 缺点
  • 1.会产生内存碎片，导致并发清理收，用户线程可用的空间不足，在无法分配大对象的情况下，不得不提前触发Full GC
  • 2.CMS收集器对CPU资源非常敏感，在并发阶段，它虽然不会导致用户停顿，但是会因为占用了一部分线程而导致应用程序变慢，总吞吐量会降低
  • 3.CMS收集器无法处理浮动垃圾，可能回车Concurrent Mode Failure失败而导致另一次Full GC的产生，在并发标记阶段由于程序的工作线程和垃圾收集线程是同步运行或者交叉运行的，那么在并发标记阶段如果产生新的垃圾对象，CMS将无法对这些垃圾对象进行标记，最终会导致这些新产生的垃圾对象没有被及时回收，从而只能在下一次执行GC时释放这些之前未被回收的内存空间
• 参数设置
• -XX：++UseConcMarkSweepGC 手动指定使用CMS收集器执行内存任务
• 开启该参数后会自动将-XX：+UseParNewGC打开，即ParNew(Young区用)，CMS(Old区)，Serial Old（备用）
• -XX：CMSlnitiatingOccupanyFraction 设置堆内存使用率的阈值，一旦达到阈值，便开始进行回收
• JDK 5及以前版本的默认值是68，即当老年代的空间使用率达到68%时，会执行一次CMS回收，JDK 6及以上版本默认值为92%
• 如果内存增长缓存，可以设置一个稍大的值，大的阈值可以有效降低CMS的触发频率，减少老年代的回收的次数可以较为明细地改善应用程序性能，反之，如果应用程序内存使用率增长的很快，则应该降低这个阈值，以避免频繁触发老年代串行收集器，因此通过该选项可以有效降低Full GC的执行次数
  
• -XX：+UseCMSCompactAtFullCollection 用于指定在执行完Full GC后对内存空间进行压缩整理，以此避免内存碎片的产生，不过由于内存压缩整理过程无法并发执行，所带来的问题就是停顿时间变得更长了
• -XX：CMSFullGCsBeforeCompaction 设置在执行多少次FullGC后对内存空间进行压缩整理
• -XX:ParallelCMSThreads 设置CMS的线程数量
• CMS 默认启动的线程数是(ParallelGCThreads + 3)/4
• ParallelGCThreads是年轻代并行收集器的线程数，当CPU资源比较紧张时，收到CMS收集器线程的影响，应用程序的性能垃圾回收阶段可能会非常糟糕

总结

• 想要最小化使用内存和并行开销：Serial GC
• 想要最大化应用程序的吞吐量：Paralel GC
• 最小化GC的中断或挺短时间：CMS GC
• JDK 9时CMS被标记为Deprecate
• 如果JDK9及以上版本虚拟机使用参数 -XX：++UseConcMarkSweepGC来开启CMS收集器时，会受到警告信息
• JDK14删除了CMS垃圾收集器
• 如果在JDK 14中使用-XX：++UseConcMarkSweepGC来开启CMS收集器，JVM不会报错，只是给出一个warning信息，但是不会exit,JVM会自动回退以默认GC方式启动JVM

G1回收器：区域化分代式

• Garbage First(G1)：延迟可控的情况下获得尽可能高的吞吐量
• G1是一个并行回收器，它把堆内存分割为很多不相关的区域(Region)(物理上不连续的)，使用不同的Region来表示Eden,幸存者0区，幸存者1区，老年代等
• G1 GC有计划的避免在整个Java堆中进行全区域的垃圾收集，G1跟踪各个Region里面的垃圾堆积的价值的大小(回收所获得的空间大小以及回收所需时间的经验值)，在后台维护一个优先列表，每次根据运行的收集时间，优先回收价值最大的Region
• 由于这种方式的侧重点在于回收垃圾最大量的区间(Region),所以我们给G1一个名字：垃圾优先(Garbage First)
• G1是一款面向服务端应用的垃圾收集器，主要针对配备多核CPU及大容量内存的机器，以极高概率满足GC停顿时间的同时，还兼具高吞吐量的性能特征
• 在JDK1.7版本正式启用，移除了Experimental的标识，是JDK 9以后默认垃圾回收器，取代了CMS回收器以及Parallel+Parallel Old组合。被Oracle官方称为全功能的垃圾收集器
• 与此同时，CMS已经在JDK9 中被标记为废弃(deprecated),在JDK 8中还不是默认的垃圾回收器，需要使用-XX：+UseG1GC来启用

G1垃圾回收器的优势与不足

• 与其他GC收集器相比，G1使用了全新的分区算法，其特点如下所示
• 并行与并发
• 并行性：G1在回收期间，可以有多个GC线程同时工作，有效利用多核计算能力，此时用户线程STW
• 并发性：G1拥有与应用程序交替执行的能力，部分工作可以和应用程序同时执行，因此，一般来说，不会在整个回收阶段发生完全阻塞应用程序的情况
• 分代收集
• 从分代上看，G1依然属于分代垃圾回收器，它会分区年轻代和老年代，年轻代依然有Eden区和Survivor区，但从堆的结构上看，它不要求整个Eden区，年轻代或者老年代都是连续的，也不再坚持固定大小和固定数量
• 将堆空间分为若干个区域(Region)，这些区域中包含了逻辑上的年轻代和老年代
• 和之前的各类回收器不同，它同时兼顾年轻代和老年代，对比其他回收器，或者工作在年轻代或者工作在老年代
  
• 空间整合
• CMS：标记-清除算法，内存碎片。若干次GC后进行一次碎片整理
• G1将内存划分为一个个的region,内存的回收时以region作为基本单位的。Region之间是复制算法，但整体上实际可以看作是标记-压缩(Mark-Compact)算法，两种算法都可以避免内存碎片，这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC，尤其是当Java堆非常大的时候，G1的优势更加明细
• 可预测的停顿时间模型(即：软实时soft real-time)
• 这是G1相对于CMS的另一大优势，G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒
• 由于分区的原因，G1可以只选取部分区域进行内存回收，这样缩小了回收的范围，因此对于全局停顿情况的发生也能得到较好的控制
• G1跟踪各个Region里面的垃圾堆积的价值的大小(回收所获得的空间大小以及回收所需时间的经验值)，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region，保证了G1收集器在有限2的时间内可以获取尽可能高的收集效率
• 相比于CMS GC,G1未必能做到CMS在最好情况下的延时停顿，但是最差情况要好很多
• 缺点
• 相比较于CMS，G1还不具备全方位，压倒性优势，比如在用户程序运行过程中，G1无论是为了垃圾收集产生的内存占用(Footprint)还是程序运行时的额外执行负载(OverLoad)都要比CMS要高
• 从经验上来说，在小内存应用上CMS的表现大概率会由于G1,而G1在大内存应用上则发挥其优势，平衡点在6-8GB之间

G1的参数设置

• -XX：+UseG1GC 手动指定使用G1收集器执行内存回收任务
• -XX：G1HeapRegionSize 设置每个Region的大小。值是2的幂，范围是1MB到32MB之间，目标是根据最小的Java堆大小划分出约2048个区域。默认是堆内存的1/2000
• -XX：MaxGCPauseMillis 设置期望达到的最大GC停顿时间指标(JVM会尽力实现，但不保证达到)，默认值是200ms
• -XX：ParallelGCThread 设置STW时GC线程数的值。最多设置为8
• -XX：ConcGCThreads 设置并发标记的线程数。将n设置为并行垃圾回收线程数(ParalelGCThreads)的1/4左右
• -XX：InitiatingHeapOccupancyPercent 设置触发并发GC周期的Java堆占用率阈值。超过此值，就触发GC，默认值是45
• G1的设计原则就是简化JVM性能调优，开发人员只需要简单的三步即可完成调优
• 第一步：开启G1垃圾收集器
• 第二步：设置堆的最大内存
• 第三步：设置最大的停顿时间
• G1中提供了三种垃圾回收模式：YoungGC,Mixed GC 和Full GC,在不同的条件被触发

G1回收器的适用场景

• 面向服务端的应用，针对具有大内存，多处理器的机器(在普通大小的堆里表现并不突出)
• 最主要的应用是需要低GC延迟，并具有大堆的应用程序提供解决方案
• 如：在堆大小约6GB或更大时，可预测的暂停时间可低于0.5秒(G1通过每次只清理一部分而不是全部的Region的增量式清理来保证每次GC停顿的时间不会过长)
• 用来替换掉JDK1.5中的CMS收集器
• 以下情况，使用G1可能比CMS好
• 1.超过50%的Java堆被活动数据占用
• 2.对象分配频率或年代提示频率变化很大
• 3.GC停顿时间过长(长于0.5至1秒)
• HotSpot垃圾收集器里。除了G1以外，其他的垃圾收集器使用内置的JVM线程执行GC的多线程操作，而G1 GC可以采用应用线程承担后台的GC工作，即当JVM的GC线程处理速度慢，系统会调用应用程序线程帮助加速垃圾回收过程。

region的适用介绍

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

G1垃圾回收器的主要回收环节

• G1 GC的垃圾回收过程主要包括如下三个环节
• 年轻代(Young GC)
• 老年代并发标记过程(Concurrent Marking)
• 混合回收(Mixed GC)
• (如果需要，单线程，独占式，高强度的Full GC还是继续存在的。它针对GC的评估失败提供了一种失败保护机制，即强力回收)
  
• 顺时针，young gc -> young gc + concurrent mark ->Mixed GC顺序，进行垃圾回收
• 应用程序分配内存，当年轻代的Eden区用尽时开始年轻代回收过程：G1年轻代收集阶段是一个并行的独占式收集器。在年轻代回收期，G1 GC暂停所有应用程序线程，启动多线程执行年轻代回收。然后从年轻代区间移动存活对象到Surivivor区间或者老年区间，也有可能是两个区间都会涉及
• 当堆内存使用达到一定值(默认45%)时，开始老年代并发标记过程
• 标记完成马上开始混合回收过程，对于一个混合回收期，G1 GC从老年代区间移动存活对象到空闲区间，这些空闲区间也就成为了老年代的一部分。和年轻代不同，老年代的G1回收器和其他GC不同，G1的老年代回收期不需要整个老年代被回收，一次只需要扫描/回收一小部分老年代的Region就可以了。同时，这个老年代Region是和年轻代一起被回收的
• 举个例子：一个Web服务器，Java进程最大堆内存为4G，每分钟响应1500个请求，每45秒钟会新分配大约2G的内存，G1会每45秒钟进行一次年轻代回收，每31个小时整个堆的使用率会达到45%，会开始老年代并发标记过程，标记完成后开始四到五次的混合回收

记忆集与写屏障

• Remembered Set 记忆集
• 一个对象被不同区域引用的问题
• 一个Region不可能是孤立的，一个Region中的对象可能被其他任意Region中对象引用，判断对象存活时，是否需要扫描整个Java堆才能保存准确
• 在其其得分代收集器，也存在这样的问题(G1更突出)
• 回收新生代也不得不同时扫描老年代？
• 这样的话会降低Minor GC的效率
• 解决方法
• 无论G1还是其他分代收集器，JVM都是使用Remembered Set来避免全局扫描
• 每个Region都有一个对应的Remembered Set
• 每次Reference类型数据写操作时，都会产生一个Write Brrier暂时中断操作
• 然后检查将要写入的引用指向的对象是否和该Reference类型数据在不同的Region(其他收集器：检查老年代对象是否引用了新生代对象)
• 如果不同，通过CardTable把相关引用信息记录到引用指向对象的所在Region对应的Remembered Set中
• 当进行垃圾收集时，在GC根节点的枚举范围加入Remembered Set；就可以保证不进行全局扫描，也不会有遗漏
• G1比其他垃圾回收器多占用10%到20%的空间用于记忆集

G1垃圾回收过程的详细说明

G1垃圾回收的优化建议

垃圾回收器总结

GC日志分析

垃圾回收器的新发展

附录

1.字节码文件反编译内容

// 字节码文件反编译
F:\git\myself\firefish-mall\firefish-game\target\classes\com\wd\chatroom\client>javap -v ChatClient.class
Classfile /F:/git/myself/firefish-mall/firefish-game/target/classes/com/wd/chatroom/client/ChatClient.class
  Last modified 2024-5-10; size 1850 bytes
  MD5 checksum 86e83c0304e366ab162244f345048b70
  Compiled from "ChatClient.java"
public class com.wd.chatroom.client.ChatClient
  minor version: 0
  major version: 52
  flags: ACC_PUBLIC, ACC_SUPER
Constant pool:
    #1 = Methodref          #29.#63       // java/lang/Object."<init>":()V
    #2 = Class              #64           // java/net/Socket
    #3 = Class              #65           // com/wd/chatroom/client/ChatClient
    #4 = String             #66           // 127.0.0.1
    #5 = Methodref          #2.#67        // java/net/Socket."<init>":(Ljava/lang/String;I)V
    #6 = Class              #68           // java/io/BufferedReader
    #7 = Class              #69           // java/io/InputStreamReader
    #8 = Methodref          #2.#70        // java/net/Socket.getInputStream:()Ljava/io/InputStream;
    #9 = Methodref          #7.#71        // java/io/InputStreamReader."<init>":(Ljava/io/InputStream;)V
   #10 = Methodref          #6.#72        // java/io/BufferedReader."<init>":(Ljava/io/Reader;)V
   #11 = Class              #73           // java/io/PrintWriter
   #12 = Methodref          #2.#74        // java/net/Socket.getOutputStream:()Ljava/io/OutputStream;
   #13 = Methodref          #11.#75       // java/io/PrintWriter."<init>":(Ljava/io/OutputStream;Z)V
   #14 = Fieldref           #76.#77       // java/lang/System.in:Ljava/io/InputStream;
   #15 = Fieldref           #76.#78       // java/lang/System.out:Ljava/io/PrintStream;
   #16 = String             #79           // >
   #17 = Methodref          #80.#81       // java/io/PrintStream.println:(Ljava/lang/String;)V
   #18 = Methodref          #6.#82        // java/io/BufferedReader.readLine:()Ljava/lang/String;
   #19 = String             #83           // quit
   #20 = Methodref          #58.#84       // java/lang/String.equals:(Ljava/lang/Object;)Z
   #21 = Methodref          #11.#81       // java/io/PrintWriter.println:(Ljava/lang/String;)V
   #22 = Class              #85           // java/lang/StringBuilder
   #23 = Methodref          #22.#63       // java/lang/StringBuilder."<init>":()V
   #24 = String             #86           // Server:
   #25 = Methodref          #22.#87       // java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   #26 = Methodref          #22.#88       // java/lang/StringBuilder.toString:()Ljava/lang/String;
   #27 = Methodref          #2.#89        // java/net/Socket.close:()V
   #28 = Methodref          #76.#90       // java/lang/System.exit:(I)V
   #29 = Class              #91           // java/lang/Object
   #30 = Utf8               SERVER_IP
   #31 = Utf8               Ljava/lang/String;
   #32 = Utf8               ConstantValue
   #33 = Utf8               SERVER_PORT
   #34 = Utf8               I
   #35 = Integer            1234
   #36 = Utf8               <init>
   #37 = Utf8               ()V
   #38 = Utf8               Code
   #39 = Utf8               LineNumberTable
   #40 = Utf8               LocalVariableTable
   #41 = Utf8               this
   #42 = Utf8               Lcom/wd/chatroom/client/ChatClient;
   #43 = Utf8               main
   #44 = Utf8               ([Ljava/lang/String;)V
   #45 = Utf8               line
   #46 = Utf8               response
   #47 = Utf8               args
   #48 = Utf8               [Ljava/lang/String;
   #49 = Utf8               socket
   #50 = Utf8               Ljava/net/Socket;
   #51 = Utf8               input
   #52 = Utf8               Ljava/io/BufferedReader;
   #53 = Utf8               out
   #54 = Utf8               Ljava/io/PrintWriter;
   #55 = Utf8               keyboard
   #56 = Utf8               StackMapTable
   #57 = Class              #48           // "[Ljava/lang/String;"
   #58 = Class              #92           // java/lang/String
   #59 = Utf8               Exceptions
   #60 = Class              #93           // java/io/IOException
   #61 = Utf8               SourceFile
   #62 = Utf8               ChatClient.java
   #63 = NameAndType        #36:#37       // "<init>":()V
   #64 = Utf8               java/net/Socket
   #65 = Utf8               com/wd/chatroom/client/ChatClient
   #66 = Utf8               127.0.0.1
   #67 = NameAndType        #36:#94       // "<init>":(Ljava/lang/String;I)V
   #68 = Utf8               java/io/BufferedReader
   #69 = Utf8               java/io/InputStreamReader
   #70 = NameAndType        #95:#96       // getInputStream:()Ljava/io/InputStream;
   #71 = NameAndType        #36:#97       // "<init>":(Ljava/io/InputStream;)V
   #72 = NameAndType        #36:#98       // "<init>":(Ljava/io/Reader;)V
   #73 = Utf8               java/io/PrintWriter
   #74 = NameAndType        #99:#100      // getOutputStream:()Ljava/io/OutputStream;
   #75 = NameAndType        #36:#101      // "<init>":(Ljava/io/OutputStream;Z)V
   #76 = Class              #102          // java/lang/System
   #77 = NameAndType        #103:#104     // in:Ljava/io/InputStream;
   #78 = NameAndType        #53:#105      // out:Ljava/io/PrintStream;
   #79 = Utf8               >
   #80 = Class              #106          // java/io/PrintStream
   #81 = NameAndType        #107:#108     // println:(Ljava/lang/String;)V
   #82 = NameAndType        #109:#110     // readLine:()Ljava/lang/String;
   #83 = Utf8               quit
   #84 = NameAndType        #111:#112     // equals:(Ljava/lang/Object;)Z
   #85 = Utf8               java/lang/StringBuilder
   #86 = Utf8               Server:
   #87 = NameAndType        #113:#114     // append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   #88 = NameAndType        #115:#110     // toString:()Ljava/lang/String;
   #89 = NameAndType        #116:#37      // close:()V
   #90 = NameAndType        #117:#118     // exit:(I)V
   #91 = Utf8               java/lang/Object
   #92 = Utf8               java/lang/String
   #93 = Utf8               java/io/IOException
   #94 = Utf8               (Ljava/lang/String;I)V
   #95 = Utf8               getInputStream
   #96 = Utf8               ()Ljava/io/InputStream;
   #97 = Utf8               (Ljava/io/InputStream;)V
   #98 = Utf8               (Ljava/io/Reader;)V
   #99 = Utf8               getOutputStream
  #100 = Utf8               ()Ljava/io/OutputStream;
  #101 = Utf8               (Ljava/io/OutputStream;Z)V
  #102 = Utf8               java/lang/System
  #103 = Utf8               in
  #104 = Utf8               Ljava/io/InputStream;
  #105 = Utf8               Ljava/io/PrintStream;
  #106 = Utf8               java/io/PrintStream
  #107 = Utf8               println
  #108 = Utf8               (Ljava/lang/String;)V
  #109 = Utf8               readLine
  #110 = Utf8               ()Ljava/lang/String;
  #111 = Utf8               equals
  #112 = Utf8               (Ljava/lang/Object;)Z
  #113 = Utf8               append
  #114 = Utf8               (Ljava/lang/String;)Ljava/lang/StringBuilder;
  #115 = Utf8               toString
  #116 = Utf8               close
  #117 = Utf8               exit
  #118 = Utf8               (I)V
{
  public com.wd.chatroom.client.ChatClient();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         4: return
      LineNumberTable:
        line 6: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       5     0  this   Lcom/wd/chatroom/client/ChatClient;

  public static void main(java.lang.String[]) throws java.io.IOException;
    descriptor: ([Ljava/lang/String;)V
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
      stack=5, locals=7, args_size=1
         0: new           #2                  // class java/net/Socket
         3: dup
         4: ldc           #4                  // String 127.0.0.1
         6: sipush        1234
         9: invokespecial #5                  // Method java/net/Socket."<init>":(Ljava/lang/String;I)V
        12: astore_1
        13: new           #6                  // class java/io/BufferedReader
        16: dup
        17: new           #7                  // class java/io/InputStreamReader
        20: dup
        21: aload_1
        22: invokevirtual #8                  // Method java/net/Socket.getInputStream:()Ljava/io/InputStream;
        25: invokespecial #9                  // Method java/io/InputStreamReader."<init>":(Ljava/io/InputStream;)V
        28: invokespecial #10                 // Method java/io/BufferedReader."<init>":(Ljava/io/Reader;)V
        31: astore_2
        32: new           #11                 // class java/io/PrintWriter
        35: dup
        36: aload_1
        37: invokevirtual #12                 // Method java/net/Socket.getOutputStream:()Ljava/io/OutputStream;
        40: iconst_1
        41: invokespecial #13                 // Method java/io/PrintWriter."<init>":(Ljava/io/OutputStream;Z)V
        44: astore_3
        45: new           #6                  // class java/io/BufferedReader
        48: dup
        49: new           #7                  // class java/io/InputStreamReader
        52: dup
        53: getstatic     #14                 // Field java/lang/System.in:Ljava/io/InputStream;
        56: invokespecial #9                  // Method java/io/InputStreamReader."<init>":(Ljava/io/InputStream;)V
        59: invokespecial #10                 // Method java/io/BufferedReader."<init>":(Ljava/io/Reader;)V
        62: astore        4
        64: getstatic     #15                 // Field java/lang/System.out:Ljava/io/PrintStream;
        67: ldc           #16                 // String >
        69: invokevirtual #17                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
        72: aload         4
        74: invokevirtual #18                 // Method java/io/BufferedReader.readLine:()Ljava/lang/String;
        77: astore        5
        79: aload         5
        81: ldc           #19                 // String quit
        83: invokevirtual #20                 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
        86: ifeq          92
        89: goto          133
        92: aload_3
        93: aload         5
        95: invokevirtual #21                 // Method java/io/PrintWriter.println:(Ljava/lang/String;)V
        98: aload_2
        99: invokevirtual #18                 // Method java/io/BufferedReader.readLine:()Ljava/lang/String;
       102: astore        6
       104: getstatic     #15                 // Field java/lang/System.out:Ljava/io/PrintStream;
       107: new           #22                 // class java/lang/StringBuilder
       110: dup
       111: invokespecial #23                 // Method java/lang/StringBuilder."<init>":()V
       114: ldc           #24                 // String Server:
       116: invokevirtual #25                 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
       119: aload         6
       121: invokevirtual #25                 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
       124: invokevirtual #26                 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
       127: invokevirtual #17                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
       130: goto          64
       133: aload_1
       134: invokevirtual #27                 // Method java/net/Socket.close:()V
       137: iconst_0
       138: invokestatic  #28                 // Method java/lang/System.exit:(I)V
       141: return
      LineNumberTable:
        line 11: 0
        line 12: 13
        line 13: 32
        line 14: 45
        line 17: 64
        line 18: 72
        line 19: 79
        line 20: 92
        line 21: 98
        line 22: 104
        line 23: 130
        line 25: 133
        line 26: 137
        line 27: 141
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
           79      51     5  line   Ljava/lang/String;
          104      26     6 response   Ljava/lang/String;
            0     142     0  args   [Ljava/lang/String;
           13     129     1 socket   Ljava/net/Socket;
           32     110     2 input   Ljava/io/BufferedReader;
           45      97     3   out   Ljava/io/PrintWriter;
           64      78     4 keyboard   Ljava/io/BufferedReader;
      StackMapTable: number_of_entries = 3
        frame_type = 255 /* full_frame */
          offset_delta = 64
          locals = [ class "[Ljava/lang/String;", class java/net/Socket, class java/io/BufferedReader, class java/io/PrintWriter, class java/io/BufferedReader ]
          stack = []
        frame_type = 252 /* append */
          offset_delta = 27
          locals = [ class java/lang/String ]
        frame_type = 250 /* chop */
          offset_delta = 40
    Exceptions:
      throws java.io.IOException
}
SourceFile: "ChatClient.java"

2.常用调优工具

• 1.JDK命令行
  • 1.jsp
  • 2.jinfo
  • 3.jstat
  • 4.javap
  • 5.jmap
• 2.Eclipse：Memory Analyzer Tool
• 3.Jconsole
• 4.VisualVM
• 5.Jprofiler
• 6.Java Flight Recorder（JMC）
• 7.GCViewer
• 8.GC Easy

1.javap

• 1.作用：反汇编一个或多个类文件参考地址

  // 多个类文件之间用逗号分割
  javap [选项] classfile...
  javap [选项] classfile... > 指定文件路径