Java GC:为什么有两个幸存者区域?

2022-01-16 00:00:00 jvm garbage-collection java

对于 Sun/Oracle 的 JVM,我读到 GC 算法将新一代划分为一个 Eden 区域和两个幸存者区域.我想知道的是,为什么有两个幸存者区域而不仅仅是一个?该算法可以在伊甸园和一个幸存者区域之间保持乒乓球(就像它目前在两个幸存者区域之间所做的那样);或者这种方法有什么缺点吗?

For Sun/Oracle's JVM, I've read that the GC algo divides new generation into one Eden region and two survivor regions. What I'm wondering about is, why two survivor regions and not just one? The algo can keep ping-ponging between Eden and just one survivor region (the way it currently does between two survivor regions); or are there any shortcomings to this approach?

推荐答案

我相信 JRockit 的 GC 实现更像你建议的那样,只有一个伊甸园和一个幸存者空间,但不要引用我的话.

I believe JRockit's GC implementation works more like you suggest, with just a single eden and single survivor space, but don't quote me on that.

HotSpot JVM 有两个幸存者空间的原因是为了减少处理碎片的需要.新对象分配在伊甸园空间中.一切都很好.当它满了时,你需要一个 GC,所以杀死陈旧的对象并将活的对象移动到幸存者空间,在那里它们可以成熟一段时间,然后再被提升到老年代.到目前为止还是不错的.但是,下次我们用完伊甸园空间时,我们遇到了一个难题.下一次 GC 出现并清除了 eden 和我们的幸存者空间中的一些空间,但这些空间并不连续.那么是不是更好

The reason for the HotSpot JVM's two survivor spaces is to reduce the need to deal with fragmentation. New objects are allocated in eden space. All well and good. When that's full, you need a GC, so kill stale objects and move live ones to a survivor space, where they can mature for a while before being promoted to the old generation. Still good so far. The next time we run out of eden space, though, we have a conundrum. The next GC comes along and clears out some space in both eden and our survivor space, but the spaces aren't contiguous. So is it better to

  1. 尝试将来自伊甸园的幸存者放入已被 GC 清除的幸存者空间的孔中?
  2. 将幸存者空间中的所有对象向下移动以消除碎片,然后然后将幸存者移入其中?
  3. 只需说去死吧,无论如何我们都在移动所有东西",然后将两个空间中的所有幸存者复制到一个完全独立的空间(第二个幸存者空间)中,从而为您留下一个干净的伊甸园和幸存者空间在哪里可以在下一次 GC 上重复该序列?

孙对这个问题的回答是显而易见的.

Sun's answer to the question is obvious.

相关文章