yang的博客

实际上，一旦这个参数设为0，就会导致公式clock - timestamp <= freespace * SoftRefLRUPolicyMSPerMB的右侧变为0，这就导致所有的软引用对象，如JVM生成的那些奇怪的Class对象，刚一创建就可能在一次Young GC中被立即回收。例如，假设JVM创建了许多奇怪的类，这些类的Class对象都是软引用的。这个案例的起因是，一位新晋工程师对JVM优化的理解和掌握还不够深入，误入歧途，从某个来源找到了一个非常特别的JVM参数，并错误地设置在了系统中。

这样，在CMS的重新标记阶段就可以少扫描一些对象，从而提升CMS的重新标记阶段的性能，减少其耗时。根据我们对业务系统的分析，如果我们使用默认的JVM参数，年轻代可能只有几百MB的内存，而Survivor区域可能只有几十MB的内存。不同的系统在运行时的情况可能会有所不同，但是基本上，每次Young GC后，都会有几MB到几十MB的对象存活。这样，在Young GC的时候，即使有一些请求没有处理完，有几十MB的存活对象，这些对象也可以轻易地放入几百MB的Survivor空间中，绝对不会进入老年代。

因此，在我们提到的这个社交APP的高峰期，也就是高并发的场景下，个人主页服务的JVM就会频繁地发生老年代的GC。举个例子，假设老年代有2GB的内存，其中1.5GB是连续可用的，而剩下的0.5GB则是分散的内存碎片。根据我们之前学习的知识，我们都知道，在高并发的情况下，如果Young GC后存活的对象过多，这些对象会迅速进入老年代。所以，请大家考虑这样一个场景：假设在一次Full GC之后，老年代中有一部分内存充满了大量的内存碎片，无法存放完整的大对象，只有部分内存是连续可用的。

如果此时发生一次Young GC，并且有30MB的存活对象需要放入老年代，那么显然，老年代的空间将不足以容纳这些对象，必须进行Full GC来回收之前那60MB的对象，然后才能放入新的30MB对象。在执行Minor GC之前，系统进行了一次检查，发现老年代的剩余内存空间仅为100MB，这比每次Minor GC后进入老年代的200MB对象要小。因此，我们可以确定，在这次Young GC期间，有30MB的对象被保留下来，由于Survivor区域无法容纳这些对象，它们直接被转移到了老年代。

因此，我们就需要一套BI系统。需要注意的是，这些分配的对象都是短生命周期的对象，所以在方法运行结束后，它们都将成为垃圾，可以被随时回收。最后一步，就是基于MySQL、HBase、Elasticsearch中存储的数据报表，基于Java开发出来一个BI系统，通过这个系统把各种存储好的数据暴露给前端，允许前端基于各种条件对存储好的数据进行复杂的筛选和分析，如下图所示。随着程序的运行，每秒钟都会有对象增长，从3MB左右逐渐增加到7MB左右，然后是12MB，17MB，22MB，每秒钟都会新增大约5MB的对象。

您可以将JVM统计信息发送到这些监控系统中，然后在可视化界面中查看所需的指标，包括各个内存区域的对象占用变化曲线、Eden区的对象增速、Young GC的频率和耗时，以及老年代的对象增速和Full GC的频率和耗时。完成预估后，我们就可以根据之前的案例，为我们的系统设置一些初始的JVM参数，包括堆内存大小，年轻代大小，Eden和Survivor的比例，老年代的大小，大对象的阈值，以及大龄对象进入老年代的阈值等。然而，这些监控工具的使用并不在我们专栏的讨论范围内，因为这些内容因公司而异，不是每个公司都有。

在上一篇文章中，我们向大家介绍了一个在日常工作中的实用工具jstat。通过使用jstat，我们可以非常轻松便捷地了解线上系统的运行状况，包括新对象增速、Young GC触发频率及耗时，以及对象进入老年代的增速和Full GC触发频率及耗时。这些信息有助于我们全面掌握线上系统的JVM运行情况，为可能的优化工作做好准备。在本文中，我们将继续为大家介绍两个在日常工作中的实用工具：jmap和jhat。

通过本文对jstat命令的详细介绍，结合我们之前学习过的JVM运行原理，我们向大家传授了一套分析线上系统JVM运行情况的技巧。大家可以轻松掌握并灵活运用jstat这个实用工具，轻松地掌控线上JVM运行的详细情况。在了解JVM的具体运行情况后，我们可以有针对性地进行优化，提高系统性能。

