G1收集器中数组分配后为何占用2个Young区与1个Survivor区？

Hey there, let's break down exactly why you're seeing 2 Young regions and 1 Survivor region in your G1 GC logs. I'll walk through the mechanics step by step:

1. 先明确G1 GC的核心基础 #

First, let's recap key G1 details from your setup:

• Region size: 1MB (matches your heap configuration)
• Young Gen total size: 10MB (-Xmn10M)
• SurvivorRatio=8: In G1, this defines the ratio of Eden size to a single Survivor space (so Eden:Survivor0:Survivor1 = 8:1:1, meaning 8MB Eden, 1MB each Survivor in theory)
• Humongous objects: G1 classifies any object larger than half a Region (≥512KB here) as a Humongous object. These are stored in contiguous Old Gen regions, not Young Gen.

2. 你的对象分配与GC触发过程 #

Let's trace what happens when your testAllocation runs:

• You allocate allocation1, allocation2, allocation3 (each 2MB): Each of these is 2x the Region size, so they're Humongous objects. G1 allocates them directly in contiguous Old Gen regions (2 regions per object, totaling 6MB used in Old Gen).
• When allocating allocation4 (4MB), G1 needs 4 contiguous Old Gen regions. At this point, the Old Gen has 6MB used out of its 10MB total (since total heap is 20MB, Young Gen takes 10MB), but the remaining 4MB might not be contiguous. This triggers a G1 Humongous Allocation GC—a special Young GC that also kicks off the initial-mark phase of concurrent marking, as seen in your log: [GC pause (G1 Humongous Allocation) (young) (initial-mark)].

3. 为什么会有2个Young区和1个Survivor区？ #

The 2 Young regions and 1 Survivor region aren't from your large 2MB/4MB objects (those are in Old Gen). Here's where they come from:

• Young regions (2x1MB): When the JVM starts up and runs your code, it creates small internal young objects (like class metadata helpers, string instances, etc.) that get allocated in Eden. After the Young GC triggered by allocation4, G1 dynamically adjusts the active Eden space to only what's needed—right now, that's 2 regions (2MB) for new young objects, hence the 2 young (2048K) in the log.
• Survivor region (1x1MB): During the Young GC, any surviving young objects (from the initial Eden allocations) are copied to a Survivor region. This is standard Young GC behavior—Survivor spaces hold objects that survived one GC cycle before moving to Old Gen. The log shows 1 survivors (1024K) because one Survivor region is holding these surviving objects.

最后再确认一下 #

Your 2MB/4MB objects are all in Old Gen's Humongous regions, which aren't counted in the "young" or "survivors" stats. The numbers you see are purely from the JVM's internal young object allocations and the Survivor space usage after the GC.

内容的提问来源于stack exchange，提问作者YuanXL