译文-java垃圾回收机制

原文出处：java垃圾回收机制

标记清除算法介绍最主要的理论算法之一，在实践过程当中，为了真实情景须要，须要许多调整。举一个简单例子，咱们检查JVM须要作的各类事情，以便咱们安全地去建立对象。

清除压缩

当清除期间，JVM必须确保区域被不可达对象填充。这会(终将会)致使内存碎片化，一样会致使磁盘碎片化，由此产生两个问题：

• 写操做由于寻找下一个足够尺寸的空间变得耗费时间，这个写操做再也不简单。

• 当建立新对象的时候，JVM分配一个连续的空间。若是内存碎片遍及每个点，没有足够的空间容纳新建立的对象，分配就会发生错误。

为了不上面的问题，JVM会确保碎片化不会失控。所以不会仅仅标记清除，垃圾回收期间，"内存整理"进程同时在工做。这个进程从新分配全部的可达对象让他们紧密排列，消除（或者减小）碎片。下面是示意图：

分代假设

正如咱们以前提到，垃圾收集会引发应用完全停顿。对象越多回收垃圾花费的时间越长，这是显而易见的。若是咱们把使用一小块内存工做变成可能，那又会怎样呢？为了研究这种可行性，一些专家发现应用的大多数内存分为如下两种状况：

• 绝大多数对象很快就成为无用对象。

• 不多部分对象讲过很长时间存活下来。

上面的观察结果归类于新生代假设。基于这个假设：VM内存空间被划分为Young代 和Old代，后者有时也叫作Tenured。

众多算法在提高GC性能上已经取得进展，使得拥有这样一个独立易清除的内存区域变成现实。

这种方式虽然说不上毫无问题。当垃圾收集器收集一个分代中的对象的时候，不一样分代中的对象彼此相互引用的时，实际上被看成"GC roots"。

可是更更要的一点是，分代假设并不适用于一些应用。自此，由于那些“夭折”和“有可能永生”的对象,GC算法作了优化，JVM对那些期待更久生命的对象表现得友好。

内存空间

读者应该了解下图中java堆区里面的内存划分。不一样内存区域的垃圾收集机制不辣么容易理解。应该注意，不一样GC算法实现细节可能不一样，然而它们的理念是一致的。

Eden

Eden区是对象被新建立的时候分配的内存区域。在这个区域中，多线程能够同时建立多个对象。在Eden区里，Eden 被分红一个或多个Thread Local Allocation Buffer (缩写：TLAB)。在这些缓存里，JVM容许线程在对应的缓存中分配绝大多数的对象，避免昂贵的多线程同步。

当TLAB中不能分配空间时（由于空间不足），JVM会移到共享的Eden区去分配，若是共享Eden空间也不足时，Young代中垃圾回收器去释放更多的空间。若是在GC以后尚未足够的空间以供使用，对象会在Old代中分配。

当Eden回收期间，GC把全部的可达对象标记为存活。

咱们已经提早注意到，对象能够跨代关联，所以咱们必须有一个快捷途径去检查其余代的对象引用Eden区中的对象。

从一开始就记录全部的分代引用是不可取的， JVM有本身的机制：卡标记。事实上，JVM仅仅标记Eden里面有可能Old代引用Eden代的对象的“脏”对象的位置，你能够在Nitsan的博客里了解更多的信息。

标记阶段完成以后，Eden区下面全部存活的对象被复制到Survivor下面的一块区域中。如今，Eden区被清空，从新分配新建对象。正如“标记-复制”的名称同样：存活的对象被标记，而后复制(不是移动)到Survivor区。

Survivor区

紧邻Eden区的下一个区域时两个叫作from和to的Survivor区。须要注意的一点，两块区域中的一块是空的。

Survivor中的空的区域会保存下一刻Young代中垃圾回收后的对象。Young代全部存活的对象（包括Eden区和Survior区中非空的from区域）被复制到Survivor区的"to"区域。在这以后，“to”区域存放全部对象，“from”区域清空。二者进行调换（译者注：即from变成to,to变成from）。

在两个区域进行数次复制存活对象操做，直到一些对象足够成熟（“old enough”）。记住这一点，基于分代假设，一些对象在数次GC以后存活下来，并且在很长一段时间内继续被引用。

这样的“tenured”对象会升级到Old代。这种状况发生的时候，对象再也不从Survuvor区一个区域移动到另一个区域，而是进入Old区，在成为不可达对象以前它们一直存在在old区中。

为了肯定哪些对象“old enough”,须要为old区提供一种算法，GC记录幸存对象的详细信息。每代GC完成以后，那些依然存活的对象年龄进行增加。每当年龄超过设定的阀值以后，对象才会被升迁到old区。

实际上阀值被JVM动态设定，-XX:+MaxTenuringThreshold 除外，它设置最高限定。XX:+MaxTenuringThreshold=0 表示跳过Survivor区的两个区域之间复制过程直接进入old区。jvm默认阀值是GC循环15次。在Hotspot是最大值。

Survivor区空间不足以容纳Young代全部存活对象的时候升迁操做被提早触发。

Old代

Old代的具体实现细节巨复杂。Old代一般被那些几乎不可能被看成垃圾的对象占据。

Old代GC触发的次数比Young代少。所以，Old代中的存活对象，不会发生标记复制过程。相反，这些对象保持最小碎片化。这种算法创建在不一样维度之上。大致上，分为如下几步：

• 经过设置全部GC roots可达的对象标记位来标记全部可达对象。

• 删除全部的不可达对象。

• 经过复制对象并紧密排列在Old区的顶端压缩Old区的空间。

正如你看到上面描述的那样，Old代的GC必须明确处理压缩错左避免过多的碎片。

PermGen

JAVA 8以前中被称做“Permanent Generation”的特殊区域。这是之前存放例如class的metadata。而，Permgen还存储String之类的额外数据。实际上为JAVA开发者添加了许多麻烦，由于很难预测到底须要多少的空间。这些错误的预测结果表现形式为java.lang.OutOfMemoryError: Permgen space。除非是相似OutOfMemoryError的缘由是真的是由于内存泄漏，解决这种问题的简单方法是增长permgen尺寸。下图中设置permgen尺寸的最大值为256M：

java -XX:MaxPermSize=256m

Metaspace

正如预测metadata是一件纷繁复杂的事情那样，JAVA 8移除了Permanent区，换做Metaspace。从那时起，绝大多数复杂的事情都被移到Java heap区。

类定义文件，如今都存入叫作“Metaspace”的区域中。他至关于本地内存的一块区域。理论上，Metaspace尺寸仅仅受限于JAVA进程可得到本地内存大小。将JAVA开发人员从仅仅在应用多增长一个类就形成java.lang.OutOfMemoryError: Permgen space的困境中解脱出来。须要注意的是这个看起来不受限制没有损失的空间-让Metaspace无限制的增加你会引发内存重交换或者/和本地内存分配失败。

某些场合你但愿保护本身，你能够以下图所示限制Metaspace增加，Metaspace尺寸限制在265M：

java -XX:MaxMetaspaceSize=256m