企业如何建站,网站优化教程,北京建行网站,遵义县公司网站建设《上篇》中我们主要讨论的是程序集#xff08;Assembly#xff09;和应用程序域#xff08;AppDomain#xff09;的话题#xff0c;着重介绍了两个不同的程序集加载方式——独占方式和共享方式#xff08;中立域方式#xff09;#xff1b;以及基于进程范围内的字符串驻… 《上篇》中我们主要讨论的是程序集Assembly和应用程序域AppDomain的话题着重介绍了两个不同的程序集加载方式——独占方式和共享方式中立域方式以及基于进程范围内的字符串驻留。这篇将关注点放在托管对象创建时内存的分配和对大对象LOLarge Object的回收上不对之处还望各位能够及时指出。 目录 一、从类型Type与实例Instance谈起 二、实例内存分配不仅限于GC堆 三、实例对类型的引用 四、LOH中的对象如何被回收 一、从类型Type与实例Instance谈起 在面向对象的世界中类型和实例是两个核心的要素。不论是类型还是实例相关的信息都需要加载到内存中也就都对应着某一块或者多块连续或者不连续的内存。那么对类型和实例的内存分配是如何进行的呢对象是“状态”和“行为”的组合体所以从.NET Framework的角度来看类型它只具有两种类型的成员——字段和方法实际还有嵌套类型前者表示状态后者表示行为。类型使用元数据描述而实例则是符合该元数据描述的单个个体。同一个类型下的所有实例具有相同的行为它们通过状态值的不同得以区分。所以内存中的实例本篇所说的实例指的是引用类型的实例表示的是字段值而内存中的类型表示的则是类型成员结构的元数据。很多人都知道当我们创建一个对象的时候CLR会在GC堆Heap中开辟一块连续的内存空间保存字段值。那么类型信息又是保存在那块内存上呢 实际上类型信息保存在“另一个堆”上我们称之为加载器堆Loader Heap。每一个应用程序域都具有各自的加载器堆即包括我们创建的普通应用程序域也包括《上篇》中提到的三个特殊应用程序域系统程序域、共享程序域和默认程序域。如果说GC堆是实例的容器那么基于应用程序域的加载器堆就是类型的容器。CLR采用“按需加载(这里指的是类型不是程序集)、及时编译”的运行机制。当某个类型被第一次使用的时候CLR试图加载该类型。如果该类型对应的程序没有独自地加载到本应用程序域中或者没有通过中立域的形式加载到共享程序域中它会按照相应的方式加载程序集在这里我们假设采用独占方式加载。然后将使用到的这个类型加载到本应用程序域的加载器堆中。 加载器堆维护着自应用程序域创建以来使用过的所有类型记录它们对应着一个特殊的对象——方法表Method Table。当程序第一次执行到某个方法的时候CLR会定位到方法表中该条目获取相关信息进行JIT编译。所以如果某个类型在加载器堆中的方法表的某个条目至少被执行一次它就会指向一段JIT编译后的机器指令。 二、实例内存分配不仅限于GC堆 到现在为止我们知道了类型和实例分别位于基于应用程序域的加载器堆和GC堆中那么CLR的内存分配仅仅限于这“两堆”吗当然不是除了这“两堆”以及默认的进程堆还有额外“两堆”一是存放JIT编译后机器指令的JIT堆JIT Heap另一个则是专门用于“大对象”的大对象堆LOH Large Object Heap。下图反映了CLR主要维护的这些个不同的“堆”。 对于大对象堆在本文后续部分还会讲述在这里我们需要先了解CLR认为怎样的对象是“大对象”。当我们实例化一个对象的时候如果该对象大于或者等于85000字节这种对象一般是数组一般对象不会这么大CLR将认为是“大对象”并被放到LOH中否则放到GC堆中。这里有一点需要读者注意的是作为垃圾回收器的GC并不仅仅限于针对GC堆中对象的回收LOH中的对象的回收工作也在GC的管辖之下。所以从某种意义上讲你可以将之前提到的GC堆理解为SOHSmall Object Heap或者称之为“狭义GC堆”而将“广义GC堆”理解为SOHLOH。 三、实例对类型的引用 实例是类型的实例实例和它所对应的类型需要维持一种联系。反映在内存中就以为着分配在GC堆或者是LOH中的对象具有一个对位于加载器堆中该类型的方法表的引用。实例对类型的引用通过一个特殊的对象来维系——TypeHandle。我们举个例子在如下一段简单的对象实例化代码中 我先后实例化了四个对象字符串“ABC”、System.Object对象、自定义Bar对象和具有85000个元素的字节数组。 1: string strInstance ABC; 2: object objectInstance new object(); 3: Bar barInstance new Bar() 4: byte[] largeObjInstance new byte[85000]; 当上面的程序执行后围绕着实例化的四个对象和类型信息在内存中将会具有如下一个关系。最左边的是现成调用栈中的上述四个变量对于字符串类型的strInstance由于《上篇》所讲述的关于字符串驻留机制最后总的字符串被分配到系统程序域中Object和Bar类型的objectInstance与barInstance由于是小于85000字节的小对象所以被分配到GC堆中。objectInstance通过TypeHandle指向位于共享程序域中System.Objhect类型对应的方法表因为定义该类型的mscorlib程序集以中立域的方式加载而barInstance得TypeHandle指向的基于Bar类型的方法表则位于默认程序域中因为程序域默认采用独占的方式加载。元素个数为85000的字节数组largeObjInstance属于大对象直接分配到LOH中。largeObjInstance的TypeHandle指向的基于System.Byte[]类型的方法表该System.Byte[]类型同样定义在mscorlib程序集中所以该方法表同样存在于共享程序域的加载器堆。 四、LOH中的对象如何被回收 了解GC的读者应该都知道CLR采用基于“代龄Generation”的垃圾回收机制。代龄个人觉得是一个很准确的词语它充分体现了设计者用于表现“不同的对象具有不同生命周期”的意思。所有对象分三代即G0、G1和G2这实际上代表了三个不同的连续的内存块。“辈分”越高表明时间越久“辈分”越低被扫荡GC回收的频率就越高。关于基于代龄的垃圾回收机制限于篇幅就说到这里。我们的重点是GC采用怎样的机制对LOH的对象进行回收。 到目前为止对于LOH和GC堆中的对象除了大小之外我们好像没有觉得它们之间有何不同。实际上将大对象放在LOH中目的在于对其实施特殊的回收机制。关于垃圾收回我们应该有这样的认知回收的成本是和对象的大小基本成“正向”关系对象越大回收成本就越大。所以我们不能对大对象频繁地实施垃圾回收实际上CLR是将LOH对象当成最高代龄的对象。也就是说针对LOH的回收工作是和GC堆中G2一并进行的。换句话说当G2或者LOH的剩余空间低于某个限度针对它们的垃圾回收便被触发。关于LOH的垃圾回收机制我们可以通过一个非常简单的程序来验证。 1: class Program 2: { 3: static WeakReference SmallObjRef; 4: static WeakReference LargeObjRef; 5: 6: static void Main(string[] args) 7: { 8: SetValues(); 9: GC.Collect(0); 10: Console.WriteLine(GC.Collect(0)); 11: Console.WriteLine(SmallObjRef.Target null? {0}, SmallObjRef.Target null); 12: Console.WriteLine(LargeObjRef.Target null? {0}\n, LargeObjRef.Target null); 13: 14: GC.Collect(1); 15: Console.WriteLine(GC.Collect(1)); 16: Console.WriteLine(LargeObjRef.Target null? {0}\n, LargeObjRef.Target null); 17: 18: GC.Collect(2); 19: Console.WriteLine(GC.Collect(2)); 20: Console.WriteLine(LargeObjRef.Target null? {0}\n, LargeObjRef.Target null); 21: } 22: 23: static void SetValues() 24: { 25: SmallObjRef new WeakReference(new byte[84000]); 26: LargeObjRef new WeakReference(new byte[85000]); 27: } 28: } 输出结果 1: GC.Collect(0) 2: SmallObjRef.Target null? True 3: LargeObjRef.Target null? False 4: 5: GC.Collect(1) 6: LargeObjRef.Target null? False 7: 8: GC.Collect(2) 9: LargeObjRef.Target null? True 在上面的代码中没我创建了两个WeakReference对象它们的Target分别被设置成byte[84000]和byte[85000]。按照我们上面关于对“大对象”的界定后者是大对象前者不是。然后我们先后三次对G0、G1和G2实施垃圾回收我们发现“小对象”在实施针对G0的垃圾回收后就没了而“大对象”会一直存活直到针对G2的垃圾回收被执行。 关于CLR内存管理一些深层次的讨论[上篇]关于CLR内存管理一些深层次的讨论[下篇] 作者蒋金楠 微信公众账号大内老A 微博www.weibo.com/artech 如果你想及时得到个人撰写文章以及著作的消息推送或者想看看个人推荐的技术资料可以扫描左边二维码或者长按识别二维码关注个人公众号。 本文版权归作者和博客园共有欢迎转载但未经作者同意必须保留此段声明且在文章页面明显位置给出原文连接否则保留追究法律责任的权利。
