老年代对象越来越多，是不是会发现说，老年代的内存空间也会满的，可以不可以使用类似年轻代的复制算法，不合适的，因为老年代里的对象，很多都是被长期引用的，spring容器管理的各种bean
长期存活的对象是比较多的，可能甚至有几百MB
对老年代而言，他里面垃圾对象可能是没有那么多的，标记-清理，找出来那些垃圾对象，然后直接把垃圾对象在老年代里清理掉，标记-整理，把老年代里的存活对象标记出来，移动到一起，存活对象压缩到一片内存空间里去
剩余的空间都是垃圾对象整个给清理掉，剩余的都是连续的可用的内存空间，解决了内存碎片的一个问题
parnew+cms的组合，g1直接分代回收，新版本，慢慢的就是主推g1垃圾回收器了，以后会淘汰掉parnew+cms的组合，jdk 8~jdk 9比较居多一些，parnew+cms的组合比较多一些，是这么一个情况
分成好几个阶段，初始标记，并发标记，并发清理，等等，老年代垃圾回收是比较慢的，一般起码比年轻代垃圾回收慢个10倍以上，cms的垃圾回收算法，刚开始用标记-清理，标记出来垃圾对象，清理掉一些垃圾对象，整理，把一些存活的对象压缩到一起，避免内存碎片的产生
执行一个比较慢的垃圾回收，还要stop the world，需要100mb，此时就会让系统停顿100ms，不能处理任何请求，尽可能的让垃圾回收和工作线程的运行，并发着来执行