您的位置:首页 > 其它

jvm--gc垃圾收集(1)

2017-07-27 23:48 260 查看
垃圾收集,无非就是三个点,哪些内存要回收,什么时候回收,如何回收,在写代码的时候我们需要注意各种内存泄漏,内存溢出问题,当垃圾收集成为系统达到更多并发量的瓶颈的时候,我们需要对这些自动化的技术实施相应的调节,和监控。gc主要监控的是我们的内存,作为对象存活在堆里面,但是进行回收之前最重要的自然是判断对象是否还能,还要被使用。一般有几种方式来判断对象是否还要被使用:

1。给对象添加一个计数器,当一个地方使用时,计数器加一,失效时,计数器减一,任何时候计数器为0的时候,这个对象就是不能被使用的,虽然这个方式实现简单,效率也高,但是很难解决对象之间循环引用的问题比如说,一个类a有一个属性b,我们创建两个a的对象,a1,a2,a1.b=a2,a2.b=a1,a1=null,a2=null,除此之外这两个对象都没有被使用了,实际上这两个对象都已经无法被使用了,但是因为他们互相引用对方,导致计数器不会清空,内存泄漏了。

2.可达性分析法,通过节点向下索引,路径称为引用链,当一个对象到底部没有任何引用链相连的时候,则证明这个对象是不可用的,有关联则是可用的。其实作为底部对象,我们包括了四种:1。虚拟机栈2.方法去中类静态属性的引用3.方法去中常量引用的对象4.本地方法栈中native方法引用的对象。

其实作为引用,如果reference类型数据中存储的数值代表的是另外一块内存的启始地址,就称为这块内存代表一个引用。

作为我们开发,更加需求这样的对象:内存空间充足时,能够保存在内存中,如果在内存整理之后,还是很紧张,则可以抛弃这些对象。jdk1.2之后对引用概念更加细化了:

强引用:程序代码中普遍存在的,比如说 Object o = new Object(),只要强引用还存在,那么垃圾回收不会回收这些对象。

软引用:还有用,但是非必须的对象,在系统发生内存溢出之前,会把这些对象列到回收范围之内,进行二次回收,如果还没有足够内存才会抛出昨天提到的内存溢出。在1.2之后提供了SoftReference类来实现软引用

弱引用:描叙非必须对象,强度比软引用更加弱,只能生存到下一次回收之前。不管内存是否足够,都会回收这些对象。1.2之后通过weakReference类来实现

虚引用:最弱的引用关系。他完全不会对生存空间构成影响,无法通过这个引用来取得一个对象实例,提供虚引用关联的目的是为了能够在这个对象被回收的时候收到通知。1.2之后通过PhantomREference来实现。

其实作为我们之前通过可达分析中不可达的对象,也并非是立即要回收的,要真正判断对象回收至少要通过两次标记:

1.可达分析没有与gcroot的引用连,并且筛选—判断是否执行finalize()方法。如果这个对象没有覆盖这个finalize()方法或着这个方法被虚拟机调用过那么这个对象会放置在低队列中–fqueue。稍后才执行这个方法回收。

如果在等待中出现死循环,或者执行缓慢,那么容易永久等待,这是对象可能能够不被回收,这时候gc将会进行再次标记。

2.这时候如果与其他对象关联了,或者吧this付给某个类变量,那么则不会被回收。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息