JVM与GC二7、GC垃圾回收GC算法（引用计数/复制/标记清除/标记整理）是内存回收的方法论，垃圾收集器是算法的落地实

欢迎大家关注 github.com/hsfxuebao/j… ，希望对大家有所帮助，要是觉得可以的话麻烦给点一下Star哈

7、GC 垃圾回收

GC垃圾回收算法和垃圾收集器的关系？分别是什么？

GC算法（引用计数/复制/标记清除/标记整理）是内存回收的方法论，垃圾收集器是算法的落地实现
目前为止还没有完美的收集器出现，更没有万能的收集器，只有针对具体应用最合适的收集器，进行分代收集
四种主要的垃圾收集器：串行、并行、并发、G1

串行垃圾回收器（Serial）

它为单线程环境设计，且只使用一个线程进行垃圾回收，会暂停所有的用户线程，所以不适合服务器环境

程序 --> GC --> 程序 --> GC --> 程序 --> GC
1

并行垃圾回收器（Parallel）

多个垃圾收集线程并行工作，此时用户线程是暂停的，适用于科学计算/大数据处理首台处理等弱交互场景

     --> GC         --> GC          --> GC
程序 --> GC --> 程序 --> GC --> 程序 --> GC
     --> GC         --> GC          --> GC
123

并发垃圾回收器（Concurrent Mark Sweep）

用户线程和垃圾收集线程同时执行（不一定并行，可能交替执行）不需要停顿用户线程。互联网公司多用，适用对响应时间有要求的场景

     --> GC         --> 程序         --> 程序
程序 --> GC --> 程序 --> GC --> 程序 --> GC
     --> GC         --> GC          --> 程序
123

G1 垃圾回收器（Garbage first）

G1垃圾回收器将堆内存分割成不同的区域然后并发地对其进行垃圾回收

串行与并行、STW与并发

串行与并行的垃圾回收器执行 GC 时，都会中断用户线程，STW 时间都会比较长（相对于并发来讲）
并发垃圾回收器可与用户线程并发执行，降低了 STW 的时间

8、垃圾收集器

怎么看服务器默认的垃圾收集器是哪个？生产上如何配置垃圾收集器？谈谈你对垃圾收集器的理解

8.1、查看默认垃圾收集器

命令行指令：java -XX:+PrintCommandLineFlags -version

-XX:+UseParallelGC：表示使用 UseParallelGC 垃圾收集器

C:\Users\Heygo\Desktop\Interview>java -XX:+PrintCommandLineFlags -version -XX:InitialHeapSize=266620736 -XX:MaxHeapSize=4265931776 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocatio n -XX:+UseParallelGC java version "1.8.0_144" Java(TM) SE Runtime Environment (build 1.8.0_144-b01) Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode) 123456

8.2、默认的垃圾收集器

Java的GC回收的类型主要有几种：UseSerialGC，UseParallelGC，UseConcMarkSweepGC，UseParNewGC，UseParallelOldGC，UseG1GC
UseSerialOldGC被淘汰了

撕个 OpenJDK 源码

bool Arguments::check_gc_consistency() { bool status = true; // Ensure that the user has not selected conflicting sets // of collectors. [Note: this check is merely a user convenience; // collectors over-ride each other so that only a non-conflicting // set is selected; however what the user gets is not what they // may have expected from the combination they asked for. It's // better to reduce user confusion by not allowing them to // select conflicting combinations.

uint i = 0; if (UseSerialGC) i++; if (UseConcMarkSweepGC || UseParNewGC) i++; if (UseParallelGC || UseParallelOldGC) i++; if (UseG1GC) i++; if (i > 1) { jio_fprintf(defaultStream::error_stream(), "Conflicting collector combinations in option list; " "please refer to the release notes for the combinations " "allowed\n");
```
status = false;
```
} return status; } 12345678910111213141516171819202122232425

8.3、垃圾收集器细讲

垃圾收集器概述