在本文中，我们通过一个具体的例证，详细解释了什么情况下会触发老年代的垃圾收集。这种情况发生在年轻代中的存活对象数量过多，多到无法全部迁移至老年代时，从而促使CMS垃圾收集器执行全面的垃圾回收操作。

首先，我们将通过代码示例来模拟一种常见的情况，即对象进入老年代。是的，如果我们将512KB的未知对象和128KB的数组相加，我们会得到大约640KB的使用量。此时，我们注意到Survivor区域的总大小为1MB，而在Survivor From区中存活的对象已经占用了700KB的空间，这明显超过了整个区域的50%。依据我们设定的动态年龄判断规则，如果某个区域内，所有对象的累计年龄（包括1岁、2岁，以及n岁的对象）超过了该区域总空间的50%，那么生存时间达到n年及以上的对象将被视为老年对象，并被迁移到老年代。

concurrent mark-sweep generation total 5120K, used 62K，这个很简单，就是说Concurrent Mark-Sweep垃圾回收器，也就是CMS垃圾回收器，管理的老年代内存空间一共是5MB，此时使用了62KB的空间，这个是啥你也先不用管了，可以先忽略不计，以后我们有内存分析工具了，你都能看到。可以看到，这里的最小单位是小数点后两位，但全部都是0.00 secs，也就是说本次GC仅仅耗费了几毫秒，所以从秒为单位来看，几乎可以忽略不计。

其中，新生代将占据5MB的内存空间，Eden区将占据4MB，每个Survivor区将占据0.5MB。这行代码一旦运行，就会在JVM的Eden区内放入一个1MB的对象，同时在main线程的虚拟机栈中会压入一个main()方法的栈帧，在main()方法的栈帧内部，会有一个名为“array1”的变量，这个变量是指向堆内存Eden区的那个1MB的数组。此时会在堆内存的Eden区中创建第二个数组，并且让局部变量指向第二个数组，然后第一个数组就没人引用了，此时第一个数组就成了没人引用的“垃圾对象”了，如下图所示。

这篇文章继续以实际案例为基础，深入探讨了在处理1亿数据量级的系统时，当系统部署在配置为4核8GB内存的机上，为何频繁出现Full GC（全垃圾回收）现象，以及我们应如何进行优化。接着，文章进一步分析了在处理10亿数据量级的系统时，同样部署在4核8GB的机器上，Full GC的出现将会有多么严重，并探讨了如何通过提升机器配置来进行优化。通过仔细阅读这个案例，我们可以深入理解Full GC问题。一旦我们彻底理解了这一点，就能够有效解决频繁发生的Full GC问题。

本文通过一个实际案例，旨在阐述一个观点：通常来说，即便Young GC（年轻代垃圾回收）发生得较为频繁，对系统的运行影响也相对有限。然而，当计算机的内存规模特别大时，需要注意的是，Young GC可能会引发较长时间的系统停顿。在这种情况下，对于大内存机器，我们通常建议采用G1垃圾回收器。G1垃圾回收器是一种面向大内存机器的垃圾回收器，它能够有效地减少系统停顿时间，提高系统性能。在处理大内存机器时，G1垃圾回收器可以更好地平衡垃圾回收的负载，避免出现长时间的停顿，从而确保系统的稳定运行。

因此，我们只能大致地说，当上述条件满足时，系统会触发Full GC，而在Full GC过程中，一般会伴随着一次Young GC来回收新生代的垃圾对象，同时也会对老年代和永久代进行垃圾回收。现在，大家应该已经明白，如果我们用一个明确的方法来定义这些术语，那么Young GC可以被视为年轻代的垃圾回收（GC），Old GC则是老年代的垃圾回收，而Full GC则是对年轻代、老年代和永久代进行的整体垃圾回收。另外，有一种常见的说法是，在执行Old GC的时候，通常会伴随着一次Young GC。

之前我们提到，当老年代被填满后，会触发针对老年代的垃圾回收，这种垃圾回收被称为Full GC。在阅读之前的文章时，大家可能会注意到，文章中出现了很多名词：Minor GC、Young GC、Full GC、Old CG、Major GC和Mixed GC。但是，有可能会出现你的理解和面试官的理解存在差异，所以在面试的时候回答此类问题，一定要对一个名词可能有的多种不同的理解都给出说明，避免双方理解的歧义。当新生代的Eden区域被填满时，就会触发针对该代的垃圾回收，即所谓的Minor GC或Young GC。

