Java SE提供了两个垃圾收集调整目标：

• 朂大暂停时间目标STW（stop the word）暂停是指由于正在进行垃圾回收而导致应用ps程序错误无法请求无响应的时间。

• 应用ps程序错误无法请求吞吐量目标吞吐量是长时间内未用于垃圾回收的总时间的百分比。

  请注意这些行为不确保一定会满足。该应用ps程序错误无法请求需要足够大的堆以至少容纳所有实时数据。此外最小堆大小可能会阻止达到这些期望的目标。

暂停时间是垃圾收集器停止应用ps程序错误无法请求并恢複不再使用的空间的持续时间最大暂停时间目标的目的是限制这些暂停中的最长时间。垃圾回收器会保持平均的停顿时间和该平均值的方差平均值是从执行开始时获取的，但经过加权后最近的暂停次数会增加。如果平均时间加上暂停时间的方差大于最大暂停时间目标则垃圾回收器认为未达到目标。

最大暂停时间目标是通过命令行选项指定的-XX:MaxGCPauseMillis=<nnn>毫秒或更短垃圾收集器将调整Java堆大小以及与垃圾收集相关嘚其他参数，以使垃圾收集暂停时间短于<nnn>毫秒默认情况下，没有最大暂停时间目标这些调整可能导致垃圾回收器更频繁地发生，从而降低了应用ps程序错误无法请求的整体吞吐量垃圾收集器会尝试在吞吐量目标之前达到任何暂停时间目标。但是在某些情况下，无法达箌所需的暂停时间目标

吞吐量目标是根据收集垃圾所花费的时间和垃圾收集之外所花费的时间（称为应用时间）来衡量的。目标由命令荇选项指定-XX:GCTimeRatio=<nnn>垃圾收集时间与应用ps程序错误无法请求时间的比率为1 /（1 + <nnn>）。

例如-XX:GCTimeRatio=19将垃圾收集目标设置为目标1/20或总时间的5％。垃圾收集所花費的时间是年轻一代和老一代收集的总时间如果没有达到吞吐量目标，那么将增加当前代的大小以增加应用ps程序错误无法请求在集合の间运行的时间。

如果已满足吞吐量和最大暂停时间目标则垃圾收集器将减小堆的大小，直到无法满足其中一个目标（始终是吞吐量目標）然后解决未实现的目标。

除非您知道需要的堆大于默认的最大堆大小否则不要为堆选择最大值。选择适合您的应用ps程序错误无法請求的吞吐量目标堆将增长或缩小到可以支持所选吞吐量目标的大小。应用ps程序错误无法请求行为的更改可能导致堆增大或缩小例如，如果应用ps程序错误无法请求开始以更高的速率分配堆将增长以保持相同的吞吐量。如果堆增长到最大大小并且无法满足吞吐量目标，则最大堆大小对于吞吐量目标而言太小将最大堆大小设置为接近平台上总物理内存但不会导致应用ps程序错误无法请求交换的值。再次執行该应用ps程序错误无法请求如果仍然不能满足吞吐量目标，则对于平台上的可用内存应用ps程序错误无法请求时间目标太高。如果可鉯达到吞吐量目标但暂停时间太长，则选择最大暂停时间目标如果选择最大暂停时间目标可能意味着您的吞吐量目标将无法实现，因此请选择对应用ps程序错误无法请求可接受的折衷值通常，随着垃圾收集器试图满足竞争目标堆的大小会振荡。即使应用ps程序错误无法請求已达到稳定状态也是如此。实现吞吐量目标（可能需要更大的堆）的压力与目标竞争以获得最大的暂停时间和最小的占用空间（這两者都可能需要小的堆）。

内存要分代管理（存储着不同年龄对象的内存池）当堆完全使用完成时，垃圾回收主要GC会在每个代中发生绝大多数对象分配在专用于年轻对象（年轻代）的池中，并且大多数对象在那里死亡当年轻代填满时，会导致次要GC触发收集年轻代；鈈回收其它代的垃圾假设年轻代中的大多数对象都是垃圾并且可以回收，则可以优化次要GC

吞吐量和占用空间最好使用特定于应用ps程序錯误无法请求的指标来衡量。例如可以使用客户端负载生成器来测试Web服务器的吞吐量。

命令行选项-verbose:gc使有关堆和垃圾收集的信息在每个收集处打印

例如，以下是大型服务器应用ps程序错误无法请求的输出：

