自助网站建设用什么好,进出口采购网,全球搜索大全,百度如何验证网站垃圾标记阶段
对象存活判断:
在堆里存放着几乎所有的 Java 对象实例#xff0c;在GC 执行垃圾回收之前#xff0c;首先需要区分出内存中哪些是存活对象#xff0c;哪些是已经死亡的对象。只有被标记为已经死亡的对象#xff0c;GC 才会在执行垃圾回收时#xff0c;释放掉…垃圾标记阶段
对象存活判断:
在堆里存放着几乎所有的 Java 对象实例在GC 执行垃圾回收之前首先需要区分出内存中哪些是存活对象哪些是已经死亡的对象。只有被标记为已经死亡的对象GC 才会在执行垃圾回收时释放掉其所占用的内存空间因此这个过程我们可以成为垃圾标记阶段当一个对象已经不再被任何的存活的对象继续引用时就可以宣判为已经死亡判断对象存活一般有两种方式: 引用计数算法 和 可达性分析算法
标记阶段: 引用计数算法
对每个对象保存一个整形的引用计数器属性。用于记录对象被引用的情况对于一个对象 A只要有任何一个对象引用了 A则 A的引用计数器就加1当引用失效时引用计数器就减1。只要对象A的引用计数器的值为0即表示对象A不可能再被使用可进行回收
优点: 实现简单垃圾对象便于辨别判定效率高回收没有延迟性
缺点:
它需要单独的字段存储计数器这样的作法增加了存储空间的开销每次赋值都需要更新计数器伴随着加法和减法操作这增加了时间开销引用计数器有一个严重的问题即无法处理循环引用的情况。这时一条致命缺陷导致在 Java 的垃圾回收器重没有使用这类算法
示例代码:
/*** -XX:PrintGCDetails* Java 如果使用的是引用计数算法 bigSize 则不会被回收*/
public class RefCountGC {// 这个成员属性唯一的作用就是占用一定内存private byte[] bigSize new byte[5 * 1024 * 1024]; //5MBObject reference null;public static void main(String[] args) {RefCountGC obj1 new RefCountGC();RefCountGC obj2 new RefCountGC();obj1.reference obj2;obj2.reference obj1;obj1 null;obj2 null;// 显示的执行垃圾回收行为// 这里发生GC obj1 和 obj2 能否被回收System.gc();}
}Python 如何解决循环引用:
手动解除: 很好理解就是在合适时机解除引用关系 使用弱引用 weakref, weakref 是 python 提供的标准库旨在解决循环引用
标记阶段:可达性分析算法
不仅同样具备实现简单执行高效的特点更重要的该算法可以有效地解决在引用计数算法中循环引用的问题防止内存泄漏的发生可达性分析就是 Java、C# 选择的。这种类型的垃圾收集通常也叫作追踪性垃圾收集(Tracing Garbage Collection)
基本思路:
可达性分析算法是以跟对象集合(GC Roots) 为起始点按照从上至下的方式搜索被根对象集合所连接的目标对象是否可达使用可达性分析算法后内存中的存活对象都会被跟对象集合直接或间接连接着搜索所走过的路径称为引用链(Reference Chain)如果目标对象没有任何引用链相连则是不可达的就意味着对象已经死亡可以标记为垃圾对象在可达性分析算法中只有能够被根对象集合直接或间接连接的对象才是存活对象
GC Roots包括以下几类元素:
虚拟机栈中引用的对象: 各个线程被调用的方法中使用到的参数、局部变量等本地方法栈内 JNI(通常说的本地方法) 引用的对象方法区中类静态属性引用的对象: Java 类的引用类型静态变量方法区中常量引用的对象: 字符串常量池(String Table) 里的引用所有被同步锁 synchronized 持有的对象Java 虚拟机内部的引用: 基本数据类型对相应的 Class 对象一些常驻的异常对象(如: NullPointerExecption、OutOfMemoryError)系统类加载器反应 Java 虚拟机内部情况的 JMXBean、JVMT中注册的回调、本地代码缓存等除了固定 GC Roots 集合以外根据用户所选用的垃圾收集器以及当前回收的内存区域不同还可以有其他对象临时性地加入共同构成完整GC Roots 集合。比如: 分代收集和局部回收(Partial GC)
GC Root 技巧:
由于 Root 采用栈方式存放变量和指针所以如果一个指针它保存了堆内存里的对象但是自己又不存放在堆内部里面那它就是一个Root
注意:
如果要使用可达性分析算法来判断内存是否可回收那么分析工作必须在一个能保证一致性的快照中进行。这点不满足的话分析结果的准确性就无法保证这点也是导致 GC 进行时必须Stop The World的一个重要原因。即时是号称(几乎) 不会发生停顿的CMS 收集器中枚举根节点时也是必须要停顿的
对象的 finalization 机制
Java 语言提供了对象终止(finalization) 机制来允许开发人员提供对象被销毁之前的自定义处理逻辑当垃圾回收器发现没有引用指向一个对象即:垃圾回收此对象之前总会先调用这个对象的 finalize() 方法finalize() 方法允许在子类中被重写用户在对象被回收时进行资源释放。通常在这个方法中进行一些资源释放和清理的工作比如关闭文件、套接字和数据库连接等永远不要主动调用某个对象的finalize() 方法应该交给垃圾回收机制调用。因为 finalize() 可能会导致对象复活finalize() 方法的执行时间是没有保障的它完全由GC 线程决定极端情况下若不发生GC则finalize() 方法将没有执行的机会另外一个糟糕的finalize() 会严重影响GC的性能从功能上来说finalize() 方法与C 中的析构函数比较相似但是 Java 采用的是基于垃圾回收器的自动内存管理机制所以 finalize() 方法在本质上不同于 C 中的析构函数由于 finalize() 方法的存在虚拟机中的对象一般处于三种可能的状态仅有对象不可触及才可以回收。可触及的: 从根节点开始可以到达这个对象。可复活的: 对象的所有引用都被释放但是对象有可能在 finalize() 中复活。不可触及的: 对象的 finalize() 被调用并且没有复活那么就会进入不可触及的状态。不可触及的对象不可能被复活因为 finalize() 只会被调用一次
具体过程:
判断 一个对象 objA是否可回收至少要经历两次标记过程
如果对象 objA到 GC Roots 没有引用链则进行第一次标记如果对象 objA 没有重写 finalize() 方法或者 finalize() 方法已经被虚拟机调用过则虚拟机视为没有必要执行, objA 被判定为不可触及的如果对象 objA 重写了 finalize() 方法且还未执行过那么objA 会被插入到 F-Queue 队列中由一个虚拟机自动创建的、低优先级的 Finalizer 线程触发其 finalize() 方法执行finalize() 方法是对象逃脱死亡的最后机会稍后 GC 会对 F-Queue 队列中的对象进行第二次标记。如果 objA 在 finalize() 方法中与引用链上任何一个对象建立联系那么在第二次标记时objA 会被移除 即将回收 集合。之后对象会再次出现没有引用存在的情况。在这个情况下finalize 方法不会被再次调用对象会直接变成不可触及的状态
public class CanReliveObj {public static CanReliveObj obj;// 调用一次Overrideprotected void finalize() throws Throwable {super.finalize();System.out.println(调用当前重写的 finalize() 方法);obj this; // 当前待回收的对象在 finalize() 方法中与引用链上的对象建立 obj 链接}public static void main(String[] args) {try{obj new CanReliveObj();obj null;System.gc();System.out.println(第一次 gc);Thread.sleep(2000);if (obj null) {System.out.println(obj is dead);}else {System.out.println(obj is still alive);}obj null;System.gc();System.out.println(第二次 gc);Thread.sleep(2000);if (obj null) {System.out.println(obj is dead);}else {System.out.println(obj is still alive);}}catch (InterruptedException e){e.printStackTrace();}}
}MAT 与 JProfiler 的GC Roots 溯源 示例代码:
import java.util.ArrayList;
import java.util.Date;
import java.util.List;
import java.util.Scanner;public class GCRootsTest {public static void main(String[] args) {ListObject numList new ArrayList();Date birth new Date();for (int i 0; i 100; i) {numList.add(String.valueOf(i));try {Thread.sleep(10);} catch (InterruptedException e) {e.printStackTrace();}}System.out.println(数据添加完毕请操作);new Scanner(System.in).next();numList null;birth null;System.out.println(numList、birth 已置空请操作);new Scanner(System.in).next();System.out.println(结束);}
}MAT:
下载地址 http://www.eclipse.org/mat/MAT 是 Memory Analyzer 的简称, 它是一款功能强大的 Java 堆内存分析器用于查找内存泄漏以及查看内存消耗情况MAT 是基于 Eclipse 开发的是一款免费的性能分析工具
使用 VM 进行导出堆dump 并保存到本地: 使用 MAT 打开 Dump 文件 查看 GC Roots: JProfiler
下载地址: ej-technologies - Java APM, Java Profiler, Java Installer Builder
Idea 安装 JProfiler 插件进行查看: 分析OOM:
/*** -Xms8m -Xmx8m -XX:HeapDumpOnOutOfMemoryError*/
public class HeapOOM {byte[] buffer new byte[1 * 1024 *1024];public static void main(String[] args) {ArrayListHeapOOM list new ArrayList();int count 0;try{while(true){list.add(new HeapOOM());count;}}catch (Throwable e) {System.out.println(count count);e.printStackTrace();}}
}将导出的异常 dump 在 jprofiler 进行查看: 垃圾清除阶段
当成功区分出内存中存活对象和死亡对象后GC接下来的任务就是执行垃圾回收释放掉无用对象所占的内存空间以便有足够的可用内存空间为新对象分配内存。目前在 JVM 中比较常见的三种垃圾收集算法是标记-清除算法(Mark-Sweep)、复制算法(Copying)、标记-压缩算法(Mark-Compact)
何为清除:
这里所谓的清除并不是真的置空而是把需要清除的对象地址保存在空闲的地址列表里。下次有新对象需要加载时判断垃圾的位置空间是否足够如果够则存放
清除阶段: 标记-清除算法(Mark-Sweep)
执行过程:
当堆中的有效内存空间(available memory) 被耗尽的时候就会停止整个程序(也被称为 stop the world),然后进行两项工作第一项则是标记第二项则是清除
标记: Collector 从引用根节点开始遍历标记所有被引用的对象。一般是在对象的 Header 中记录为可达对象清除: Collector 对堆内存从头到尾进行线性遍历如果发现某个对象在其 Header 中没有标记为可达对象则将其回收 缺点:
效率不算高在进行 GC 的时候需要停止整个应用程序导致用户体验差这种方式清理出来的空闲内存是不连续的产生内部碎片需要维护一个空闲列表
清除阶段: 复制算法(Copying)
将活着的内存空间分为两块每次只使用其中一块在垃圾回收时将正在使用的内存中存活对象赋值到未被使用的内存块中之后清除正在使用的内存块的所有对象交换两个内存角色最后完成垃圾回收 优点:
没有标记和清除过程实现简单运行高效复制过去以后保证空间的连续性不会出现 碎片 问题
缺点:
需要两倍的内存空间对于 G1 这种分拆成为大量 region 的GC复制而不是移动意味着 GC 需要维护 region 之间对象引用关系不管是内存占用或者时间开销也不小
注意:
如果系统中的垃圾对象很多算法效果并不是很理想。复制算法需要复制的存活对象数量并不会太大或者说非常低才行
应用场景:
在新生代对常规应用的垃圾回收一次通常可以回收 70%-99%的内存空间。回收性价比很高。所以现在的商业虚拟机都是用这种收集算法回收新生代
清除阶段: 标记-压缩算法(Mark-Compact)
第一阶段和标记-清除算法一样从根节点开始标记所有被引用。第二阶段将所有存活对象压缩到内存的一端按顺序排放。之后清理边界所有的空间。标记-压缩算法的最终效果等同于标记-清除算法执行完成后再进行一次内存碎片整理因此也可以把它称为 标记-清除-压缩(Mark-Sweep-Compact) 算法 优点:
消除了标记-清除算法当中内存区域分散的缺点我们需要给新对象分配内存时JVM 只需要持有一个内存的起始地址即可消除了复制算法当中内存减半的高额代价
缺点:
从效率上来说标记-整理算法要低于复制算法移动对象的同时如果对象被其他对象引用则还需要调整引用的地址移动过程中需要全程暂停用户应用程序。即:STW
小结
Mark-SweepMark-CompactCopying速度中等最慢最快空间开销少(但会堆积碎片)少(不堆积碎片)通常需要活的对象的2倍大小(不堆积碎片)移动对象否是是
效率上来说复制算法是当之无愧的老大但是却浪费了太多的内存而为了尽量兼顾上面提到的三个指标标记-整理算法相对来说更平滑一些但是效率上不尽如人意它比复制算法多了一个标记的阶段比标记-清除多了一个整理内存的阶段
分代收集算法
并没有一个算法可以完全替代其他算法它们都具有自己独特的优势和特点分代收集算法是基于这样一个事实: 不同的对象的生命周期是不一样的。因此不同生命周期的对象可以采取不同的收集方法以便提高回收效率。一般把Java 堆分为新生代和老年代这样就可以根据各个年代的特点使用不同的回收算法以提高垃圾回收的效率目前几乎所有的 GC 都采用分代收集(Generational Collecting) 算法执行垃圾回收的年轻代(Young Gen): 区域相对老年代较小对象生命周期短、存活率低回收频繁。这种情况复制算法的回收整理速度是最快的。复制算法的效率只和当前存活对象大小有关因此很适用于年轻代的回收。而复制算法内存利用率不高的问题通过 hotspot 中的两个 survivor 的设计得到缓解老年代(Tenured Gen): 区域较大对象生命周期长、存活率高回收不及年轻代频繁。这种情况下存在大量存活率高的对象复制算法明显变得不合适。一般是由标记-清除或者标记-清除与标记-整理的混合实现。Mark 阶段的开销与存活对象的数量成正比。Sweep阶段的开销与所管理区域的大小成正相关。Compact阶段的开销与存活对象的数据成正比以 HotSpot 中的CMS回收器为例CMS 是基于 Mark-Sweep 实现的对于对象的回收效率很高。而对于碎片问题CMS采用基于 Mark-Compact 算法的 Serial Old 回收器作为补偿措施: 当内存回收不佳(碎片导致的Concurrent Model Failure 时)将采用 Serial Old 执行 Full GC 以达到堆老年代内存的整理
增量收集算法
上述现有的算法在垃圾回收过程中应用软件将处于一种Stop the World 的状态。在 Stop the World 状态下应用程序所有的线程都会挂起暂停一切正常的工作等待垃圾回收的完成。如果垃圾回收时间过长应用程序会被挂起很久将严重影响用户体验或系统的稳定性
基本思想:
如果一次性将所有的垃圾进行处理需要造成系统长时间的停顿那么就可以让垃圾收集线程和应用程序线程交替执行。每次垃圾收集线程只收集一小片区域的内存空间接着切换到应用程序线程。依次反复直到垃圾收集完成。总体来说增量收集算法的基础仍然是传统的标记-清除和复制算法。增量收集算法通过堆线程间冲突的妥善处理允许垃圾收集线程以分阶段的方式完成标记、清理或复制工作
缺点:
使用这种方式由于在垃圾回收过程中间断性地还执行了应用程序代码所以能减少系统的停顿时间。但是因为线程切换和上下文转换的消耗会使得垃圾回收的总体成本上升造成系统吞吐量下降
分区算法
一般来说在相同条件下堆空间越大一次GC时所需要的时间就越长有关GC产生的停顿也增长。为了更好地控制GC产生的停顿时间将一块大的内存区域分割成多个小块根据目标的停顿时间每次合理地回收若干个小区间而不是整个堆空间从而减少一次GC所产生的停顿分代算法将按照对象的生命周期长短分成两个部分分区算法将整个堆空间划分为连续的不同小区间 region。每个小区间都独立使用独立回收。这种算法好处是可以控制一次回收多少个小区间