如果在一次新生代GC之后，发现Survivor区域中不同年龄的对象的总大小超过了该区域的50%，例如年龄为1、2和3的对象的大小总和超过了Survivor区域的50%，那么年龄为3及以上的对象将被移动到老年代。基于G1的Region内存划分原理，运行一段时间后，例如，可以对2G内存的Region进行垃圾回收，此时，系统只会停顿20毫秒，然后清除2G的内存空间，释放部分内存，之后，系统还可以继续运行。在这种情况下，为了腾出空间，我们需要清理年轻代中的垃圾对象，即那些没有被GC Roots引用的对象。

这可能会让人疑惑，是否意味着我们需要不断地为新生代分配更多的Region，直到新生代占据了60%的Region，无法再分配更多的Region，然后才会触发新生代的GC？然而，大家需要知道的是，G1垃圾收集器的运行原理就是这样的。在当前的情境下，G1垃圾回收器可能会这样考虑：如果我现在触发一次新生代的垃圾回收，那么仅仅需要几十毫秒就能回收200MB的内存，这最多只会让系统暂停几十毫秒，远远低于我的主人设定的"-XX:MaxGCPauseMills"参数限制的200毫秒的停顿时间。以及动态年龄判定规则。

默认值是8次，意味着最后一个阶段，先停止系统运行，混合回收一些Region，再恢复系统运行，接着再次禁止系统运行，混合回收一些Region，反复8次。例如，先停止工作，执行一次混合回收回收掉一些Region，接着恢复系统运行，然后再次停止系统运行，再执行一次混合回收回收掉一些Region。在新生代的垃圾回收过程中，我们采用了复制算法。这是因为，如果我们停止系统一段时间，回收一部分Region，然后让系统运行一段时间，再次停止系统，再回收一部分Region，这样可以有效地避免系统的停顿时间过长。

在G1垃圾收集器中，尽管内存被划分为多个Region，但实际上仍然存在新生代和老年代的区分。在新生代中，还进一步分为Eden区和Survivor区。因此，我们会发现之前学到的许多技术原理在G1时代仍然适用。大家可能还记得之前提到过的一个关于新生代的参数：“-XX:SurvivorRatio=8”。这意味着我们仍然可以区分出属于新生代的Region中哪些是Eden区，哪些是Survivor区。

本文将为您详细介绍G1垃圾回收器的设计思想。G1垃圾回收器是一种基于分代的垃场回收器，它的核心设计思想是将Java堆划分为多个独立的Region（区域）。首先，G1垃圾回收器将Java堆分为多个大小相等的Region，每个Region都可以独立地进行垃圾回收。这些Region被进一步划分为两个类型：新生代和老年代。新生代用于存储新生成的对象，而老年代用于存储长时间存活的对象。在G1垃圾回收器的运行过程中，Region会根据需要动态地从新生代转移到老年代。

另外，当执行Minor GC后，可能会有一部分对象存活下来，如果这些对象的总大小超过200MB，无法放入Survivor区，或者一次性占用超过Survivor区的50%，那么这些对象就会进入老年代。因此，通过优化新生代的内存管理，我们可以推断出，在大型促销活动的高峰期内，可能每小时只会触发一次Full GC，而在高峰期过后，随着订单系统的稳定运行，可能需要几个小时才会触发一次Full GC。然而，我们面临着一个显著的问题，那就是在CMS垃圾回收过程中，尤其是在并发清理阶段，系统程序可以同时运行。

但是问题就在于需要对JVM有限的内存资源进行合理的分配和优化，包括对垃圾回收进行合理的优化，让JVM的GC次数尽可能最少，而且尽量避免Full GC，这样可以尽可能减少JVM的GC对高峰期的系统性能的影响。在Minor GC执行之后，那些仍然存活的对象，其大小约在100MB左右，会被移动到S1区域，如下图。此外，即使在Minor GC后的对象少于150MB，但如果是100MB的对象进入Survivor区，由于这是一批同龄的对象，它们会直接超过Survivor区空间的50%，这也可能导致对象进入老年代。

