MyException - 我的异常网
当前位置:我的异常网» CLR » 垃圾回收机制GC知识再总结兼谈怎么用好GC

垃圾回收机制GC知识再总结兼谈怎么用好GC

www.MyException.Cn  网友分享于:2015-08-26  浏览:0次
垃圾回收机制GC知识再总结兼谈如何用好GC

一、为什么需要GC

应用程序对资源操作,通常简单分为以下几个步骤:

1、为对应的资源分配内存

2、初始化内存

3、使用资源

4、清理资源

5、释放内存

应用程序对资源(内存使用)管理的方式,常见的一般有如下几种:

1、手动管理:C,C++

2、计数管理:COM

3、自动管理:.NET,Java,PHP,GO…

但是,手动管理和计数管理的复杂性很容易产生以下典型问题:

1.程序员忘记去释放内存

2.应用程序访问已经释放的内存

产生的后果很严重,常见的如内存泄露、数据内容乱码,而且大部分时候,程序的行为会变得怪异而不可预测,还有Access Violation等。

.NET、Java等给出的解决方案,就是通过自动垃圾回收机制GC进行内存管理。这样,问题1自然得到解决,问题2也没有存在的基础。

总结:无法自动化的内存管理方式极容易产生bug,影响系统稳定性,尤其是线上多服务器的集群环境,程序出现执行时bug必须定位到某台服务器然后dump内存再分析bug所在,极其打击伟德国际app人员编程积极性,而且源源不断的类似bug让人厌恶。

 

二、GC是如何工作的

GC的工作流程主要分为如下几个步骤:

1、标记(Mark)

2、计划(Plan)

3、清理(Sweep)

4、引用更新(Relocate)

5、压缩(Compact)

GC

(一)、标记

目标:找出所有引用不为0(live)的实例

方法:找到所有的GC的根结点(GC Root), 将他们放到队列里,然后依次递归地遍历所有的根结点以及引用的所有子节点和子子节点,将所有被遍历到的结点标记成live。弱引用不会被考虑在内

(二)、计划和清理

1、计划

目标:判断是否需要压缩

方法:遍历当前所有的generation上所有的标记(Live),根据特定算法作出决策

2、清理

目标:回收所有的free空间

方法:遍历当前所有的generation上所有的标记(Live or Dead),把所有处在Live实例中间的内存块加入到可用内存链表中去

(三)、引用更新和压缩

1、引用更新

目标: 将所有引用的地址进行更新

方法:计算出压缩后每个实例对应的新地址,找到所有的GC的根结点(GC Root), 将他们放到队列里,然后依次递归地遍历所有的根结点以及引用的所有子节点和子子节点,将所有被遍历到的结点中引用的地址进行更新,包括弱引用。

2、压缩

目标:减少内存碎片

方法:根据计算出来的新地址,把实例移动到相应的位置。

 

三、GC的根节点

本文反复出现的GC的根节点也即GC Root是个什么东西呢?

每个应用程序都包含一组根(root)。每个根都是一个存储位置,其中包含指向引用类型对象的一个指针。该指针要么引用托管堆中的一个对象,要么为null。

在应用程序中,只要某对象变得不可达,也就是没有根(root)引用该对象,这个对象就会成为垃圾回收器的目标。

用一句简洁的英文描述就是:GC roots are not objects in themselves but are instead references to objects.而且,Any object referenced by a GC root will automatically survive the next garbage collection.

.NET中可以当作GC Root的对象有如下几种:

1、全局变量

2、静态变量

3、栈上的所有局部变量(JIT)

4、栈上传入的参数变量

5、寄存器中的变量

注意,只有引用类型的变量才被认为是根,值类型的变量永远不被认为是根。只有深刻理解引用类型和值类型的内存分配和管理的不同,才能知道为什么root只能是引用类型。

顺带提一下JAVA,在Java中,可以当做GC Root的对象有以下几种:

1、虚拟机(JVM)栈中的引用的对象

2、方法区中的类静态属性引用的对象

3、方法区中的常量引用的对象(主要指声明为final的常量值)

4、本地方法栈中JNI的引用的对象

 

四、什么时候发生GC

