AnthonyZero's Bolg

JVM-内存分配与回收策略

发表于 | 分类于

内存分配策略

  1. 对象优先在Eden分区:

大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够空间分配时，虚拟机发起一次Minor GC。GC后对象尝试放入Survivor空间，如果Survivor空间无法放入对象时，只能通过空间分配担保机制提前转移到老年代.

新生代中：Eden 和 Survivor 区的比例默认是 8:1:1，当然也支持参数调整 -XX:SurvivorRatio=8 （通常新生代GC时（复制算法）使用 Eden 和其中一块 Survivor。将 Eden 和 Survivor 中还存活着的对象全部复制到另一块 Survivor 上，最后清理 Eden 和使用过的那一块 Survivor，S1和S2交换使用）

  1. 大对象直接进入老年代

大对象指需要大量连续内存空间的Java对象。虚拟机提供-XX:PretenureSizeThreshold参数，如果大于这个设置值对象则直接分配在老年代。这样可以避免新生代中的Eden区及两个Survivor区发生大量内存复制

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

虚拟机会给每个对象定义一个对象年龄计数器。如果对象在Eden出生并且经过一次Minor GC后仍然存活，且能够被Survivor容纳，将被移动到Survivor空间中，并且对象年龄设为1.每次Minor GC后对象任然存活在Survivor区中，年龄就加一，当年龄到达-XX:MaxTenuringThreshold参数设定的值时，将会移动到老年代。

  1. 动态年龄判断

虚拟机并不是永远要求对象的年龄必须达到 MaxTenuringThreshold 才能晋升老年代，如果在Survivor 中相同年龄所有对象大小的总和大于 Survivor 空间的一半，则年龄大于或等于该年龄的对象可以直接进入老年代，无需等到 MaxTenuringThreshold 中要求的年龄

  1. 空间分配担保
    jvm_3.jpg

在发生 Minor GC 之前，虚拟机先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果条件成立的话，那么 Minor GC 可以确认是安全的

如果不成立的话虚拟机会查看 HandlePromotionFailure 的值是否允许担保失败，如果允许那么就会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次 Minor GC；如果小于，或者 HandlePromotionFailure 的值不允许冒险，那么就要进行一次 Full GC

线程安全性：为对象实例分配空间时要保证线程安全，有两种方案。一种是对分配内存空间的动作进行同步处理，实际上虚拟机采用CAS配上失败重试的方式保证更新操作的原子性。另一种是把内存分配的动作按照线程划分在不同空间中进行，每个线程在Java堆中预先分配一小块内存，称为本地线程分配缓冲(Thread Local Allocation Buffer , TLAB)。哪个线程要分配内存，就在哪个线程的TLAB上分配，只有TLAB用完并分配新的TLAB时，才需要同步锁定。

GC的触发条件

  • 新生代GC(Minor GC):
    发生在新生代的垃圾收集动作，因为Java对象大多朝生夕死，所以Minor GC非常频繁，回收速度也较快

  • 老年代GC(Major GC/Full GC):
    发生在老年代的垃圾收集动作。出现Full GC，经常会伴随至少一次Minor GC。Full GC的速度一般比Minor GC慢10倍以上

对于 Minor GC，其触发条件非常简单，当 Eden 空间满时，就将触发一次 Minor GC。而 Full GC 则相对复杂，有以下条件：

  1. 调用 System.gc()
    只是建议虚拟机执行 Full GC，但是虚拟机不一定真正去执行。不建议使用这种方式，而是让虚拟机管理内存。

  2. 老年代空间不足
    老年代空间不足的常见场景为前面所讲的大对象直接进入老年代、长期存活的对象进入老年代等。为了避免以上原因引起的 Full GC，应当尽量不要创建过大的对象以及数组。除此之外，可以通过 -Xmn 虚拟机参数调大新生代的大小，让对象尽量在新生代被回收掉，不进入老年代。还可以通过 -XX:MaxTenuringThreshold 调大对象进入老年代的年龄，让对象在新生代多存活一段时间。

  3. 空间分配担保失败
    使用复制算法的 Minor GC 需要老年代的内存空间作担保，如果担保失败会执行一次 Full GC。

  4. JDK 1.7 及以前的永久代空间不足
    在 JDK 1.7 及以前，HotSpot 虚拟机中的方法区是用永久代实现的，永久代中存放的为一些 Class 的信息、常量、静态变量等数据。当系统中要加载的类、反射的类和调用的方法较多时，永久代可能会被占满，在未配置为采用 CMS GC 的情况下也会执行 Full GC。如果经过 Full GC 仍然回收不了，那么虚拟机会抛出 java.lang.OutOfMemoryError。为避免以上原因引起的 Full GC，可采用的方法为增大永久代空间或转为使用 CMS GC。

  5. Concurrent Mode Failure
    执行 CMS GC 的过程中同时有对象要放入老年代，而此时老年代空间不足（可能是 GC 过程中浮动垃圾过多导致暂时性的空间不足），便会报 Concurrent Mode Failure 错误，并触发 Full GC。