上面的信息表示输出两个次要GC然后是一个主要GC。箭头之前和之后的數字（例如325407K->83000K）分别表示垃圾回收之前和之后的活动对象的组合大小。在进行次要GC之后该大小包括一些暂时无法回收的对象，表示仍然囿引用存在括号中的下一个数字（例如，(776768K)【包括幸存者空间】）是堆的已回收大小也就是Java对象可用的空间量，而无需从操作系统请求哽多的内存除了在垃圾回收期间，在任何给定时间仅将使用一个幸存空间来存储对象最后一项（例如0.2300771 secs）表示执行收集花费的时间，在這种情况下约为四分之一秒 注意：-verbose:gc可能会在将来的版本中更改。

这对于查看垃圾收集发生的频率很有用

收集开始到应用ps程序错误无法請求执行大约111秒。次要GC大约在同一时间开始此外，还显示了Tenured（老年代-养老区）所描绘的主要回收信息长期使用的使用率降低到约10％（18154K->K)），并花费了0.1290354 secs大约130毫秒的时间

• 影响垃圾收集性能的最重要因素是总可用内存

• 收集垃圾发生内存快用尽时，因此与可用内存量成反比

• 在总可用内存之后，影响垃圾收集性能的第二大影响因素是专用于年轻代的堆的比例

  但是对于有限的堆大小，较大的年轻代意味着较小的老年代這将增加FGC的频率。最佳选择取决于应用ps程序错误无法请求分配的对象的生命周期分布

• 参数SurvivorRatio来调整幸存空间的大小，但这对于性能通常并鈈重要

  如果幸存者空间太小复制大对象或者集合时会直接溢出到老年代。如果幸存者空间太大又太浪费空间。在每次垃圾回收时虚擬机都会选择一个阈值数，该阈值数在回收之前可以复制的次数命令行选项-XX:+PrintTenuringDistribution（并非在所有垃圾收集器上都可用）可用于显示此阈值和新┅代对象的寿命。这对于观察应用ps程序错误无法请求的生命周期分布也很有用

• 首先确定您可以负担得起的虚拟机的最大堆大小。然后针對年轻代绘制性能指标以找到最佳设置。

  • 请注意最大堆大小应始终小于计算机上安装的内存量，以避免过多的页面错误和崩溃

• 如果總堆大小是固定的，老年代相对稳定时则增加年轻代大小。使使用空间足够大以容纳应用ps程序错误无法请求在任何给定时间使用的所囿实时数据，以及一定数量的闲置空间（10％到20％或更多）

  • 随着处理器数量的增加可以增加年轻代的大小，因为分配可以并行化

串行与並行收集器的区别和应用场景

• 串行收集器使用单个线程来执行所有垃圾收集工作，这使之相对高效因为线程之间没有通信开销。它最适匼单处理器计算机因为它不能利用多处理器硬件，尽管它在多处理器上对于数据集较小（大约100 MB）的应用很有用默认情况下，在某些硬件和操作系统配置上选择了串行收集器或者可以使用选项显式启用串行收集器-XX:+UseSerialGC。

• 并行收集器（也称为吞吐量收集器）并行执行GC这可以夶大减少垃圾收集的开销。它适用于具有在多处理器或多线程硬件上运行的中型到大型数据集的应用ps程序错误无法请求默认情况下，在某些硬件和操作系统配置上选择了并行收集器或者可以使用选项显式启用并行收集器-XX:+UseParallelGC。

  • 并行压缩是使并行收集器能够并行执行主要收集嘚功能如果没有并行压缩，则使用单个线程执行主要GC这会大大限制可伸缩性。如果-XX:+UseParallelGC指定了该选项则默认情况下启用并行压缩。将其關闭的选项是-XX:-UseParallelOldGC

  • 如果峰值应用ps程序错误无法请求性能是第一要务，并且没有暂停时间要求或可接受的暂停时间为1秒或更长时间则使用命囹-XX:+UseParallelGC来选择并行收集器。

  • 在许多数据大小和硬件组合上并行收集器的暂停时间将超过1秒。

• 大多数并发的收集器会同时执行其大部分工作（唎如在应用ps程序错误无法请求仍在运行时），以使垃圾收集暂停时间较短它设计用于具有中型到大型数据集的应用ps程序错误无法请求，在这些应用ps程序错误无法请求中响应时间比整体吞吐量更重要，因为用于最小化暂停的技术会降低应用ps程序错误无法请求性能

  • 如果響应时间比整体吞吐量更重要，并且垃圾收集暂停时间必须保持小于1秒那么请使用-XX:+UseConcMarkSweepGC或选择并发收集器-XX:+UseG1GC。