垃圾收集器就来具体实现这些GC算法并实现内存回收。不同厂商、不同版本的虚拟机实现差别很大，HotSpot中包含的收集器如下图所示：

垃圾收集器对应的组合关系

8.3.1、部分参数说明

DefNew：Default New Generation
Tenured：Old
ParNew：Parallel New Generation
PSYoungGen：Parallel Scavenge
ParOldGen：Parallel Old Generation

8.3.2、Server & Client

适用范围：只需要掌握Server模式即可，Client模式基本不会用
根据操作系统以及硬件区分 Client 和 Server：
- 32位Window操作系统，不论硬件如何都默认使用Client的JVM模式
- 32位其它操作系统，2G内存同时有2个cpu以上用Server模式，低于该配置还是Client模式
- 64位only server模式

8.3.3、新生代垃圾回收

串行GC（Serial）/（Serial Copying）

串行收集器：Serial收集器

一句话：一个单线程的收集器，在进行垃圾收集时候，必须暂停其他所有的工作线程直到它集结束。
串行收集器是最古老，最稳定以及效率高的收集器，只使用一个线程去回收但其在进行垃圾收集过程中可能会产生较长的停顿（Stop-The-World状态）。
虽然在收集垃圾过程中需要暂停所有其他的工作线程，但是它简单高效，对于限定单个CPU环境来说，没有线程交互的开销可以获得最高的单线程垃圾收集效率，因此Serial垃圾收集器依然是java虚拟机运行在Client模式下默认的新生代垃圾收集器。

参数配置：

对应JVM参数是：-XX:+UseSerialGC
开启后会使用：Serial（Young区用）+Serial Old（Old区用）的收集器组合
表示：新生代、老年代都会使用串行回收收集器，新生代使用复制算法，老年代使用标记-整理算法

-Xms10m -Xmx10m -XX:PrintGCDetails -XX:+PrintCommandLineFlags -XX:UseSerialGC 1

并行GC（ParNew）

ParNew（并行）收集器

一句话：使用多线程进行垃圾回收，在垃圾收集时，会Stop-the-World暂停其他所有的工作线程直到它收集结束。
ParNew收集器其实就是Serial收集器新生代的并行多线程版本，最常见的应用场景是配合老年代的CMS GC工作，其余的行为和Seria收集器完全一样，ParNew垃圾收集器在垃圾收集过程中同样也要暂停所有其他的工作线程。它是很多java虚拟机运行在Server模式下新生代的默认垃圾收集器。

参数配置：

常用对应JVM参数：-XX:+UseParNewGC启用ParNew收集器，只影响新生代的收集，不影响老年代
开启上述参数后，会使用：ParNew（Young区用）+Serial Old的收集器组合，新生代使用复制算法，老年代采用标记-整理算法
但是，ParNew+Tenured这样的搭配，java8已经不再被推荐： Java HotSpot（TM）64-Bit Server VM warning：Using the ParNew young collector with the Serial old collector is deprecated and will likely be removed in a future release
-XX:ParallelGCThreads 限制线程数量，默认开启和CPU数目相同的线程数

-Xms10m -Xmx10m -XX:PrintGCDetails -XX:+PrintCommandLineFlags -XX:+UseParNewGC 1

并行回收GC（Parallel）/（Parallel Scavenge）

Parallel 并行回收

Parallel Scavenge收集器类似ParNew也是一个新生代垃圾收集器，使用复制算法，也是一个并行的多线程的垃圾收集器，俗称吞吐量优先收集器。一句话：串行收集器在新生代和老年代的并行化
它重点关注的是：可控制的吞吐量（Thoughput=运行用户代码时间/(运行用户代码时间+垃圾收集时间)，也即比如程序运行100分钟，垃圾收集时间1分钟，吞吐量就是99%）。高吞吐量意味着高效利用CPU的时间，它多用于在后台运算而不需要太多交互的任务。
自适应调节策略也是ParallelScavenge 收集器与ParNew收集器的一个重要区别。（自适应调节策略：虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间（-XX:MaxGCPauseMilis）或最大的吞吐量。

