JVM垃圾回收算法Java APP应用程序不允许程序员手动管理内存中的垃圾回收，因为JVM有自己的垃圾回收线程。 内存不足时，将自动开始回收利用。 为了平衡效率和内存碎片，派生了一系列垃圾回收算法。
1 .标记算法执行步骤：
标记：遍历整个内存区域，并标记要回收的对象。 清除：再次遍历内存并回收已标记的内存。 图解：
缺点：
效率问题； 两次穿越内存空间(第一次标记，第二次清除)。 容量问题：如果容易出现大量内存碎片，需要另一个相对较大的内存，则总可用内存足够，但由于太分散，连续找不到满足分配请求的内存，必须重新启动GC。 2 .复制算法将内存分割成两大块，每次只使用其中一个。 一块消失，GC启动后，将该块中的存活对象复制到其他区域，一次清理其浪费的内存。 下次触发GC的时候，把那个块中生存的东西再复制到那个上，然后删除那个块，循环往复。
图解：
优点
相对标记清理算法解决了内存碎片问题，因为复制时会将所有存活的对象合并在一起。 效率高(清理内存时，顺利记住地址，一次删除)。缺点：
内存使用率不高，一次只能使用一半的内存。 8G内存，只能使用4G，这是不能接受的。 通过对研究的改进，发现大部分对象都是“朝生夕死”，即生命周期非常短。 也就是说，在GC发生的时候，实际上几乎所有的对象都已经在等待回收，还处于正常状态的对象很少。 因为生存非常少，所以在进行复制时，复制的对象非常少，占用的空间也非常小，完全不需要按照1:1分割内存空间。 剩下也没用，充分分配就可以了。
但是，有些对象的生命周期非常长，例如缓存中的对象或其他对象。 如果每次都尝试复制和移动这些对象，则会特别麻烦。 另外，如果有些对象非常大，复制后就不能放置。 因此，根据对象的特点进行了分治。 把整个堆分成两个大块。 用于保管如意象世代和古老年代，各自具有不同特征的对象。
如意的大象世代怎么样？ 保管生命周期短的对象及其体积小的对象。
旧时代保管着生命周期长、体积大的对象。
并对如意的大象世代和古老的年代采用了不同的垃圾回收算法。 如意大象使用复制算法：
将所有如意的大象世代按8 : 1 : 1的比例分成3部分，最大的称为tmddt (伊甸园)区，较小的分别称为To Survivor和From Survivor。
在最初的GC中，只需将tmddt生存的对象复制到To即可。 然后回收整个tmddt区。 再次为GC时，将tmddt和To存活的内容复制到From，循环重复该过程。 这样，每一代如意大象的可用内存占整个如意大象世代的90%，大大提高了内存利用率。
但是，不能保证每次生存的对象不到如意的大象世代全体的10%，此时即使复制也无法保存过去。 因此，在此使用旧年，进行分配担保，如果不能保存的话将对象保存在旧年。 如果还不够，就扔OOM。 另外，如果一个对象在多次内存回收后仍存在，则进入旧年代，该次数通过
(‐XX: MaxTenuringThreshold控件，最大值为15.(对象头中的4个位存储)。
3 .标记如果整理算法对象存活率高或对象大，用前面的复制算法这样复制，复制没有意义，浪费时间。 因此，针对古老的年代提出了“标签整理”算法。
执行步骤：
标记：对需要回收的内容进行标记组织：将存活对象移动到内存边缘，直接清理未使用的内存。 图解：
4、分代收集算法分代收集算法其实并没有什么新的东西，根据上面如意象的世代和年代不同的对象特点，采用不同的算法进行回收，命名为分代收集。
对象怎样才会进入老年代呢？
晋升：在对象足够老的时候、上了年纪的时候晋升。 怎样才能足够老呢？ 对象在多次回收垃圾后，依然存活。 也就是说，多次从from-to到to-from，多次生存。 jvm认为没有必要继续按原样复制这样的对象，因此将其提升为旧时代。 分配保证：默认Survivor只占整个年轻一代的10%。 从eden区域复制到from/to时，将无法保存。 此时，对象将移动到旧年代。 -XX:PretenureSizeThreshold大对象直接分配给旧年代。 动态对象年龄判定：在eden区，如果某个年龄的对象已经占整个eden的一半，则以上年龄的对象将进入老年代。