和我一起作Tess的windbg lab - Lab3, Memory

原文地址：http://blogs.msdn.com/b/tess/archive/2008/02/15/net-debugging-demos-lab-3-memory.aspx

操作步骤：

1、产生压力：tinyget -srv:localhost -uri:/BuggyBits/Links.aspx -loop:4000

2、观察taskmgr的输出，w3wp的内存每秒钟大概增长100M。

3、内存到700M左右的时候，抓一个hang dump

4、由于这是一个memory的问题，所以我们要先看GC Heap的情况，运行命令：!eeheap -gc，结果如下：

　　GC Heap Size  0x2b307720(724596512)

　　由于dump一共870M，而GC占用了720M左右，所以我们的重点在于托管内存的分析。

5、看heap的整体状况，运行!dumpheap -stat，结果如下：

　　790fd8c4    49787    721599752 System.String

　　嗯，720M的托管内存中，String占用了绝大多数。

6、看一下string的情况，根据2/8原则，大小相同的string也许会很多，这里我们过滤一下，看看10K以上大小的字符串，运行命令：!dumpheap -mt 790fd8c4  -min 10000

　　0331d6dc 790fd8c4    20020    
　　03322534 790fd8c4    20020    
　　0332738c 790fd8c4    20020    
　　0332c1e4 790fd8c4    20020    
　　0333103c 790fd8c4    20020    

　　大部分都是20K的字符串，随便找一个，我们需要看它被谁分配的

7、运行!gcroot 0331d6dc，结果如下：

　　Scan Thread 16 OSTHread 318
　　Scan Thread 18 OSTHread c38
　　Scan Thread 19 OSTHread a40
　　Scan Thread 20 OSTHread c00
　　Scan Thread 24 OSTHread 998
　　Scan Thread 14 OSTHread 4cc
　　Finalizer queue:Root:0331d6b8(Link)->
　　0331d6c8(System.Text.StringBuilder)->
　　0331d6dc(System.String)

　　在14号线程中，Link引用了这个字符串。而且我们看到，link是在Finalizer Queue中的。

8、查看finalizequeue，输出如下：

　　057e0bcc    35998       575968 Link

　　一共35998个Link对象。由于该对象存在于Finalizequeue中，所以一定显示的实现了Finalize方法。

9、查看该方法，代码如下：

　　~Link()
　　{
      　　//some long running operation when cleaning up the data
      　　Thread.Sleep(5000);
　　}

10、换个方向，看上面步骤7中的那个Link对象，!do 0331d6b8，输出结果如下：

      　　MT    Field   Offset                 Type VT     Attr    Value Name
　　790fdc5c  4000006        4 ...ext.StringBuilder  0 instance 0331d6c8 url
　　790fd8c4  4000007        8        System.String  0 instance 029bb0b8 name
　　再看第一个url对象，运行!do 0331d6c8 ，结果如下：

　　      MT    Field   Offset                 Type VT     Attr    Value Name
　　791016bc  40000b1        8        System.IntPtr  1 instance    dc1d8 m_currentThread
　　79102290  40000b2        c         System.Int32  1 instance 2147483647 m_MaxCapacity
　　790fd8c4  40000b3        4        System.String  0 instance 0331d6dc m_StringValue

　　注意最后一行的那个m_StringValue，对比一下步骤7中的!gcroot输入。

　　从这里我们看到，Link中包含了一个StringBuilder，而StringBuilder中包含了一个20K的字符串。

11、看代码：

　　public Link(string name, string url)
    　　{
        　　this.name = name;
        　　this.url.Append(url);
    　　}
　　可以看到，Link对象的构造方法中，引用了字符串。

12、再回头看上面的步骤9，Link自作聪明的实现了Finalize方法，但是该方法执行的时间太长（这里是5秒钟），导致垃圾回收的时候，迟迟不能把该对象回收掉。因为Link引用了字符串url，所以相应的字符串也无法被回收。这样内存就上涨的很快了。

 

Over