参数配置：

常用JVM参数：-XX:+UseParallelGC或-XX:+UseParallelOldGC（可互相激活）使用Parallel Scanvenge收集器
开启该参数后：新生代使用复制算法，老年代使用标记-整理算法
多说一句：-XX:ParallelGCThreads=数字N表示启动多少个GC线程
- cpu>8：N=5/8
- cpu<8：N=实际个数
-Xms10m -Xmx10m -XX:PrintGCDetails -XX:+PrintCommandLineFlags -XX:+UseParallelGC 或者 -Xms10m -Xmx10m -XX:PrintGCDetails -XX:+PrintCommandLineFlags -XX:+UseParallelOldlGC 123

8.3.4、老年代垃圾回收

串行GC（Serial Old）/（Serial MSC）

Serial Old是 Serial垃圾收集器老年代版本，它同样是个单线程的收集器，使用标记-整理算法，这个收集器也主要是运行在Client默认的java虚拟机默认的年老代垃圾收集器。
在Server模式下，主要有两个用途（了解）：
- 在JDK1.5之前版本中与新生代的Parallel Scavenge 收集器搭配使用。即垃圾收集器组合为：Parallel Scavenge+Serial Old
- 在JDK1.5之后作为老年代版中使用CMS收集器的后备垃圾收集方案。

参数配置：

-Xms10m -Xmx10m -XX:PrintGCDetails -XX:+PrintCommandLineFlags -XX:+UseSerialOldlGC
1

并行GC（Parallel Old）/（Parallel MSC）

Parallel Old收集器是Parallel Scavenge的老年代版本，使用多线程的标记-整理算法，Parallel Old收集器在JDK1.6才开始提供。
在JDK1.6之前，新生代使用ParallelScavenge收集器只能搭配年老代的Serial Old收集器，只能保证新生代的吞吐量优先，无法保证整体的吞吐量。即在JDK1.6之前的垃圾回收器的搭配方案为Parallel Scavenge+Serial Old
Parallel Old正是为了在年老代同样提供吞吐量优先的垃圾收集器，如果系统对吞吐量要求比较高，JDK1.8后可以优先考虑新生代。Parallel Scavenge和年老代Parallel Old 收集器的搭配策略。在JDK1.8的垃圾回收器的搭配方案为Parallel Scavenge+Parallel Old

参数配置：

JVM常用参数：-XX:+UseParallelOldGC 使用Parallel Old收集器
设置该参数后，新生代Parallel+老年代Parallel Old

-Xms10m -Xmx10m -XX:PrintGCDetails -XX:+PrintCommandLineFlags -XX:+UseParallelOldlGC 或者 -Xms10m -Xmx10m -XX:PrintGCDetails -XX:+PrintCommandLineFlags -XX:+UseParallelGC 123

并发标记清除GC（CMS）

CMS收集器（Concurrent Mark Sweep：并发标记清除）是一种以获取最短回收停顿时间为目标的收集器。
适合应用在互联网站或者B/S系统的服务器上，这类应用尤其重视服务器的响应速度，希望系统停顿时间最短。
CMS非常适合堆内存大、CPU核数多的服务器端应用，也是G1出现之前大型应用的首选收集器。
Concurrent Mark Sweep并发标记清除，并发收集低停顿，并发指的是与用户线程一起执行

参数配置：

开启该收集器的JVM参数：-XX:+UseConcMarkSweepGC
开启该参数后会自动将-XX:+UseParNewGC打开开启该参数后，使用ParNew（Young区用）+CMS（Old区用）+Serial Old的收集器组合，Serial Old将作为CMS出错的后备收集器

-Xms10m -Xmx10m -XX:PrintGCDetails -XX:+PrintCommandLineFlags -XX:+UseConcMarkSweepGC 1

