背景知识

探索JVM体系结构

HotSpot架构

HotSpot JVM拥有一个支持强大功能和基础的架构，并支持实现高性能和大规模可扩展性的能力。例如，HotSpot JVM JIT编译器生成动态优化。换句话说，他们在Java应用程序运行时做出优化决策，并生成针对底层系统架构的高性能本机机器指令。 此外，通过对其运行时环境和多线程垃圾收集器的成熟进化和可持续工程化，HotSpot JVM即使在大规模的可用计算机系统上也能实现高可扩展性。

image.png

JVM的主要组件包括类加载器，运行时数据区和执行引擎。

JVM有三个调整性能的组件。堆heap是存储对象数据的位置。 此Region由启动时选择的垃圾收集器GC Collector管理。大多数调优选项都与调整堆大小和根据业务情况选择最合适的垃圾收集器有关。JIT编译器对性能也有很大影响，但很少需要使用较新版本的JVM进行调优。

性能基础知识

通常，在调优Java应用程序时，重点是两个主要目标的其中一个：响应能力或吞吐量。 随着教程的进展，我们将回顾这些概念。

响应能力

响应能力是指应用程序或系统对请求的数据进行响应的速度。

例子包括：

• 桌面UI响应事件的速度有多快
• 网站返回页面的速度有多快
• 返回数据库查询的速度有多快

对于专注于响应能力的应用程序，过长的暂停时间是不可接受的。重点是要在短时间内做出响应。

吞吐量

吞吐量侧重于在特定时间段内最大化应用程序的工作量。
如何衡量吞吐量的示例包括：

• 在给定时间内完成的交易数量。
• 批处理程序可在一小时内完成的作业数。
• 可以在一小时内完成的数据库查询数。

对于专注于吞吐量的应用程序，较长的暂停时间是可接受的，由于高吞吐量应用程序的性能专注于在较长时间内的表现，因此不需要考虑快速响应时间。

G1垃圾收集器

Garbage-First（G1）收集器是一种服务器式垃圾收集器，适用于具有大内存的多核心处理器的机器。它在满足以高概率垃圾收集（GC）暂停时间的目标同时，实现了高吞吐量。
Oracle JDK 7 Update 4及更高版本完全支持G1垃圾收集器。
G1收集器专为以下应用而设计：

• 可以与使用了CMS收集器等应用程序的线程同时运行。
• 紧凑的剩余空间，GC不会引起长时间的暂停。
• 需要更多可预测的GC暂停持续时间。
• 不想牺牲很多吞吐量性能。
• 不需要更大的Java堆。

G1计划作为Concurrent Mark-Sweep Collector（CMS）的长期替代品。与CMS相比，G1成为是一个更好的解决方案。其中的一个区别是G1是紧凑型收集器。 G1依赖于Regionregion，所以足够紧凑，可以完全避免使用细粒度的自由列表进行的空间分配。
这大大简化了收集器的各个部分，并且主要消除了潜在的碎片问题。此外，G1提供比CMS收集器更可预测的垃圾收集暂停机制，并允许用户指定所需暂停的目标。

G1机制概览

旧的垃圾收集器（串行，并行，CMS）都将堆构建为三个部分：年轻代，老年代和固定内存大小的永久代。

image.png

所有内存对象都结束于这三个之中的其一。

G1收集器采用不同的方法：

image.png

堆被分为一组大小相等的堆Region，每个Region都是一个连续的虚拟内存区域。某些Region集合具有与旧收集器中相同的角色（eden，survivor，old），但它们没有固定的大小。这为内存使用提供了更大的灵活性。

执行垃圾收集时，G1以类似于CMS收集器的方式运行。G1会执行并发的全局标记过程，以确定整个堆中对象的活跃度。在标记过程完成之后，G1知道哪些Region基本上是空的。它首先在这些Region收集，通常这就会产生大量的自由空间。这就是为什么这种垃圾收集方法称为Garbage-First。顾名思义，G1将其收集和压缩活动集中在可能充满可回收对象的堆Region，即垃圾。

G1使用暂停预测模型来满足用户定义的暂停时间目标，并根据指定的暂停时间目标选择要收集的Region数。

由G1确定为成熟可回收的Region作为垃圾，使用退出策略回收。G1将对象从堆的一个或多个Region复制到堆上的单个Region，并且在此过程中压缩并释放内存。这种退出机制在多处理器上并行执行，以减少暂停时间并提高吞吐量。因此，对于每次垃圾收集，G1会持续工作以减少碎片，在用户定义的暂停时间内工作。这超出了以前两种方法的性能：CMS（Concurrent Mark Sweep）垃圾收集器不进行压缩。ParallelOld垃圾收集仅执行整堆压缩，这会导致相当长的暂停时间。

值得注意的是G1不是实时收集器。它以高概率但不是绝对确定性的来满足设定的暂停时间目标。基于先前回收的数据，G1估算可以在用户指定的目标时间内收集多少个Region。因此，收集器具有收集Region的相当准确的成本模型，并且它使用该模型来确定在停留在暂停时间目标内时要收集哪些Region和Region的数量。

注意：G1具有并发（与应用程序线程一起运行，例如，细化，标记，清理）和并行（多线程，例如，冻结运行态）阶段。Full GC仍然是单线程的，但如果正确调整，您的应用程序应该可以避免Full GC。

G1 Footprint

如果从ParallelOldGC或CMS收集器迁移到G1，您可能会看到更大的JVM进程大小。 这主要与“accounting”数据结构有关，例如记忆集和集合集。
记忆集或RSet：在一个给定Region中跟踪对象引用。堆中每个Region有一个RSet。RSet支持并行，并独立收集Region。 RSets的总体Footprint影响小于5％。
集合集或CSets：该集合中的Region将在1次GC中全部回收。 在GC期间，CSet中的所有实时数据都被撤离（复制/移动）。 Region集可以是Eden，survivor和/或老年代。 CSets对JVM的大小影响不到1％。

推荐使用G1的情形

G1针对的第一个重点是为运行需要大空间堆、有限GC延迟的应用程序的用户提供解决方案。 这意味着堆大小约为6GB或更大，稳定且可预测的暂停时间要低于0.5秒。

如果应用程序具有以下一个或多个特征，那么现今还在使用CMS或ParallelOldGC垃圾收集器运行的应用程序切换到G1的话将会得到收益。

• Full GC持续时间太长或太频繁。
• 对象分配率或晋升（有用（存在引用）的对象会在垃圾回收的过程中被晋升到较高等级的内存区域）率差异很大。
• 不需要的垃圾收集或压缩的长时暂停（超过0.5到1秒）

注意：如果您使用的是CMS或ParallelOldGC，并且您的应用程序没有经历长时间的垃圾收集暂停，那么您的收集器策略保持当前状态是没有问题的。更改为G1收集器不是使用最新JDK的必要条件。