没有合适的资源?快使用搜索试试~ 我知道了~
1.JVM内存分配与回收1.1 对象优先在Eden区分配大多数情况下,对象在新生代中 Eden 区分配 2.如何判断对象可以被回收堆中几乎放着所有的对象实例,对
资源详情
资源评论
资源推荐
1.JVM 内存分配与回收
1.1 对象优先在 Eden 区分配
大多数情况下,对象在新生代中 Eden 区分配。当 Eden 区没有足够空间进行分配时,虚拟
机将发起一次 Minor GC。我们来进行实际测试一下。
在测试之前我们先来看看 Minor Gc 和 Full GC 有什么不同呢?
新生代 GC(Minor GC):指发生新生代的的垃圾收集动作,Minor GC 非常频繁,回
收速度一般也比较快。
老年代 GC(Major GC/Full GC):指发生在老年代的 GC,出现了 Major GC 经常会伴
随至少一次的 Minor GC(并非绝对),Major GC 的速度一般会比 Minor GC 的慢 10 倍以
上。
测试:
通过以下方式运行:
添加的参数: -XX:+PrintGCDetails
运行结果:
从上图我们可以看出 eden 区内存几乎已经被分配完全(即使程序什么也不做,新生代也
会使用至少 2000 多 k 内存)。假如我们再为 allocation2 分配内存会出现什么情况呢?
简单解释一下为什么会出现这种情况: 因为给 allocation2 分配内存的时候 eden 区内存几
乎已经被分配完了,我们刚刚讲了当 Eden 区没有足够空间进行分配时,虚拟机将发起一
次 Minor GC.GC 期间虚拟机又发现 allocation1 无法存入 Survior 空间,所以只好通过 分配
担保机制 把新生代的对象提前转移到老年代中去,老年代上的空间足够存放 allocation1,
所以不会出现 Full GC。执行 Minor GC 后,后面分配的对象如果能够存在 eden 区的话,
还是会在 eden 区分配内存。可以执行如下代码验证:
1.2 大对象直接进入老年代
大对象就是需要大量连续内存空间的对象(比如:字符串、数组)。
为什么要这样呢?
为了避免为大对象分配内存时由于分配担保机制带来的复制而降低效率。
1.3 长期存活的对象将进入老年代
既然虚拟机采用了分代收集的思想来管理内存,那么内存回收时就必须能识别那些对象应
放在新生代,那些对象应放在老年代中。为了做到这一点,虚拟机给每个对象一个对象年
龄(Age)计数器。
如果对象在 Eden 出生并经过第一次 Minor GC 后仍然能够存活,并且能被 Survivor 容纳的
话,将被移动到 Survivor 空间中,并将对象年龄设为 1.对象在 Survivor 中每熬过一次
MinorGC,年龄就增加 1 岁,当它的年龄增加到一定程度(默认为 15 岁),就会被晋升到
老年代中。对象晋升到老年代的年龄阈值,可以通过参数 -XX:MaxTenuringThreshold 来设
置。
2.如何判断对象可以被回收
堆中几乎放着所有的对象实例,对堆垃圾回收前的第一步就是要判断那些对象已经死亡(
即不能再被任何途径使用的对象)。
2.1 引用计数法
给对象中添加一个引用计数器,每当有一个地方引用它,计数器就加 1;当引用失效,计
数器就减 1;任何时候计数器为 0 的对象就是不可能再被使用的。
这个方法实现简单,效率高,但是目前主流的虚拟机中并没有选择这个算法来管理内存
,其最主要的原因是它很难解决对象之间相互循环引用的问题。 所谓对象之间的相互引
用问题,如下面代码所示:除了对象 objA 和 objB 相互引用着对方之外,这两个对象之间
再无任何引用。但是他们因为互相引用对方,导致它们的引用计数器都不为 0,于是引用
计数算法无法通知 GC 回收器回收他们。
2.2 可达性分析算法
这个算法的基本思想就是通过一系列的称为 “GC Roots” 的对象作为起点,从这些节点开
始向下搜索,节点所走过的路径称为引用链,当一个对象到 GC Roots 没有任何引用链相
连的话,则证明此对象是不可用的。
GC Roots 根节点:类加载器、Thread、虚拟机栈的本地变量表、static 成员、常量引用、
本地方法栈的变量等等
剩余23页未读,继续阅读
华亿
- 粉丝: 38
- 资源: 308
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0