首先我们带着问题来学习
Q1：哪些内存需要回收？
Q2：什么时候回收？
Q3：如何回收？
上一章我们说到JAVA内存运行时的各个部分，其实程序计数器、虚拟机栈、本地方法栈3个区域随线程而生随线程而灭。本章主要讨论的内存分配与回收指的就是这一部分的内存。
JAVA虚拟机的GC是自动回收内存，为什么我们还要去了解GC和内存分配？答案很简单：因为我们在日常的开发中都会遇到各种内存溢出泄漏等问题，说白了就是Exception报：OutOfMemoryError等错误你需要去排查吧，当系统达到更高并发量的瓶颈时，了解JVM中的GC有助于你更准更快的去定位到底哪里出了问题。从而去更好的解决它！以后只要实施必要的监控和调节就可以了。
正文：
1、对象已死吗？如何确定对象是否还“活着”
堆里面存放着JAVA中几乎所有的实例对象，GC在对堆进行回收前，首要做的就是判断这些对象中哪些还活着，哪些已经死了。
引用计数器方法
一般我们判断对象是否还活着的算法是给对象添加一个应用法计数器，每当一个地方引用它时，计数器值+1，当引用失效时，计数器-1，为0时就是不可能再被使用的，
举个例子：
//对象A和对象B都有字段nama
objA.name=objB
objB.name=objA
除此之外这两个对象再无引用，但是互相引用，那么他们的计数器就不为0，所以计数器算法无法通知GC回收他们。
- 给对象添加一个引用计数器，每当有一个地方引用它时，计数器就加1，当引用失效时，计数器就减1。
- 优点是判定简单，效率也很高。缺点是无法解决相互循环引用的问题
可达性分析方法
- 通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为“引用链”，当一个对象到GC Roots没有任何引用链相连时，说明这个对象是可回收的。
- Java语言中，可作为GC Roots的对象包括以下几种：虚拟机栈中引用的对象，方法区中类静态属性引用的对象，方法区中常量引用的对象，本地方法栈中JNI引用的对象。
再谈引用
- JDK1.2 之后把引用分为了四种：强引用、软引用、弱引用、虚引用
- 强引用：只要强引用还存在，就不会被垃圾回收器回收。类似 Object o=new Object()
- 软引用：指一些有用但并非必须的对象，在系统将要发生内存溢出的时候，会将这部分对象回收。SoftReference 类来实现软引用
- 弱引用：被弱引用关联的对象只能生存到下一次垃圾回收。WeakReference 类来实现弱引用
- 虚引用：一个对象是否有虚引用的存在，完全不会对其生存时间造车影响，也无法通过虚引用取得对象的引用。一个对象设置虚引用的唯一目的是在被垃圾回收的时候收到一个系统通知
对象被回收的过程
- 当对象进行可达性分析没有与GC Roots相连的引用链，将会被第一次标记，并根据是否需要执行finalize()方法进行一次筛选，对象没有重写finalize()或者虚拟机已经调用过finalize(),都被视为不需要执行
- 如果对象有必要执行finalize，会被放入到F-Queue队列中，并在稍后由虚拟机自动创建的低优先级的Finalizer线程去触发它，并不保证等待此方法执行结束。
- 如果对象在finalize()方法执行中，重新和GC Roots产生了引用链，则可以逃脱此次被回收的命运，但finalize()方法只能运行一次，所以并不能通过此方法逃脱下一次被回收
- 笔者不建议使用这个方法，建议大家完全忘掉这个方法的存在。
回收方法区
- 主要包括废弃常量和无用类的回收。判断类无用：类的实例都被回收，类的ClassLoader被回收，类的Java.Lang.Class对象没有在任何地方引用。满足这三个条件，类才可以被回收（卸载）
- HotSpot虚拟机通过 -Xnoclassgc 参数进行控制是否启用类卸载功能。在大量使用反射、动态代理、CGLib等框架，需要虚拟机具备类卸载功能，避免方法区发生内存溢出
2、垃圾回收算法
标记-清除算法
- 先标记出所有要回收的对象，在标记完成后统一进行对象的回收。有两个不足：
1 是效率问题，标记和清除的效率都不高。
2 是空间问题，会产生大量不连续的内存碎片，碎片太多会都导致大对象无法找到足够的内存，从提前触发垃圾回收。
复制算法
- 新生代分为一个Eden，两个Survival空间，默认比例是8:1。回收时，将Eden和一个Survival的存活对象全部放入到另一个Survival空间中，最后清理掉刚刚的Eden和Survival空间
- 当Survival空间不够时，由老年代进行内存分配担保
标记-整理算法
- 根据老年代对象的特点，先标记存活对象，将存活对象移动到一端，然后直接清理掉端边界以外的对象
分代收集算法
- 新生代采用复制算法，老年代采用标记-删除，或者标记-整理算法。
3、HotSpot算法实现
枚举根节点实现
- 可达性分析时会进行GC停顿，停顿所有的Java线程。
- HotSpot进行的是准确式GC，当系统停顿下来后，虚拟机有办法得知哪些地方存在着对象引用，HotSpot中使用一组称为OopMap的数据结构来达到这个目的
安全点
- HotSpot没有为每个指令都生成OopMap，只在特定的位置记录这些信息，这些位置称为安全点。安全点的选定不能太少，也不能太频繁，安全点的选定以“是否让程序长时间执行”为标准
- 采用主动式中断的方式让所有线程都跑到最近的安全点上停顿下来。设置一个标志，各个程序执行的时候轮询这个标志，发现中断标志为真时自己就中断挂起
安全区域
- 解决没有分配Cpu时间的暂时不执行的程序停顿。
4、垃圾收集器
如果两个收集器之间有连线，说明可以搭配使用。没有最好的收集器，也没有万能的收集器，只有对应具体应用最合适的收集器。
Serial 收集器
- 新生代收集器，单线程回收。优点在于，简单而高效，对于运行在Client模式下的虚拟机来说是一个很好的选择（比如用户的桌面应用）
- 参数 -XX:UseSerialGC，打开此开关后，使用Serial+Serial Old的收集器组合进行内存回收
ParNew收集器
- 新生代收集器，Serial的多线程版本，除了Serial收集器之外，只有它能与CMS收集器配合工作。
- -XX:+UseConcMarkSweepGC 选项后默认的新生代收集器，也可以使用 -XX:+UseParNewGC 选项来强制指定它
- ParNew收集器在单CPU的环境中，效果不如Serial好，随着CPU的增加，对于GC时系统资源的利用还是很有效的。
- 默认开启的收集线程数和CPU数相等，可以使用 -XX:ParallelGCThreads 指定
Parallel Scavenge收集器
- 新生代收集器，并行收集器，复制算法，和其他收集器不同，关注点的是吞吐量（垃圾回收时间占总时间的比例）。提供了两个参数用于控制吞吐量。
- -XX:MaxGCPauseMillis，最大垃圾收集停顿时间，减少GC的停顿时间是以牺牲吞吐量和新生代空间来换取的，不是设置的越小越好
- -XX:GCTimeRatio，设置吞吐量大小，值是大于0小于100的范围，相当于吞吐量的倒数，比如设置成99，吞吐量就为1/（1+99）=1%。
- -XX:UseAdaptiveSizePolicy ，这是一个开关参数，打开之后，就不需要设置新生代大小（-Xmn）、Eden和Survival的比例（-XX:SurvivalRatio）、 晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节参数，收集器会自动调节这些参数。
Serial Old 收集器
- 单线程收集器，老年代，主要意义是在Client模式下的虚拟机使用。在Server端，用于在JDK1.5以及之前版本和Parallel Scavenge配合使用，或者作为CMS的后备预案。
Palallel Old 收集器
- 是Parallel Scavenge的老年代版本。在注重吞吐量的场合，都可以优先考虑Parallel Scavenge 和Palallel Old 配合使用
CMS 收集器
- Concurrent Mark Sweep，是一种以获取最短回收停顿时间为目标的收集器，尤其重视服务的响应速度。基于标记-清除算法实现。
- 分为四个步骤进行垃圾回收：初始标记，并发标记，重新标记，并发清除。只有初始标记和重新标记需要停顿。
- 初始标记只是标记一下GC Roots能直接关联到的对象，速度很快。并发标记就是进行GC Roots的Tracing。
- 重新标记为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间会比初始标记阶段稍长，远比并发时间短。
- 耗时最长的并发标记和并发清除过程中，处理器可以与用户线程一起工作。
- 它并不是完美的，有如下三个比较明显的缺点：
1、垃圾回收时会占用一部分线程，导致系统变慢，总吞吐量会降低。
2、无法处理浮动垃圾，需要预留足够的内存空间给用户线程使用，可以通过 -XX:CMSInitiatingOccupancyFraction 参数控制触发垃圾回收的阈值。
如果预留的内存无法满足程序需要，就会出现“Concurrent Mode Failure”失败，这时将启动应急预案，启用Serial Old 进行垃圾回收，停顿时间会变长
所以-XX:CMSInitiatingOccupancyFraction 参数的值设置的太高，会导致频繁“Concurrent Mode Failure”失败，性能反而降低。
3、标记-清理，容易产生内存碎片。-XX:+UseCMSCompactAtFullColletion 开启碎片整理功能，默认开启，-XX:CMSFullGCsBeforeCompaction，控制多少次不压缩的FullGC之后来一次带压缩的
G1 收集器
- 包括新生代和老年代的垃圾回收。和其他收集器相比的优点：并行和并发，分代收集，标记-整理，可预测的停顿。垃圾回收分为以下几个步骤：
- 初始标记：标记GC Roots能够直接关联到的对象，这阶段需要停顿线程，时间很短
- 并发标记：进行可达性分析，这阶段耗时较长，可与用户程序并发执行
- 最终标记：修正发生变化的记录，需要停顿线程，但是可并行执行
- 筛选回收：对各个Region的回收价值和成本进行排序，根据用户所期望的停顿时间来执行回收计划
5、内存分配和回收策略
- 对象优先在Eden分配，当新生区没有足够的内存是，通过分配担保机制提前转移到老年代中去
- 大对象直接进入老年代。大对象是指需要大量连续内存空间的对象，虚拟机提供了参数 -XX:PretenureSizeThreshold（只对Serial，PerNew两个回收器起效），令大于这个值得对象直接在老年代分配，避免了Eden和两个Survival之间发生大量的内存复制。
- 长期存活的对象将进入老年代。虚拟机给每个对象定义了对象年龄计数器（Age），如果对象在Eden出生，经过第一次Minor GC后依然存活，并且能被Survival容纳的话，将被移动到Survival，对象年龄设为1。对象在Survival中每熬过一次Major GC，年龄就增加1，达到一定程度（默认是15），就会被晋升到老年代。对象晋升老年代的阈值，可以通过参数-XX:MaxTenuringThreShold 指定
- 动态对象年龄判断。如果在Survival空间中相同年龄所有对象的大小综合超过了Survival空间的一半，年龄大于等于这个年龄的对象都会被晋升到老年代。无需等待年龄超过MaxTenuringThreShold指定的年龄
- 空间分配担保。只要老年代的连续空间大于新生代对象总和或者历次晋升的平均大小，就进行Major GC，否则进行Full GC。
扫一扫
243
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