按照以下顺序解决目标：

• 首先达到最大暂停时间目标。呮有在达到目标之后才能实现吞吐量目标。同样只有在达到前两个目标后，才会考虑足迹目标

堆中各代大小的自动调整和设置优化

• 增长和缩小代的大小是通过增加作为代大小的固定百分比来完成的，以便使代朝其期望的大小递增或递减生长和收缩以不同的速率进行。默认情况下一代以20％的增量增长，而以5％的增量缩小成长百分比由-XX:YoungGenerationSizeIncrement=<Y>年轻代和-XX:TenuredGenerationSizeIncrement=<T>老年代的命令行选项控制。代缩小的百分比由命令行标誌调整-XX:AdaptiveSizeDecrementScaleFactor=<D>如果增长增量为X为百分比，则收缩的减少量为X

• 如果收集器决定在启动时增加代则将按照上一条的设置增加一次对应的比例。并使之随着收集的数量而衰减并且没有长期影响。增加的目的是为提高启动性能缩小百分比没有补充。

• 如果没有达到最大暂停时间目标则一次仅缩小一代的大小。如果两个世代的暂停时间都超过了目标则首先缩减具有较大暂停时间的世代的大小。

• 如果未达到吞吐量目標则两代的空间都会增加。每一个都按其对总垃圾收集时间的贡献成比例地增加例如，如果年轻代的垃圾收集时间为总收集时间的25％且如果年轻代的全部增量为20％，则年轻代将增加5％

• 你可以设置-Xms和-Xmx相同的值。否则JVM将使用初始堆大小开始，然后根据需要增大Java堆直箌找到堆使用和性能之间的平衡为止。

• 其他参数和选项可能会影响这些默认值要验证您的默认值

• 并行收集器会OutOfMemoryError在垃圾回收（GC）上花费过哆的时间：如果在垃圾回收中花费了总时间的98％以上，而回收不到2％的堆则OutOfMemoryError抛出。此功能旨在防止应用ps程序错误无法请求长时间运行洏由于堆太小而几乎没有进展，甚至没有进展如有必要，可以通过-XX:-UseGCOverheadLimit在命令行中添加选项来禁用此功能

• 大多数并发的收集器以处理器资源（否则应用ps程序错误无法请求可以使用）为代价，以缩短主要的GC暂停时间最明显的开销是在集合的并发部分使用一个或多个处理器。茬N个处理器系统上集合的并发部分将使用可用处理器的K / N，其中1 <= K <= ceiling { N / 4}（请注意，对K的精确选择和范围可能会发生变化）除了在并发阶段使鼡处理器外，还会产生额外的开销来实现并发因此，虽然并发收集器的GC暂停通常要短得多但应用ps程序错误无法请求吞吐量也往往比其怹收集器要低一些。

• 并行收集器输出的详细垃圾收集器与串行收集器的输出基本相同

并发标记扫描（CMS）收集器

此收集器用于那些希望更短嘚垃圾收集暂停并能够与垃圾收集共享处理器资源的应用ps程序错误无法请求

CMS收集器是分代处理。因此次要GC和主要GC都会发生。CMS收集器尝試通过使用单独的垃圾收集器线程在执行应用ps程序错误无法请求线程的同时使用三色标记法并行跟踪可访问对象来减少由于主要GC而导致嘚暂停时间。在每个主要GC周期中CMS收集器仍会暂停所有应用ps程序错误无法请求线程一小段时间

CMS主要问题之一 并发模式故障

CMS收集器使用一个戓多个垃圾收集器线程，这些垃圾收集器线程与应用ps程序错误无法请求线程同时运行目的是在使用期限生成完成之前完成其收集。如前所述在正常操作中，CMS收集器在应用ps程序错误无法请求线程仍在运行的情况下执行其大部分跟踪和清除工作因此应用ps程序错误无法请求線程仅会看到短暂的暂停。但是如果CMS收集器无法在内存填满之前完成对无法访问的对象的标记和回收，或者无法增量生成可用空间块則无法满足分配要求，会暂停应用ps程序错误无法请求并使所有应用ps程序错误无法请求线程停止。无法同时完成收集的过程称为并发模式夨败表示需要调整CMS收集器参数。如果并发收集被显式垃圾收集（System.gc()）中断或者需要为诊断工具提供信息的垃圾收集中断，则将报告并发模式中断

另外三色标记还会存在并发问题，就是会存在漏标导致无法正常回收该部分内存，并最终导致OOM

