标签：大小 关于 碎片 内存 资源 关注 计数 垃圾回收 内存碎片
程序计数器、虚拟机栈、本地方法栈3个区域随线程而生，随线程而灭；栈中的栈帧随着方法的进入和退出而有条不紊地执行者出栈和入栈。每个栈帧中分配多少内存基本上是在类结构确定下来时就已知的（尽管在运行期会由JIT编译器进行一些优化），因此这几个区域的内存分配和回收都具备确定性，在这几个区域内就不需要过多考虑回收问题，因为方法结束或者线程结束时，内存自然就跟随着回收了。而Java堆和方法区则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序运行期间时才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，垃圾收集器所关注的是这部分内存
给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。
这个算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用连，当一个对象到GC Roots没有任何引用链相连时（用图论的话来说，就是从GC Roots到这个对象不可达）时，则证明此对象是不可用。
如同它的名字一样，算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象，它的不足有两个：一个是效率问题，标记和清除两个过程的效率都不高；另一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后再程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作 。
复制算法将可用内存按容量划分为大小相等的两块，每次只使用其中的一块，当这一块的内存用完了，就将还存活着的对象复制到另一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效，代价是将内存缩小为了原来的一半，代价太高 。
IBM公司专门研究表明：新生代中的对象98%是“朝生夕死”的，所以并不需要按照1：1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。当回收时，将Eden和Survivor中还存活着的对象一次性地复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8：1，也就是每次新生代中可用内存空间为整个新生代容量的90%（80%+10%），我们没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保
3、标记-整理算法
复制收集算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法
根据老年代的特点，有人提出一种“标记-整理”算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都想一段移动，然后直接清理掉端边界以外的内存 。
当前商业虚拟机的垃圾收集都采用“分代收集”算法，这种算法并没有什么新的思想，知识根据对象存活周期的不同将内存划分为几块，一般是吧java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都会发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成手机，而老年代中因为对象存活率高，没有额外空间对它进行分配担保，就必须使用“标记-清理”或者“标记-整理”算法来进行回收。
这个收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，知道它收集结束 。
Serial收集器对于运行在Client模式下的虚拟机来说是一个很好的选择。
ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数（例如：-XX：SurvivorRatio、-XX：PretenureSieThreshold等）、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样，
ParNew是许多运行在Server模式下的虚拟机中首选的新生代收集器，其中一个与性能无关但是很重要的原因是，除了Serial收集器外，目前只有它能与CMS收集器配合工作，CMS作为老年代的收集器，新生代只能选择ParNew或者Serial收集器中的一个，ParNew收集器也是使用-XX：+UseConcMarkSweepGC选项后的默认新生代收集器，也可以使用-XX:+UserParNewGC选项来强制指定它
ParNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果，甚至优于存在线程交互的开销，该收集器在通过超线程技术实现的两个CPU的环境中都不能百分之百地可以超越S俄日按来收集器。当然，随着可以使用的CPU的数量增加，它对于GC时系统资源的有效利用还是有好处的，它默认开启的线程数与CPU的数量相同，在CPU非常多的环境下，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数 。
此收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器，看上去和ParNew都一样。CMS等收集器关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量，所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）
停顿时间越短就越适合需要与用户交互的程序、良好的相应速度能提升用户体验，而高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务
Parallel Scavenge收集器提供了两个传输用于精准控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX：MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX：GCTimeRatio参数，GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的，系统把新生代调小点，收集300MB新生代肯定比收集500MB块吧，这也导致垃圾收集发生得更频繁一些，原来10秒收集一次、每次停顿100毫秒，现在变成5秒收集一次、每次停顿70毫秒。停顿时间的确在下降，但吞吐量也降下来了。所以此收集器也经常称为“吞吐量优先”收集器。除上述两个参数之外，还要一个参数-XX：+UseAdaptiveSizePolicy，这是一个开关参数，当这个参数打开之后，就不需要手动指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX：SurvivorRatio）、晋升老年代对象年龄（-XX：PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况手机性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种调节方式称为GC自适应的调节策略。
Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记-整理”算法，这个收集器的主要意义也是在于给Client模式下的虚拟机使用。如果在Server模式下，那么它主要还有两大用途：一种用途是在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用，另一种用途就是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。
Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法，在Jdk1.5以及之前的版本，新生代选择了Parallel Scavenge收集器，老年代除了Serial Old收集器外别无选择，由于老年代Serial Old收集器在服务端应用性能上的“拖累”，使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果。
直到Parallel Old收集器出现后，“吞吐量优先”收集器终于有了比较名副其实的应用组合，在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器 。
CMS收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的相应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。此收集器是基于“标记-清除”算法实现的，整个过程分为4个步骤，包括：
初始标记、并发标记、重新标记、并发清除
其中，初始标记、重新标记这两个步骤仍然需要“Stop The World”，初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的挺短时间一般为比初始标记阶段稍长一些，但远比并发标记的时间短
由于整个过程中耗时最长的并发标记和并发清除过程手机器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的
优点：
并发收集、低停顿
缺点：
1、在并发阶段，它虽然不会导致用户线程停顿，但是会因为占用了一部分线程（或者说CPU资源）而导致应用程序变慢，总吞吐量会降低
2、CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生
3、由于CMS是一款基于“标记-清除”算法实现的收集器，这种收集结束后会产生大量空间碎片产生。空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出项老年代还有很大空间剩余，不得不提前出发一次Full GC，为了解决这个问题，CMS收集器提供了一个-XX：+UseCMSCompactAtFullCollection开关参数，用于在CMS收集器顶部至要进行FullGC时开启内存碎片的合并整理过程，内存整理的过程是无法并发的，空间碎片问题没有了，但停顿时间不得不变长，还有一个参数-XX：CMSFullGCsBeforeCompaction，这个参数用于设置执行多少次不压缩的Full GC后，跟着来一次带压缩的（默认值为0，表示每次进入Full GC时都进行碎片整理）
G1收集器是当今收集器技术发展的最前沿成果之一，是一款面向服务端应用的垃圾收集器
G1收集器特点是：
1、并行与并发
2、分代收集
3、空间整合 从整体来看是基于“标记-整理”算法实现，从局部上来看是基于“复制”算法实现的
4、可预测的停顿，G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关注点，除了追求低停顿外，还能建立可预测的停顿时间模型
使用G1收集器，java堆的内存布局就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域，虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合
过程：
初始标记、并发标记、最终标记、筛选回收
新生代、老年代、永久代
对象的内存分配，往大方向讲，就是在堆上分配（但也可能经过JIT编译后被拆散为标量类型并间接地栈上分配），对象主要分配在新生代的Eden区上，如果启动了本地线程分配缓冲，将按线程优先在TALB上分配，少数情况下也可能会直接分配在老年代中，分配的规则并不是百分之百固定的，取决于当前使用的哪一种垃圾收集器组合，还有虚拟机中与内存相关的参数的设置，本节测试时使用Client模式，验证的是在使用Serial/Serial Old收集器下
虚拟机给每个对象定义了一个对象年龄（Age）计数器，年龄增加到一定程度将会被晋升到老年代。
为了更好地适应不同程序的内存状况，虚拟机并不是永远地要求对象的年龄必须达到才能晋升老年代，如果Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代
在发生Minor GC之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么Minor GC可以确保是安全的。如果不成立，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次Minor GC，尽管这次Minor GC是有风险的；如果小于，或者HandlePromotionFailure设置不允许毛线，那这时也要改为进行一次Full GC。
Minor GC:指发生在新生代的垃圾收集动作，因为java对象大多具备朝生夕灭的特性，所以MinorGC非常频繁，一般回收速度也比较快
Full GC/Major GC：指发生在老年代的GC，出现了 Major GC，经常会伴随至少一次的 Minor GC（但非绝对的，在 ParallelScavenge 收集器的收集策略里就有直接进行 Major GC 的策略选择过程） 。
MajorGC 的速度一般会比 Minor GC 慢 10倍以上。
内存回收与垃圾收集器在很多时候都是影响系统性能、并发能力的主要因素之一，虚拟机之所以提供多种不同的收集器以及提供大量的调节参数，是因为只有根据实际应用需求、实现方式选择最优的收集方式才能获取最高的性能。没有固定收集器、参数组合，也没有最优的调优方式，虚拟机也就没有什么必然的内存回收行为
本片文章是参考《深入理解JVM》而写的，博主推荐大家可以详细地看一下这本书，里面讲了好多关于JVM深入的知识，可以让我们这些java开发人员更加地熟悉自己编写的程序。以后编写出更加完善的代码！！！
标签：大小 关于 碎片 内存 资源 关注 计数 垃圾回收 内存碎片
原文地址：https://www.cnblogs.com/sxkgeek/p/8960904.html
