深入理解JVM(3)—垃圾回收

Java内存分为五个部分,其中程序计数器、虚拟机栈、本地方法栈三个区域是线程私有的,随线程生而生,随线程灭而灭。方法区和Java堆的分配和回收则是动态的,内存的回收也是针对这部分内存的。

1、如何确定对象已死?
要对对象进行回收,就需要判断对象是否已经“死去”(即接下来程序不再使用它或者很长一段时间不再使用它)。常用的方法是:

(1)引用计数算法
给对象添加一个引用计数器,每当有地方使用它,就将计数器加1,不再使用时,计数器减1,当对象的引用计算器值为0时,表明不再有地方使用它,就表示该对象”已死”。
由于引用计数器很难解决对象间相互引用的情况,如对象A引用对象B,而对象B同时又引用了A,当两对象失效时,两者的引用计数器由于存在相互引用仍互不为0无法被回收,所以Java虚拟机并没有采用引用计数算法来管理内存。
但是引用计数方法简单,效率也高,在大部分情况下有着很好的应用,如Python语言、FlashPlayer等。
(2)可达性分析算法
在主流商业程序语言,如Java、C#的主流实现中,都是通过可达性分析来判断对象是否存活的。算法思想是,从被称作“GC Roots”的对象开始向下搜寻对象,所走过的路径称为引用链,若对象与“GC Roots”间没有引用链存在时说明该对象已死。如下图,对象5,6,7之间存在相互引用,但由于它们没有到GC Roots的引用链存在,故可以判定为可回收对象。
这里写图片描述

在Java语言中,可作为GC Roots的对象包括
Ⅰ、虚拟机栈(栈帧中的局部变量表)中引用的对象
Ⅱ、方法区中类静态属性引用的对象
Ⅲ、方法区常量引用的对象
Ⅳ、本地方法引用的对象

2、生存还是死亡?
通过可达性分析标记的不可达对象,也不一定会被回收。判断对象是否真正死亡,至少需要两次标记过程:首先在可达性分析中没有发现引用链,将会对对象进行第一次标记并判断此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法或者虚拟机已经调用过finalize()方法,那么就可以判断“没有必要执行”。
当对象被判断“没有必要执行”finalize()方法时,就会将对象放置在F-Queue队列中,并在稍后由一个虚拟机创建的Finalizer线程去执行它。第二次标记是GC对F-Queue队列进行标记,此时,对象要想存活,则必须在finalize()方法中实现自救—重新与引用链关联,如把自己(this关键字)赋值给某个类变量或者对象的成员变量,这样在GC进行第二次标记时就会将该对象移除“即将回收”集合,从而避免被回收。例如:

/**
*代码演示了两点:
*1、对象可以在GC时自救;
*2、其自救机会只有一次,因为一个对象的finalize()方法最多被系统调用一次
*/
public class FinalizeEscape {  

    public static FinalizeEscape FC = null;  

    @Override  
    protected void finalize() throws Throwable {  
        super.finalize();  
        System.out.println("finalize method invoke");  
        //通过赋值进行自救,只能利用finalize()自救
        FC = this;  
    }  

    public static void main(String[] args) throws Exception {  
        FC = new FinalizeEscape();  
        //第一次自救成功  
        FC = null;  
        System.gc();  
        Thread.sleep(500);  
        if(FC != null)  
            System.out.println("i am alive");  
        else   
            System.out.println("i am dead");  
        //由于finalize()已经被调用一次,故这次自救失败了  
        FC = null;  
        System.gc();  
        Thread.sleep(500);  
        if(FC != null)  
            System.out.println("i am alive");  
        else   
            System.out.println("i am dead");  
    }  
}  

3、方法区的回收
方法区中的垃圾回收主要是废弃字面量及无用类。判断字面量是否废弃与判断堆中对象十分相似。例如,若常量池中存在字符串“abc”,而系统中并没有任何String对象的值为“abc”的,也就是没有任何对象引用它,那么它就可以被回收了。无用类的判定稍微复杂点,需要满足
(1)该类的所有对象实例已经被回收;
(2)加载该类的ClassLoader已经被回收;
(3)该类的类对象Class没有在任何地方被引用,无法使用反射来访问该类的方法。
当方法区中的类满足以上条件时,就可以对无用类进行回收了。

4、垃圾收集算法
(1)标记-清除算法
标记-清除(Mark-Sweep)算法是最基础的垃圾回收算法,算法分为标记和清除两阶段。首先对需要回收的对象进行标记(即判断对象死亡的两次标记),当标记完成后对这些对象统一回收。该算法简单容易实现,是回收算法的基础,但是该算法由于标记和清除过程的效率都不高,还易产生空间碎片。算法示意如下:
这里写图片描述

(2)复制算法
为了提高回收效率,复制算法将内存划分为大小相等的两块,每次只使用其中一块,当此块内存用完了,就将此内存中仍存活的对象复制的另一块内存中,然后将该内存整个回收。该算法实现简单,运行高效,但是对内存使用存在很大的浪费。算法示意如下:
这里写图片描述
现在的商业虚拟机都采用复制算法来回收新生代。IBM公司的专门研究表明,新生代中的对象有98%都是“朝生夕死”的,所以不需要按上面说的平分内存,而是按约8:1:1的比例划分为Eden区和两块Survivor区,每次使用Eden区和其中一块Survivor区,即使用了90%的内存空间,当内存不足需要回收时,将这两块区域中仍存活的对象复制到另一块Survivor区中,然后回收这两块内存。当然,可能会出现回收时仍存活的对象超过Survivor区的大小,这时候就需要通过内存的分配担保机制将对象复制到老年代中保存。

