本章主要讲解以下C#的垃圾回收机制,之前也有文章提到:
Effect C# 学习笔记 .Net资源管理_dmk17771552304的博客-CSDN博客
Garbage Collector(垃圾收集器),仅就内存而言的垃圾收集。
它以应用程序的root为基础,遍历应用程序在Heap上动态分配的所有对象,通过识别它们是否被引用来确定哪些对象是已经死亡的、哪些仍需要被使用。已经不再被应用程序的root或者别的对象所引用的对象就是已经死亡的对象,即所谓的垃圾,需要被回收。这就是GC工作的原理。为了实现这个原理,GC有多种算法。比较常见的有Refrence Conting(引用计数)、Mark Sweep(标记压缩)、Copy Collection(复制集合)等等。目前主流的虚拟系统.NET CLR,Java VM都是采用的标记压缩算法。
Heap内存经过回收、压缩之后,可以继续采用前面的heap内存分配方法,即仅用一个指针记录heap分配的起始地址就可以。主要处理步骤:将线程挂起→确定roots→创建reachable objects graph→对象回收→heap压缩→指针修复。可以这样理解roots:heap中对象的引用关系错综复杂(交叉引用、循环),形成复杂的graph,roots是CLR在heap之外可以找到的各种入口点。
GC搜索roots的地方包括全局对象、静态变量、局部对象、函数调用参数、当前CPU寄存器中的对象指针(还有终结队列finalization queue)等。主要归为2种类型:已经初始化的静态变量、线程仍在使用的对象(stack + CPU register)。Reachable objects : 指根据对象引用关系,从roots出发可以到达的对象。例如当前执行函数的局部变量对象A是一个root object,它的成员变量引用了对象B,则B是一个reachable object。从roots出发可以创建reachable objects graph,剩余对象即为unreachable,可以被回收。
指针修复是因为compact过程移动了heap对象,对象地址发生变化,需要修复所有引用指针,包括stack、CPU register中的指针以及heap种其他对象的引用指针。Debug和Release执行模式之间稍有区别,Release模式下后续代码没有引用的对象是unreachable的,而Debug模式下需要等到当前函数执行完毕,这些对象才会称为unreachable,目的是为了调试时跟踪局部对象的内容。传给了COM+的托管对象也会称为root,并且具有一个引用计数器以兼容COM+的内存管理机制,引用计数为0时,这些对象才可能称为被回收对象。Pinned objects指分配之后不能移动的对象,例如传递给非托管代码的对象(或者使用了fixed关键字),GC在指针修复时无法修改非托管代码中的引用指针,因而这些对象移动将发生异常。Pinned objects会导致heap出现碎片,但大部分情况来说传给非托管代码的对象应当在GC时能够被回收掉。
将对象按照生命周期分成新的、老的,可以对新、老区域采用不同的回收策略和算法,加强对新区域的回收处理力度,争取在较短时间间隔、较小的内存区域内,以较低成本将执行路径上大量新近抛弃不再使用的局部对象及时回收掉。分代算法的假设前提条件:
1、大量新创建的对象生命周期都比较短,而较老的对象生命周期会更长;
2、对部分内存进行回收比基于全部内存的回收操作要快;
3、新创建的对象之间关联程度通常较强。heap分配的对象是连续的,关联度较强有利于提高CPU cache的命中率,.NET 将 heap分成3各代龄区域:Gen 0、Gen 1、Gen 2;
Heap分为3个代龄区域,相应的GC有3中方式:#Gen 0 collections, #Gen 1 collections,#Gen 2 collections。如果Gen 0 heap内存达到阈值,则触发0代GC,0代GC后Gen 0中幸存的对象进入Gen 1。如果Gen 1的内存达到阈值,则进行1代GC,1代GC将Gen 0 heap和Gen 1 heap一起进行回收,幸存的对象进入Gen2。
2代GC将Gen 0 heap、Gen 1 heap和Gen 2 heap一起回收,Gen 0 和Gen 1比较小,这两个代龄加起来总是保持16M左右;Gen2的大小由应用程序确定,可能达到几G,因此0代和1代GC的成本非常低,2代GC称为full GC,通常成本很高。粗略的计算0代和1代GC应当能在几毫秒到几十毫秒之间完成,Gen 2 heap比较大时,full GC可能需要花费几秒时间。大致上来讲.NET应用运行期间,2代、1代和0代GC的频率应当大致为1:10:100。
这两个队列和.NET对象所提供的Finalize方法有关。这两个队列并不用于存储真正的对象,而是存储一组指向对象的指针。当程序中使用了new操作符在Managed Heap上分配空间时,GC会对其进行分析,如果该对象含有Finalize方法则在Finalization Queue中添加一个指向该对象的指针。
在GC被启动以后,经过Mark阶段分辨出哪些是垃圾。再在垃圾中搜索,如果发现垃圾中有被Finalization Queue中的指针所指向的对象,则将这个对象从垃圾中分离出来,并将指向它的指针移动到Freachable Queue中。这个过程被称为是对象的复生(Resurrection),本来死去的对象就这样被救活了。为什么要救活它呢?因为这个对象的Finalize方法还没有被执行,所以不能让它死去。Freachable Queue平时不做什么事,但是一旦里面被添加了指针之后,它就会去触发所指对象的Finalize方法执行,之后将这个指针从队列中剔除,这时对象就可以安静的死去了。
.NET Framework的System.GC类提供了控制Finalize的两个方法,ReRegisterForFinalize和SuppressFinalize。前者是请求系统完成对象的Finalize方法,后者是请求系统不要完成对象的Finalize方法。ReRegisterForFinalize方法其实就是将指向对象的指针重新添加到Finalization Queue中。这就出现了一个很有趣的现象,因为在Finalization Queue中的对象可以复生,如果在对象的Finalize方法中调用ReRegisterForFinalize方法,这样就形成了一个在堆上永远不会死去的对象,像凤凰涅槃一样每次死的时候都可以复生。
托管资源:
.NET中的所有类型都是(直接或间接)从System.Object类型派生的。
CTS中的类型被分成两大类——引用类型(reference type,又叫托管类型[managed type]),分配在内存堆上;值类型(value type),分配在堆栈上。如图:
引用类型分配在托管堆(Managed Heap)上,声明一个变量在栈上保存,当使用new创建对象时,会把对象的地址存储在这个变量里。托管堆相反,从低地址往高地址分配内存,如图:
.NET中超过80%的资源都是托管资源。
非托管资源:
ApplicationContext, Brush, Component, ComponentDesigner, Container, Context, Cursor, FileStream, Font, Icon, Image, Matrix, Object, OdbcDataReader, OleDBDataReader, Pen, Regex, Socket, StreamWriter, Timer, Tooltip, 文件句柄, GDI资源, 数据库连接等等资源。可能在使用的时候很多都没有注意到!
.NET的GC机制有这样两个问题:
首先,GC并不是能释放所有的资源。它不能自动释放非托管资源。
第二,GC并不是实时性的,这将会造成系统性能上的瓶颈和不确定性。
GC并不是实时性的,这会造成系统性能上的瓶颈和不确定性。所以有了IDisposable接口,IDisposable接口定义了Dispose方法,这个方法用来供程序员显式调用以释放非托管资源。使用using语句可以简化资源管理。
示例:
///summary /// 执行SQL语句,返回影响的记录数 summary ///param name="SQLString"SQL语句/param ///returns影响的记录数/returns publicstaticint ExecuteSql(string SQLString) { using (SqlConnection connection =new SqlConnection(connectionString)) { using (SqlCommand cmd =new SqlCommand(SQLString, connection)) { try { connection.Open(); int rows = cmd.ExecuteNonQuery(); return rows; } catch (System.Data.SqlClient.SqlException e) { connection.Close(); throw e; } finally { cmd.Dispose(); connection.Close(); } } } }
当你用Dispose方法释放未托管对象的时候,应该调用GC.SuppressFinalize。如果对象正在终结队列(finalization queue), GC.SuppressFinalize会阻止GC调用Finalize方法。因为Finalize方法的调用会牺牲部分性能。如果你的Dispose方法已经对委托管资源作了清理,就没必要让GC再调用对象的Finalize方法(MSDN)。附上MSDN的代码,大家可以参考。
publicclass BaseResource : IDisposable { // 指向外部非托管资源 private IntPtr handle; // 此类使用的其它托管资源. private Component Components; // 跟踪是否调用.Dispose方法,标识位,控制垃圾收集器的行为 privatebool disposed =false; // 构造函数 public BaseResource() { // Insert appropriate constructor code here. } // 实现接口IDisposable. // 不能声明为虚方法virtual. // 子类不能重写这个方法. publicvoid Dispose() { Dispose(true); // 离开终结队列Finalization queue // 设置对象的阻止终结器代码 // GC.SuppressFinalize(this); } // Dispose(bool disposing) 执行分两种不同的情况. // 如果disposing 等于 true, 方法已经被调用 // 或者间接被用户代码调用. 托管和非托管的代码都能被释放 // 如果disposing 等于false, 方法已经被终结器 finalizer 从内部调用过, //你就不能在引用其他对象,只有非托管资源可以被释放。 protectedvirtualvoid Dispose(bool disposing) { // 检查Dispose 是否被调用过. if (!this.disposed) { // 如果等于true, 释放所有托管和非托管资源 if (disposing) { // 释放托管资源. Components.Dispose(); } // 释放非托管资源,如果disposing为 false, // 只会执行下面的代码. CloseHandle(handle); handle = IntPtr.Zero; // 注意这里是非线程安全的. // 在托管资源释放以后可以启动其它线程销毁对象, // 但是在disposed标记设置为true前 // 如果线程安全是必须的,客户端必须实现。 } disposed =true; } // 使用interop 调用方法 // 清除非托管资源. [System.Runtime.InteropServices.DllImport("Kernel32")] privateexternstatic Boolean CloseHandle(IntPtr handle); // 使用C# 析构函数来实现终结器代码 // 这个只在Dispose方法没被调用的前提下,才能调用执行。 // 如果你给基类终结的机会. // 不要给子类提供析构函数. ~BaseResource() { // 不要重复创建清理的代码. // 基于可靠性和可维护性考虑,调用Dispose(false) 是最佳的方式 Dispose(false); } // 允许你多次调用Dispose方法, // 但是会抛出异常如果对象已经释放。 // 不论你什么时间处理对象都会核查对象的是否释放, // check to see if it has been disposed. publicvoid DoSomething() { if (this.disposed) { thrownew ObjectDisposedException(); } } // 不要设置方法为virtual. // 继承类不允许重写这个方法 publicvoid Close() { // 无参数调用Dispose参数. Dispose(); } publicstaticvoid Main() { // Insert code here to create // and use a BaseResource object. } }
GC.Collect() 方法
作用:强制进行垃圾回收。
GC的方法: