垃圾回收机制（GC）：垃圾回收中的一个很重要的问题STW（stop the world）问题。触发垃圾回收的时候，很可能回使当前程序的其他的业务逻辑被暂停。垃圾回收，是回收内存：它的主要战场在堆上。
其实这里的垃圾回收，说是回收内存，更准确的说是"回收对象"，每次垃圾回收的时候，释放的若干个对象。（实际的单位都是对象）
1.识别出垃圾
1.1 引用计数
这种思想方法，并没有在JVM中使用，但是广泛应用于其他主流语言的垃圾回收机制中。（Python，PHP）
此时垃圾回收机制：（有专门的扫描线程，去获取到当前每个对象的引用计数的情况）发现对象的引用计数为0，说明这个对象就可以释放了。
1.2 可达性分析（JVM用的是这个）
本质上使用"时间"换"空间"相比于引用计数，需要消耗更多的额外的时间，但是总体来说，还是可控的，不会产生类似于"循环引用"这样的问题。在代码的过程中，会定义很多的变量。比如，栈上的局部变量/方法区中的静态类型的变量/常量池中引用的对象....就可以从这些变量作为起点，出发，尝试去进行"遍历"，所谓的遍历就是沿着这些变量中持有的引用类型的成员，在进一步的往下进行访问，所有能被访问到的对象，自然就不是垃圾了，剩下的遍历一圈也访问不到的对象，自然就是垃圾。
2. 把标记为垃圾的对象内存进行释放
2.1 标记-清楚
把标记为垃圾的对象， 直接释放掉。（最朴素的做法）
此时就是把标记为垃圾的对象对应的内存直接释放，就会产生了上述的内存碎片。它产生了很多小的，但是离散的空闲内存空间，就可能会导致后续申请内存失败。。
2.2 复制算法
复制算法，核心就是不直接释放内存，而是把不是垃圾的对象，复制到内存的另一半，接下俩就把左侧空间整体释放掉。
2.3 标记-整理
也能解决内存碎片问题，类似于 顺序表 删除中间元素，通过这个过程，也能有效解决内存碎片的问题，并且这个过程也不像复制算法一样，需要浪费过多的内存空间，但是这里的搬运内存开销很大。
3. 分代回收（依据不同种类的对象，采取不同的方式）
引入概念对象的年龄，JVM中专门的线程负责周期性扫描/释放，一个对象，如果被线程扫描了一次，可达了（不是垃圾），年龄就+1（初始年龄相当于是0）。JVM中就会根据对象年龄的差异，把整个堆内存分成俩个大的部分，新生代（年龄小的对象）/老年代（年龄大的对象）。
分代回收过程：
-
当代码中new 出一个新的对象，这个对象就是被创建在伊甸区。
-
第一轮GC扫描完成之后，少数伊甸区中幸存的对象，就会通过复制算法，拷贝到生存区后续GC的扫描线程还会持续进行扫描，不仅要伊甸区，也要扫描生存却的对象。生存区中的大部分对象也在扫描中被标记为垃圾，少数存活的，就会继续使用复制算法，拷贝到另一个生存区中。只要这个对象能够在生存区继续存活，就会被复制算法继续拷贝到另一半的生存区中，并且没经历一次GC的扫描，对象的年龄都会+1。
3.如果这个对象在生存区中，经过了若干轮GC任然存在健在，JVM就会认为，这个对象生命周期大概率很长，就把这个对象从生存区，拷贝到老年区。
- 老年代的对象，当然也要被GC扫描，但是扫描的频次就会大大降低了。
5.对象在老年代寿终正寝，此时JVM就会按照标记整理的方式，释放内存。