垃圾回收机制

对象的大小

• 对象头: 对象自己本身的一些信息

• 一个是对象的实例变量作为数据占用的空间

引用关系

狭义的定义:如果reference类型的数据中存储的数值代表的是另一块内存的起始地址,就称这块内存代表着一个引用

强引用

软引用

弱引用

虚引用

垃圾回收的概念

类对象回收

• 首先该类的所有实例对象都已经从Java堆内存里被回收

• 其次加载这个类的ClassLoader已经被回收

• 最后，对该类的Class对象没有任何引用

判断对象存活算法

引用计数法

public class Class1 {
    public Object instance = null;
    private static final int MEMORY = 1024 * 1024;
    private byte[] bigSize = new byte[2 * MEMORY];

    public static void testGC() {
        Class1 o1 = new Class1();//step1
        Class1 o2 = new Class1();//step2
        o1.instance = o2;//step3
        o2.instance = o1;//step4
        o1=null;//step5
        o2=null;//step6
        System.gc();
    }

    public static void main(String[] args) {
        testGC();
    }
}

[GC (System.gc()) [PSYoungGen: 8028K->4824K(76288K)] 8028K->4832K(251392K), 0.0026914 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (System.gc()) [PSYoungGen: 4824K->0K(76288K)] [ParOldGen: 8K->4666K(175104K)] 4832K->4666K(251392K), [Metaspace: 3376K->3376K(1056768K)], 0.0053168 secs] [Times: user=0.02 sys=0.00, real=0.00 secs]
Heap
 PSYoungGen      total 76288K, used 1966K [0x000000076ae00000, 0x0000000770300000, 0x00000007c0000000)
  eden space 65536K, 3% used [0x000000076ae00000,0x000000076afeb9e0,0x000000076ee00000)
  from space 10752K, 0% used [0x000000076ee00000,0x000000076ee00000,0x000000076f880000)
  to   space 10752K, 0% used [0x000000076f880000,0x000000076f880000,0x0000000770300000)
 ParOldGen       total 175104K, used 4666K [0x00000006c0a00000, 0x00000006cb500000, 0x000000076ae00000)
  object space 175104K, 2% used [0x00000006c0a00000,0x00000006c0e8ead8,0x00000006cb500000)
 Metaspace       used 3387K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 325K, capacity 388K, committed 512K, reserved 1048576K

可达性算法(根搜索法)

1. 虚拟机栈(栈帧中的本地变量表)中的引用的对象

2. 方法区中的类静态属性引用的对象

3. 方法区中的常量引用的对象

4. 本地方法栈中JNI(一般说的Native)的引用的对象

finalize()方法

JVM堆内存分代模型

堆中对象的特点

1. 大部分对象都是存活周期极短的 : 朝生夕死
在上面代码中，那个ReplicaManager对象，实际上属于短暂存活的这么一个对象

2. 少数对象是长期存活的



上面那段代码的意思，就是给Kafka这个类定义一个静态变量，也就是“replicaManager”，这个Kafka类是在JVM的方法区里的
然后让“replicaManager”引用了一个在Java堆内存里创建的ReplicaManager实例对象，如下图



接着在main()方法中，就会在一个while循环里，不停的调用ReplicaManager对象的load()方法，做成一个周期性运行的模式。 这个ReplicaManager实例对象，他是会一直被Kafka的静态变量引用的，然后会一直驻留在Java堆内存里，是不会被垃圾回收掉的。
因为这个实例对象他需要长期被使用，周期新的被调用load()方法，所以他就成为了一个长时间存在的对象。
类似这种被类的静态变量长期引用的对象，他需要长期停留在Java堆内存里，这这种对象就是生存周期很长的对象，他是轻易不会被垃圾回收的，他需要长期存在，不停的去使用他。

分代模型

分代原因

分代年龄

新生代对象到老年代的时机

Minor GC (Young GC)

分代年龄到指定次数

动态对象年龄判断

大对象直接进入老年代

Minor GC后的对象太多无法放入Survivor区

老年代空间分配担保规则

触发分配担保策略的时机

担保过程

1. 在执行任何一次Minor GC之前，JVM会先检查一下老年代可用的内存空间，是否大于新生代所有对象的总大小。 为啥检查这个呢？因为最极端的情况下，可能新生代Minor GC过后，所有对象都存活下来了，那岂不是新生代所有对象全部要进入老年代？如下图。
如果说发现老年代的内存大小是大于新生代所有对象的，此时就可以放心大胆的对新生代发起一次Minor GC了，因为即使Minor GC之后所有对象都存活，Survivor区放不下了，也可以转移到老年代去。



假如执行Minor GC之前，发现老年代的可用内存已经小于了新生代的全部对象大小了 那么这个时候是不是有可能在Minor GC之后新生代的对象全部存活下来，然后全部需要转移到老年代去，但是老年代空间又不够？理论上，是有这种可能的。

2. 下一步判断，就是看看老年代的内存大小，是否大于之前每次Minor GC后进入老年代的对象的平均大小。
举个例子，之前每次Minor GC后，平均都有10MB左右的对象会进入老年代，那么此时老年代可用内存大于10MB。
这就说明，很可能这次Minor GC过后也是差不多10MB左右的对象会进入老年代，此时老年代空间是够的，看下图。

3. 如果上面那个步骤失败了，此时就会直接触发一次“FullGC”，就是对老年代进行垃圾回收，尽量腾出来一些内存空间，然后再执行Minor GC。
如果上面两个步骤都判断成功了，那么就是说可以冒点风险尝试一下Minor GC。此时进行Minor GC有几种可能。
第一种可能，Minor GC过后，剩余的存活对象的大小，是小于Survivor区的大小的，那么此时存活对象进入Survivor区域即可。
第二种可能，Minor GC过后，剩余的存活对象的大小，是大于 Survivor区域的大小，但是是小于老年代可用内存大小的，此时就直接进入老年代即可。
第三种可能，很不幸，Minor GC过后，剩余的存活对象的大小，大于了Survivor区域的大小，也大于了老年代可用内存的大小。此时老年代都放不下这些存活对象了，就会发生“Handle Promotion Failure”的情况，这个时候就会触发一次“Full GC”。Full GC就是对老年代进行垃圾回收，同时也一般会对新生代进行垃圾回收。
因为这个时候必须得把老年代里的没人引用的对象给回收掉，然后才可能让Minor GC过后剩余的存活对象进入老年代里面。

4. 如果要是Full GC过后，老年代还是没有足够的空间存放Minor GC过后的剩余存活对象，那么此时就会导致所谓的“OOM”内存溢出了

垃圾收集算法

复制算法

标记-整理算法