内存动态分配和垃圾自动回收机制(一)

内存动态分配和垃圾自动回收机制(一)

关于垃圾回收机制自己的一点感悟(如有不对忘指正)

java和C语言中间隔着一个很厚的墙—-内存动态分配和垃圾回收机制,墙外面的想进来,墙里面的真会玩.

其实java并不是内存动态分配和垃圾自动回收机制的最早的实践者,这个构想在1960年就已经在MIT的Lisp中提出.

《think in java》的作者也说,很多优秀的C语言项目是死于内存的开销并未及时的回收而造成的内存溢出.

在之前的笔记中也介绍过JVM的在运行时是分为五个区,其中程序计数器,本地方法栈和虚拟机方法栈都是随着线程的消失而消失,这里方法栈,随着线程调用的方法不停变换着栈帧,当线程结束它就消亡了.这里只有方法区和堆是被所有的线程所共有的.这两部分是在jvm启动时就会被创建出来,他们只有在jvm关闭之后才会消失.

要实现垃圾自动回收机制这里就有三个要直面的问题:

1.怎么判断对象’挂了’

2.什么时候回收

3.怎么回收

那么让我们看一下Java的设计者们是怎么解决这个问题的

1.怎么判断对象’挂了’

这里Java使用的是探针的方式(GC Roots),但是还是要先提一下,这里有一个相对简单的实现,可能科班出身的攻城狮都知道,就是给对象加一个状态,使用中状态是1,对象不被引用之后(不再被程序使用)标记状态改成0,这种方式固然实现起来相当的简单,但是有一个致命的问题那就是当几个对象在相互循环的调用,也就是说是

例如三个对象存在这种调用关系:a -> b -> c -> a

这时在采用这种方式就不行了,其实这几个对象都已经不再被使用了,应该被标记为应被回收,但是因为这种调用关系使他们不能被回收.这是就要使用GC Roots来实现回收机制.

GC Roots这种方式是通过一个探针(根对象)去看这个对象还有没有外部的引用,就是还在调用(使用着它),如果没有则这就是一个要回收的对象.

2.什么时候回收

对于这个问题其实我真的不了解java是怎么设计GC的回收时机的,理论上说可以通过调用System.gc()方法,调用这个方法可以加快GC对该对象的回收;

其实具体GC的回收时机,是根据堆的新生代的分区参数,大小来决定的,GC通过这些我们自己设定的参数GC自己算出需要回收的时间,如果回收时间间隔太小,则比较影响体验(回收过程中会有stop-the-world的操作),而回收时间较长时,这时被标记的对象数量较多,GC负担过大,极端时,会导致崩溃.

但是!!!这都不是一定的,也就是说这些知识理论上有用.换句话说,一切看人家心情…

这里有一点是可以肯定的GC在回收的过程中所有在运行的程序都要停止,等GC回收完毕之后才能继续执行,那么重点来了,GC是怎么回收这部分对象的呢.

(2017年8月15日19:12:45)

3.怎么回收

这里只能说一下回收所用到的思想,因为在回收的过程中有很多的细节去做处理.其实现在说的是从JDK1.0发布时就在使用的几种GC回收思想,后续的回收算法也是在这几种的思想上进行了改进.

现在主要的回收算法主要采用到了分代处理:新生代,老年代.现在主流的回收算法是都是回收新生代,占75%-95%之间,新生代的对象可以说是”朝生夕死”.

复制算法

在复制算法中,将堆中的新生代分成了三块区域,一个大区域Eden,两个小区域Survivor,Eden:Survivor=8:1,新生代new的对象是在Eden和其中一个Survivor中(假如叫Survivor1),当在Eden和Survivor1中确定了要回收的对象的时候,将这两个区域中还活着的对象复制到另一个空的Survivor区域中,然后清空Eden和Survivor1,这种方式在大多数情况下都是可以满足(98%),但是也有2%的情况下存在溢出的可能性,这时还有一个补充方案就是将活着的对象复制到永久代中保证不会发生溢出.这是一个折中的方案.

复制-清除

复制清除是清除算法中最早提出的方案,这需要所有正在进行的程序都要停止(stop-the-world)然后运行这个算法去清理,并且将清理掉空缺的位置再复制排列整齐,这就相当于清洁工要清扫你的公司的工位,你们公司所有人必须要放下手头的工作,哪怕你们是活着的对象,也要这样做,这样的弊端是显而易见的,因为大家都要等待他才能做接下来的工作,假如现在需要回收的对象很少(极端情况90%的对象都是活着的,可是大家都要(stop-the-word)等待,很影响体验,但是GC表示也很无奈,其实多数情况下这个停顿是很短暂大概是几十毫秒左右)

标记-清除

这个算法算是对上面算法的一个补充,先对要清理的对象进行标记对要回收的对象进行辨别,然后进行清理,避免了刚才上述所说的极端情况,是对清理算法的一个补充

待续..