学号--实验3JVM实战-对象自我拯救与GC日志深入分析.docVIP

实验报告封面 课程名称： Java虚拟机编程 课程代码： SS2033 任课老师： 潘正军 实验指导老师: 潘正军 实验报告名称： 实验3 JVM实战-对象自我拯救与GC日志深入分析 学生姓名： 学号： 教学班： 递交日期： 签收人： 我申明，本报告内的实验已按要求完成，报告完全是由我个人完成，并没有抄袭行为。我已经保留了这份实验报告的副本。 申明人(签名): 实验报告评语与评分： 评阅老师签名：实验题目 实验3 JVM实战-对象自我拯救与GC日志深入分析 实验地点及组别 U206/U208 1人/组 实验时间 实验目的 理解引用计数算法的缺陷和对象何时生死 掌握对象自我拯救的原理并通过案例进行实证 掌握垃圾收集算法和GC日志的深入分析方法 二、实验环境（本实验的硬件和软件环境及使用仪器等） 硬件：PC电脑一台； 配置：winxp或win7系统，内存大于2G 硬盘250G及以上 JDK1.7 、Eclipse或者MyEclipse 三、实验实现过程 ?1.判断对象是否已死的引用计数引用算法案例实战 应用场景说明： 很多教科书判断对象是否存活的算法是这样的：给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。在面试过很多的应届生和一些有多年工作经验的开发人员，他们对于这个问题给予的都是这个答案。 客观地说，引用计数算法（Reference Counting）的实现简单，判定效率也很高，在大部分情况下它都是一个不错的算法，也有一些比较著名的应用案例，例如微软公司的COM（Component Object Model）技术、使用ActionScript 3的FlashPlayer、Python语言和在游戏脚本领域被广泛应用的Squirrel中都使用了引用计数算法进行内存管理。但是，至少主流的Java虚拟机里面没有选用引用计数算法来管理内存，其中最主要的原因是它很难解决对象之间相互循环引用的问题。 举个简单的例子，下列代码中的testGC（）方法：对象objA和objB都有字段instance，赋值令objA.instance=objB及objB.instance=objA，除此之外，这两个对象再无任何引用，实际上这两个对象已经不可能再被访问，但是它们因为互相引用着对方，导致它们的引用计数都不为0，于是引用计数算法无法通知GC收集器回收它们。 验证代码 运行结果 结果分析 从运行结果中可以清楚看到，GC日志中包含“4571K-＞375K”，意味着虚拟机并没有因为这两个对象互相引用就不回收它们，这也从侧面说明虚拟机并不是通过引用计数算法来判断对象是否存活的。 2.JVM一次对象自我拯救案例实证 应用场景说明 即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize（）方法。当对象没有覆盖finalize（）方法，或者finalize（）方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执 行”。 如果这个对象被判定为有必要执行finalize（）方法，那么这个对象将会放置在一个叫做F-Queue的队列之中，并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行它。这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束，这样做的原因是，如果一个对象在finalize（）方法中执行缓慢，或者发生了死循环（更极端的情况），将很可能会导致F-Queue队列中其他对象永久处于等待，甚至导致整个内存回收系统崩溃。final