淘先锋技术网

首页 1 2 3 4 5 6 7

java内存分配策略

JVM采用分代的垃圾回收策略：不同对象的生命周期是不一样的。目前JVM分代主要是分三个年代：

  • 新生代：所有新创建的对象都首先在新生代进行内存分配。新生代具体又分为3个区，一个Eden区、一个From Survivor区和一个To Sruvivor区。大部分对象都被分配在Eden区，当Eden区满时，还存活的对象将被复制到From Survivor区，当From Survivor区满时，此区还存活的对象将被复制到To Survivor区。最后，当To Survivor区也满时，这时从From Survivor区复制过来并且还存活的对象将被复制到老年代。
  • 老年代：在年轻代中经历了N次（一般是15次）GC后依然存活的对象，就会被放到老年代当中。因此，可以认为老年代是存放一些生命周期较长的对象。
  • 永久代（方法区的实现） : PermGen----->替换为Metaspace(本地内存中) 。
    元空间是方法区的在HotSpot jvm 中的实现，方法区主要用于存储类的信息、常量池、方法数据、方法代码等。方法区逻辑上属于堆的一部分，但是为了与堆进行区分，通常又叫“非堆”。
    元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。

具体如下图所示： 


对象优先在Eden分配

在大多数情况下，对象在新生代的Eden区中分配。当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC。

虚拟机提供了-XX:+PrintGCDetails这个收集日志参数，告诉虚拟机在发生垃圾收集行为时打印内存回收日志，并且在进程退出的时候输出当前的内存各区域分配情况。

使用示例代码来分析GC过程，具体代码如下：

package jvm;

import java.lang.String;

/**
 * 执行的jvm参数：-verbose:gc -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8
 */
class GarbageCollection {
    public static final int ONEMB = 1024 * 1024;

    public static void testAllocation() {
        byte[] allocation1, allocation2, allocation3, allocation4;

        allocation1 = new byte[2 * ONEMB];
        allocation2 = new byte[2 * ONEMB];
        allocation3 = new byte[2 * ONEMB];
        allocation4 = new byte[4 * ONEMB];
        System.out.println("OK!");
    }


    public static void main(String[] args) {
        GarbageCollection.testAllocation();
    }
}

运行结果：

[GC (Allocation Failure) [PSYoungGen: 6532K->1007K(9216K)] 6532K->5139K(19456K), 0.0332233 secs] [Times: user=0.03 sys=0.00, real=0.03 secs] 
OK!
Heap
 PSYoungGen      total 9216K, used 7391K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
  eden space 8192K, 77% used [0x00000000ff600000,0x00000000ffc3bfe0,0x00000000ffe00000)
  from space 1024K, 98% used [0x00000000ffe00000,0x00000000ffefbdf0,0x00000000fff00000)
  to   space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000)
 ParOldGen       total 10240K, used 4132K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
  object space 10240K, 40% used [0x00000000fec00000,0x00000000ff009200,0x00000000ff600000)
 Metaspace       used 2984K, capacity 4494K, committed 4864K, reserved 1056768K
  class space    used 325K, capacity 386K, committed 512K, reserved 1048576K

通过-Xmx20M限定了Java堆大小为20M，-Xmn限定了新生代的大小为10M，剩下的10M分给老年代。同时，使用-XX:SurvivorRatio=8决定了新生代Eden区与一个Survivor区的空间比例是8:1，在运行结果中也能看到“eden space 8192K, from space 1024K, to space 1024K”，新生代总共可用的空间是9216K（Eden区+1个Survivor区的总容量）。

执行testAllocation()中分配allocation4对象的语句时会发生一次Minor GC，这次GC的结果是新生代6651KB变成148KB，而总内存占用量则几乎没有减少（因此allocation1、allocation2、allocation3三个对象都是存活的，虚拟机几乎没有任何可以回收的对象）。这次GC发生的原因是给allocation4分配内存的时候，发现Eden已经被占用了6MB，剩余空间不足以分配allocation4所需要的4M内存，因此发生了Minor GC。GC期间虚拟机又发现已有的3个2MB大小的对象全部无法收入Survivor空间，所以只好通过担保机制提前转移到老年代去。