1、当应用程序分配新的对象,GC的代的预算大小已经达到阈值,比如GC的第0代已满

2、代码主动显式调用System.GC.Collect()

3、其他特殊情况,比如,windows报告内存不足、CLR卸载AppDomain、CLR关闭,甚至某些极端情况下系统参数设置改变也可能导致GC回收

 

五、GC中的代

代(Generation)引入的原因主要是为了提高性能(Performance),以避免收集整个堆(Heap)。一个基于代的垃圾回收器做出了如下几点假设:

1、对象越新,生存期越短

2、对象越老,生存期越长

3、回收堆的一部分,速度快于回收整个堆

.NET的垃圾收集器将对象分为三代(Generation0,Generation1,Generation2)。不同的代里面的内容如下:

1、G0 小对象(Size<85000Byte)

2、G1:在GC中幸存下来的G0对象

3、G2:大对象(Size>=85000Byte);在GC中幸存下来的G1对象

  object o = new Byte[85000]; //large object
  Console.WriteLine(GC.GetGeneration(o)); //output is 2,not 0

ps,这里必须知道,CLR要求所有的资源都从托管堆(managed heap)分配,CLR会管理两种类型的堆,小对象堆(small object heap,SOH)和大对象堆(large object heap,LOH),其中所有大于85000byte的内存分配都会在LOH上进行。一个有趣的问题是为什么是85000字节?

代收集规则:当一个代N被收集以后,在这个代里的幸存下来的对象会被标记为N+1代的对象

 

六、谨慎显式调用GC

GC的开销通常很大,而且它的运行具有不确定性,微软的编程规范里是强烈建议你不要显式调用GC。但你的代码中还是可以使用framework中GC的某些方法进行手动回收,前提是你必须要深刻理解GC的回收原理,否则手动调用GC在特定场景下很容易干扰到GC的正常回收甚至引入不可预知的错误。

比如如下代码:

        void SomeMethod()
        {
            object o1 = new Object();
            object o2 = new Object();

            o1.ToString();
            GC.Collect(); // this forces o2 into Gen1, because it's still referenced
            o2.ToString();
        }

如果没有GC.Collect(),o1和o2都将在下一次垃圾自动回收中进入Gen0,但是加上GC.Collect(),o2将被标记为Gen1,也就是0代回收没有释放o2占据的内存

还有的情况是编程不规范可能导致死锁,比如流传很广的一段代码:

    public class MyClass
    {
        private bool isDisposed = false;

        ~MyClass()
        {
            Console.WriteLine("Enter destructor...");

            lock (this) //some situation lead to deadlock
            {
                if (!isDisposed)
                {
                    Console.WriteLine("Do Stuff...");
                }
            }
        }
    }
MyClass

通过如下代码进行调用:

           var instance = new MyClass();

            Monitor.Enter(instance);
            instance = null;

            GC.Collect();
            GC.WaitForPendingFinalizers();
          
            Console.WriteLine("instance is gabage collected");

上述代码将会导致死锁。原因分析如下:

1、客户端主线程调用代码Monitor.Enter(instance)代码段lock住了instance实例

2、接着手动执行GC回收,主线程会执行MyClass析构函数

3、在MyClass析构函数内部,使用了lock (this)代码,而主线程还没有释放instance(也即这里的this),此时主线程只能等待

虽然严格来说,上述代码并不是GC的错,和多线程操作似乎也无关,而是Lock使用不正确造成的。

