JVM内存结构主要包括: 方法区, 堆区, 程序计数器, 本地方法区, 虚拟机栈. 其中的程序计数器, 本地方法区, 虚拟机栈这三个区域是的生命周期随线程生灭, 所以不需要过多考虑这方面的GC问题.
在JDK1.2之后, Java对引用的概念进行了补充, 总体分为四类: 强引用, 软引用, 弱引用, 虚引用. 这四种引用强度逐渐减弱.
为每一个对象的的数据结构添加一个引用计数器, 用于统计指向该对象的引用的数量, 每当多一个引用的时候, 其引用计数器就加一, 当引用不再指向该地址之后计数器减一. 一旦计数器的值为0,则表示没有引用指向该对象, 则对象已经死亡 (寻梦环游记说的: 人真正的死亡是所有活着的人的都忘了你的时候).
目前JVM的主流垃圾回收器采取的可达性分析算法, 这个算法的实质在于将一系列GC Roots作为初始的存活对象的集合(Live Set), 然后从该集合出发, 探索所有能过被集合直接或间接引用的对象, 并且将其加入集合之中, 这个过程就是标记过程. 最终, 未被探索到的对象便是死亡, 是可以回收的.
可达性分析, 可以解决循环引用问题, 但是自身也存在一些问题, 比如说在多线程的情况下, 其他线程可能会更新已经访问过的对象的引用, 造成漏删. 解决方案是 进行两次可达性分析, 如果两次某对象都被标记则进行删除.
由名可得: 标记-清除. 得到需要清除的对象之后就直接进行清除.
缺点: 多次GC之后, 造成大量的碎片空间. 对于需要连续存储的较大对象无法存储,OutofMemoryError
由名可得: 标记-清除-移动整理. 对标记清除算法的一次改进, 但是因为移动操作, 所以时间成本较高.
将可用的内存按容量分为大小两块, 每次只是用其中一块, 当这一块的内存用完了, 就将还存活着的对象复制到另一块内存上, 然后再把已使用的内存空间清理掉.
如果另一块Survivor空间没有足够的内存来存放上一次新生代收集下来的存活对象, 那么这些对象则直接通过担保机制进入老年代.
当前商业虚拟机的垃圾收集器都是采用分代收集算法, 根据对象存活周期的不同将内存划分为几块. 一般把Java堆分为新生代,老年代. JVM根据各个年代的特点采用不同的手机算法.
Java堆是JVM所管理的内存的最大的一块, 也是GC主要的工作区. 其主要分为两个区年轻代和老年代, 其中年轻代又分为Eden和Survivor区, 其中Survivor区又分为FROM和To两个区. 可能这个时候大家又会有疑问, 为什么需要Survivor区, 为什么Survivor还要分为两个区?
Eden区 : IBM表示有98%的对象是朝生夕死, 所以针对这一现状, 大多数情况下, 对象会在新生代Eden区中进行分配, 当Eden区没有足够的空间进行分配的时候, 虚拟机会发起一次GC. 通过这次GC之后,Eden会被清空,Eden区中绝大部分的对象会被回收, 而那些无需回收的存货对象, 将会进到Survivor的FROM区(若FROM不够, 则直接进入Old区).
不是新生代到老年代么, 直接中Eden到Old不好了么,为什么要这么复杂. 如果没有Survivor区,Eden区每一次GC, 存活的对象就会被送到老年代, 老年代很快就会被填满, 而虽然有很多对象虽然一次没有被消灭掉,但是也存活不了太多次, 这个时候将其移入Old区会很快的将其填满.
所以Survivor的存在意义就是减少被送到老年代的对象, 进而减少GC的发生.Survivor的筛选保证, 只有经历16此的GC还能再新生代存活的对象,才会被送到老年代.
Old区占据着2/3的堆内存空间,只有在Marjor GC的时候才会进行清理, 每次GC都会出发stop-the-world. 内存越大,SWT的时间也越长, 所以内存也不仅仅是越大越好, 由于复制算法的对象存活率较高的老年代会进行很多次的复制操作, 效率很低, 所以老年代这里采用的是 标记整理算法.
除了上述所说, 在内存担保机制的情况下, 无法安置的对象也会直接进入老年代, 以下几种情况也会进入老年代.
大对象: 指需要大量连续内存空间的对象, 这部分对象不论是不是朝生夕死, 都会直接进入到老年代, 这样做主要是为了避免在
区之间发生大量的内存复制, 当你的系统有非常多的朝生夕死的大对象的时候, 就值得注意了.
长期存活对象: 虚拟机给每个对象定义了一个对象年龄(Age)计数器. 正常情况下的对象会不断的在
, 年龄就会自增1, 当年龄增加到15岁的时候, 就会被移入老年代. 这里的15是可以进行自定义的.
动态对象年龄: 虚拟机并不重视对象的年龄必须大于15岁, 才会放入老年区, 如果
- 本文固定链接: http://fenleilaji.cc/?id=12331
- 转载请注明: admin 于 分类垃圾-环境保护从分类垃圾做起! 发表
《本文》有 0 条评论