[ASP.NET Debugging BuggyBits读书笔记] Lab03 Memory

1. 打开Performance Monitor。在Counter Logs里添加New Log Settings，命名为Lab3-Mem。添加的Log对象为.NET CLR Memory和Process。

2. 使用TinyGet执行命令个 tinyget –srv:localhost –uri:/buggybits/links.aspx –loop:4000

3. 命令执行以后，可以看到w3wp.exe进程的大小持续增长，并且在tinyeget命令结束以后，程序所站大小仍然不减：

4. 等待一段时间以后，在Performance monitor里面打开刚才存储的日志，添加Process对象的Virtual bytes计数器，添加.NET CLR Memory对象的Bytes in all Heaps计数器，将他们的scale调整为0.00000001：

可见随着Bytes in All heaps(青色)的增长，进程的virtual bytes(白色)也在增长。因此可以判定是.NET进程的heap的增长带来了内存消耗的增长，并且内存增长之后没有回收。

5.  切换到WinDbg目录在命令行执行 adplus –hang –pn w3wp.exe –quiet 注意此时应该将应用程序池的各种Recycle选项全部关闭。否则可能因为抓取时间太长，w3wp.exe进程关闭，hang dump抓取失败。

6. 使用WinDbg打开刚才得到的dump文件。执行 .loadby sos.dll mscorwks

7. 执行 !eeheap -gc查看GC的情况，可见有一个heap，因为是单核。如果是双核，则会有两个heap。Heap大小为700多兆，可见是heap出问题了。

8. 执行 !dumpheap –stat:

可见System.String占据了大部分的内存空间。

9. 执行 !dumpheap –type Link并终止输出。找到其中一个object的地址02eab13c，执行 !do 02eab13c：可以发现Stringbuilder和System.String都是包含在Link类型中的类型。

这就解释了!dumpheap –stat中看到的占据heap最多的对象的类型的内存占用情况。

10. 执行 !dumpheap –type System.String 并强行终止输出。以其中一个对象的地址 027da238为例，执行 !do 027da238，可以找到这个string对象存储的值。

11. 为了找到为什么该对象没有被回收，查看哪些线程对它还有root，因此执行命令 !gcroot 027da238:

可见Finalizer queue对其有引用，因此可以推断Finalizer queue还没有对这个对象执行Finalize方法。

12. 执行 !threads找到Finalize queue的线程是 17：

13. 执行 ~17s切换到该线程。执行 !clrstack:

可见这就是Finalize queue上对该对象的root一直保持着的原因：线程休眠了。

14. 在App_Code文件夹里找到哦啊Link.cs:

可见该对象规定了Finalize方法，因此会被放到Finalize queue上去。而这个方法里面，导致执行该方法的Finalize线程休眠了，所以对象一直有引用，内存得不到释放。