• 和我一起作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

  • 相关阅读:
    Easy File Sharing Web Server 7.2
    我的安全之路——二进制与逆向篇
    下拉滚动,导航条悬停在顶部
    Java-json对象转Map
    Java-验证码生成(数字+字母)
    Java-List分页工具
    HDU-1556-Color the ball (线段树和差分数组两种解法)
    牛客练习赛34-C-little w and Segment Coverage(差分数组)
    牛客练习赛34-C-little w and Segment Coverage(差分数组)
    差分数组原理及应用
  • 原文地址:https://www.cnblogs.com/juqiang/p/1766143.html
Copyright © 2020-2023  润新知