【转载】Java垃圾回收内存清理相关(虚拟机书第三章),GC日志的理解,CPU时间、墙钟时间的介绍

时间:2022-05-25 16:00:09

主要看《深入理解Java虚拟机》

第三张 P84 开始是垃圾收集相关。

1. 1960年诞生于MIT的Lisp是第一门采用垃圾回收的语言。

2. 程序计数器、虚拟机栈、本地方法栈3个区域随线程而生而亡。

3. 垃圾回收主要关注的是堆里面的对象。

1. 检查

1.1 引用计数。基本不用。因为很难解决相互循环引用的问题。当然Python、COM等应用里面用到了。热热

1.2 可达性分析。Reachability Analysis. 通过一系列作为GC roots的对象作为起始。

GC roots的对象包括:

虚拟机栈(栈帧中的本地变量表)中引用的对象。

方法区中类静态属性引用的对象。

方法区中常量引用的对象。

本地方法栈中JNI(Native方法)引用的对象。

1.3 判定都与引用有关。

传统判定:reference类型的数据中存储的数值代表的是另外一块内存,就称这块内存代表着一个引用。

但问题是非1即0.

JDK1.2之后,引用概念进行了扩充,分为:

强引用、软引用、弱引用、虚引用4中。

【转载】Java垃圾回收内存清理相关(虚拟机书第三章),GC日志的理解,CPU时间、墙钟时间的介绍

1.4 两次标记过程:

1. 如果可达性分析发现没有与 GC roots相连,经历第一次筛选,条件是此对象是否有必要执行finalize()。如果没有,或者已经被调用过,则不需要再调用。

2.  如果判定需要调用,放在F-Queue里面,由虚拟机自动建立的,低优先级的Finalizer线程去执行它。

之后GC会对F-Queue中的对象进行第二次标记,如果之前的finalize方法导致对象又与GC roots发生了关联,那么这个对象就不再需要被回收了。

书中的 P90 有示例代码。

但是Java的finalize()方法强烈不建议使用,有很多不确定性。建议忘了它。try{}finally{}能够代替所有场景。

1.5 方法区(虚拟机的永久代)垃圾回收

回收:废弃常量、无用的类。

废弃常量:没有地方引用它。

无用的类:所有实例已经回收;加载该类的ClassLoader已经回收;对应的Class对象没有任何地方被引用,无法在任何地方通过反射访问该类的方法。

在大量使用反射、动态代理、OSGi的场景需要虚拟机具备卸载的能力。

3. 垃圾手机算法

3.1 标记-清除算法:1.效率问题,两个步骤效率都不高;2.空间问题,容易产生大量碎片。

3.2 复制算法:基本都采用这种算法回收新生代。一块较大的Eden空间和两块较小的Survivor空间,大小8:1。

3.3 标记-整理算法:老年代的特点,而使用。让所有存活对象都向一端移动。

3.4 分代收集:根据对象存活周期的不同而把内存分为几块,新生代(复制)、老年代(标记-清除、标记-整理)。

4. HotSpot实现

4.1 枚举根节点

可达性分析:

1. GC roots主要在全局性引用(常量或类静态属性)与执行上下文(栈桢中的本地变量表),时间消耗大。

2. 必须在确保一致性的快照中进行。

OopMap

有一组称为OopMap的数据结构来达到这个目的,在类加载完成的时候,Hotspot就把对象内什么偏移量上是什么类型的数据计算出来,在JIT编译过程中,也会特点位置记录栈和寄存器中哪些位置是引用,这样GC在扫描时就直接得知这些信息。

4.2 安全点

在OopMap协助下,Hotspot可以快速准确地完成GC roots枚举。但是只在特定位置记录这些信息,这些位置成为安全点(Safepoint),只有到达安全点,才会GC。

Safepoint的选择标准:是否具有让程序长时间执行,而这不是根据指令流太长,而是根据方法调用、循环跳转、异常跳转等。

怎么让程序跑到安全点停下来:抢先式中断(Preemptive Suspension)和主动式中断(Voluntary Suspension)。

抢先式中断:主动让所有线程都暂停,如果有线程不在点上,就恢复执行,让所有线程到点。现在几乎没有虚拟机是这样实现。

主动式中断:简单设一个标志,各个线程主动去轮询。标识为真就自己挂起。比如设置一个 test value addr地址,然后设置addr不可读,就会发生一个自陷异常中断,在预先注册的异常处理器中暂停线程。

4.3 安全区域

有的线程在sleep, blocked,那么无法响应,也可能不在安全点。所以要设置安全区域,引用不发生变化的区域。

线程执行到Safe Region中,标识自己已进入,即使sleep,JVM要GC时,不用管标记进入Safe Region的线程,而这个线程如果恢复,要离开Safe Region时,要检查系统是否已经收集完成 GC roots。

