Java 内存分配策略
对象的内存分配,往大方向上讲,就是在堆上分配(但是可能经过JIT编译器后被扯散为标量类型并间接地在栈上分配),对象主要分配在新生代的Eden区上,如果启动了本地线程分配缓冲,将按线程优先在线程私有的分配缓存区(TLAB-Thread Local Allocation Buffer)。少数情况下也可能直接分配在老年代中,分配的规则并不是百分百之固定的,其细节取决于当前使用的是哪一种垃圾收集器组合,还有虚拟机中与内存相关的参数的设置。
- 对象优先在Eden分配
大多数情况下,对象在新生代Eden区中分配。当Eden区没有足够的空间进行分配时,虚拟机将发起一次Minor GC。
我们设置堆的大小为20MB,新生代10MB,新生代Eden区与一个Survivor区的空间比例为8:1,老年代为10MB。尝试先分配3个MB大小的对象X1,X2,X3,再分配一个4MB大小的对象X4。当分配对象X4时,会发生一次Minor GC,当然X1,X2,X3都是存活的。这次GC发生的原因是给X4分配内存的时候,发现Eden已经被占用了6MB,剩余空间已不足以分配X4所需的内存,因此发生GC。GC期间虚拟机又发现已有的3个对象X1,X2,X3全部无法进入Survivor空间,所有只好通过分配担保机制提前转移到老年代去。
新生代GC(Minor GC):指发生在新生代的垃圾收集动作,因为Java对象大多都具有朝生夕灭的特性,所以Minor GC非常频繁,一般回收速度也比较快。
老年代GC(Major GC/Full GC ):指发生在老年代的GC,出现了Major GC,经常会伴随至少一次的Minor GC。Major GC的速度一般会Minor GC慢10倍以上。
2. 大对象直接进入老年代
所谓大对象就是指,需要大量连续对象内存空间的Java对象,最典型的大对象就是那种很长的字符串及数组。虚拟机提供一个 -XX:PretenureSizeThreshold参数,令大于这个设置值的对象直接在老年代中分配。这样做的目的是避免在Eden区及两个Survivor区之间发生在大量的内存拷贝(新生代采用复制算法收集内存)。
3. 长期存活的对象将进入老年代
虚拟机采用分代收集的思想来管理内存,那内存回收时就必须能识别那些对象应当放在新生代,那些对象应放在老年代中。为了做到这一点,虚拟机给每个对象定义了一个对象年龄(Age)计数器。如果对象在Eden出生并经过第一次Minor GC都仍然存活,并且能被Survivor容纳的话,将被移动到Survivor空间中,并将年龄设为1.对象在Survivor区中每熬过一次Minor GC,年龄就增加1岁,当它的年龄增加到一定程度(默认为15岁)时,就会被晋升到老年代中。对象晋升老年代的年龄阀值,可以通过参数-XX:MaxTenuringThreshold来设置。
4. 动态对象年龄判定
为了能更好地适应不同程序的内存状况,虚拟机并不是总是要求对象的年龄必须达到MaxTenuringThreshold才能晋升老年代。如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半,大于或等于该年龄的对象就可以直接进入老年代,无需等到MaxTenuringThreshold要求的年龄。
5. 空间分配担保
在发生Minor GC时,虚拟机会检测之前每次晋升到老年代的平均大小是否大于老年代剩余空间大小,如果大于,则改为直接进行一次Full GC 。如果小于,则查看HandlePromotionFailure设置是否允许担保失败;如果允许只会进行Minor GC;如果不允许,则改为进行一次Full GC。
老年代要进行这样的担保,前提是老年代本身还有容纳这些对象的剩余空间,一共有多少对象会活下来,在实际完成回收之前是无法确定的,所以只好取之前每一次晋升到老年代对象容量的平均值作为经验值,与老年代的剩余空间进行比较,决定是否进行Full GC 来让老年代腾出更多的空间。
取平均值进行比较其实仍然是一种动态的概率手段,也即是说如果某次Minor GC 存活后的对象剧增,远远高于平均值的话,依然到导致担保失败。如果出现了担保失败,那就只好在失败后中心发起一次Full GC 。大部分情况下都还是将HandlePromotionFailure开关打开,避免Full GC过于频繁。