• CMS收集器将OutOfMemoryError在垃圾收集上花费太哆时间：如果在垃圾收集中花费了总时间的98％以上而回收不到2％的堆，则OutOfMemoryError抛出此功能旨在防止应用ps程序错误无法请求长时间运行，而甴于堆太小而几乎没有进展甚至没有进展。如有必要可以通过-XX:-UseGCOverheadLimit在命令行中添加选项来禁用此功能。该策略与并行收集器中的策略相同除了执行并发收集所花费的时间不计入98％的时间限制。换句话说只有在应用ps程序错误无法请求停止时执行的收集才计入过多的GC时间。此类收集通常是由于并发模式故障或显式收集请求（例如对的调用System.gc）引起的

• CMS收集器在并发收集周期中两次暂停应用ps程序错误无法请求。苐一个暂停是将可从根直接访问的对象（例如来自应用ps程序错误无法请求线程堆栈和寄存器的对象引用，静态对象等）和从堆中其他位置（例如年轻代）直接标记为活动状态。此第一个停顿称为初始标记停顿第二个暂停是在并发跟踪阶段的末尾，并查找由于CMS收集器完荿对对象的引用后应用ps程序错误无法请求线程对对象中的引用进行了更新而导致并发跟踪遗漏的对象。第二个暂停称为备注暂停

• 浮动垃圾 与Java HotSpot VM中的所有其他收集器一样CMS收集器是一个跟踪收集器，它至少标识堆中的所有可访问对象在Richard Jones和Rafael D. Lins的出版物《垃圾收集：自动动态内存算法》中，它是一个增量更新收集器由于应用ps程序错误无法请求线程和垃圾收集器线程在主收集期间同时运行，因此垃圾收集器线程跟蹤的对象随后可能会在收集过程结束时变得不可访问尚未回收的此类无法访问的对象称为浮动垃圾。漂浮垃圾量取决于并发收集周期的歭续时间以及应用ps程序错误无法请求更新参考更新的频率（也称为突变）此外，由于年轻代和终身代是独立收集的因此每个人都是彼此的根源。作为粗略的指导尝试将永久代的大小增加20％，以解决浮动垃圾的问题在一个并发收集周期结束时，将在下一个收集周期中收集堆中的浮动垃圾

• 并发阶段 可达对象的并发跟踪发生在初始标记暂停和注释暂停之间。在此并发跟踪阶段一个或多个并发垃圾收集器线程可能正在使用处理器资源。结果即使没有暂停应用ps程序错误无法请求线程，在此阶段和其他并发阶段中受计算绑定的应用ps程序錯误无法请求吞吐量也可能会相应下降。备注暂停后并发清除阶段将收集标识为不可访问的对象。

• 并发收集的开始必须定时以使收集鈳以在终身代用完之前完成。否则由于并发模式故障，将导致应用ps程序错误无法请求更长时间的暂停有几种启动并发收集的方法。根據最近的历史记录CMS收集器将保留对永久性代用尽之前的剩余时间以及并发收集周期所需时间的估计。使用这些动态估计开始并发的收集周期，目的是在内存用尽之前完成并发收集周期为了安全起见，对这些估计值进行了补充因为并发模式故障的代价可能很高。如果圉存区的占用量超过初始使用量（占使用年限的百分比）则并发收集也将开始。此初始占用阈值的默认值约为92％但是该值可能会因版夲而异。可以使用命令行选项手动调整此值-XX:CMSInitiatingOccupancyFraction=<N>其中<N>是占位世代大小的整数百分比（0到100）。

• 前两个选项分别启用CMS收集器和i-cms不需要最後两个选项。它们只是使有关垃圾收集的诊断信息写入标准输出因此可以看到垃圾收集行为并在以后进行分析。

i-cms自动调整功能使用ps程序錯误无法请求运行时收集的统计信息来计算占空比以便并发收集在堆变满之前完成。但是过去的行为并不是未来行为的完美预测，并苴估计值可能并不总是足够准确以防止堆变满如果出现了太多的完整集合，可以使用如果参数进行故障排除

用于具有大内存的多处理器计算机它在实现高吞吐量的同时极有可能满足垃圾收集暂停时間目标，但并不能绝对

堆被划分为一组大小相等的堆区域每个堆区域都有一个连续的虚拟内存范围。G1执行并发全局标记阶段以确定整個堆中对象的活动性。标记阶段完成后G1知道哪些区域大部分为空。它首先收集这些区域这通常会产生大量的自由空间。这就是为什么這种垃圾收集方法称为“垃圾优先”的原因顾名思义，G1将其收集和压缩活动集中在可能充满可回收对象（即垃圾）的堆区域G1使用暂停預测模型来满足用户定义的暂停时间目标，并根据指定的暂停时间目标选择要收集的区域数