CMS 的 4 步过程

初始标记（CMS initial mark）：只是标记一下GC Roots能直接关联的对象，速度很快，仍然需要暂停所有的工作线程。
并发标记（CMS concurrent mark）和用户线程一起：进行GCRoots跟踪的过程，和用户线程一起工作，不需要暂停工作线程。主要标记过程，标记全部对象
重新标记（CMS remark）：为了修正在并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，仍然需要暂停所有的工作线程。由于并发标记时，用户线程依然运行，因此在正式清理前，再做修正
并发清除（CMS concurrent sweep）和用户线程一起：清除GC Roots不可达对象，和用户线程一起工作，不需要暂停工作线程。基于标记结果，直接清理对象由于耗时最长的并发标记和并发清除过程中，垃圾收集线程可以和用户现在一起并发工作，所以总体上来看CMS收集器的内存回收和用户线程是一起并发地执行。

CMS 四步骤总结

优点

并发收集停顿时间低

缺点

并发执行，对CPU压力较大：由于并发进行，CMS在收集与应用线程会同时会增加对堆内存的占用，也就是说，CMS必须要在老年代堆内存用尽之前完成垃圾回收，否则CMS回收失败时，将触发担保机制，串行老年代收集器将会以STW的方式进行一次GC，从而造成较大停顿时间
采用的标记清除算法会产生大量碎片：标记清除算法无法整理空间碎片，老年代空间会随着应用时长被逐步耗尽，最后将不得不通过担保机制对堆内存进行压缩。CMS也提供了参数-XX:CMSFulIGCsBeforeCompaction（默认0，即每次都进行内存整理）来指定多少次CMS收集之后，进行一次压缩的Full GC。

Demo 代码

/*
1.-Xms10m -Xmx10m -XX:+PrintGCDetails -XX:+PrintCommandLineFlags -XX:+UseSerialGC
2.-Xms10m -Xmx10m -XX:+PrintGCDetails -XX:+PrintCommandLineFlags -XX:+UseParNewGC
3.-Xms10m -Xmx10m -XX:+PrintGCDetails -XX:+PrintCommandLineFlags -XX:+UseParallelGC
4.-Xms10m -Xmx10m -XX:+PrintGCDetails -XX:+PrintCommandLineFlags -XX:+UseParallelOldGC
5.-Xms10m -Xmx10m -XX:+PrintGCDetails -XX:+PrintCommandLineFlags -XX:+UseConcMarkSweepGC
6.-Xms10m -Xmx10m -XX:+PrintGCDetails -XX:+PrintCommandLineFlags -XX:+UseG1GC
7.-Xms10m -Xmx10m -XX:+PrintGCDetails -XX:+PrintCommandLineFlags -XX:+UseSerialOldGC (已经没有了)
*/
public class GCDemo {

    public static void main(String[] args) {
        System.out.println("GCDemo...");
        try {
            String str = "bjtu";
            while (true) {
                str += str + new Random().nextInt(77777777) + new Random().nextInt(88888888);
                str.intern();
            }
        } catch (Throwable e) {
            e.printStackTrace();
        }
    }
}
123456789101112131415161718192021222324

8.4、如何选择垃圾收集器

9、G1 垃圾收集器

9.1、Before G1

以前收集器特点

年轻代和老年代是各自独立且连续的内存块
年轻代收集，使用单eden+S0+S1进行复制算法
老年代收集必须扫描整个老年代区域
都是以尽可能快速地执行GC为设计原则

9.2、G1 是什么

G1（Garbage-First）收集器，是一款面向服务端应用的收集器

从官网的描述中，我们知道G1是一种服务器端的垃圾收集器，应用在多处理器和大容量内存环境中，在实现高吞吐量的同时，尽可能的满足垃圾收集暂停时间的要求。另外，它还具有以下特性：