5. 垃圾收集器。

有点多,如图:

【转载】Java垃圾回收内存清理相关(虚拟机书第三章),GC日志的理解,CPU时间、墙钟时间的介绍

7种收集器,作用于不同分代。如果两个收集器存在连线,那么表示可以搭配使用。

后面十几页都是各种收集器介绍。略过。

GC日志:

其中,开始数字,表示GC发生时间,然后Full GC表示经过了(Stop the World)。有时候对新生代的回收,也会Stop the World,因为担保失败。

接下来是发生GC的区域,可能有新生代、老年代、永久代,根据GC收集器不同,而命名不同。

关于用户态消耗的CPU时间、内核态消耗的CPU时间、墙钟时间(Wall Clock Time)。说得很不错。

【转载】Java垃圾回收内存清理相关(虚拟机书第三章),GC日志的理解,CPU时间、墙钟时间的介绍

再后面讲对象内存分配:

1. 大方向,就是在堆上分配(可能JIT编译后拆散为标量类型而间接在栈上分配)。

有几条最普遍的内存分配准则:

1. 对象有现在新生代Eden区中分配。当没有足够空间,虚拟机发起一次Minor GC.

Minor GC与Full GC的区别:

【转载】Java垃圾回收内存清理相关(虚拟机书第三章),GC日志的理解,CPU时间、墙钟时间的介绍

2. 大对象直接进入老年代

典型对象就是那种很长的byte[]或者字符串。直接放入老年代的目的是避免新生代在Eden和两个Survivor之间频繁复制。

3. 长期存活的对象进入老年代

虚拟机给每个对象定义一个对象年龄计数器,每次Minor GC,复制到Survivor,年龄+1。当到达默认为15岁,就会晋升到老年代(这个晋升年龄有参数可以调,MaxTenuringThreshold)。

4. 动态判定年龄及晋升

当Survivor中相同年龄对象总和大于Survivor容积的一半,年龄大于等于该年龄的对象直接进入老年代。

注意说的是容积,不是对象个数。

5. 空间分配担保

Survivor不够用,把无法容纳的对象放入老年代。需要担保。并且根据经验值,判断是否Full GC。

还有就是取平均值比较的动态概率手段,如果Minor GC后存活的对象远高于正常,汇报之担保失败,并发起Full GC。

第三章基本看完,后面几章还有实际调试的例子。

一些总结

(http://www.360doc.com/content/12/1219/15/495229_255087879.shtml):

【转载】Java垃圾回收内存清理相关(虚拟机书第三章),GC日志的理解,CPU时间、墙钟时间的介绍

关于引用:

【转载】Java垃圾回收内存清理相关(虚拟机书第三章),GC日志的理解,CPU时间、墙钟时间的介绍

标记-清除算法:

【转载】Java垃圾回收内存清理相关(虚拟机书第三章),GC日志的理解,CPU时间、墙钟时间的介绍

复制算法:

【转载】Java垃圾回收内存清理相关(虚拟机书第三章),GC日志的理解,CPU时间、墙钟时间的介绍

标记-整理算法:

【转载】Java垃圾回收内存清理相关(虚拟机书第三章),GC日志的理解,CPU时间、墙钟时间的介绍

分代:

【转载】Java垃圾回收内存清理相关(虚拟机书第三章),GC日志的理解,CPU时间、墙钟时间的介绍

还有另一篇文章,讲得也挺好 (http://blog.csdn.net/zsuguangh/article/details/6429592):

垃圾收集的算法分析

2.1. 引用计数法(Reference Counting Collector)

运行较快,不会长时间中断程序执行,适宜地必须实时运行的程序。

增加了程序执行的开销。无法处理循环引用。

2.2. tracing算法(Tracing Collector)

使用了根集的概念。基于tracing算法的垃圾收集器从根集开始扫描,识别出哪些对象可达,并用某种方式标记可达对象,例如设置一个或多个位。基于tracing算法的垃圾收集也称为标记和清除(mark-and-sweep)垃圾收集器。

2.3. compacting算法(Compacting Collector)

为了解决堆碎片问题。在清除的过程中,算法将所有的对象移到堆的一端,堆的另一端就变成了一个相邻的空闲内存区。收集器会对它移动的所有对象的所有引用进行更新,在基于Compacting算法的收集器的实现中,一般增加句柄和句柄表。

2.4. copying算法(Coping Collector)

开始时把堆分成一个对象区和多个空闲区,一种典型的基于coping算法的垃圾回收是stop-and-copy算法,在对象区与空闲区域的切换过程中,程序暂停执行。

2.5. generation算法(Generational Collector)

如果收集器必须复制所有的活动对象,这增加了程序等待时间。generation算法将堆分成两个或多个,每个子堆作为对象的一代 (generation)。

在分代式的垃圾收集器运行后,上次运行存活下来的对象移到下一最高代的子堆中,由于老一代的子堆不会经常被回收,因而节省了时间。

2.6. adaptive算法(Adaptive Collector)

在特定的情况下,一些垃圾收集算法会优于其它算法。基于Adaptive算法的垃圾收集器就是监控当前堆的使用情况,并将选择适当算法的垃圾收集器。

System.gc()方法

使用System.gc()可以不管JVM使用的是哪一种垃圾回收的算法,都可以请求Java的垃圾回收。

需要注意的是,调用System.gc()也仅仅是一个请求(建议)。JVM接受这个消息后,并不是立即做垃圾回收,而只是对几个垃圾回收算法做了加权,使垃圾回收操作容易发生,或提早发生,或回收较多而已。

finalize()方法:protected void finalize() throws Throwable

在finalize()方法返回之后,对象消失,垃圾收集开始执行。原型中的throws Throwable表示它可以抛出任何类型的异常。

之所以要使用finalize(),是存在着垃圾回收器不能处理的特殊情况。

假定你的对象(并非使用new方法)获得了一块“特殊”的内存区域,由于垃圾回收器只知道那些显示地经由new分配的内存空间,
所以它不知道该如何释放这块“特殊”的内存区域,那么这个时候java允许在类中定义一个由finalize()方法。 特殊的区域例如:
)由于在分配内存的时候可能采用了类似 C语言的做法,而非JAVA的通常new做法。这种情况主要发生在native method中,
比如native method调用了C/C++方法malloc()函数系列来分配存储空间,但是除非调用free()函数,否则这些内存空间将不会得到释放,
那么这个时候就可能造成内存泄漏。但是由于free()方法是在C/C++中的函数,所以finalize()中可以用本地方法来调用它。以释放这些“特殊”的内存空间。 )又或者打开的文件资源,这些资源不属于垃圾回收器的回收范围。 例如,假设某一个对象在创建过程中会将自己绘制到屏幕上,如果不是明确地从屏幕上将其擦出,它可能永远都不会被清理。
如果在finalize()加入某一种擦除功能,当GC工作时,finalize()得到了调用,图像就会被擦除。