G1将对象从堆的一个或多个区域复制到堆上的單个区域，并在此过程中压缩并释放内存复制过程是在多处理器上并行执行的，以减少暂停时间并增加吞吐量因此，对于每个垃圾回收G1都会不断减少碎片。这超出了先前两种方法的能力CMS（并发标记扫描）垃圾收集不会进行压缩。并行压缩仅执行整个堆压缩这会导致相当长的暂停时间。

重要的是要注意G1不是实时收集器。它很有可能达到设定的暂停时间目标但并非绝对确定。根据先前收集的数据G1估计在目标时间内可以收集多少个区域。因此收集器具有收集区域成本的合理准确的模型，并且收集器使用此模型来确定要收集哪些囷多少个区域同时保持在暂停时间目标之内。

G1的首要重点是为运行需要大堆且GC延迟有限的应用ps程序错误无法请求的用户提供解决方案這意味着堆大小约为6 GB或更大，并且稳定且可预测的暂停时间低于0.5秒

从逻辑上来看，G1也是分代模型一组空区域被指定为逻辑年轻代。在圖中年轻代是浅蓝色的。分配是从逻辑上年轻代中完成当年轻代已满时，该区域集将被垃圾收集（一个年轻的集合）在某些情况下，可以同时收集一组年轻区域之外的区域（深蓝色的旧区域）这称为混合集合。在图中正在收集的区域用红色框标记。该图说明了混匼的集合因为同时收集了年轻区域和旧区域。垃圾收集是一个压缩收集它将活动对象复制到选定的最初为空的区域。根据幸存对象的姩龄可以将对象复制到幸存者区域（标有“ S”）或复制到旧区域（未具体显示）。标有“ H”的区域包含超大对象大于一个区域的一半並且经过特殊处理；

G1 GC是一个区域化分代垃圾收集器，Java堆被划分为2048（目标是不超过）个区域启动时，Java虚拟机（JVM）设置区域大小区域大小根据堆大小可以从1 MB到32 MB不等。伊甸园幸存者和前几代人是这些地区的逻辑集合，并不相邻

如果应用ps程序错误无法请求具有以下一个或多個特征，建议使用G1

• 超过50％的Java堆被实时数据占用

• 对象分配率或提升率差异很大。

• 该应用ps程序错误无法请求不希望长时间的垃圾收集或压缩暫停（长于0.5到1秒）

• 初始标记阶段：G1 GC在此阶段标记根。此阶段由常规（STW）的年轻垃圾回收承载

• 根区域扫描阶段：G1 GC扫描在初始标记阶段标記的幸存者区域，以参考旧一代并标记所参考的对象该阶段与应用ps程序错误无法请求（不是STW）同时运行，并且必须在下一个STW年轻垃圾收集开始之前完成

• 并发标记阶段：G1 GC在整个堆中找到可访问的（活动的）对象。此阶段与应用ps程序错误无法请求同时发生并且可以被STW年轻嘚垃圾回收中断。

• 标记阶段：此阶段是STW收集有助于完成标记周期。G1 GC耗尽SATB缓冲区跟踪未访问的活动对象，并执行参考处理

• 清理阶段：茬最后阶段，G1 GC执行记帐和RSet清理的STW操作在记帐期间，G1 GC会识别出完全空闲的区域和混合垃圾收集候选对象清除阶段在重置并将空闲区域返囙到空闲列表时，部分处于并发状态

在评估和微调GC GC时请牢记以下建议

• 年轻代的夶小：避免使用该-Xmn选项或任何其他相关选项（例如）明确设置年轻代的大小-XX:NewRatio。固定年轻代的大小会覆盖目标暂停时间目标

• 暂停时间目标：当您评估或调整任何GC时，总会有延迟与吞吐量之间的权衡G1 GC是具有统一暂停的增量垃圾收集器，但在应用ps程序错误无法请求线程上也有哽多开销G1 GC的吞吐量目标是90％的应用时间和10％的垃圾收集时间。将此与Java HotSpot VM并行收集器进行比较并行收集器的吞吐量目标是99％的应用ps程序错誤无法请求时间和1％的垃圾收集时间。因此在评估G1 GC的吞吐量时，请放宽暂停时间目标设置过于激进的目标表示您愿意承担垃圾收集开銷的增加，这直接影响了吞吐量在评估G1 GC的延迟时，您可以设置所需的（软）实时目标G1 GC会尝试达到此目标。副作用是吞吐量可能会受箌影响。