像CMS收集器一样，能与应用程序线程并发执行。
整理空闲空间更快。
需要更多的时间来预测GC停顿时间。
不希望牺牲大量的吞吐性能。
不需要更大的Java Heap。

G1收集器的设计目标是取代CMS收集器，它同CMS相比，在以下方面表现的更出色：

G1是一个有整理内存过程的垃圾收集器，不会产生很多内存碎片。
G1的Stop The World（STW）更可控，G1在停顿时间上添加了预测机制，用户可以指定期望停顿时间。

为什么会出现 G1？

CMS垃圾收集器虽然减少了暂停应用程序的运行时间，但是它还是存在着内存碎片问题。于是，为了去除内存碎片问题，同时又保留CMS垃圾收集器低暂停时间的优点，JAVA7发布了一个新的垃圾收集器——G1垃圾收集器。
G1是在2012年才在jdk1.7u4中可用。oracle官方计划在jdk9中将G1变成默认的垃圾收集器以替代CMS。它是一款面向服务端应用的收集器，主要应用在多CPU和大内存服务器环境下，极大的减少垃圾收集的停顿时间，全面提升服务器的性能，逐步替换java8以前的CMS收
主要改变是Eden，Survivor和Tenured等内存区域不再是连续的了，而是变成了一个个大小一样的region，每个region从1M到32M不等。一个region有可能属于Eden，Survivor或者Tenured内存区域。

9.3、G1 特点

G1能充分利用多CPU、多核环境硬件优势，尽量缩短STW。
G1整体上采用标记-整理算法，局部是通过复制算法，不会产生内存碎片。
宏观上看G1之中不再区分年轻代和老年代。把内存划分成多个独立的子区域（Region），可以近似理解为一个围棋的棋盘。
G1收集器里面讲整个的内存区都混合在一起了，但其本身依然在小范围内要进行年轻代和老年代的区分，保留了新生代和老年代，但它们不再是物理隔离的，而是一部分Region的集合且不需要Region是连续的，也就是说依然会采用不同的GC方式来处理不同的区域。
G1虽然也是分代收集器，但整个内存分区不存在物理上的年轻代与老年代的区别，也不需要完全独立的survivor（to space）堆做复制准备。G1只有逻辑上的分代概念，或者说每个分区都可能随G1的运行在不同代之间前后切换。

9.4、G1 底层原理

Region区域化垃圾收集器：最大的好处是化整为零，避免全内存扫描，只需要按区域来进行扫描即可

区域化内存划片Region，整体编为了一些列不连续的内存区域，避免了全内存区的GC操作。
核心思想是将整个堆内存区域分成大小相同的子区域（Region），在JVM启动时会自动设置这些子区域的大小。
在堆的使用上，G1并不要求对象的存储一定是物理上连续的，只要逻辑上连续即可，每个分区也不会固定地为某个代服务，可以按需在年轻代和老年代之间切换。
启动时可以通过参数-XX:G1HeapRegionSize=n可指定分区大小（1MB~32MB，且必须是2的幂），默认将整堆划分为2048个分区。
每个Region 小范围在1MB~32MB，最多能设置2048个区域，也即能够支持的最大内存为：32MB*2048=65536MB=64G内存

G1算法将堆划分为若干个区域（Region），它仍然属于分代收集器

这些Region的一部分包含新生代，新生代的垃圾收集依然采用暂停所有应用线程的方式，将存活对象拷贝到老年代或者Survivor空间。
这些Region的一部分包含老年代，G1收集器通过将对象从一个区域复制到另外一个区域，完成了清理工作。这就意味着，在正常的处理过程中，G1完成了堆的压缩（至少是部分堆的压缩），这样也就不会有CMS内存碎片问题的存在了。

在G1中，还有一种特殊的区域，叫Humongous（巨大的）区域