这次GC结束后，4MB的allocation4对象顺利分配在Eden中，因此程序执行完成的结果是Eden占用4MB（被allocation4占用），Survivor空间，老年代被占用6MB（被allocation1、allocation2、allocation3占用）。通过GC日志也能说明这一点。

大对象直接进入老年代

所谓的大对象是指，需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组。大对象对虚拟机的内存分配来说是一个坏消息，经常出现大对象容易导致内存还有不少空间的情况下就提前触发了GC以获取足够的连续空间来“安置”它们。 
虚拟机提供了一个-XX:PretenureSizeThreshold参数，令大于这个设置值的对象直接在老年代分配。这样做的目的是避免在Eden区以及两个Survivor区之间发生大量的内存复制。

示例代码如下：

package jvm;

import java.lang.String;

/**
 * -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:PretenureSizeThreshold=1048576
 */
class GarbageCollection {
    public static final int ONEMB = 1024 * 1024;

    public static void testAllocation() {
        byte[] allocation4;

        allocation4 = new byte[4 * ONEMB];  // 直接在老年代分配
        System.out.println("OK!");
    }


    public static void main(String[] args) {
        GarbageCollection.testAllocation();
    }
}

运行结果是应该是这样的：

OK!
Heap
 PSYoungGen      total 9216K, used 5296K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
  eden space 8192K, 64% used [0x00000000ff600000,0x00000000ffb2c120,0x00000000ffe00000)
  from space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000)
  to   space 1024K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x00000000fff00000)
 ParOldGen       total 10240K, used 0K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
  object space 10240K, 0% used [0x00000000fec00000,0x00000000fec00000,0x00000000ff600000)
 PSPermGen       total 21504K, used 2554K [0x00000000f9a00000, 0x00000000faf00000, 0x00000000fec00000)
  object space 21504K, 11% used [0x00000000f9a00000,0x00000000f9c7e888,0x00000000faf00000)
实际结果是： 
OK!
Heap
 PSYoungGen      total 9216K, used 6697K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
  eden space 8192K, 81% used [0x00000000ff600000,0x00000000ffc8a450,0x00000000ffe00000)
  from space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000)
  to   space 1024K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x00000000fff00000)
 ParOldGen       total 10240K, used 0K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
  object space 10240K, 0% used [0x00000000fec00000,0x00000000fec00000,0x00000000ff600000)
 Metaspace       used 3063K, capacity 4494K, committed 4864K, reserved 1056768K
  class space    used 331K, capacity 386K, committed 512K, reserved 1048576K

长期存活的对象将进入老年代

既然虚拟机采用了分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应放在新生代，哪些对象应放在老年代。为了做到这一点，虚拟机给每个对象定义了一个对象年龄(Age)计数器。如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设为1。对象在Survivor区中每“熬过”一次Minor GC，年龄就增加1岁。当它的年龄增加到一定程度（默认是15岁），将会被晋升到老年代。对象晋升到老年代的阈值可以通过参数-XX:MaxTenuringThreshold设置。

空间分配担保

在发生Minor GC之前，虚拟机会先检查老年代最大可用连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么Minor GC是确保安全的。如果不成立，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，蒋尝试进行一次Minor GC，尽管这次GC是有风险的。如果小于，或者HandlePromotionFailure设置不允许冒险，那这时也要改为进行一次Full GC。 
下面解释一下“冒险”是冒了什么风险？ 

这里的风险其实就是指：老年代的空间不一定能容纳青年代所有存活的对象，一旦不能容纳，那就还需要进行一次Full GC。

Minor GC and Full GC

Minor GC：从年轻代空间（包括Eden和Survivor区域）回收内存成为Minor GC。在发生Minor GC时候，有两处需要注意的地方：

  1. 当JVM无法为一个新的对象分配空间时会触发Minor GC，例如当Eden区满了，所以分配的频率越高，执行Minor GC的频率也可能越频繁。
  2. 所有的Minor GC都会触发“stop-the-world”，停止应用程序的线程。对于大部分应用程序，停顿导致的延迟都是可以忽略不计的。

Full GC：对整个堆进行整理，包括Young Generation、Old Generation、Permanent Generation。Full GC因为需要对整个区进行回收，所以比Minor GC要慢，因此应该尽可能减少Full GC的次数。