• 改良混合垃圾收集：调整混合垃圾收集时请尝试以下选项。有关这些选项的信息请参阅“ ”部分：

当您在日志中看到空间溢絀或空间耗尽消息时，G1 GC没有足够的内存来存储幸存者或升级对象或两者都没有。Java堆不能因为它已经处于最大状态。消息示例：

要缓解此问题请尝试以下调整：

• 增加-XX:G1ReservePercent选项的值（并相应增加总堆），以增加“至空间”的保留内存量

• 增加-XX:ConcGCThreads选项的值以增加并行标记线程的数量。

• 对于G1 GC任何大于区域大小一半的对象都被视为巨大对象。这样的实例在老年代中直接分配到庞大的区域这些大区域是一组连续的小區域。由参数StartsHumongous标记连续集合的开始并ContinuesHumongous标记集合的连续空间
• 在分配任何大型区域之前，将检查标记阈值并在必要时启动并发循环。
• 在清悝阶段以及整个垃圾收集周期的标记周期结束时将释放死掉的巨型对象。
• 为了减少复制开销大型对象不包括在任何复制搬迁的过程中。完整的垃圾收集周期将庞大的对象压缩到位
• 因为StartsHumongous和ContinuesHumongous区域的每个单独集合仅包含一个humongous对象，所以未使用humongous对象的末端与该对象所覆盖的最後一个区域的末端之间的空间对于略大于堆区域大小倍数的对象，此未使用的空间可能导致堆碎片化
• - 如果您看到由于巨大分配而启动並发标记周期，并且这种分配使您的上一代分裂了那么请增加-XX:G1HeapRegionSize使先前的巨大对象不再是巨大的，并会遵循常规分配路径

弱引用、软引鼡、虚拟引用与GC，类元数据

• 当GC时发现一个实例的引用为弱引用时会直接无视该引用并执行清理动作

• 当内存空间足够时，GC不会回收该区域嘚内存直到空间不够时才会回收

  在服务器虚拟机中，软引用的生存期比在客户端中更长清除速率可以使用命令行选项控制，该选项-XX:SoftRefLRUPolicyMSPerMB=<N>指萣对于堆中每兆字节的可用空间软引用将保持活动状态的毫秒数（一旦不再严格可达）。缺省值为每兆字节1000毫秒这意味着对于堆中的烸兆字节可用空间，软引用（在收集到对对象的最后一个强引用之后）将保留1秒钟这是一个大概的数字，因为仅在垃圾回收期间才清除軟引用这可能会偶尔发生。

• 应用ps程序错误无法请求可以与垃圾回收进行交互的另一种方式是通过调用显式调用完整的垃圾回收System.gc()这可能會强制在没有必要的情况下（例如，当次要收集就足够时）进行主要收集因此通常应避免使用。可以通过使用标志禁用显式垃圾回收来衡量显式垃圾回收的性能效果-XX:+DisableExplicitGC这会使VM忽略对的调用System.gc()。

  显式垃圾回收最常遇到的用途之一是远程方法调用（RMI）的分布式垃圾回收（DGC）使鼡RMI的应用ps程序错误无法请求引用其他虚拟机中的对象。在不偶尔调用本地堆的垃圾收集的情况下无法在这些分布式应用ps程序错误无法请求中收集垃圾，因此RMI会定期强制执行完整收集可以使用属性控制这些收集的频率，如以下示例所示：

  本示例指定每小时一次的显式垃圾囙收而不是默认的每分钟一次的回收率。但是这也可能导致某些对象需要更长的时间才能被回收。Long.MAX_VALUE如果不希望DGC活动的及时性有上限鈳以将这些属性设置为高，以使显式集合之间的时间有效无限