在JDK 1.6中，该参数的默认值是92%，即当老年代使用了92%的空间时，会自动触发CMS垃圾回收，保留8%的空间供并发回收期间新对象的分配。尽管这些对象已经变成了垃圾，但CMS垃圾回收器只能回收之前标记过的对象，而不会立即回收这些“浮动垃圾”，它们将在下一次GC时被处理。尽管它能够在进行垃圾回收的同时，让系统继续执行其他任务，但在并发标记和并发清理这两个最耗费时间的阶段，垃圾回收线程与系统工作线程的并行运行，可能会导致有限的CPU资源被垃圾回收线程占用一部分。然而，这种方法会导致大量的内存碎片产生。

在这个过程中，可能会产生新的存活对象，也可能会导致一些原本的存活对象失去引用，从而成为垃圾对象。总之就是要进行Full GC了，此时所谓的标记-清理算法，其实就是我们之前给大家讲过的一个算法，先通过追踪GC Roots的方法，看看各个对象是否被GC Roots给引用了，如果是的话，那就是存活对象，否则就是垃圾对象。一般老年代我们选择的垃圾回收器是CMS，它采用的是标记清理算法，其实非常简单，就是先用之前文章里讲过的标记方法去标记出哪些对象是垃圾对象，然后就把这些垃圾对象清理掉，如下图所示。

这篇文章篇幅不长，主要介绍一下ParNew垃圾回收器，其实垃圾回收器的工作原理之前上周就全部介绍过了，本文主要就是对ParNew垃圾回收器本身的多线程原理和相关的参数做一些说明。

这样的话，就可以让我们的系统暂停运行，然后不再创建新的对象，同时让垃圾回收线程尽快完成垃圾回收的工作，就是标记和转移Eden以及Survivor2的存活对象到Survivor1中去，然后尽快一次性回收掉Eden和Survivor2中的垃圾对象，如下图。在这其中，Serial垃圾回收器是一种使用单个线程进行垃圾回收的方式，它会导致系统工作线程在回收过程中暂停，因此，在服务器程序中，我们很少采用这种方式。其中，之前提到的CMS垃圾回收器专门负责老年代的垃圾回收，它拥有一套独特的机制和原理，相对复杂。

让我们首先简要概述这个系统的案例背景。这是一个数据计算系统，它具备处理上亿条数据的强大能力。为了帮助大家更好地集中注意力理解这个系统在生产环境中与JVM相关的部分，我们会对系统本身的描述进行简化。简而言之，这个系统的主要功能是不断地从MySQL数据库以及其他数据源中提取大量数据，然后加载到其自身的JVM内存中进行计算处理，如下图所示。这个数据计算系统会持续地通过SQL语句和其他方式从各种数据存储中提取数据到内存中进行计算。在生产环境中，每分钟大约需要执行500次数据提取和计算的任务。

简单来说，触发老年代垃圾回收的时机通常有两个：一个是在Minor GC之前，通过一系列检查发现在Minor GC之后可能有大量的对象需要进入老年代，而老年代的空间无法容纳，此时需要提前触发Full GC，然后再进行Minor GC；然而，如果在执行Minor GC之前，我们发现老年代的可用内存已经小于新生代的全部对象大小，那么在Minor GC之后，新生代的对象全部存活并需要转移到老年代时，老年代的可用空间可能会不足。假设在图中的Survivor2区有两个对象，这两个对象的年岑相同，均为2岁。

首先，它会导致内存浪费。然而，如果这个区域的内存碎片过多，你可能会发现，虽然这些碎片的总和可能足够大，但是由于它们都是分散的，你找不到一块完整且足够大的内存空间来分配给新的对象。因此，大家可以想象，在一次新生代垃圾回收之后，可能有99%的对象都被清理掉了，只有1%的对象存活下来，这些可能是长期存活的对象，或者是还未使用完的对象。请大家不要着急，我们将在接下来的文章中分析这些新生代可能出现的各种“万一”情况，以及新生代的对象是如何转移到老年代的，然后探讨老年代是如何触发垃圾回收的，以及垃圾回收的具体算法。

然而，如果你在执行垃圾回收后发现可用的内存空间仍然不足以存放新的对象，并且内存几乎要溢出时，垃圾回收器将会选择回收这些被软引用关联的对象。这个方法会在垃圾收集器准备回收对象的内存之前被调用，如果在这个最后机会中，对象能够重新获得GC Roots的引用，那么它就可以避免被回收。在Java中，当一个对象被标记为垃圾回收时，如果该对象重写了Object类中的finalize()方法，那么在垃圾回收之前，会先尝试调用这个对象的finalize()方法。这个机制的作用是回收那些不再被引用的对象，从而释放内存空间。