一旦垃圾回收器准备好释放对象占用的存储空间,首先会去调用finalize()方法进行一些必要的清理工作。只有到下一次再进行垃圾回收动作的时候,才会真正释放这个对象所占用的内存空间。

垃圾收集器的存在并不能完全消除对析构函数的需要,或者说不能消除对析构函数代表的那种机制的需要。(另外finalize()函数是在垃圾回收器准备释放对象占用的存储空间的时候被调用的,绝对不能直接调用finalize(),所以应尽量避免用它)

在C++中所有的对象运用delete()一定会被销毁,而JAVA里的对象并非总会被垃圾回收器回收。

记住下面三句话:

1 对象可能不被垃圾回收,2 垃圾回收并不等于“析构”,3 垃圾回收只与内存有关。

问:如果一个对象不再被使用,是不是要在finalize()中释放这个对象中含有的其它对象呢?

不是的。因为无论对象是如何创建的,垃圾回收器都会负责释放那些对象占有的内存。

触发主GC(Garbage Collector)的条件

JVM进行次GC的频率很高,但因为这种GC占用时间极短,所以对系统产生的影响不大。

更值得关注的是主GC的触发条件,因为它对系统影响很明显。

1)当应用程序空闲时,即没有应用线程在运行时,GC会被调用。因为GC在优先级最低的线程中进行,所以当应用忙时,GC线程就不会被调用,但以下条件除外。

2)Java堆内存不足时,GC会被调用。当应用线程在运行,并在运行过程中创建新对象,若这时内存空间不足,JVM就会强制地调用GC线程,以便回收内存用于新的分配。若GC一次之后仍不能满足内存分配的要求,JVM会再进行两次GC作进一步的尝试,若仍无法满足要求,则 JVM将报“out of memory”的错误,Java应用将停止。

由于是否进行主GC由JVM根据系统环境决定,而系统环境在不断的变化当中,所以主GC的运行具有不确定性,无法预计它何时必然出现,但可以确定的是对一个长期运行的应用来说,其主GC是反复进行的。

6. 减少GC开销的措施

根据上述GC的机制,程序的运行会直接影响系统环境的变化,从而影响GC的触发。若不针对GC的特点进行设计和编码,就会出现内存驻留等一系列负面影响。为了避免这些影响,基本的原则就是尽可能地减少垃圾和减少GC过程中的开销。

具体措施包括以下几个方面:

(1)不要显式调用System.gc()

  此函数建议JVM进行主GC,虽然只是建议而非一定,但很多情况下它会触发主GC,从而增加主GC的频率,也即增加了间歇性停顿的次数。

(2)尽量减少临时对象的使用

  临时对象在跳出函数调用后,会成为垃圾,少用临时变量就相当于减少了垃圾的产生,从而延长了出现上述第二个触发条件出现的时间,减少了主GC的机会。

