垃圾回收器与内存分配策略
程序计数器、虚拟机栈、本地方法栈的生命周期与相关线程有关,随线程生而生,死而死。这三个区域的内存分配与回收具有确定性,因为当线程结束,内存就跟着线程被回收了。
判断对象已死的三种方法
1.引用计数法:给对象增加一个引用计数器,每当有一个地方引用他时,计数器就加一,当引用失效就减一,任何时刻计数器为0的对象就是不能再被使用,判定对象已死。
python语言采用引用计数法进行内存管理。
但是引用计数法无法解决对象的循环引用问题。
2.可达性分析算法
Java(C#等语言)默认采用可达性分析算法判断对象是否已死。其核心思想是:通过一系列“GC Roots”的对象作为起始点,从这些节点开始向下搜索,搜索走过的路径称之为"引用链",当一个对象到GC Roots没有任何的引用链相连时,证明此对象是不可用的。
在Java中,可作为GC Roots的对象有:1.虚拟机栈中引用的对象2.方法区中类静态属性引用的对象3.方法区中常量引用的对象4.本地方法栈中native方法引用的方法
Java的引用分为四种:
1.强引用:类似于"Object obj = new Object()",只要强引用存在,垃圾回收器就不会收掉被引用的对象实例。
2.软引用:对于软引用关联的对象,在系统将要发生内存溢出之前,会把这些对象列入回收范围之中进行第二次回收,如果这次回收还是没有足够的内存,才会抛出内存溢出异常。
3.弱引用:例如ThreadLocal中的key就是以弱引用的方式保存的。被弱引用的对象只能存活到下一次垃圾回收之前,当GC开始,无论当前内容是否够用,都会回收掉只被弱引用关联的对象。
4.虚引用:无法通过虚引用取得一个对象实例,因此一个对象是否有虚引用的存在不会对其生存时间构成影响。为一个对象设置虚引用的唯一目的就是能在对象回收前收到一个系统通知。
在可达性分析算法下的判定对象至少要经历两次标记过程:如果没有与GC Roots相连接的引用链将会被第一次标记并且进行一次筛选,筛选的条件是此对象是否执行finalize()方法。当对象没有覆写或此方法已经被调用过了,那么此时的对象才是真正的“死”对象。
被判定要执行finalize()方法的对象会被放置在F-Queue的队列中,GC会对队列中的对象进行第二次标记,被标记上的对象被移除“即将回收”的集合。
任何一个对象的finalize()方法只会被调用一次
回收方法区
方法区(永久代)的垃圾回收主要收集两部分内容:废弃常量和无用的类
判定一个类是无用类的条件:
1.该类所有的实例都被回收
2.加载该类的ClassLoader已经被回收
3.该类对应的Class对象没有在任何地方被引用,无法通过反射访问该类的方法
垃圾回收算法
1.标记-清除算法
这是最基础的收集算法,需经历“标记”“清除”两个阶段的两次遍历。
算法缺点:1.效率不高2.产生大量不连续碎片,当需要一大片连续空间时就会出发另一次垃圾收集
2.复制算法(新生代回收算法)
他将可用内存划分为大小相等的两块,当其中一块需要垃圾回收时。会将此区域还或者的对象复制到另一块上,然后把已使用的内存一次性全清理。
此算法弥补了标记-清理算法的缺点,现在商用的虚拟机都采用此新生代回收算法来回收新生代,但是实际上并不是分为相等的两块空间,而是将新生代内存分为较大空间(Eden)和较小的两块空间(Survivor From,Survivor To);Eden:Survivor From:Survivor To空间的大小比例大约为8:1:1.
每次只使用Eden和Survivor中的一块,当回收时,将Eden和Survivor中还存活的对象一次性复制到另一块Survivor中,最后全部清理刚才用过的Eden和Survivor空间。
当Survivor空间不够时,需依赖其他内存(老年代)进行分配担保
HotSpot实现的复制算法流程如下:
1.当Eden区满的时候,会触发第一次Minor gc,把还活着的对象拷贝到Survivor From区;当Eden区再次触 发Minor gc的时候,会扫描Eden区和From区域,对两个区域进行垃圾回收,经过这次回收后还存活的对象, 则直接复制到To区域,并将Eden和From区域清空。
2. 当后续Eden又发生Minor gc的时候,会对Eden和To区域进行垃圾回收,存活的对象复制到From区域,并将 Eden和To区域清空。
3. 部分对象会在From和To区域中复制来复制去,如此交换15次(由JVM参数MaxTenuringThreshold决定,这 个参数默认是15),终如果还是存活,就存入到老年代
3.标记整理算法(老年代回收算法)
复制收集算法在对象存活率较高时经历多次复制效率会很低,因此在老年一代不使用复制算法。
在标记整理算法中清理对象时让所有存活的对象都向一端移动,然后直接清理边界以外的内存。
4.分代收集算法
当前JVM垃圾收集都是采用的分代收集算法。将Java堆分为新生代和老年代,在新生代中,每次垃圾收集都有大批对象死去,只有少量存活,因此采用复制算法。而老年代中对象存活率高,没有额外空间对他进行担保,采用标记-清理算法
==(面)==解Minor GC和Full GC么,这两种GC有什么不一样吗
1 Minor GC又称为新生代GC : 指的是发生在新生代的垃圾收集。因为Java对象大多都具备朝生夕灭的特性,因此Minor GC(采用复制算法)非常频繁,一般回收速度也比较快。
2 Full GC 又称为 老年代GC或者Major GC : 指发生在老年代的垃圾收集。出现了Major GC,经常会伴随 至少一次的Minor GC(并非绝对,在Parallel Scavenge收集器中就有直接进行Full GC的策略选择过程)。 Major GC的速度一般会比Minor GC慢10倍以上。
垃圾收集器
并发:在单CPU中,多条垃圾收集线程并行工作,用户仍处于等待状态。
并行:在多核CPU中,用户线程与垃圾线程同时执行(不一定并行,可能交替执行),用户程序继续运行,而垃圾收集器在另一个CPU上。
吞吐量:吞吐量 = 运行用户代码时间 /(运行用户代码时间 + 垃圾收集时间)
GC停顿时间的缩短是以牺牲吞吐量和新生代 空间作为代价的
七种垃圾收集器
Serial收集器(新生代收集器,串行GC)
特性:是单线程收集器,在进行垃圾收集时必须暂停其他工作线程直到它收集结束。
应用场景:在Client模式下默认的新生代收集器
注:Client模式:可开发桌面程序,但在JDK1.8中已取消
Server模式:服务器运行,不加载桌面程序
优势:简单高效
ParNew收集器(新生代收集器,并行GC)
特性:Serial收集器的多线程版本,除了Serial收集器外,目前只有它能与CMS收 集器配合工作
应用场景:在Server模式下的虚拟机中首选的新生代收集
Parallel Scavenge收集器(新生代收集器,并行GC)
特性: Parallel Scavenge收集器是一个新生代收集器,它也是使用复制算法的收集器,又是并行的多线程收集器,具有GC自适应的调节策略(监控JVM状态,调整新生代与Survivor区域的比例;调整合适的停顿时间和吞吐量)Parallel Scavenge收集器也经 常称为“吞吐量优先”收集器
应用场景:停顿时间越短就越适合需要与用户交互的程序,良好的响应速度能提升用户体验,而高吞吐量则可以高效率地利用 CPU时间,尽快完成程序的运算任务,主要适合在后台运算而不需要太多交互的任务
Parallel Scavenge收集器 VS ParNew收集器: Parallel Scavenge收集器与ParNew收集器的一个重要区别 是它具有自适应调节策略
Serial Old收集器(老年代收集器,串行GC)
特性: Serial Old是Serial收集器的老年代版本,它同样是一个单线程收集器,使用标记-整理算法。
应用场景:
Client模式使用。
Server模式下:一种用途是在JDK 1.5以及之前的版本中与 Parallel Scavenge收集器搭配使用,另一种用途就是作为CMS收集器的后备预案,在并发收集发生 Concurrent Mode Failure时使用
Parallel Old收集器(老年代收集器,并行GC)
特性: Parallel Old是Parallel Scavenge收集器的老年代版本,使用多线程和“标记-整理”算法。
CMS收集器(老年代收集器,并发GC)
特性:基于标记清理算法,是一种以获取最短停顿时间为目标的收集器(响应速度高)
CMS的运作过程:
- 初识标记,速度快,但需要Stop-The-World
- 并发标记,是进行GC Roots Tracing的过程
- 重新标记,修正并发标记期间用户运作程序产生的标记变动。比并发标记时间短,但需要Stop-The-World
- 并发清除:清除对象
缺点:
占用线程,对CPU资源敏感; CMS默认启动的回收线程数是(CPU数量+3)/ 4
CMS收集器无法处理浮动垃圾(与CMS并行运行的用户线程产生的垃圾)
CMS收集器会产生大量空间碎片
CMS作为老年代的收集器,却无法与JDK 1.4.0中已经存在的新生代收集器Parallel Scavenge配合工作
Parallel Scavenge收集器 VS CMS等收集器: Parallel Scavenge收集器的特点是它的关注点与其他收集器不 同,CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间,而Parallel Scavenge收集器的 目标则是达到一个可控制的吞吐量(Throughput)。
G1收集器(唯一一款全区域的垃圾回收器
G1(Garbage First)垃圾回收器是用在heap memory很大的情况下,把heap划分为很多很多的region块,然后 并行的对其进行垃圾回收。
G1垃圾回收器在清除实例所占用的内存空间后,还会做内存压缩
在G1垃圾收集器中,年轻代的垃圾回收过程使用复制算法
对于老年代上的垃圾收集,G1垃圾收集器也分为4个阶段,基本跟CMS垃圾收集器一样,但略有不同。
执行流程:
- 初始标记,需要Stop-The-World,从根对象出发,根minor GC一起发生
- 并发标记:标记的同时G1计算每个块对象的存活率
- 最终标记:采用SATB算法标记可达对象
- 筛选回收:对低存活率的块进行回收,与minor GC一起发生。
七种收集器的配合关系
理解GC日志
一般GC日志:
[GC [DefNew: 3324K->152K(3712K), 0.0025925 secs] 3324K->152K(11904K), 0.0031680 secs]
[Full GC [Tenured: 0K->210K(10240K), 0.0149142 secs] 4603K->210K(19456K), [Perm : 2999K->2999K(21248K)], 0.0150007 secs] [Times: user=0.01 sys=0.00, real=0.02 secs]
内存的分配与回收策略
1.对象优先在Eden区中分配,当Eden区没有足够空间进行分配时,虚拟机发生一次Minor GC.
2.大对象(需要大量连续空间的Java对象)直接进入老年代,但是经常出现大对象容易导致内存不足触发GC。
3.长期存活的对象将进入老年代。在Eden出生的对象每经历一次Minor GC年龄就增加一岁,当增加到15岁时就晋升为老年代;或是在Survivor空间中相同年龄所有对象大小总和大于Survivor空间的一半,年龄大于或等于该年龄的直接进入老年代。
4.空间分配担保
取平均值是一种概率事件,失败后会重新发起Full GC.
常用JVM性能监控工具与故障处理工具
1.JDK\bin目录下的监控和故障处理工具
RMI:remote method invoke 远程方法调用(Java独有)
RPC:remote process invoke 远程进程调用
会利用命令查看jvm状态,jvm可视化软件visualVM软件查看jvm状态,分析程序性能。