JVM学习(4)——全面总结Java的GC算法和回收机制

简介:

  引用实例被添加在引用队列中,可以在任何时候通过查询引用队列回收对象。

  

  现在我对一个对象的生命周期进行描述:

  新建Java对象A首先处于可达的,未执行finalize方法的状态, 随着程序的运行,一些引用关系会消失,或者变迁,当对A使用可达性算法判断,对象A变成了 GC Roots 不可达时,A从可达状态变迁到不可达状态,但是JVM不会就就这样把它清理了,而是在第一次GC的时候,对它首先进行一个标记(标记清除算法),之后最少还要再进行一次筛选,而对其筛选的的条件就是看该对象是否覆盖了Object的finalize方法,或者看这个对象是否执行过一次finalize方法。如果没有执行,也没有覆盖,就满足筛选条件,JVM将其放入F-Queue队列,由JVM的一个低优先级的线程执行该队列中对象的finalize方法。此时执行finalize方法优先级是很低的,且不会保证等待finalize方法执行完毕才进行第二次回收(怕发生无限等待的情景,JVM崩溃),之后不久GC对队列里的对象进行二轮回收,去判断该对象是否可达,若不可达,才进行回收,否则,对象“复活”( 执行finalize的过程中,应用程序是可以让对象再次被引用,复活的)。而在可达性判断的时候,还要兼顾四种引用类型,根据不同的引用类型特点去判断是否是回收的对象。看例子:
 
 
复制代码
package wys.demo1;

public class Demo1 {
    public static Demo1 obj;
    
    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        
        System.out.println("CanReliveObj finalize called");
        
        obj = this;// 把obj复活了!!!
    }
    
    @Override
    public String toString(){
        return "I am CanReliveObj";
    }
    
    public static void main(String[] args) throws InterruptedException{
        obj = new Demo1();// 强引用
        obj = null;   //不会被立即回收,是可复活的对象
        
        System.gc();// 主动建议JVM做一次GC,GC之前会调用finalize方法,而我在里面把obj复活了!!!
        Thread.sleep(1000);

        if(obj == null){
            System.out.println("obj 是 null");
        }else{
            System.out.println("obj 可用");
        }
        
        System.out.println("第二次gc");
        obj = null;    //不可复活
        System.gc();
        Thread.sleep(1000);
        
        if(obj == null){
            System.out.println("obj 是 null");
        }else{
            System.out.println("obj 可用");
        }
    }
}
复制代码

  结果:

CanReliveObj finalize called
obj 可用
第二次gc
obj 是 null

  说明JVM不管程序员手动调用finalize,JVM它就是执行一次finalize方法。执行finalize方法完毕后,GC会再次进行二轮回收,去判断该对象是否可达,若不可达,才进行回收。

  

  建议:避免使用finalize方法!

  太复杂了,还是让系统照管比较好。可以定义其它的方法来释放非内存资源。建议使用try-catch-finally来替代它执行清理操作。

  如果手动调用了finalize,很容易出错。且它执行的优先级低,何时被调用,不确定——也就是何时发生GC不确定,因为只有当内存告急时,GC才工作,即使GC工作,finalize方法也不一定得到执行,这是由于程序中的其他线程的优先级远远高于执行finalize()的线程优先级。 因此当finalize还没有被执行时,系统的其他资源,比如文件句柄、数据库连接池等已经消耗殆尽,造成系统崩溃。且垃圾回收和finalize方法的执行本身就是对系统资源的消耗,有可能造成程序的暂时停止,因此在程序中尽量避免使用finalize方法。

  上面提到了GC或者执行finalize可能造成程序暂停,这引出一个概念: Stop-The-World现象。
  这是Java中一种全局暂停的现象,全局停顿,所有Java代码停止,类似JVM挂起的状态……但是native代码可以执行,但不能和JVM交互。这多半由于GC引起,其他的引起原因比如:
  • Dump线程
  • JVM的死锁检查
  • 堆的Dump。
  这三者出现概率很低,多半是程序员手动引起的,而GC是JVM自动引起的。
  
   GC时为什么会有全局停顿?
  类比在聚会时打扫房间,聚会时很乱,又有新的垃圾产生,房间永远打扫不干净,只有让大家停止活动了,才能将房间在某一个状态下打扫干净。回程序中就是只有程序暂停了,才能全面,完整,正确的清理一次垃圾对象,否则前脚清理了,后脚还有新的,永远清理不完,对判断垃圾对象也是一个判断上干扰的问题,也永远干净不了。
 
   Stop-The-World现象危害
  长时间服务停止,没有响应,一般新生代的GC停顿时间很短,零点几秒。而老年代比较时间长,几秒甚至几十分钟……一般堆内存越大,GC时间越长,也就是 Stop-The-World越久。所以,JVM的内存不是越大越好,要根据实际情况设置。
  遇到HA系统,可能引起主备切换,严重危害生产环境。比如一个系统,一个主机服务器,一个备机服务器,不会同时启动,我们会只使用一个,比如主机暂时因为GC没有响应,如果时间太长,我们会使用备机,一旦主机恢复了,主机也启动了,此时备机主机都启动了,很可能导致服务器数据不一致……
  
  前面罗嗦了一堆,那么这些算法是如何在JVM中配合使用的呢?那么就引出新的问题需要解决: JVM的垃圾回收器。
  回忆下堆的结构:还是以Java 7为例子:
  Java堆整体分两代,新生代和老年代,顾名思义,前者存放新生对象,大部分都是朝生夕死!进行GC的次数不多,后者存放的是时间比较久的对象,也就是多次GC还没死的对象。对象创建的时候,大部分都是放入新生代的eden区,除非是很大的对象,可能会直接存放到老年代,还有之前说的栈上分配(逃逸分析)。
  如果eden对象在GC时幸存,就会进入幸存区,也就是s0,s1,或者叫from和to,或者叫survivor(两个),大小一样。完全对称,功能也一样。前面说了GC有复制算法,那么就是使用在这里,GC在新生代时,eden区的存活对象被复制到未使用的幸存区,假设是to,而正在使用的是from区的年轻的对象也会一起被复制到了to区,如果to区满了,这些对象也和大对象,老年对象一样直接进入了老年代保存(担保空间)。此时,eden区剩余的对象和from区剩余的对象就是垃圾对象,能直接GC,to区存放的是新生代的此次GC活下来的对象。避免了产生内存碎片。

  先不说了,先看看JVM的垃圾回收器吧,先看一种最古老的收集器——串行收集器

  最古老,最稳定,效率高,但是串行的最大问题就是停顿时间很长!因为串行收集器只使用一个线程去回收,可能会产生较长的停顿现象。我们可以使用参数-XX:+UseSerialGC,设置新生代、老年代使用串行回收,此时新生代使用复制算法,老年代使用标记-压缩算法(标记-压缩算法首先需要从根节点开始,对所有可达对象做一次标记。但之后,它并不简单的清理未标记的对象,而是将所有的存活对象压缩到内存的一端。之后,清理边界外所有的空间。有效解决内存碎片问题)。

  因为串行收集器只使用一个线程去回收,可能会产生较长的停顿现象。

 

  还有一种收集器叫并行收集器(两种并行收集器)

  • 一种是ParNew并行收集器。使用JVM参数设置XX:+UseParNewGC,设置之后,那么新生代就是并行回收,而老年代依然是串行回收,也就是并行回收器不会影响老年代,它是Serial收集器在新生代的并行版本,新生代并行依然使用复制算法,但是是多线程,需要多核支持,我们可以使用JVM参数: XX:ParallelGCThreads 去限制线程的数量。如图:

  注意:新生代的多线程回收不一定快!看在多核还是单核,和具体环境。、

  • 还有一种是Parallel收集器,它类似ParNew,但是更加关注JVM的吞吐量!同样是在新生代复制算法,老年代使用标记压缩算法,可以使用JVM参数XX:+UseParallelGC设置使用Parallel并行收集器+ 老年代串行,或者使用XX:+UseParallelOldGC,使用Parallel并行收集器+ 并行老年代。也就是说,Parallel收集器可以同时让新生代和老年代都并行收集。如图:

  关于并行收集器还有两个参数设置:
  -XX:MaxGCPauseMills,代表最大的GC线程占用的停顿时间,单位是毫秒,GC尽力保证回收时间不超过设定值,不是100%的保证。
  -XX:GCTimeRatio,GC使用的cpu时间占总时间的百分比,理解为吞吐量,0-100的取值范围,垃圾收集时间占总时间的比,默认99,即最大允许1%时间做GC。我们肯定希望停顿时间短,且占用总时间比例少,但是这两个参数是矛盾的。因为停顿时间和吞吐量不可能同时调优。
  如果GC很频繁,那么GC的最大停顿时间变短,但吞吐量变小,如果GC次数很少,最大的停顿时间就会变长,但吞吐量增大。

  

  最后看一个很重要的收集器-CMS(并发标记清除收集器Concurrent Mark Sweep)收集器

  顾名思义,它在老年代使用的是标记清除算法,而不是标记压缩算法,也就是说CMS是老年代收集器(新生代使用ParNew),所谓并发标记清除就是CMS与用户线程一起执行。标记-清除算法与标记-压缩相比,并发阶段会降低吞吐量,使用参数-XX:+UseConcMarkSweepGC打开。

   CMS运行过程比较复杂,着重实现标记的过程,可分为:

  • 初始标记,标记GC ROOT 根可以直接关联到的对象(会产生全局停顿),但是初始标记速度快。
  • 并发标记(和用户线程一起),主要的标记过程,标记了系统的全部的对象(不论垃圾不垃圾)。
  • 重新标记,由于并发标记时,用户线程依然运行(可能产生新的对象),因此在正式清理前,再做一次修正,会产生全局停顿
  • 并发清除(和用户线程一起),基于标记结果,直接清理对象。这也是为什么使用标记清除算法的原因,因为清理对象的时候用户线程还能执行!标记压缩算法的压缩过程涉及到内存块移动,这样会有冲突。
  • 并发重置,为下一次GC做准备工作。

 

   CMS的特点
  尽可能降低了JVM的停顿时间,但是会影响系统整体吞吐量和性能,比如:
  1. 在用户线程运行过程中,分一半CPU去做GC,系统性能在GC阶段,反应速度就下降一半。
  2. 清理不彻底。因为在清理阶段,用户线程还在运行,会产生新的垃圾,无法清理。
  3. 因为和用户线程基本上是一起运行的,故不能在空间快满时再清理。