(3)标记-整理算法
Java堆中老年代的对象存活率比较高,使用复制算法会出现很多的复制操作或分配担保问题,所以针对老年代的特点,提出了“标记-整理(Mark-Compact)”算法。分为标记和整理过程,标记过程跟“标记-清除”算法的标记过程一致,整理过程则是将存放对象移动到同一端,然后直接清除掉端边界外的内存。算法示意如下:
这里写图片描述

5、Java虚拟机HotSpot处理GC的上下文
(1)枚举GC Roots
前面讲到回收内存的对象存活判定的可达性分析算法,需要从被称为“GC Roots”的对象出发搜寻引用链,但是在很多实际运用中,仅方法区就有数百M,对里面的所有引用进行遍历显然不合理。而且该算法要求分析工作在确保一致性的快照中进行——“一致性”指的是算法在分析期间,系统看起来被冻结在某个时间点上,也即保证分析期间不再出现对象引用关系的变化。因此需要在发生GC时必须停顿所有的Java执行线程。
在GC时,如何快速查询作为”GC Roots”的引用,从而确定对象的存活状态,在HotSpot中是通过一组称为OopMap的数据结构实现的。OopMap可以这样理解,在源代码里面每个变量都是有类型的,但是编译之后的代码就只有变量在栈上的位置了,oopMap就是一个附加的信息,告诉你栈上哪个位置本来是个什么类型。在Java编译时,会在安全点(下面会讲到)记录下栈和寄存器中哪些位置是引用,这样,GC在扫描时就可以直接确定“GC Roots”引用。
(2)安全点
在OopMap的协助下,可以快速地枚举GC Roots,但是由于引起OopMap内容变化的指令非常多,如果为每一条指令都生成对应的OopMap,则需要大量额外空间,导致GC成本变高。
为了解决这个问题,Java虚拟机定义了安全点(Safepoint),只有字节码执行到安全点位置,才能暂停启动GC,生成OopMap。安全点的选定要求既不能过少导致GC等待时间太长,也不能太多增加运行时的负荷,安全点主要设置在以下几个位置
1、循环的末尾;
2、方法临返回前 / 调用方法的call指令后;
3、可能抛异常的位置 。
如何保证当发生GC时,线程都处于安全点,主要是通过主动式中断来实现的:在安全点设置一个轮询标志,各个线程执行时主动去轮询这个标志,发现中断标志为真的时就自己中断挂起。
(3)、安全区域
安全点可以很好地解决线程执行时进入GC的问题,但对处于睡眠和阻塞状态的线程却无能为力,为了解决这个问题,java虚拟机设置了安全区域(Safe Region),安全区域是指在一段代码片中,引用关系不会变化,在这个区域任何地方都可以发生GC,可以看作为扩展了的安全点。只有当执行的线程进入安全点,非执行态的线程处于安全区域时,才会触发GC。
当线程执行到安全区域后, 首先会标示自己进入了安全区域, 那样, 当在这段时间内发生GC时, 就不用管这样的线程了,当线程要离开该区域时, 要检查系统是否已经完成了根节点枚举(或整个GC过程),如果已完成,则线程继续执行, 否则, 它就必须等待直到收到可以安全离开安全区域的信号。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
森林防火应急联动指挥系统是一个集成了北斗定位/GPS、GIS、RS遥感、无线网络通讯、4G网络等技术的现代化智能系统,旨在提高森林火灾的预防和扑救效率。该系统通过实时监控、地图服务、历史数据管理、调度语音等功能,实现了现场指挥调度、语音呼叫通讯、远程监控、现场直播、救火人员生命检测等工作的网络化、智能化、可视化。它能够在火灾发生后迅速组网,确保现场与指挥中心的通信畅通,同时,系统支持快速部署,适应各种极端环境,保障信息的实时传输和历史数据的安全存储。 系统的设计遵循先进性、实用性、标准性、开放性、安全性、可靠性和扩展性原则,确保了技术的领先地位和未来的发展空间。系统架构包括应急终端、无线专网、应用联动应用和服务组件,以及安全审计模块,以确保用户合法性和数据安全性。部署方案灵活,能够根据现场需求快速搭建应急指挥平台,支持高并发视频直播和大容量数据存储。 智能终端设备具备三防等级,能够在恶劣环境下稳定工作,支持北斗+GPS双模定位,提供精确的位置信息。设备搭载的操作系统和处理器能够处理复杂的任务,如高清视频拍摄和数据传输。此外,设备还配备了多种传感器和接口,以适应不同的使用场景。 自适应无线网络是系统的关键组成部分,它基于认知无线电技术,能够根据环境变化动态调整通讯参数,优化通讯效果。网络支持点对点和点对多点的组网模式,具有低功耗、长距离覆盖、强抗干扰能力等特点,易于部署和维护。 系统的售后服务保障包括安装实施服务、系统维护服务、系统完善服务、培训服务等,确保用户能够高效使用系统。提供7*24小时的实时故障响应,以及定期的系统优化和维护,确保系统的稳定运行。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值