如果一个对象占用的空间超过了分区容量50%以上，G1收集器就认为这是一个巨型对象。这些巨型对象默认直接会被分配在年老代，但是如果它是一个短期存在的巨型对象，就会对垃圾收集器造成负面影响。
为了解决这个问题，G1划分了一个Humongous区，它用来专门存放巨型对象。如果一个H区装不下一个巨型对象，那么G1会寻找连续的H分区来存储。为了能找到连续的H区，有时候不得不启动Full GC。

G1 回收步骤

G1收集器下的Young GC针对Eden区进行收集，Eden区耗尽后会被触发，主要是小区域收集+形成连续的内存块，避免内存碎片

Eden区的数据移动到Survivor区，假如出现Survivor区空间不够，Eden区数据会部会晋升到Old区
Survivor区的数据移动到新的Survivor区，部会数据晋升到Old区
最后Eden区收拾干净了，GC结束，用户的应用程序继续执行。

G1 工作的四大步骤

初始标记：只标记GC Roots能直接关联到的对象
并发标记：进行GC Roots Tracing的过程
最终标记：修正并发标记期间，因程序运行导致标记发生变化的那一部分对象
筛选回收：根据时间来进行价值最大化的回收

G1 Demo 代码

代码

public class GCDemo {

public static void main(String[] args) {
    System.out.println("GCDemo...");
    try {
        String str = "bjtu";
        while (true) {
            str += str + new Random().nextInt(77777777) + new Random().nextInt(88888888);
            str.intern();
        }
    } catch (Throwable e) {
        e.printStackTrace();
    }
}

} 12345678910111213141516171819202122

JVM 参数