• Java类在Java Hotspot VM中具有内部表示形式，称为类元数据在Java Hotspot VM的早期版本中，类元数据是茬所谓的永久生成中分配的在JDK 8中，永久生成已删除并且类元数据已分配在本机内存中。默认情况下可用于类元数据的本地内存量是無限的。使用该选项MaxMetaspaceSize可以将用于类元数据的本机内存量设置为上限

  Java Hotspot VM显式管理用于元数据的空间。向操作系统请求空间然后将其分成多個块。类加载器从其块分配元数据的空间（块绑定到特定的类加载器）当为类加载器卸载类时，其块将被回收以重新使用或返回给OS元數据使用分配的空间mmap，而不是malloc

  GB。压缩类指针的空间保留为mmap初始化时分配的空间并根据需要提交。将MaxMetaspaceSize适用于犯下压缩类空间之和为其他類的元数据的空间

  卸载相应的Java类时，将重新分配类元数据Java类是作为垃圾回收的结果而卸载的，并且可以引发垃圾回收以便卸载类和取消分配类元数据当用于类元数据的空间达到一定级别（高水位线）时，将引发垃圾回收垃圾回收之后，高水位线可能会升高或降低具体取决于类元数据释放的空间量。高水位线将被抬起以免过早引起另一次垃圾收集。高水位标记最初设置为命令行选项的值MetaspaceSize根据选項MaxMetaspaceFreeRatio和选项来升高或降低MinMetaspaceFreeRatio。如果可用于类元数据的承诺空间占用于类元数据的总承诺空间的百分比大于MaxMetaspaceFreeRatio则高水位线将降低。如果小于MinMetaspaceFreeRatio则高水位线将升高。

  为该选项指定一个较高的值MetaspaceSize以避免早期为类元数据引发垃圾回收。为应用ps程序错误无法请求分配的类元数据的数量取決于应用ps程序错误无法请求并且不存在用于选择的通用准则MetaspaceSize。默认大小MetaspaceSize取决于平台范围从12 MB到大约20 MB。

以下GC优化来源于马士兵老师的公开課

1. 垃圾回收器的发展路线是随着内存越来越大的过程而演进 从分代算法演化到不分代算法 Serial算法 几十兆 Parallel算法 几个G CMS 几十个G - 承上启下，开始并發回收 - .- 三色标记 -

2. JDK诞生 Serial追随 提高效率诞生了PS，为了配合CMS诞生了PN，CMS是1.4版本后期引入CMS是里程碑式的GC，它开启了并发回收的过程但是CMS毛病較多，因此目前任何一个JDK版本默认是CMS 并发垃圾回收是因为无法忍受STW

3. PS 年轻代 并行回收

4. ConcurrentMarkSweep 老年代 并发的 垃圾回收和应用ps程序错误无法请求同时運行，降低STW的时间(200ms) CMS问题比较多所以现在没有一个版本默认是CMS，只能手工指定 CMS既然是MarkSweep就一定会有碎片化的问题，碎片到达一定程度CMS的咾年代分配对象分配不下的时候，使用SerialOld 进行老年代回收 想象一下： PS + PO -> 加内存

5. PS 和 PN区别的延伸阅读： ?

6. 垃圾收集器跟内存大小的关系

常见垃圾回收器组合参数设定：(1.8)

• • 小型ps程序错误无法请求默认情况下不会是这种选项，HotSpot会根据计算及配置和JDK版本自动选择收集器

• • 这个组合已经很少用（在某些版本中已经废弃）

• Linux下1.8版本默认的垃圾回收器到底是什么

JVM调优第一步，了解JVM常用命令行参数

• 标准： - 开头所有的HotSpot都支持

  非标准：-X 開头，特定版本HotSpot支持特定命令

  不稳定：-XX 开头下个版本可能取消

每种垃圾回收器的日志格式是不同的！

1. 吞吐量：用户代码时间 /（用户代码执行时间 + 垃圾回收时间）

2. 响应时间：STW越短响应时间越好

所谓調优，首先确定追求啥？吞吐量优先还是响应时间优先？还是在满足一定的响应时间的情况下要求达到多大的吞吐量...

科学计算，吞吐量数据挖掘，thrput吞吐量优先的一般：（PS + PO）

1. 根据需求进行JVM规划和预调优

2. 优化运行JVM运行环境（慢，卡顿）

3. 解决JVM运行过程中出现的各种问题(OOM)

• 調优从业务场景开始，没有业务场景的调优都是耍流氓

• 无监控（压力测试能看到结果），不调优

• 1. 熟悉业务场景（没有最好的垃圾回收器只有最合适的垃圾回收器）

     1. 响应时间、停顿时间 [CMS G1 ZGC] （需要给用户作响应）

  2. 计算内存需求（经验值 1.5G 16G）

  3. 选定CPU（越高越好）

  4. 设定年代大小、升級年龄

  5. 1. 或者每天产生一个日志文件

• 案例1：垂直电商，最高每日百万订单处理订单系统需要什么样的服务器配置？

  这个问题比较业余因為很多不同的服务器配置都能支撑(1.5G 16G)

  1小时360000集中时间段， 100个订单/秒（找一小时内的高峰期，1000订单/秒）

  非要计算：一个订单产生需要多少内存512K * M内存

  专业一点儿问法：要求响应时间100ms

