垃圾回收时发生的一个诡异问题

2012-03-14
浏览
导读:前些天在论坛里看到了一篇帖子垃圾收集问题是不是bug其问题如下: static tc gto; public class tc { public int a=99; ~tc() { a=-1; //set breakpoint 1 gto=

前些天在论坛里看到了一篇帖子垃圾收集问题——是不是bug其问题如下:

static tc gto;
public class tc
{
public int a=99;
~tc()
{
a=-1; //set breakpoint 1
gto=this;
}
}
private void button1_Click(object sender,EventArgs e)
{
tc to=new tc();
GC.Collect();
GC.WaitForPendingFinalizers();
return; // set breakpoint 2
}
two problems:
click button once,it seem the ~tc() not execute at all.and it will excute at the second time clicking.why?
the second clicking,breakpoint 2, "gto" and "to", gto.a=-1,while to.a=99,why?

问题很好解答第一次强制回收的时候并不能回收局部变量to,只有下次点击的时候才会回收上次产生的tc对象所以~tc()没有立即执行。而第二个问题是因为在析构函数中将对象的a置为-1并将引用赋值给了一个全局对象所以gto.a=-1,而新new出的来的tc对象a自然为99.我本来对第一个问题的解答信心满满,但当我正要回答问题时我看到了gomoku 的回复,他说到:

1,在调试时,Visual Studio提供了显示即时值的功能,比如让你的breakpoint 2的地方,能够检查tc的值。

要检查tc的值,这就要求tc不能被垃圾回收,为此Visual Studio调试器插入了特殊代码以保证tc在离开button1_Click()以前不会被回收。

2,Release版就不同了。你把例子用Release编译运行,就会发现,同Debug相反,~tc()在第一次GC.Collect时就被调用了。

我立刻动手进行试验,发现release下果然如gomoku所说我不免对自己的理解有所怀疑。因为我深信这肯定和vs的断点无关,而且msdn,.net书籍,国内外技术文章在讲解垃圾回收原理时都是这么解释的”一开始gc把托管堆上的对象都视为可回收的,然后从应用程序的一组根出发寻找可达对象,不可达的对象则被回收。由JIT编译器和CLR运行时维护根指针列表,主要包括全局变量、静态变量、局部变量和寄存器指针等“所以我认为即使在release下也因该和debug下表现相同,除非release下有优化操作根本就不会保存这个局部变量。所以我马上看debug和release两个版本的IL

debug:

IL_0000: nop
IL_0001: newobj tc::.ctor
IL_0006: stloc.0
IL_0007: call System.GC::Collect
IL_000c: nop
IL_000d: call System.GC::WaitForPendingFinalizers
IL_0012: nop
IL_0013: br.s IL_0015
IL_0015: ret

release:

ilAddr = 01394590
IL_0000: newobj tc::.ctor
IL_0005: pop
IL_0006: call System.GC::Collect
IL_000b: call System.GC::WaitForPendingFinalizers
IL_0010: ret

SSH笔记三 反向生成DAO 优化开发目录

SSH笔记四 整合struts2

SSH笔记五 整合Tiles2

一个Java记事本的源程序

网页Applet录音机的制作