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

前些天在论坛里看到了一篇帖子垃圾收集问题——是不是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

我们看到debug和release有明显的区别，debug下有IL_0006: stloc.0 指令而release下载new完tc后直接就pop了。ok有了il垫底只要再看jitted后的机器汇编就能确定msdn上说的确实没错，不过 …… 郁闷的事情发生了。从vs中看debug和release的反汇编基本没有区别栈上都保存了局部变量to的值。想了半天才换然大悟gomoku的回复中说了vs为了调试方便给反汇编中加了一些代码所以我看到的debug和release下是一样的。

好了后面的事情就简单了，就是一个搜集证据的过程。不过更郁闷的事情发生了，我用了2天时间才弄白windbg怎么获得release下方法的jitted后汇编（真理真是很难被验证的，为了证明一个真理你需要多付出几倍甚至与几十倍的代价来揭穿谎言和谬误，当然我不是说gomoku说的是谬误只是并没有说到问题的关键点上），这里我特别要感谢lbq的文章和cici对我的指导。

debug下主要反汇编：

mov dword ptr [ebp-10h],eax //new出来的对象地址
mov ecx,dword ptr [ebp-10h]
call dword ptr ds:[806DE8h] (Test_WinForm.GC_Test+tc..ctor(), mdToken: 0600004f)
mov eax,dword ptr [ebp-10h]
mov dword ptr [ebp-0Ch],eax //在栈上保存对象地址
call mscorlib_ni+0x6b7bcc (6c6a7bcc) (System.GC.Collect(), mdToken: 06000ab8) //强制垃圾回收
nop
call mscorwks!GCInterface::RunFinalizers (6cbe3491)

release下反汇编：

mov ebp,esp
mov ecx,7D6714h (MT: Test_WinForm.GC_Test+tc)
call mscorwks!JIT_NewFast (6cafc5d4) //new tc()
mov dword ptr [eax+4],63h //将99复制给对象地址+4（这里就是a的位置），相当于构造函数
xor edx,edx
lea ecx,[edx-1]
call mscorwks!GCInterface::CollectGeneration (6cbbd082)
call mscorwks!GCInterface::RunFinalizers (6cbe3491)
pop ebp
ret 4

在这里要说明一点，虽然在强制调用gc前EAX中保存了tc的对象地址，但因为EAX这个寄存器只是方法调用后返回值的所以不能确保在这个寄存器的值不会被替换掉（通过跟踪GCInterface::CollectGeneration发现该函数一开始就把eax中的值替换掉了）。既然明白了垃圾回收时确定可达对象的原理我们就可以做一个小小的实验了，在强制垃圾后面加入这条语句：

private void button1_Click(object sender,EventArgs e)
{
tc to=new tc();
GC.Collect();
GC.WaitForPendingFinalizers();

string s = tc.ToString();
return;

}

这时在release下运行其运行结果就和debug下一样了必须要点击第二次才会执行析构函数，让我们再看看此时的反汇编：

mov ebp,esp
push esi
mov ecx,7D6714h (MT: Test_WinForm.GC_Test+tc)
call mscorwks!JIT_NewFast (6cafc5d4)
mov esi,eax //将对象地址赋值给esi
mov dword ptr [esi+4],63h
xor edx,edx
lea ecx,[edx-1]
call mscorwks!GCInterface::CollectGeneration (6cbbd082)
call mscorwks!GCInterface::RunFinalizers (6cbe3491)
mov ecx,esi //将保存在esi中的值返回个ecx
mov eax,dword ptr [ecx]
call dword ptr [eax+28h] //调用ToString()
pop esi
pop ebp
ret 4
我跟踪了整个gc函数发现虽然在函数体内替换了esi的值但是函数结束后esi的值被恢复了而eax的值是不会被恢复的，现在还不明白原理。实际上本文没有什么特别的东西只是证明了一下gc理论和jit优化的能力。