参考:
一:《你必须知道的.NET》电子工业出版社
二:对.Net 垃圾回收Finalize 和Dispose的理解
.NET中的内存分配
几个基本概念:
TypeHandle:类型句柄,指向对应的方法表。每个对象创建时都包含该附加成员。每个类型都对应于一个方法表,方法表创建于编译时,主要包含了类型的特征信息、实现的接口数等等。
SyncBlockIndex:用于线程同步,每个对象创建时也包含该附加成员,它指向一块被称为SyncBlockIndex的内存块,用于管理同对象同步。
NextObjPtr, 由托管堆维护的一个指针,用于标识下一个新建对象分配时在托管堆中所处的位置。CLR初始化时,NextObiPtr位于托管堆的基地址。
托管堆
对32位处理器来说,应用程序完成进程初始化后,CLR 将在进程的可用地址空间上分配一块保留的地址空间,它是进程(每个进程可使用 4GB)中可用地址空间上的一块内存区域,但并不对应于任何物理内存,这块地址空间即是托管堆。
托管堆又根据存储信息的不同划分为多个区域,其中最重要的是垃圾回收堆(GC Heap)和加载堆(Loader Heap)。
GC Heap 用于存储对象实例,受 GC管理;
Loader Heap 用于存储类型系统,又分为High-Frequency Heap、Low-Frequency Heap和 Stub Heap,不同的堆上存储不同的信息。Loader Heap最重要的信息就是元数据相关的信息,也就是 Type 对象,每个Type 在Loader Heap上体现为一个Method Table(方法表),而Method Table 中则记录了存储的元数据信息,例如基类型、静态字段、实现的接口、所有的方法等等。Loader Heap 不受GC控制,其生命周期为从创建到AppDomain卸载。
值类型一般创建在线程的堆栈上。
引用类型的实例分配于托管堆上。
引用类型内存分配过程
示例如下:
using System; public class UserInfo { private Int32 age = -1; private char level = 'A'; } public class User { private Int32 id; private UserInfo user; } public class VIPUser : User { public bool isVip; public bool IsVipUser() { return isVip; } public static void Main() { VIPUser aUser; aUser = new VIPUser(); aUser.isVip = true; Console.WriteLine(aUser.IsVipUser()); } }
分配过程剖析:
首先,将声明一个引用类型变量 aUser:
VIPUser aUser;
它仅是一个引用(指针),保存在线程的堆栈上,占用 4Byte 的内存空间,将用于保存 VIPUser对象的有效地址,此时 aUser未指向任何有效的实例,因此被自行初始化为 null,试图对 aUser 的任何操作将抛出 NullReferenceException异常。
接着,通过new操作执行对象创建:
aUser = new VIPUser();
其过程又可细分为以下几步:
(a)CLR按照其继承层次进行搜索,计算类型及其所有父类的字段,该搜索将一直递归到 System.Object类型,并返回字节总数。以本例而言类型 VIPUser 需要的字节总数为15Byte,具体计算为:VIPUser类型本身字段 isVip(bool型)为1Byte;父类User 类型的字段 id(Int32 型)为 4Byte,字段user 保存了指向 UserInfo 型的引用,因此占 4Byte,而同时还要为 UserInfo 分配6Byte
字节的内存。
(b)实例对象所占的字节总数还要加上对象附加成员所需的字节总数,其中附加成员包括TypeHandle和SyncBlockIndex,共计 8字节(在 32位 CPU平台下)。因此,需要在托管堆上分配的字节总数为23 字节,而堆上的内存块总是按照4Byte的倍数进行分配,因此本例中将分配24字节的地址空间。
(c)CLR 在当前 AppDomain对应的托管堆上搜索,找到一个未使用的24字节的连续空间,并为其分配该内存地址。事实上,GC使用了非常高效的算法来满足该请求,NextObjPtr指针只需要向前推进24 个字节,并清零原 NextObjPtr指针和当前 NextObjPtr 指针之间的字节,然后返回原NextObjPtr指针地址即可,该地址正是新创建对象的托管堆地址,也就是 aUser引用指向的实例地址。而此时的NextObjPtr 仍指向下一个新建对象的位置。
注意,栈的分配是向低地址扩展,而堆的分配是向高地址扩展。
在上述操作时,如果试图分配所需空间而发现内存不足时,GC将启动垃圾收集操作来回收垃圾对象所占的内存。
最后,调用对象构造器,进行对象初始化操作,完成创建过程。
该构造过程,又可细分为以下几个环节:
(a)构造VIPUser 类型的 Type对象,主要包括静态字段、方法描述、实现的接口等,并将其分配在上文提到托管堆的 Loader Heap上。
(b)初始化 aUser的两个附加成员:TypeHandle和SyncBlockIndex。将TypeHandle 指针指向Loader Heap上的MethodTable,CLR 将根据 TypeHandle 来定位具体的 Type;将 SyncBlockIndex 指针指向Synchronization Block 的内存块,用于在多线程环境下对实例对象的同步操作。
(c)调用 VIPUser 的构造器,进行实例字段的初始化。实例初始化时,会首先向上递归执行父类初始化,直到完成System.Object类型的初始化,然后再返回执行子类的初始化,直到执行 VIPUser类为止。以本例而言,初始化过程首先执行 System.Object类,再执行 User类,最后才是VIPUser类。最终,newobj分配的托管堆的内存地址,被传递给 VIPUser 的this 参数,并将其引用传给栈上声明的aUser。
上述过程,基本完成了一个引用类型创建、内存分配和初始化的整个流程,然而该过程只能看作是一个简化的描述,实际的执行过程更加复杂,涉及一系列细化的过程和操作。对象创建并初始化之后,内存的布局,可以表示为下图。
其余种种
对于值类型嵌套引用类型的情况,引用类型变量作为值类型的成员变量,在堆栈上保存该成员的引用,而实际的引用类型仍然保存在 GC堆上;
对于引用类型嵌套值类型的情况,则该值类型字段将作为引用类型实例的一部分保存在 GC堆上。
方法调用过程
如上所言,MethodTable中包含了类型的元数据信息,类在加载时会在 Loader Heap上创建这些信息,一个类型在内存中对应一份 MethodTable,其中包含了所有的方法、静态字段和实现的接口信息等。对象实例的 TypeHandle在实例创建时,将指向MethodTable 开始位置的偏移处(默认偏移12Byte)。通过对象实例调用某个方法时,CLR 根据TypeHandle 可以找到对应的 MethodTable,进而可以定位到具体的方法,再通过 JIT Compiler 将IL 指令编译为本地 CPU指令,该指令将保存在一个动态内存中,然后在该内存地址上执行该方法,同时该 CPU指令被保存起来用于下一次的执行。
静态字段的内存分配和释放
静态字段也保存在方法表中,位于方法表的槽数组后,其生命周期为从创建到 AppDomain卸载。因此一个类型无论创建多少个对象,其静态字段在内存中也只有一份。静态字段只能由静态构造函数进行初始化,静态构造函数确保在任何对象创建前,或者在任何静态字段或方法被引用前执行,其详细的执行顺序在 7.8 节“动静之间:静态和非静态”有所讨论。
.NET的垃圾回收机制:
CLR管理内存的区域主要有三块:
一:
线程的堆栈 ,用于分配值类型实例。堆栈主要有操作系统管理,不受垃圾收集器的控制,当值类型实例所在的方法结束时,其存储单位自动释放。栈的执行效率高,但存储容量有限。
二:
GC堆,用于分配小对象实例。如果引用类型对象的实例小于85000字节,实例将被分配在GC堆上。当有内存分配或者回收时,垃圾收集器会对GC对进行压缩。
三:
LOH(Large object heap),用于分配大对象实例。LOH堆不会被压缩,而且只有在完全GC回收时才会被回收,这种设计方案是对垃圾回收性能的优化考虑。
GC如何判断某个对象为垃圾
每个应用程序有一组根(指针),根指向托管堆中的存储位置,由 JIT编译器和 CLR运行时维护根指针列表,主要包括全局变量、静态变量、局部变量和寄存器指针等。
当垃圾收集器启动时,它假设所有对象都是可回收的垃圾,并开始遍历所有的根,将根引用的对象标记为可达对象添加到可达对象图中,在遍历过程中,如果根引用的对象还引用着其他对象,则该对象也被添加到可达对象图中,依次类推,垃圾收集器通过根列表的递归遍历,将能找到所有可达对象,并形成一个可达对象图。同时那些不可达对象则被认为是可回收对象,垃圾收集器接着运行垃圾收集进程来释放垃圾对象的内存空间。
垃圾收集器何时启动:
(1)内存不足溢出时,更确切地应该说是第 0代对象充满时。
(2)调用 GC.Collect 方法强制执行垃圾回收。
(3)Windows报告内存不足时,CLR 将强制执行垃圾回收。
(4)CLR 卸载AppDomain 时,GC将对所有代龄的对象执行垃圾回收。
(5)其他情况,例如物理内存不足,超出短期存活代的内存段门限,运行主机拒绝分配内存
等等
何为紧缩
GC在垃圾回收之后,堆上将出现多个被收集对象的“空洞”,为避免托管堆的内存碎片,会重新分配内存,压缩托管堆,此时 GC可以看出是一个紧缩收集器,其具体操作为:GC找到一块较大的连续区域,然后将未被回收的对象转移到这块连续区域,同时还要对这些对象重定位,修改应用程序的根以及发生引用的对象指针,来更新复制后的对象位置。
关于Generation(代龄)的详细情况请参考《你必须知道的.NET》第五章,P187
非托管资源的回收
GC全权负责了对托管堆的内存管理,然而除了内存,还有一些非托管资源比如数据库链接、文件句柄、网络链接、互斥体、COM对象、套接字、位图和GDI+对象等, 这些GC是不管的。
非托管资源的清理,主要有两种方式:Finalize 方法和 Dispose 方法。
Finalize方式
其实就是用析构函数来释放资源
例如
class GCApp: Object { ~GCApp() { //执行资源清理 } }
该析构函数会被编译成一个Finalize()方法。
Finalize方法调用时,会强制调用父类的FInalize方法。
若某个类有析构函数,则当GC回收该对象之前,会自动执行其析构函数来清理非托管资源,否则直接将该对象从内存清除。
若一个对象调用了GC.SuppressFinalize()方法,则GC在清理它之前不会再调用它的析构函数。
Finalize方式存在很多弊端
比如
调用Finalize()的时间无法控制,只在GC决定要回收该对象时才调用其析构函数,这导致一些资源比如文件句柄长时间被占据。
极大地损伤性能,GC使用一个终止化队列的内部结构来跟踪具有 Finalize方法的对象。当重写了Finalize方法的类型在创建时,要将其指针添加到该终止化队列中,由此对性能产生影响。
因此一般情况下在自定义类型中应避免重写 Finalize 方法,而通过 Dispose 模式来完成对非托管资源的清理
Dispose模式
其实就是某个类实现 System.IDisposable接口。
该接口中定义了一个公有无参的 Dispose 方法,用户在该方法中清理非托管资源。
Dispose方法需要用户显式的调用才能被执行。这保证了用户能够及时地释放非托管资源,而不必等到GC回收该对象之前才释放资源。
例子:
class MyDispose : IDisposable { //实现IDisposable接口 public void Dispose() { //释放资源 } }
派生类中实现Dispose模式,应该重写基类的受保护Dispose方法,并且通过base调用基类的Dispose方法,以确保释放继承链上所有对象的引用资源,在整个继承层次中传播 Dispose模式。
protected override void Dispose(bool disposing) { if (!disposed) { try { //子类资源清理 //...... disposed = true; } finally { base.Dispose(disposing); } } }
最佳策略
最佳的资源清理策略,应该是同时实现 Finalize 方式和 Dispose方式。
一方面,Dispose方法可以克服Finalize 方法在性能上的诸多弊端;另一方面,Finalize 方法又能够确保没有显式调用 Dispose 方法时,也自行回收使用的所有资源。
例子:
我们模拟一个简化版的文件处理类 FileDealer,其中涉及对文件句柄的访问
using System; using System.Runtime.InteropServices; class FileDealer : IDisposable { //定义一个访问文件资源的 Win32句柄 private IntPtr fileHandle; //定义引用的托管资源 private ManagedRes managedRes; //定义构造器,初始化托管资源和非托管资源 public FileDealer(IntPtr handle, ManagedRes res) { fileHandle = handle; managedRes = res; } //实现终结器,定义Finalize ~FileDealer() { if (fileHandle != IntPtr.Zero) { Dispose(false);//确保当没有显式调用Dispose时,在对象被GC销毁前也会调用Dispose方法。 } } //实现IDisposable接口 public void Dispose() { Dispose(true); //阻止GC调用Finalize方法 GC.SuppressFinalize(this); } //实现一个处理资源清理的具体方法 protected virtual void Dispose(bool disposing) { if (disposing) { //清理托管资源 managedRes.Dispose(); } //执行资源清理,在此为关闭对象句柄 if (fileHandle != IntPtr.Zero) { CloseHandle(fileHandle); fileHandle = IntPtr.Zero; } } public void Close() { //在内部调用Dispose来实现 Dispose(); } //实现对文件句柄的其他应用方法 public void Write() { } public void Read() { } //引入外部Win32API [DllImport("Kernel32")] private extern static Boolean CloseHandle(IntPtr handle); }这个例子的妙处在于既可以显式调用Dispose方法,又能够保证当我们没有显式地调用Dispose()方法时,GC回收该对象之前也会调用Dispose(false)方法来释放非托管资源。
本例子的说明:
Dispose方法中,应该使用 GC. SuppressFinalize防止GC调用Finalize方法,因为显式调用Dispose之后就没有必要再让GC调用Finalize()方法了。
公有Dispose方法不能实现为虚方法,以禁止在派生类中重写。
在该模式中,公有Dispose方法通过调用重载虚方法 Dispose(bool disposing)方法来实现,具体的资源清理操作实现于虚方法中。Dispose(true)在Dispose()中调用,Dispose(false)在析构函数中调用,两者的区别在于Dispose(true)表示要将托管资源和非托管资源一并清理掉,而Dispose(false)由于是GC调用finalize()时候被调用,GC已经准备清理这个对象了,所以就不需要再手动地清理托管资源了。
总结
Finalize是CLR提供的一个机制, 它保证如果一个类实现了Finalize方法,那么当该类对象被垃圾回收时,垃圾回收器会调用Finalize方法
Dispose(bool disposing)不是CRL提供的一个机制, 而仅仅是一个设计模式。
Finalize由GC自行调用,而Dispose由开发者强制执行调用。
尽量避免使用Finalize方式来清理资源,必须实现Finalize时,也应一并实现 Dispose方法,来提供显式调用的控制权限。
执行Finalize()的准确时间是不确定的,这取决于GC。
Finalize方法和Dispose方法,只能清理非托管资源,释放内存的工作仍由GC负责。
对象使用完毕应该立即释放其资源,最好显式调用 Dispose方法来实现
using语句
凡是实现了Dispose模式的类型,均可以 using语句来定义其引用范围.
例如:
public static void Main() { using(FileDealer fd = new FileDealer(new IntPtr(), new ManagedRes())) { fd.Read(); } }
当执行流超过了using的代码块之后,fd对象会自动调用Dispose()方法释放资源。