-Xms10m -Xmx10m -XX:+PrintGCDetails -XX:+PrintCommandLineFlags -XX:+UseG1GC 1
程序运行结果
- initial-mark：初始标记
- GC concurrent-mark-start ：并发标记
- GC remark：最终标记
- GC cleanup：筛选回收
[GC pause (G1 Humongous Allocation) (young) (initial-mark) (to-space exhausted), 0.0032657 secs] [Parallel Time: 1.8 ms, GC Workers: 8] [GC Worker Start (ms): Min: 116.9, Avg: 117.0, Max: 117.2, Diff: 0.2] [Ext Root Scanning (ms): Min: 0.1, Avg: 0.3, Max: 0.6, Diff: 0.5, Sum: 2.4] [Update RS (ms): Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 0.8] [Processed Buffers: Min: 0, Avg: 1.9, Max: 4, Diff: 4, Sum: 15] [Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0] [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0] [Object Copy (ms): Min: 1.0, Avg: 1.2, Max: 1.3, Diff: 0.3, Sum: 9.8] [Termination (ms): Min: 0.0, Avg: 0.0, Max: 0.1, Diff: 0.1, Sum: 0.4] [Termination Attempts: Min: 1, Avg: 6.9, Max: 14, Diff: 13, Sum: 55] [GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.2] [GC Worker Total (ms): Min: 1.5, Avg: 1.7, Max: 1.8, Diff: 0.2, Sum: 13.5] [GC Worker End (ms): Min: 118.7, Avg: 118.7, Max: 118.7, Diff: 0.0] [Code Root Fixup: 0.0 ms] [Code Root Purge: 0.0 ms] [Clear CT: 0.2 ms] [Other: 1.3 ms] [Evacuation Failure: 0.9 ms] [Choose CSet: 0.0 ms] [Ref Proc: 0.3 ms] [Ref Enq: 0.0 ms] [Redirty Cards: 0.1 ms] [Humongous Register: 0.0 ms] [Humongous Reclaim: 0.0 ms] [Free CSet: 0.0 ms] [Eden: 5120.0K(6144.0K)->0.0B(1024.0K) Survivors: 0.0B->1024.0K Heap: 7351.7K(10.0M)->6167.8K(10.0M)] [Times: user=0.09 sys=0.00, real=0.00 secs] [GC concurrent-root-region-scan-start] [GC concurrent-root-region-scan-end, 0.0009353 secs] [GC concurrent-mark-start] [GC pause (G1 Humongous Allocation) (young) (to-space exhausted), 0.0037669 secs] [Parallel Time: 2.7 ms, GC Workers: 8] [GC Worker Start (ms): Min: 122.1, Avg: 122.1, Max: 122.2, Diff: 0.1] [Ext Root Scanning (ms): Min: 0.1, Avg: 0.4, Max: 2.6, Diff: 2.5, Sum: 3.3] [Update RS (ms): Min: 0.0, Avg: 0.0, Max: 0.1, Diff: 0.1, Sum: 0.1] [Processed Buffers: Min: 0, Avg: 0.4, Max: 3, Diff: 3, Sum: 3] [Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0] [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.2, Diff: 0.2, Sum: 0.2] [Object Copy (ms): Min: 0.0, Avg: 1.1, Max: 1.5, Diff: 1.5, Sum: 9.0] [Termination (ms): Min: 0.0, Avg: 1.0, Max: 1.3, Diff: 1.3, Sum: 7.9] [Termination Attempts: Min: 1, Avg: 1.0, Max: 1, Diff: 0, Sum: 8] [GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1] [GC Worker Total (ms): Min: 2.5, Avg: 2.6, Max: 2.6, Diff: 0.1, Sum: 20.6] [GC Worker End (ms): Min: 124.7, Avg: 124.7, Max: 124.7, Diff: 0.0] [Code Root Fixup: 0.0 ms] [Code Root Purge: 0.0 ms] [Clear CT: 0.1 ms] [Other: 0.9 ms] [Evacuation Failure: 0.5 ms] [Choose CSet: 0.0 ms] [Ref Proc: 0.2 ms] [Ref Enq: 0.0 ms] [Redirty Cards: 0.1 ms] [Humongous Register: 0.0 ms] [Humongous Reclaim: 0.0 ms] [Free CSet: 0.0 ms] [Eden: 1024.0K(1024.0K)->0.0B(1024.0K) Survivors: 1024.0K->0.0B Heap: 7372.3K(10.0M)->6188.4K(10.0M)] [Times: user=0.00 sys=0.00, real=0.00 secs] [GC concurrent-mark-end, 0.0043902 secs] [GC remark [Finalize Marking, 0.0001364 secs] [GC ref-proc, 0.0002039 secs] [Unloading, 0.0004323 secs], 0.0008988 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [GC cleanup 7372K->7372K(10M), 0.0005463 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364
G1 中堆分为两部分：garbage-first heap 和 Metaspace（Non-heap）

Heap garbage-first heap total 10240K, used 4199K [0x00000000ff600000, 0x00000000ff700050, 0x0000000100000000) region size 1024K, 1 young (1024K), 0 survivors (0K) Metaspace used 3510K, capacity 4496K, committed 4864K, reserved 1056768K class space used 384K, capacity 388K, committed 512K, reserved 1048576K 12345

9.5、G1 常用参数

常用配置参数（了解）

-XX:+UseG1GC
-XX:G1HeapRegionSize=n：设置G1区域的大小。值是2的幂，范围是1M到32M。目标是根据最小的Java堆大小划分出约2048个区域
-XX:MaxGCPauseMillis=n：最大停顿时间，这是个软目标，JVM将尽可能（但不保证）停顿时间小于这个时间
-XX:InitiatingHeapOccupancyPercent=n：堆占用了百分之多少的时候就触发GC，默认是45
-XX:ConcGCThreads=n：并发GC使用的线程数
-XX:G1ReservePercent=n：设置作为空闲空间的预留内存百分比，以降低目标空间溢出的风险，默认值是10%

G1 常用配置：

开发人员仅仅需要声明以下参数即可：
三步归纳：开始G1+设置最大内存+设置最大停顿时间

-XX:MaxGCPauseMilis=n：最大GC停顿时间，单位毫秒，这是个软目标，JVM将尽可能（但不保证）停顿小于这个时间

-XX:+UseG1GC -Xmx32g -XX:MaxGCPauseMillis=100 1

9.6、G1 的优势

G1 相较于 CMS 的优势

比起CMS有两个优势：

G1不会产生内存碎片
可以精确控制停顿。该收集器把整个堆（新生代、老生代）划分为多个固定大小的区域，每次根据允许停顿的时间去收集垃圾最多的区域。

10、生产调优

10.1、SpringBoot 调优步骤

SpringBoot 微服务的生产部署和调参优化步骤

IDEA开发完微服务工程
maven进行clean + package
要求微服务启动的时候，同时配置我们的JVM/GC的调优参数
公式：java -server jvm的各种参数 -jar jar/war包名字

java -server -Xms1024m -Xmx1024m -XX+UseG1GC -jar springboot2019-1.0-SNAPSHOT.war 1

10.2、调优思路和性能评估

整机：top（查看 CPU、内存使用率等，也可使用精简版系统性能命令：uptime）

主要查看 CPU、MEM、load average（按 1 可详细查看 CPU 的每个核心状态）

CPU：vmstat（查看 CPU 使用情况）

vmstat -n 2 3

一般vmstat工具的使用是通过两个数字参数来完成的，第一个参数是采样的时间间隔数单位是秒，第二个参数是采样的次数

参数含义

-procs
- r：运行和等待CPU时间片的进程数，原则上1核的CPU的运行队列不要超过2，整个系统的运行队列不能超过总核数的2倍，否则代表系统压力过大
- b：等待资源的进程数，比如正在等待磁盘I/O、网络I/O等
-cpu
- us：用户进程消耗CPU时间百分比，us值高，用户进程消耗CPU时间多，如果长期大于50%，需要优化程序
- sy：内核进程消耗的CPU时间百分比
- 说明：us +sy参考值为80%，如果us+sy大于80%，说明可能存在CPU不足
- id：处于空闲的CPU百分比
- wa：系统等待IO的CPU时间百分比
- st：来自于一个虚拟机偷取的CPU时间的百分比

其他的查看指令

查看所有cpu核信息：mpstat -P ALL 2 （每两秒采样一次）
每个进程使用cpu的用量分解信息：pidstat -u 1 -p 进程编号

内存：free（查看应用程序可用内存数）

free：以字节为单位
free -g：以 GB 为单位
free -m：以 GB 为单位

经验值

应用程序可用内存/系统物理内存>70%内存充足
应用程序可用内存/系统物理内存<20%内存不足，需要增加内存
20%<应用程序可用内存/系统物理内存<70%内存基本够用

pidstat -p 进程号 -r 采样间隔秒数，可查看进程占用内存的情况

硬盘：df（查看磁盘剩余空间数）

磁盘io：iostat（磁盘IO性能评估）

磁盘块设备分布

rkB/s每秒读取数据量kB
wkB/s每秒写入数据量kB
svctm I/O请求的平均服务时间，单位毫秒
await I/O请求的平均等待时间，单位毫秒；值越小，性能越好
util一秒中有百分几的时间用于I/O操作。接近100%时，表示磁盘带宽跑满，需要优化程序或者增加磁盘
rkB/s、wkB/s根据系统应用不同会有不同的值，但有规律遵循：长期、超大数据读写，肯定不正常，需要优化程序读取。
svctm的值与await的值很接近，表示几乎没有/O等待，磁盘性能好，如果await的值远高于svctm的值，则表示I/O队列等待太长，需要优化程序或更换更快磁盘。

pidstat -p 进程号 -r 采样间隔秒数，可查看进程磁盘的使用情况

网络io：ifstat（查看网络占用情况）

默认本地没有，下载ifstat

wget http://gael.roualland.free.fr/ifstat/ifstat-1.1.tar.gz

tar xzvf ifstat-1.1.tar.gz 

cd ifstat-1.1

./configure

make 

make install
1234567891011

查看网络 I/O 情况