共计 1065 个字符，预计需要花费 3 分钟才能阅读完成。
为什么一个 Survivor 区不行？第一局部中，咱们晓得了必须设置 Survivor 区。假如当初只有一个 survivor 区，咱们来模仿一下流程：刚刚新建的对象在 Eden 中，一旦 Eden 满了，触发一次 Minor GC，Eden 中的存活对象就会被挪动到 Survivor 区。这样持续循环上来，下一次 Eden 满了的时候，问题来了，此时进行 Minor GC，Eden 和 Survivor 各有一些存活对象，如果此时把 Eden 区的存活对象硬放到 Survivor 区，很显著这两局部对象所占有的内存是不间断的，也就导致了内存碎片化。我绘制了一幅图来表明这个过程。其中色块代表对象，红色框别离代表 Eden 区（大）和 Survivor 区（小）。Eden 区天经地义大一些，否则新建对象很快就导致 Eden 区满，进而触发 Minor GC，有悖于初衷。
碎片化带来的危险是极大的，重大影响 Java 程序的性能。堆空间被分布的对象占据不间断的内存，最间接的后果就是，堆中没有足够大的间断内存空间，接下去如果程序须要给一个内存需要很大的对象分配内存。。。画面太美不敢看。。。这就好比咱们爬山的时候，背包里所有货色紧挨着放，最初就可能省出一块残缺的空间放相机。如果每件行李之间隔一点空隙乱放，很可能最初就要一路把相机挂在脖子上了。那么，牵强附会的，应该建设两块 Survivor 区，刚刚新建的对象在 Eden 中，经验一次 Minor GC，Eden 中的存活对象就会被挪动到第一块 survivor space S0，Eden 被清空；等 Eden 区再满了，就再触发一次 Minor GC，Eden 和 S0 中的存活对象又会被复制送入第二块 survivor space S1（这个过程十分重要，因为这种复制算法保障了 S1 中来自 S0 和 Eden 两局部的存活对象占用间断的内存空间，防止了碎片化的产生）。S0 和 Eden 被清空，而后下一轮 S0 与 S1 替换角色，如此周而复始。如果对象的复制次数达到 16 次，该对象就会被送到老年代中。下图中每局部的意义和上一张图一样，就不加正文了。
上述机制最大的益处就是，整个过程中，永远有一个 survivor space 是空的，另一个非空的 survivor space 无碎片。那么，Survivor 为什么不分更多块呢？比方说分成三个、四个、五个? 显然，如果 Survivor 区再细分上来，每一块的空间就会比拟小，很容易导致 Survivor 区满，因而，我认为两块 Survivor 区是通过衡量之后的最佳计划。原文：https://www.cnblogs.com/duanxz/p/6076662.html
