1.JVM的基本结构
1.1 类加载子系统
1.2 运行时数据区（内存结构）
1.2.1 堆
虚拟机启动后自动分配，用于存放类的实例对象，几乎所有的对象，包括长两次都在堆上分配内存，当对象无法在该区域上申请内存时，会抛出out of mmemory error，同时也是垃圾回收的主要区域。
1.2.1.1 新生代
类的出生、成长、消亡的区域。一个类的产生，应用，到最后被垃圾回收器回收，结束生命
- eden(伊甸区) 所有的类都是从eden space new出来的
- survivur(幸存者区) 分为 from区和to区。当eden区空间使用完后，程序需要继续创建对象，jvm会怼eden区做一次垃圾回收，把回收后，仍然存活的对象，放到from区，当from区的空间也满了的时候，对该区域再进行垃圾回收，并把回收后的对象移动到to区。如果新建的对象，空间不足的时候，会被移动到老年代。
1.2.1.2 老年代
新生代，经过多次GC仍存活，一般为15的时候，会被移动到老年代，如果老年代区满了后，会进行full GC，full GC会占用线程，使程序进入短暂的死机状态，若执行完full gc后依然不够空间，会抛出outOfMemoryError
1.2.1.3 元空间
在JDK1.8之后，元空间替代了永久代，它是对JVM规范中方法区的实现，区别在于元数据区不在虚拟机当中，而是用
的本地内存，永久代在虚拟机当中，永久代逻辑结构上也属于堆，但是物理上不属于
1.2.2 方法区
类的字段和方法的所有字节码，以及依稀的特殊的方法，如构造函数。所有定义的方法的信息，都保存在方法区。静态变量+常量+类信息（构造方法、接口定义）+运行时常量池都存在方法区中。
1.2.3 栈
javax线程执行方法的内存模型，一个线程对应一个栈。每个方法执行的同时会创建一个栈帧（用于存储局部变量表，操作数栈，动态链接库，方法出口）。一个线程私有的部分，包含了栈，程序计数器，本地方法栈。共享进程中的堆和方法区。
-
- 局部变量表，存储了引用对象，他指向堆中的实例对象，实例对象的创建，则是通过方法区的类模板进行创建。
-
- 方法出口，当存在循环调用的时候，方法出口的类似于动态链接，指向调用他的上一层的方法。
-
- 操作数栈，用于存储计算过程中的变量，先将要操作的两个变量压入栈，要计算的时候，从局部变量表中复制一份到操作数栈中，然后取出两个数，计算结果再压入栈中，同时可以保存在局部变量表中。
1.2.4 程序计数器
程序计数器是一个指针，指向方法区中的方法字节码，即为即将执行的代码。由执行引擎读取下一条指令。
1.2.5 本地方法栈
与栈的作用类似，栈用于jvm执行方法服务，本地方法栈为jvm执行本地方法服务，登记native方法，在excution engine 执行的时候加载本地方法库
1.3 执行引擎
2. GC算法和收集器
GC算法
- 引用计数
给对象添加一个引用计数器，每当有一个引用的时候，该数值加1。当引用失效，该数值减1，为0的时候，表示该对象不被使用，可以回收。
这个算法实现简单，效率高。但是目前虚拟机没有采用这种算法的，因为该算法无法解决循环引用的问题。 -
可达性分析算法
这种算法的思想是，通过一系列的GCRoot的对象作为起点，从这些节点中，向下探索，节点所走的路径称为引用链，当一个对象到GCroot 没有引用链的时候，那么该对象是不可用的。
image
如何判断一个常量是废弃常量
假如在常量池中存在字符串"abc"，如果当前没有任何String对象引用该字符串常量的话，就说明常量”abc“就是废弃
常量，如果这时发生内存回收的话而且有必要的话，”abc“会被系统清理出常量池
如何判断一个类是无用的类
- 该类所有的实例都已经被回收，也就是 Java 堆中不存在该类的任何实例。
- 加载该类的 ClassLoader 已经被回收。
- 该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
虚拟机可以对满足上述3个条件的无用类进行回收，这里仅仅是”可以“，而并不是和对象一样不适用了就必然会被回
收。
垃圾回收算法
标记清除算法
这个算法分为两个阶段，“标记”和”清除“。首先标记出所有需要回收的对象，在标记完成后
统一回收所有被标记的对象
缺点
- 效率问题，标记和清除两个过程的效率都不高；
- 空间问题，标记清除后会产生大量不连续的碎片；
复制算法
为了解决效率问题，把内存分为了两块，每次只使用其中一块。当这一块内存使用完后，便将仍存活的对象复制到另外一片内存区域，然后清空当前的内存区域，这样每次回收，都是对内存一半的区域进行回收，且不存在内存碎片问题，常用语，survior space中的from区到to区这个过程
缺点
- 内存空间的浪费，使用率不高。
标记整理算法
根据老年代的特点提出的一种标记算法，标记过程和“标记-清除”算法一样，但是后续步骤不是直接对可回收对象进行
回收，而是让所有存活的对象向一段移动，然后直接清理掉边界以外的内存
分代收集算法
现在的商用虚拟机的垃圾收集器基本都采用"分代收集"算法，这种算法就是根据对象存活周期的不同将内存分为几
块。一般将java堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。
在新生代中，每次收集都有大量对象死去，所以可以选择复制算法，只要付出少量对象的复制成本就可以完成每次垃
圾收集。而老年代的对象存活几率时比较高的，而且没有额外的空间对它进行分配担保，就必须选择“标记-清除”或
者“标记-整理”算法进行垃圾收集
3. 垃圾收集器
Serial收集器
Serial（串行）收集器收集器是最基本、历史最悠久的垃圾收集器了。大家看名字就知道这个收集器是一个单线程收
集器了。它的 “单线程” 的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进
行垃圾收集工作的时候必须暂停其他所有的工作线程（ “Stop The World” ），直到它收集结束。
新生代采用复制算法，老年代采用标记-整理算法。
ParNew收集器
ParNew收集器其实就是Serial收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为（控制参数、收集
算法、回收策略等等）和Serial收集器完全一样。
新生代采用复制算法，老年代采用标记-整理算法。
Parallel Scavenge收集器
Parallel Scavenge 收集器类似于ParNew 收集器。
Parallel Scavenge收集器关注点是吞吐量（高效率的利用CPU）。CMS等垃圾收集器的关注点更多的是用户线程的停
顿时间（提高用户体验）。所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值。 Parallel
Scavenge收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量，如果对于收集器运作不太了解的话，
手工优化存在的话可以选择把内存管理优化交给虚拟机去完成也是一个不错的选择。
新生代采用复制算法，老年代采用标记-整理算法。
Serial Old收集器
Serial收集器的老年代版本，它同样是一个单线程收集器。它主要有两大用途：一种用途是在JDK1.5以及以前的版本
中与Parallel Scavenge收集器搭配使用，另一种用途是作为CMS收集器的后备方案。
Parallel Old收集器
Parallel Scavenge收集器的老年代版本。使用多线程和“标记-整理”算法。在注重吞吐量以及CPU资源的场合，都可以
优先考虑 Parallel Scavenge收集器和Parallel Old收集器。
CMS收集器
并行和并发概念补充：
- 并行（Parallel） ：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。
- 并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行，可能会交替执行），用户程序
在继续运行，而垃圾收集器运行在另一个CPU上。
CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它而非常符合在注重用
户体验的应用上使用。
优点：
并发收集、低停顿。
缺点：
- 对CPU资源敏感；
- 无法处理浮动垃圾；
- 它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生。
CMS回收步骤
- 初始标记（CMS initial mark）： 暂停所有的其他线程，并记录下直接与root相连的对象，速度很快
- 并发标记（CMS concurrent mark）： 同时开启GC和用户线程，用一个闭包结构去记录可达对象。但在这个阶
段结束，这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域，所以GC
线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。 - 重新标记（CMS remark）： 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生
变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶
段时间短 - 并发清除（CMS concurrent sweep）： 开启用户线程，同时GC线程开始对为标记的区域做清扫。
G1收集器
G1 (Garbage-First)是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足
GC停顿时间要求的同时,还具备高吞吐量性能特征.
G1后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的Region，这种使用Region划分内存空间以及有优先级的区域回收方式，保证了GF收集器在有限时间内可以尽可能高的收集效率（把内存化整为零）。
- 并行与并发：G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短StopThe-World停顿时间。部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方
式让java程序继续执行 - 分代收集：虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念。 空间整
合：与CMS的“标记–清理”算法不同，G1从整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基
于“复制”算法实现的 - 可预测的停顿：这是G1相对于CMS的另一个大优势，降低停顿时间是G1 和 CMS 共同的关注点，但G1 除了追
求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内
G1运行步骤
- 初始标记 会进行短暂的stw
- 并发标记 不会进行stw
- 最终标记 会进行短暂的stw
- 筛选回收
3. GC调优步骤
- 打印GC日志
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc:./gc.log
Tomcat可以直接加载JAVA_OPTS变量里
- 分析日志得到关键性指标
- 分析GC原因，调优JVM参数
Parallel Scavenge收集器(默认)
分析parallel-gc.log
- 第一次调优，设置Metaspace大小：增大元空间大小-XX:MetaspaceSize=64M -XX:MaxMetaspaceSize=64M
- 第二次调优，增大年轻代动态扩容增量（默认是20%），可以减少YGC：-XX:YoungGenerationSizeIncrement=30
比较下几次调优效果：
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc:./gc.log
| 吞吐量 | 最大停顿 | 平均停顿 YGC FGC |
|---|---|---|
| 97.169% | 420 ms | 60.0 ms 12 2 |
| 98.775% | 60.0 ms | 28.0 ms 10 0 |
配置CMS收集器
-XX:+UseConcMarkSweepGC
分析gc-cms.log
配置G1收集器
-XX:+UseG1GC
分析gc-g1.log
- young GC:[GC pause (G1 Evacuation Pause)(young)
- initial-mark:[GC pause (Metadata GC Threshold)(young)(initial-mark) (参数：InitiatingHeapOccupancyPercent)
- mixed GC:[GC pause (G1 Evacuation Pause)(Mixed) (参数：G1HeapWastePercent)
- full GC:[Full GC (Allocation Failure)(无可用region)
（G1内部，前面提到的混合GC是非常重要的释放内存机制，它避免了G1出现Region没有可用的情况，否则就会触
发 FullGC事件。CMS、Parallel、Serial GC都需要通过Full GC去压缩老年代并在这个过程中扫描整个老年代。G1的
Full GC算法和Serial GC收集器完全一致。当一个Full GC发生时，整个Java堆执行一个完整的压缩，这样确保了最大
的空余内存可用。G1的Full GC是一个单线程，它可能引起一个长时间的停顿时间，G1的设计目标是减少Full GC，满
足应用性能目标。）
查看发生MixedGC的阈值：jinfo -flag InitiatingHeapOccupancyPercent 进程ID
调优：
- 第一次调优，设置Metaspace大小：增大元空间大小-XX:MetaspaceSize=64M -XX:MaxMetaspaceSize=64M
- 第二次调优，添加吞吐量和停顿时间参数：-XX:GCTimeRatio=99 -XX:MaxGCPauseMillis=10
GC常用参数
堆栈设置
-Xss:每个线程的栈大小
-Xms:初始堆大小，默认物理内存的1/64
-Xmx:最大堆大小，默认物理内存的1/4
-Xmn:新生代大小
-XX:NewSize:设置新生代初始大小
-XX:NewRatio:默认2表示新生代占年老代的1/2，占整个堆内存的1/3。
-XX:SurvivorRatio:默认8表示一个survivor区占用1/8的Eden内存，即1/10的新生代内存。
-XX:MetaspaceSize:设置元空间大小
-XX:MaxMetaspaceSize:设置元空间最大允许大小，默认不受限制，JVM Metaspace会进行动态扩展。
垃圾回收统计信息
-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-Xloggc:filename
收集器设置
-XX:+UseSerialGC:设置串行收集器
-XX:+UseParallelGC:设置并行收集器
-XX:+UseParallelOldGC:老年代使用并行回收收集器
-XX:+UseParNewGC:在新生代使用并行收集器
-XX:+UseParalledlOldGC:设置并行老年代收集器
-XX:+UseConcMarkSweepGC:设置CMS并发收集器
-XX:+UseG1GC:设置G1收集器
-XX:ParallelGCThreads:设置用于垃圾回收的线程数
并行收集器设置
-XX:ParallelGCThreads:设置并行收集器收集时使用的CPU数。并行收集线程数。
-XX:MaxGCPauseMillis:设置并行收集最大暂停时间
-XX:GCTimeRatio:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)
CMS收集器设置
-XX:+UseConcMarkSweepGC:设置CMS并发收集器
-XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。
-XX:ParallelGCThreads:设置并发收集器新生代收集方式为并行收集时，使用的CPU数。并行收集线程数。
-XX:CMSFullGCsBeforeCompaction:设定进行多少次CMS垃圾回收后，进行一次内存压缩
-XX:+CMSClassUnloadingEnabled:允许对类元数据进行回收
-XX:UseCMSInitiatingOccupancyOnly:表示只在到达阀值的时候，才进行CMS回收
-XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况
-XX:ParallelCMSThreads:设定CMS的线程数量
-XX:CMSInitiatingOccupancyFraction:设置CMS收集器在老年代空间被使用多少后触发
-XX:+UseCMSCompactAtFullCollection:设置CMS收集器在完成垃圾收集后是否要进行一次内存碎片的整理
G1收集器设置
-XX:+UseG1GC:使用G1收集器
-XX:ParallelGCThreads:指定GC工作的线程数量
-XX:G1HeapRegionSize:指定分区大小(1MB~32MB，且必须是2的幂)，默认将整堆划分为2048个分区
-XX:GCTimeRatio:吞吐量大小，0-100的整数(默认9)，值为n则系统将花费不超过1/(1+n)的时间用于垃圾收集
-XX:MaxGCPauseMillis:目标暂停时间(默认200ms)
-XX:G1NewSizePercent:新生代内存初始空间(默认整堆5%)
-XX:G1MaxNewSizePercent:新生代内存最大空间
-XX:TargetSurvivorRatio:Survivor填充容量(默认50%)
-XX:MaxTenuringThreshold:最大任期阈值(默认15)
-XX:InitiatingHeapOccupancyPercen:老年代占用空间超过整堆比IHOP阈值(默认45%),超过则执行混合收集
-XX:G1HeapWastePercent:堆废物百分比(默认5%)
-XX:G1MixedGCCountTarget:参数混合周期的最大总次数(默认8)
怎么选择垃圾收集器？
- 优先调整堆的大小让服务器自己来选择
- 如果内存小于100m，使用串行收集器
- 如果是单核，并且没有停顿时间的要求，串行或JVM自己选择
- 如果允许停顿时间超过1秒，选择并行或者JVM自己选
- 如果响应时间最重要，并且不能超过1秒，使用并发收集器