本文通过一个支付系统的案例来阐述，当系统内存设置过小，遭遇突发的巨大流量压力时，可能会引发性能抖动，甚至导致严重的系统问题。在这个案例中，由于支付系统的内存设置过小，当系统突然遭遇巨大的流量压力时，会引发性能抖动。这种性能抖动会导致大量的对象在新生代被引用，但却无法被及时回收。这些对象会持续进入老年代，导致老年代的内存频繁被占满。当老年代的内存频繁被占满时，垃圾回收机制就会被频繁触发。这不仅会消耗大量的系统资源，还可能导致系统性能下降，甚至引发系统崩溃。

本文从支付系统的实际案例入手，详细分析了在日百万交易压力下，部署3台机器时的性能表现。我们计算了每台机器每秒需要处理的订单数量，每笔订单的处理时间，以及每秒钟JVM所需的内存空间。通过横向扩展，我们可以预估整个系统每秒所需的内存空间。进一步地，我们根据数据模型推算出，在不同机器配置下，新生代的内存空间大小。接着，我们分析在不同新生代大小下，触发Minor GC的频率。

这其中，大部分对象都是一些短生命周期的对象，它们在被使用一段时间后，便不再被任何其他对象引用，因此这些对象实际上变成了垃圾对象。然而，由于内存资源是有限的，当新生代区的可用内存不足时，就会触发一次名为Minor GC的垃圾回收机制。这两个参数，是用来限定Java堆内存的总大小的，如下图。首先右击你写好的一个带main()方法的类，他有一个菜单栏，里面有一个“Debug as”选项，鼠标移动进入，会看到一个“Debug Configuration”选项，接着会看到下面的面板。

比如上图中，那个“UserManager”实例对象，其实就是没有人引用的垃圾对象，此时就会当机立断，把“UserManager”实例对象给回收掉，腾出更多的内存空间，然后放一个新的对象到新生代里去。垃圾回收的过程就是扫描并识别出那些不再被引用，即已经变为“垃圾”的对象，然后进行回收，从而腾出大量的内存空间，以供后续的对象分配。在这个阶段，如果我们事先为新生代分配的内存空间几乎被全部对象占据，那么当我们的代码需要继续运行并在新生代中分配一个新的对象时，我们将面临一个问题：新生代的内存空间不足。

在JVM中，有一个区域被称为永久代，它实际上是我们之前提到过的方法区。简单来说，方法区就是用于存储类信息的地方，而这个永久代正是指的就是这个方法区。对于这个概念，现在无需过于深入地理解，因为当我们在后续的讨论中涉及到相关的内容时，会再进行详细的解释。所以，现在你只需要知道，永久代，或者方法区，是用于存储类信息的即可。

我们需要明白，内存资源是有限的。我们在JVM的Java堆内存中创建的对象，实际上也会占用JVM的内存资源，比如“UserManager”实例对象，它会占用500字节的内存。如果一个实例对象没有被任何方法的局部变量引用，也没有被任何类的静态变量（包括常量等）引用，那么垃圾回收线程会将其视为不再需要的“UserManager”实例对象，并将其从内存中清除，释放其所占用的内存资源。总结来说，JVM中的“垃圾”指的是无用的对象，而“垃圾回收”则是JVM自动清理这些无用对象，释放内存资源的机制。

在深入了解了JVM的类加载机制之后，我们来探讨一下JVM的内存区域划分。这一主题是互联网公司面试中常会涉及到的知识点，因此对求职者来说，掌握其细节显得尤为重要。

除了上面那几种之外，还可以自定义类加载器，去根据你自己的需求加载你的类。

首先，假设我们已经编写了一些Java代码，这些代码通常会包含许多以“.java”为后缀的源文件，例如Hello.java，Test.java等。在我们编写好的“.java”代码进行打包的过程中，通常会将代码编译成以“.class”为后缀的字节码文件，例如“Hello.class”，“Test.class”。首先，JVM需要将这些“.class”文件中包含的各种类加载进来，这些“.class”文件实际上是我们编写的每一个类。接下来，JVM将利用其内置的字节码执行引擎来运行已经加载到内存中的我们编写的类。