try...catch...finally中的finally一定会执行吗？

在windows中，每个线程默认的栈大小是1M，托管线程也一样。在32位windows中，用C#在系统中最多可以创建多少个线程呢？答案稍后说。

大家都知道try...catch...finally是用来控制异常的流转，一般说来finally是最后一班岗哨，问100个人，99个肯定说一定会执行。是的，一般来讲确实是能执行到的，原因是什么呢？比如在try或catch里return之后为什么还能执行到finally呢？答案是因为return只是把返回值放入相应的地方（一般来讲是寄存器），准备返回；在一个函数返回之前，也就是ret指令调用之前，还有一些代码需要执行，就是清空堆栈（弹出入栈的压入的参数，函数的首地址等），这和函数的调用方式stdcal有关。那么finally有没有机会不执行呢？看代码：

  1     static  void Foo()
 2     {
 3         Foo();
 4     }
 5 
 6     static void Main()
 7     {
 8         int i=0;
 9         try
10         {
11             Foo();   
12         }
13         catch(Exception ex)
14         {
15             ;
16         }
17         finally
18         {
19             i = 2;
20         }
21         
22     }

这个递归调用会造成System.StackOverflowException,但是我下面有catch啊？为什么就直接程序直接就结束了呢？

下面用windbg调试一下：

大家可以看到起始的时候esp是在0012fb70，ebp是在0012fcb4；而异常发生的时候esp在00033000，而ebp在0012f480可以发现两个问题：

1.0012fb70-00033000=fcb70（十进制是1035120>1MB），所以溢出了

2.栈是向上增长的，逆着内存地址增长的顺序，所以esp会不停的减小，而ebp在esp下面固定每一次方法调用的基地址。但是这个时候ebp已经是0012f480了，超过了进入Foo之前的esp的地址，溢出了，所以回到了栈底。

这个时候callstack已经完全回不去了，也就是说方法链不能依着原来的路径返回到调用方法之外，就出现了无法恢复的异常，CLR直接把主线程给kill了，结果进程就退出了。

换段代码：

这个代码里的finally是可以运行的，因为溢出的不是主线程的堆栈，所以kill了也没事。但是同样会抛出System.StackOverflowException异常。 当然，可以通过参数来控制线程最大堆栈大小。可以通过一些tool来观察这些线程的活动，由于时间有限，我就不做了，赶紧洗洗上班去。最后公布答案：用C#创建用户级的线程（如果你非得较真用P/V Invoke来创建内核级线程，我无话可说，也不要用boot.ini /3GB）极限是2048个（往往到不了这个数），因为32系统只有2G内存用于用户态程序，而每个线程默认的栈大小是1M，所以2G/1M=2048个，大家可以运行下面的代码测试一下：

这段代码来自jeff的一个presentation。在我的机器上运行的是：

不对之处，欢迎大家指正。