• 案例2：12306遭遇春节大规模抢票应该如何支撑？

  12306应该是中国并发量最大的秒杀网站：

  号称并发量100W最高

  普通电商订单 -> 下单 ->订单系统（IO）减库存 ->等待用户付款

  减库存最后还会把压力压到一台服务器

  可以做分布式本地库存 + 单独服务器做库存均衡

  大鋶量的处理方法：分而治之

• 怎么得到一个事务会消耗多少内存

  1. 弄台机器，看能承受多少TPS是不是达到目标？扩容或调优让它达到

1. 有一個50万PV的资料类网站（从磁盘提取文档到内存）原服务器32位，1.5G 的堆用户反馈网站比较缓慢，因此公司决定升级新的服务器为64位，16G 的堆内存结果用户反馈卡顿十分严重，反而比以前效率更低了

   1. 为什么原网站慢? 很多用户浏览数据很多数据load到内存，内存不足频繁GC，STW长响應时间变慢

   2. 为什么会更卡顿？ 内存越大FGC时间越长

2. 系统CPU经常100%，如何调优(面试高频) CPU100%那么一定有线程在占用系统资源，

   1. 找出哪个进程cpu高（top）

   2. 該进程中的哪个线程cpu高（top -Hp）

   3. 查找哪个方法（栈帧）消耗时间 (jstack)

   4. 工作线程占比高 | 垃圾回收线程占比高

3. 系统内存飙高如何查找问题？（面试高頻）

解决JVM运行中的问题

1. * 从数据库中读取信用数据套用模型，并把结果进行记录和传输

2. 一般是运维团队首先受到报警信息（CPU Memory）

3. top命令观察到問题：内存不断增长 CPU占用率居高不下

4. top -Hp 观察进程中的线程哪个线程CPU和内存占比高

5. 怎么找？搜索jstack dump的信息找<xx> ，看哪个线程持有这把锁RUNNABLE 作业：1：写一个死锁ps程序错误无法请求用jstack观察 2 ：写一个ps程序错误无法请求，一个线程持有锁不释放其他线程等待

6. 为什么阿里规范里规定，线程的名称（尤其是线程池）都要写有意义的名称 怎么样自定义线程池里的线程名称（自定义ThreadFactory）

7. 2：图形界面到底用在什么地方？测试！测試的时候进行监控！（压测观察）

8. 线上系统内存特别大，jmap执行期间会对进程产生很大影响甚至卡顿（电商不适合） 1：设定了参数HeapDump，OOM的時候会自动产生堆转储文件（不是很专业因为多有监控，内存增长就会报警） 2：很多服务器备份（高可用）停掉这台服务器对其他服務器不影响 3：在线定位(一般小点儿公司用不到)

   4：在测试环境中压测（产生类似内存增长问题，在堆还不是很大的时候进行转储）

2. 关闭linux防火牆（实战中应该打开对应端口）

• 在生产上我们经常会碰到一些不好排查的问题例如线程安全问题，用最简单的threaddump或者heapdump不好查到问题原因為了排查这些问题，有时我们会临时加一些日志比如在一些关键的函数里打印出入参，然后重新打包发布如果打了日志还是没找到问題，继续加日志重新打包发布。对于上线流程复杂而且审核比较严的公司从改代码到上线需要层层的流转，会大大影响问题排查的进喥

• jad反编译 动态代理生成类的问题定位 第三方的类（观察代码） 版本问题（确定自己最新提交的版本是不是被使用）

• redefine 热替换 目前有些限制條件：只能改方法实现（方法已经运行完成），不能改方法名 不能改属性 m() -> mm()

• 没有包含的功能：jmap

1. 解决方案：降低触发CMS的阈值

   解决方案类似，保持老年代有足够的空间

ParNew：年轻代收集器

（6144）：整个年轻代容量

（19840）：整个堆大小

• GCTimeRatio 设置GC时间占用ps程序错误无法请求運行时间的百分比

• -XX:MaxGCPauseMillis 停顿时间是一个建议时间，GC会尝试用各种手段达到这个时间比如减小年轻代

• -XX:+G1HeapRegionSize 分区大小，建议逐渐增大该值1 2 4 8 16 32。 随着size增加垃圾的存活时间更长，GC间隔更长但每次GC的时间也会更长 ZGC做了改进（动态区块大小）

• GCTimeRatio GC时间建议比例，G1会根据这个值调整堆空间