(3)对象不用时最好显式置为Null

  一般而言,为Null的对象都会被作为垃圾处理,所以将不用的对象显式地设为Null,有利于GC收集器判定垃圾,从而提高了GC的效率。

(4)尽量使用StringBuffer,而不用String来累加字符串

  由于String是固定长的字符串对象,累加String对象时,并非在一个String对象中扩增,而是重新创建新的String对象,如Str5=Str1+Str2+Str3+Str4,这条语句执行过程中会产生多个垃圾对象,因为对次作“+”操作时都必须创建新的String对象,但这些过渡对象对系统来说是没有实际意义的,只会增加更多的垃圾。避免这种情况可以改用StringBuffer来累加字符串,因StringBuffer是可变长的,它在原有基础上进行扩增,不会产生中间对象。

(5)能用基本类型如Int,Long,就不用Integer,Long对象

  基本类型变量占用的内存资源比相应对象占用的少得多,如果没有必要,最好使用基本变量。

(6)尽量少用静态对象变量

  静态变量属于全局变量,不会被GC回收,它们会一直占用内存。

(7)分散对象创建或删除的时间

  集中在短时间内大量创建新对象,特别是大对象,会导致突然需要大量内存,JVM在面临这种情况时,只能进行主GC,以回收内存或整合内存碎片,从而增加主GC的频率。集中删除对象,道理也是一样的。它使得突然出现了大量的垃圾对象,空闲空间必然减少,从而大大增加了下一次创建新对象时强制主GC的机会。

7. 关于垃圾回收的几点补充

可以发现垃圾回收有以下的几个特点:

(1)垃圾收集发生的不可预知性:由于实现了不同的垃圾回收算法和采用了不同的收集机制,所以它有可能是定时发生,有可能是当出现系统空闲CPU资源时发生,也有可能是和原始的垃圾收集一样,等到内存消耗出现极限时发生,这与垃圾收集器的选择和具体的设置都有关系。

(2)垃圾收集的精确性:主要包括2 个方面:(a)垃圾收集器能够精确标记活着的对象;(b)垃圾收集器能够精确地定位对象之间的引用关系。前者是完全地回收所有废弃对象的前提,否则就可能造成内存泄漏。而后者则是实现归并和复制等算法的必要条件。所有不可达对象都能够可靠地得到回收,所有对象都能够重新分配,允许对象的复制和对象内存的缩并,这样就有效地防止内存的支离破碎。

(3)现在有许多种不同的垃圾收集器,每种有其算法且其表现各异,既有当垃圾收集开始时就停止应用程序的运行,又有当垃圾收集开始时也允许应用程序的线程运行,还有在同一时间垃圾收集多线程运行。

(4)垃圾收集的实现和具体的JVM 以及JVM的内存模型有非常紧密的关系。不同的JVM 可能采用不同的垃圾收集,而JVM 的内存模型决定着该JVM可以采用哪些类型垃圾收集。现在,HotSpot 系列JVM中的内存系统都采用先进的面向对象的框架设计,这使得该系列JVM都可以采用最先进的垃圾收集。

(5)随着技术的发展,现代垃圾收集技术提供许多可选的垃圾收集器,而且在配置每种收集器的时候又可以设置不同的参数,这就使得根据不同的应用环境获得最优的应用性能成为可能。

针对以上特点,我们在使用的时候要注意:

(1)不要试图去假定垃圾收集发生的时间,这一切都是未知的。比如,方法中的一个临时对象在方法调用完毕后就变成了无用对象,这个时候它的内存就可以被释放。

(2)Java中提供了一些和垃圾收集打交道的类,而且提供了一种强行执行垃圾收集的方法--调用System.gc(),但这同样是个不确定的方法。Java 中并不保证每次调用该方法就一定能够启动垃圾收集,它只不过会向JVM发出这样一个申请,到底是否真正执行垃圾收集,一切都是个未知数。

(3)挑选适合自己的垃圾收集器。一般来说,如果系统没有特殊和苛刻的性能要求,可以采用JVM的缺省选项。否则可以考虑使用有针对性的垃圾收集器,比如增量收集器就比较适合实时性要求较高的系统之中。系统具有较高的配置,有比较多的闲置资源,可以考虑使用并行标记/清除收集器。

(4)关键的也是难把握的问题是内存泄漏。良好的编程习惯和严谨的编程态度永远是最重要的,不要让自己的一个小错误导致内存出现大漏洞。

(5)尽早释放无用对象的引用。大多数程序员在使用临时变量的时候,都是让引用变量在退出活动域(scope)后,自动设置为null,暗示垃圾收集器来收集该对象,还必须注意该引用的对象是否被监听,如果有,则要去掉监听器,然后再赋空值。