同时请注意,GC的某些行为在Debug和Release模式下完全不同(Jeffrey Richter在<<CLR Via C#>>举过一个Timer的例子说明这个问题)。比如上述代码,在Debug模式下你可能发现它是正常运行的,而Release模式下则会死锁。

 

七、当GC遇到多线程

这一段主要参考<<CLR Via C#>>的线程劫持一节。

前面讨论的垃圾回收算法有一个很大的前提就是:只在一个线程运行。而在现实伟德国际app中,经常会出现多个线程同时访问托管堆的情况,或至少会有多个线程同时操作堆中的对象。一个线程引发垃圾回收时,其它线程绝对不能访问任何线程,因为垃圾回收器可能移动这些对象,更改它们的内存位置。CLR想要进行垃圾回收时,会立即挂起执行托管代码中的所有线程,正在执行非托管代码的线程不会挂起。然后,CLR检查每个线程的指令指针,判断线程指向到哪里。接着,指令指针与JIT生成的表进行比较,判断线程正在执行什么代码。

如果线程的指令指针恰好在一个表中标记好的偏移位置,就说明该线程抵达了一个安全点。线程可在安全点安全地挂起,直至垃圾回收结束。如果线程指令指针不在表中标记的偏移位置,则表明该线程不在安全点,CLR也就不会开始垃圾回收。在这种情况下,CLR就会劫持该线程。也就是说,CLR会修改该线程栈,使该线程指向一个CLR内部的一个特殊函数。然后,线程恢复执行。当前的方法执行完后,他就会执行这个特殊函数,这个特殊函数会将该线程安全地挂起。然而,线程有时长时间执行当前所在方法。所以,当线程恢复执行后,大约有250毫秒的时间尝试劫持线程。过了这个时间,CLR会再次挂起线程,并检查该线程的指令指针。如果线程已抵达一个安全点,垃圾回收就可以开始了。但是,如果线程还没有抵达一个安全点,CLR就检查是否调用了另一个方法。如果是,CLR再一次修改线程栈,以便从最近执行的一个方法返回之后劫持线程。然后,CLR恢复线程,进行下一次劫持尝试。所有线程都抵达安全点或被劫持之后,垃圾回收才能使用。垃圾回收完之后,所有线程都会恢复,应用程序继续运行,被劫持的线程返回最初调用它们的方法。

实际应用中,CLR大多数时候都是通过劫持线程来挂起线程,而不是根据JIT生成的表来判断线程是否到达了一个安全点。之所以如此,原因是JIT生成表需要大量内存,会增大工作集,进而严重影响性能。

概念叙述到此结束,手都抄软了^_^,这书卖的贵和书里面的理论水平一样有道理。

这里再说一个真实案例。某web应用程序中大量使用Task,后在生产环境发生莫名其妙的现象,程序时灵时不灵,根据数据库日志(其实还可以根据Windows事件跟踪(ETW)、IIS日志以及dump文件),发现了Task执行过程中有不规律的未处理的异常,分析后怀疑是CLR垃圾回收导致,当然这种情况也只有在高并发条件下才会暴露出来。

 

八、伟德国际app中的一些建议和意见

由于GC的代价很大,平时伟德国际app中注意一些良好的编程习惯有可能对GC有积极正面的影响,否则有可能产生不良效果。

1、尽量不要new很大的object,大对象(>=85000Byte)直接归为G2代,GC回收算法从来不对大对象堆(LOH)进行内存压缩整理,因为在堆中下移85000字节或更大的内存块会浪费太多CPU时间

2、不要频繁的new生命周期很短object,这样频繁垃圾回收频繁压缩有可能会导致很多内存碎片,可以使用设计良好稳定运行的对象池(ObjectPool)技术来规避这种问题

3、使用更好的编程技巧,比如更好的算法、更优的数据结构、更佳的解决策略等等

update:.NET4.5.1及其以上版本已经支持压缩大对象堆,可通过System.Runtime.GCSettings.LargeObjectHeapCompactionMode进行控制实现需要压缩LOH。可参考这里

根据经验,有时候编程思想里的空间换时间真不能乱用,用的不好,不但系统性能不能保证,说不定就会导致内存溢出(Out Of Memory),关于OOM,可以参考我之前写过的一篇文章有效预防.NET应用程序OOM的经验备忘

之前在维护一个系统的时候,发现有很多大数据量的处理逻辑,但竟然都没有批量和分页处理,随着数据量的不断膨胀,隐藏的问题会不断暴露。然后我在重写的时候,都按照批量多次的思路设计实现,有了多线程、多进程和分布式集群技术,再大的数据量也能很好处理,而且性能不会下降,系统也会变得更加稳定可靠。

最后感慨一下,反复看一本好书远远比看十本二十本不那么靠谱的书收获更多。

参考:

<<CLR Via C#>>

<<深入理解Java虚拟机>>

<<C# In Depth>>

<<Think In Java>>

http://msdn.microsoft.com/zh-cn/magazine/cc188793%28en-us%29.aspx

文章评论

当下全球最炙手可热的八位少年创业者
当下全球最炙手可热的八位少年创业者
“肮脏的”IT工作排行榜
“肮脏的”IT工作排行榜
为啥Android手机总会越用越慢?
为啥Android手机总会越用越慢?
程序员最害怕的5件事 你中招了吗?
程序员最害怕的5件事 你中招了吗?
2013年美国伟德国际app者薪资调查报告
2013年美国伟德国际app者薪资调查报告
为什么程序员都是夜猫子
为什么程序员都是夜猫子
如何成为一名黑客
如何成为一名黑客
我跳槽是因为他们的显示器更大
我跳槽是因为他们的显示器更大
程序员必看的十大电影
程序员必看的十大电影
Java程序员必看电影
Java程序员必看电影
每天工作4小时的程序员
每天工作4小时的程序员
初级 vs 高级伟德国际app者 哪个性价比更高?
初级 vs 高级伟德国际app者 哪个性价比更高?
要嫁就嫁程序猿—钱多话少死的早
要嫁就嫁程序猿—钱多话少死的早
亲爱的项目经理,我恨你
亲爱的项目经理,我恨你
那些争议最大的编程观点
那些争议最大的编程观点
如何区分一个程序员是“老手“还是“新手“?
如何区分一个程序员是“老手“还是“新手“?
Web伟德国际app人员为什么越来越懒了?
Web伟德国际app人员为什么越来越懒了?
10个帮程序员减压放松的网站
10个帮程序员减压放松的网站
总结2014中国互联网十大段子
总结2014中国互联网十大段子
“懒”出效率是程序员的美德
“懒”出效率是程序员的美德
程序猿的崛起——Growth Hacker
程序猿的崛起——Growth Hacker
写给自己也写给你 自己到底该何去何从
写给自己也写给你 自己到底该何去何从
 程序员的样子
程序员的样子
看13位CEO、创始人和高管如何提高工作效率
看13位CEO、创始人和高管如何提高工作效率
2013年中国软件伟德国际app者薪资调查报告
2013年中国软件伟德国际app者薪资调查报告
团队中“技术大拿”并非越多越好
团队中“技术大拿”并非越多越好
60个伟德国际app者不容错过的免费资源库
60个伟德国际app者不容错过的免费资源库
那些性感的让人尖叫的程序员
那些性感的让人尖叫的程序员
十大编程算法助程序员走上高手之路
十大编程算法助程序员走上高手之路
编程语言是女人
编程语言是女人
我的丈夫是个程序员
我的丈夫是个程序员
做程序猿的老婆应该注意的一些事情
做程序猿的老婆应该注意的一些事情
程序员的一天:一寸光阴一寸金
程序员的一天:一寸光阴一寸金
一个程序员的时间管理
一个程序员的时间管理
我是如何打败拖延症的
我是如何打败拖延症的
鲜为人知的编程真相
鲜为人知的编程真相
中美印日四国程序员比较
中美印日四国程序员比较
5款最佳正则表达式编辑调试器
5款最佳正则表达式编辑调试器
老美怎么看待阿里赴美上市
老美怎么看待阿里赴美上市
聊聊HTTPS和SSL/TLS协议
聊聊HTTPS和SSL/TLS协议
程序员应该关注的一些事儿
程序员应该关注的一些事儿
10个调试和排错的小建议
10个调试和排错的小建议
Google伦敦新总部 犹如星级庄园
Google伦敦新总部 犹如星级庄园
老程序员的下场
老程序员的下场
旅行,写作,编程
旅行,写作,编程
Web伟德国际app者需具备的8个好习惯
Web伟德国际app者需具备的8个好习惯
程序员的鄙视链
程序员的鄙视链
程序员都该阅读的书
程序员都该阅读的书
程序员周末都喜欢做什么?
程序员周末都喜欢做什么?
软件伟德国际app程序错误异常ExceptionCopyright © 2009-2015 MyException 版权所有