当我执行AppDomain.Unload(myDomain)时,我希望它也会执行完整的垃圾收集。
根据杰弗里·里希特在"CLR via C#“中的说法,他在AppDomain.Unload中说:
CLR强制执行垃圾回收,回收由现在已卸载的AppDomain创建的任何对象所使用的内存。这些对象的Finalize方法将被调用,从而使这些对象有机会正确地自我清理。
根据“定制.NET框架公共语言运行时”中的"Steven Pratschner“:
在所有终结器都已运行并且域中不再有线程在执行之后,CLR准备卸载内部实现中使用的所有内存中的数据结构。但是,在此之前,必须收集驻留在域中的对象。在下一次垃圾收集发生后,应用程序域数据结构将从进程地址空间中卸载,并且该域被视为已卸载。
我是不是误解了他们的话?我执行了以下解决方案来重现意外行为(在.net 2.0 sp2中):
一个名为"Interfaces“的类库项目,其中包含以下接口:
public interface IXmlClass
{
void AllocateMemory(int size);
void Collect();
}
一个名为"ClassLibrary1“的类库项目,它引用了”接口“,并包含这样的类:
public class XmlClass : MarshalByRefObject, IXmlClass
{
private byte[] b;
public void AllocateMemory(int size)
{
this.b = new byte[size];
}
public void Collect()
{
Console.WriteLine("Call explicit GC.Collect() in " + AppDomain.CurrentDomain.FriendlyName + " Collect() method");
GC.Collect();
Console.WriteLine("Number of collections: Gen0:{0} Gen1:{1} Gen2:{2}", GC.CollectionCount(0), GC.CollectionCount(1), GC.CollectionCount(2));
}
~XmlClass()
{
Console.WriteLine("Finalizing in AppDomain {0}", AppDomain.CurrentDomain.FriendlyName);
}
}
一个引用"Interfaces“项目并执行以下逻辑的控制台应用程序项目:
static void Main(string[] args)
{
AssemblyName an = AssemblyName.GetAssemblyName("ClassLibrary1.dll");
AppDomain appDomain2 = AppDomain.CreateDomain("MyDomain", null, AppDomain.CurrentDomain.SetupInformation);
IXmlClass c1 = (IXmlClass)appDomain2.CreateInstanceAndUnwrap(an.FullName, "ClassLibrary1.XmlClass");
Console.WriteLine("Loaded Domain {0}", appDomain2.FriendlyName);
int tenmb = 1024 * 10000;
c1.AllocateMemory(tenmb);
Console.WriteLine("Number of collections: Gen0:{0} Gen1:{1} Gen2:{2}", GC.CollectionCount(0), GC.CollectionCount(1), GC.CollectionCount(2));
c1.Collect();
Console.WriteLine("Unloaded Domain{0}", appDomain2.FriendlyName);
AppDomain.Unload(appDomain2);
Console.WriteLine("Number of collections after unloading appdomain: Gen0:{0} Gen1:{1} Gen2:{2}", GC.CollectionCount(0), GC.CollectionCount(1), GC.CollectionCount(2));
Console.WriteLine("Perform explicit GC.Collect() in Default Domain");
GC.Collect();
Console.WriteLine("Number of collections: Gen0:{0} Gen1:{1} Gen2:{2}", GC.CollectionCount(0), GC.CollectionCount(1), GC.CollectionCount(2));
Console.ReadKey();
}
运行控制台应用程序时的输出为:
Loaded Domain MyDomain
Number of collections: Gen0:0 Gen1:0 Gen2:0
Call explicit GC.Collect() in MyDomain Collect() method
Number of collections: Gen0:1 Gen1:1 Gen2:1
Unloaded Domain MyDomain
Finalizing in AppDomain MyDomain
Number of collections after unloading appdomain: Gen0:1 Gen1:1 Gen2:1
Perform explicit GC.Collect() in Default Domain
Number of collections: Gen0:2 Gen1:2 Gen2:2
注意事项:
其他注意事项: XmlClass是否可终结化并不重要。在上面的示例中也出现了相同的行为。
问题:
发布于 2010-04-29 15:19:58
其他注意事项:
在与Jeffrey Richter进行了一些邮件交流后,他很友好地看了一下这个问题:
好的,我读了你的帖子。
首先,在对XMLClass对象进行GC之前,不会对该数组进行GC,并且需要两个GC来收集该对象,因为它包含一个Finalize方法。
其次,卸载appdomain至少会执行GC的标记阶段,因为这是确定哪些对象不可访问的唯一方法,以便可以调用它们的Finalize方法。
但是,GC的紧凑部分可能会在卸载GC时完成,也可能不会完成。调用GC.CollectionCount obvious并不能说明全部情况。这并不表明GC标记阶段确实发生了。
而且,AppDomain.Unload可能会通过一些内部代码启动GC,这不会导致集合计数变量递增。我们已经知道了一个事实,即正在执行标记阶段,并且集合计数没有反映这一点。更好的测试方法是查看调试器中的一些对象地址,看看是否确实发生了压缩。如果是这样的话(我怀疑是这样),那么集合计数就是没有被正确更新。如果你想把这个作为我的回复发布到网站上,你可以这样做。
在接受了他的建议并研究了SOS (也删除了finalizer)之后,它揭示了这一点:
在AppDomain.Unload之前:
!EEHeap -gc
Number of GC Heaps: 1
generation 0 starts at 0x0180b1f0
generation 1 starts at 0x017d100c
generation 2 starts at 0x017d1000
ephemeral segment allocation context: none
segment begin allocated size
017d0000 017d1000 01811ff4 0x00040ff4(266228)
Large object heap starts at 0x027d1000
segment begin allocated size
027d0000 027d1000 02f75470 0x007a4470(8012912)
Total Size 0x7e5464(8279140)
------------------------------
GC Heap Size 0x7e5464(8279140)
在AppDomain.Unload之后(相同的地址,没有进行堆压缩)
!EEHeap -gc
Number of GC Heaps: 1
generation 0 starts at 0x0180b1f0
generation 1 starts at 0x017d100c
generation 2 starts at 0x017d1000
ephemeral segment allocation context: none
segment begin allocated size
017d0000 017d1000 01811ff4 0x00040ff4(266228)
Large object heap starts at 0x027d1000
segment begin allocated size
027d0000 027d1000 02f75470 0x007a4470(8012912)
Total Size 0x7e5464(8279140)
------------------------------
GC Heap Size 0x7e5464(8279140)
在GC.Collect()之后,不同的地址表示堆压缩已经完成。
!EEHeap -gc
Number of GC Heaps: 1
generation 0 starts at 0x01811234
generation 1 starts at 0x0180b1f0
generation 2 starts at 0x017d1000
ephemeral segment allocation context: none
segment begin allocated size
017d0000 017d1000 01811ff4 0x00040ff4(266228)
Large object heap starts at 0x027d1000
segment begin allocated size
027d0000 027d1000 027d3240 0x00002240(8768)
Total Size 0x43234(274996)
------------------------------
GC Heap Size 0x43234(274996)
在更多的sos之后,我得出的结论是,它肯定是设计出来的,堆压缩不是必须完成的。在AppDomain卸载期间,您唯一可以真正确定的是对象将被标记为不可访问,并将在下一次垃圾收集期间被收集(就像我说过的,除非巧合,否则在卸载应用程序域时不会准确地进行垃圾回收)。
编辑:我也问过毛尼·斯蒂芬斯,他直接在GC团队工作。你可以在评论here的某个地方读到她的回复。她证实这是设计出来的。案例结案:)
发布于 2010-04-28 02:05:08
更明智的做法是重新审视您的体系结构,而不是专注于扮演垃圾收集器的角色。
https://stackoverflow.com/questions/2723579
复制相似问题