可以使用-XX:CMSInitiatingOccupancyFraction设置触发CMS GC的阈值,设置空间内存占用到多少时,去触发GC,如果不幸内存预留空间不够,就会引起concurrent mode failure。

可以使用-XX:+ UseCMSCompactAtFullCollection, Full GC后,进行一次整理,而整理过程是独占的,会引起停顿时间变长。

可以使用-XX:+CMSFullGCsBeforeCompaction,设置进行几次Full GC后,进行一次碎片整理。
还可以使用-XX:ParallelCMSThreads,设定CMS的线程数量,一般设置为cpu数量,不用太大。
 
   为减轻GC压力,我们需要注意些什么?

   从三个方面考虑:

  • 软件如何设计架构
  • 代码如何写
  • 堆空间如何分配

 

辛苦的劳动,转载请注明出处,谢谢……http://www.cnblogs.com/kubixuesheng/p/5208647.html
相关文章
|
11月前
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
11月前
|
存储 监控 算法
基于 C++ 哈希表算法实现局域网监控电脑屏幕的数据加速机制研究
企业网络安全与办公管理需求日益复杂的学术语境下,局域网监控电脑屏幕作为保障信息安全、规范员工操作的重要手段,已然成为网络安全领域的关键研究对象。其作用类似网络空间中的 “电子眼”,实时捕获每台电脑屏幕上的操作动态。然而,面对海量监控数据,实现高效数据存储与快速检索,已成为提升监控系统性能的核心挑战。本文聚焦于 C++ 语言中的哈希表算法,深入探究其如何成为局域网监控电脑屏幕数据处理的 “加速引擎”,并通过详尽的代码示例,展现其强大功能与应用价值。
217 2
|
11月前
|
人工智能 算法 NoSQL
LRU算法的Java实现
LRU(Least Recently Used)算法用于淘汰最近最少使用的数据,常应用于内存管理策略中。在Redis中,通过`maxmemory-policy`配置实现不同淘汰策略,如`allkeys-lru`和`volatile-lru`等,采用采样方式近似LRU以优化性能。Java中可通过`LinkedHashMap`轻松实现LRUCache,利用其`accessOrder`特性和`removeEldestEntry`方法完成缓存淘汰逻辑,代码简洁高效。
508 0
|
6月前
|
存储 人工智能 算法
从零掌握贪心算法Java版:LeetCode 10题实战解析(上)
在算法世界里,有一种思想如同生活中的"见好就收"——每次做出当前看来最优的选择,寄希望于通过局部最优达成全局最优。这种思想就是贪心算法,它以其简洁高效的特点,成为解决最优问题的利器。今天我们就来系统学习贪心算法的核心思想,并通过10道LeetCode经典题目实战演练,带你掌握这种"步步为营"的解题思维。
|
存储 算法 安全
探究‘公司禁用 U 盘’背后的哈希表算法与 Java 实现
在数字化办公时代,信息安全至关重要。许多公司采取“禁用U盘”策略,利用哈希表算法高效管理外接设备的接入权限。哈希表通过哈希函数将设备标识映射到数组索引,快速判断U盘是否授权。例如,公司预先将允许的U盘标识存入哈希表,新设备接入时迅速验证,未授权则禁止传输并报警。这有效防止恶意软件和数据泄露,保障企业信息安全。 代码示例展示了如何用Java实现简单的哈希表,模拟公司U盘管控场景。哈希表不仅用于设备管理,还在文件索引、用户权限等多方面助力信息安全防线的构建,为企业数字化进程保驾护航。
|
存储 人工智能 算法
数据结构与算法细节篇之最短路径问题:Dijkstra和Floyd算法详细描述,java语言实现。
这篇文章详细介绍了Dijkstra和Floyd算法,这两种算法分别用于解决单源和多源最短路径问题,并且提供了Java语言的实现代码。
1205 3
数据结构与算法细节篇之最短路径问题:Dijkstra和Floyd算法详细描述,java语言实现。
|
监控 算法 Java
JVM—垃圾收集算法和HotSpot算法实现细节
JVM的垃圾收集算法和HotSpot的实现细节复杂但至关重要,通过理解和掌握这些算法,可以为Java应用程序选择合适的垃圾收集器,并进行有效的性能调优。选择适当的垃圾收集策略,结合合理的内存配置和日志分析,能够显著提升应用的运行效率和稳定性。
276 15
|
存储 监控 算法
基于 PHP 二叉搜索树算法的内网行为管理机制探究
在当今数字化网络环境中,内网行为管理对于企业网络安全及高效运营具有至关重要的意义。它涵盖对企业内部网络中各类行为的监测、分析与管控。在内网行为管理技术体系里,算法与数据结构扮演着核心角色。本文将深入探究 PHP 语言中的二叉搜索树算法于内网行为管理中的应用。
173 4
|
12月前
|
存储 算法 物联网
解析局域网内控制电脑机制:基于 Go 语言链表算法的隐秘通信技术探究
数字化办公与物联网蓬勃发展的时代背景下,局域网内计算机控制已成为提升工作效率、达成设备协同管理的重要途径。无论是企业远程办公时的设备统一调度,还是智能家居系统中多设备间的联动控制,高效的数据传输与管理机制均构成实现局域网内计算机控制功能的核心要素。本文将深入探究 Go 语言中的链表数据结构,剖析其在局域网内计算机控制过程中,如何达成数据的有序存储与高效传输,并通过完整的 Go 语言代码示例展示其应用流程。
231 0
|
存储 监控 算法
公司监控上网软件架构:基于 C++ 链表算法的数据关联机制探讨
在数字化办公时代,公司监控上网软件成为企业管理网络资源和保障信息安全的关键工具。本文深入剖析C++中的链表数据结构及其在该软件中的应用。链表通过节点存储网络访问记录,具备高效插入、删除操作及节省内存的优势,助力企业实时追踪员工上网行为,提升运营效率并降低安全风险。示例代码展示了如何用C++实现链表记录上网行为,并模拟发送至服务器。链表为公司监控上网软件提供了灵活高效的数据管理方式,但实际开发还需考虑安全性、隐私保护等多方面因素。
263 0
公司监控上网软件架构:基于 C++ 链表算法的数据关联机制探讨