WinDbg初始体验3，剪不断的铁链(OutOfMemory案例分析Ⅱ)

铁链总是很难剪断的，.NET的对象引用链条就犹如铁链那么坚固。稍有不注意，你就会因为这个链条而让你的程序背上沉重的负担，进而让你的程序Crash。接下来我们就结合WinDbg来分析一个这样的例子。

上回说到，解决了Lucene.net的缓存问题后，内存依久就是如洪水水位一样，无情的暴涨，马上又到了警戒水位了，没有办法，只有炸堤防洪。要得彻底的解决问题，还得依靠Windbg和dump文件。这回，我捕捉到一个也将近1G左右的dump文件。好吧，让我们重新开始吧。查看拖管堆：

0:011> !eeheap -gc
PDB symbol for mscorwks.dll not loaded
Number of GC Heaps: 4
------------------------------
Heap 0 (000e22d0)
generation 0 starts at 0x473a8500
generation 1 starts at 0x4738941c
generation 2 starts at 0x02860038
ephemeral segment allocation context: none
 segment    begin allocated     size
1b84dc60 7b45382c  7b46a268 0x00016a3c(92732)
000f66d8 7a72c42c  7a74d308 0x00020edc(134876)
000eaef0 790d5588  790f4b38 0x0001f5b0(128432)
02860000 02860038  0685cc24 0x03ffcbec(67095532)
30000000 30000038  33ffe93c 0x03ffe904(67102980)
44350000 44350038  475e4afc 0x03294ac4(53037764)
Large object heap starts at 0x12860038
 segment    begin allocated     size
12860000 12860038  144620a8 0x01c02070(29368432)
1fc00000 1fc00038  1fe659b0 0x00265978(2513272)
50fc0000 50fc0038  5178d060 0x007cd028(8179752)
Heap Size  0xd91b88c(227653772)
------------------------------
Heap 1 (000e3538)
generation 0 starts at 0x6e30f94c
generation 1 starts at 0x6e2dad60
generation 2 starts at 0x06860038
ephemeral segment allocation context: none
 segment    begin allocated     size
06860000 06860038  0a85ff64 0x03ffff2c(67108652)
22000000 22000038  25ffffe0 0x03ffffa8(67108776)
38350000 38350038  3c33b76c 0x03feb734(67024692)
6d110000 6d110038  6e4fa678 0x013ea640(20883008)
Large object heap starts at 0x14860038
 segment    begin allocated     size
14860000 14860038  1489a178 0x0003a140(237888)
Heap Size  0xd40fd88(222363016)
------------------------------
Heap 2 (000e4a48)
generation 0 starts at 0x441e9d28
generation 1 starts at 0x441d3978
generation 2 starts at 0x0a860038
ephemeral segment allocation context: none
 segment    begin allocated     size
0a860000 0a860038  0e85fb00 0x03fffac8(67107528)
2a000000 2a000038  2dffd6a4 0x03ffd66c(67098220)
40350000 40350038  441f5d34 0x03ea5cfc(65690876)
Large object heap starts at 0x16860038
 segment    begin allocated     size
16860000 16860038  16860048 0x00000010(16)
Heap Size  0xbea2e40(199896640)
------------------------------
Heap 3 (000e5f30)
generation 0 starts at 0x40224450
generation 1 starts at 0x401e7bcc
generation 2 starts at 0x0e860038
ephemeral segment allocation context: none
 segment    begin allocated     size
0e860000 0e860038  1285f4b8 0x03fff480(67105920)
26000000 26000038  29ffeee0 0x03ffeea8(67104424)
3c350000 3c350038  4022445c 0x03ed4424(65881124)
Large object heap starts at 0x18860038
 segment    begin allocated     size
18860000 18860038  18b13eb0 0x002b3e78(2834040)
Heap Size  0xc1865c4(202925508)
------------------------------
GC Heap Size  0x32d54a18(852838936)

从拖管堆的大小（800多M）可以看出，大部分的内存还是被拖管堆给占用了。而且我们还可以看到以前一个情节不同的是，这回，大对象并不是很多。我们可以从下面的命令得到验证：

0:011> !dumpheap -min 85000
------------------------------
Heap 0
 Address       MT     Size
473ac50c 000e1888  1400656 Free
4750491c 000e1888   916416 Free
12881370 000e1888  1019752 Free
1297a718 7912254c   118160    
129974a8 000e1888   411144 Free
129fbab0 79122610   121248    
12a19460 79122610  4672296    
12e8df88 79122610  4672296    
13303ce0 000e1888   453440 Free
13373820 000e1888   449360 Free
133e29d0 000e1888  2834040 Free
13696a58 000e1888  3287480 Free
139b9620 000e1888  4480064 Free
13dff470 000e1888  3294072 Free
141239f8 000e1888  3400864 Free
1fc00038 000e1888   513424 Free
1fc7d9f8 000e1888   906888 Free
1fd5b080 7912254c   124488    
1fd796c8 000e1888   966872 Free
50fc0038 000e1888  8055264 Free
5176ea18 7912254c   124488    
total 21 objects
------------------------------
Heap 1
 Address       MT     Size
6e317958 000e1888  1976064 Free
14860048 000e1888   113384 Free
1487bb30 7912254c   124488    
total 3 objects
------------------------------
Heap 2
 Address       MT     Size
total 0 objects
------------------------------
Heap 3
 Address       MT     Size
18860048 000e1888  2720656 Free
18af83d8 7912273c   113368    
total 2 objects
------------------------------
total 26 objects
Statistics:
      MT    Count    TotalSize Class Name
7912273c        1       113368 System.Byte[]
7912254c        4       491624 System.Object[]
79122610        3      9465840 System.Collections.Hashtable+bucket[]
000e1888       18     37199840      Free
Total 26 objects

大对象（大于85000 bytes）的数量并不多，共有26个对象，而且还有18是已释放的。看来，从大对象找不到我们想要的结果。那我们就查看小一个等级的对象，看一下小于8500的对象都有哪些？

0:011> !dumpheap -min 8500
------------------------------
Heap 0
 Address       MT     Size
790da154 790f9244     9280    
0287c318 790f9244    16404    
028804d4 790f9244    16404    
02884f18 790f9244    32788    
02aec324 7912273c     9604    
02b1dffc 790f9244    16404    
02b22be8 790f9244    32788    
03038134 79122610    13248    
0323006c 7912273c    11616    
0586a068 7912254c    17904    
3090bd60 7912273c    14836    
30adaffc 7912273c    54188    
31fc6d04 7912273c    25728    
32954478 79122610    28008    
33f4296c 790f9244    16404    
33f47558 790f9244    32788    
44581a38 790f9244    16404    
44586624 790f9244    32788    
4461668c 79122610    28008    
44dad90c 790f9244    16404    
44db1ac8 790f9244    16404    
44db650c 790f9244    32788    
44dd90f8 790f9244    16404    
44dddce4 790f9244    32788    
44df4004 790f9244    16404    
44df81c0 790f9244    16404

......

3f028880 790f9244    16404    
3f02d46c 790f9244    32788    
3f182a1c 790f9244    16404    
3f187608 790f9244    32788    
3f1fd1dc 790f9244    16404    
3f201dc8 790f9244    32788    
3f25cef8 790f9244    16404    
3f261ae4 790f9244    32788    
3f2f36c8 790f9244    16404    
3f2f82b4 790f9244    32788    
3f7a87a8 7912254c    28204    
4001eca4 000e1888     8760 Free
401d399c 790f9244    21988    
18860048 000e1888  2720656 Free
18af83d8 7912273c   113368    
total 111 objects
------------------------------
total 400 objects
Statistics:
      MT    Count    TotalSize Class Name
79122868        1        22676 System.Int64[]
02803518        1        30908 System.Collections.Generic.Dictionary`2+Entry[[System.String, mscorlib],[System.Web.Configuration.AuthorizationSection, System.Web]][]
7912273c       17       484412 System.Byte[]
7912254c       14       707912 System.Object[]
790f9244      330      8062572 System.String
79122610       14      9715704 System.Collections.Hashtable+bucket[]
000e1888       23     37249276      Free
Total 400 objects

好的，共找到400个对象，这时我们看到一个好现象，那就是对象的大小都是有规律的，有规律就好办事。我还想看看这些都是些什么对象？

0:011> !dumpheap  -stat
------------------------------
Heap 0
total 3617074 objects
------------------------------
Heap 1
total 4237968 objects
------------------------------
Heap 2
total 3868413 objects
------------------------------
Heap 3
total 3860949 objects
------------------------------
total 15584404 objects
Statistics:
      MT    Count    TotalSize Class Name
7ae7d438        1           12 System.Drawing.ColorConverter
......看数量多的

1cfb3180    33572      1074304 System.EventHandler`1[[NBear.Web.Data.NBearDataSourceEventArgs, NBear.Web.Data]]
66408158    16788      1074432 System.Web.UI.HtmlControls.HtmlLink
1c21a8b4    10418      1083472 Shop.Code.Controls.InitQSCheckBox
663a2e58     5599      1097404 System.Web.HttpResponse
1cb989d4    11192      1119200 SoF.Web.Controls.AjaxExtender.NameValueAutoComplete
1cfb2504     5596      1141584 ASP.default_master
1c21bff4    15627      1187652 Shop.Code.Controls.InitQSTextBox
648f09f4    25240      1211520 System.Configuration.ConfigurationValues
663e20a4    21658      1386112 System.Web.UI.HtmlControls.HtmlMeta
1c6c2074     3362      1425488 ASP.product_sortproductlist_aspx
663a6f84     5599      1433344 System.Web.Hosting.ISAPIWorkerRequestInProcForIIS6
6638e588    19015      1445140 System.Web.Configuration.HttpHandlerAction
648f1150    40166      1445976 System.Configuration.ConfigurationLockCollection
7a74db74    72771      1455420 System.ComponentModel.EventHandlerList+ListEntry
663b8af4    47082      1506624 System.Web.UI.RenderMethod
663c8014   127279      1527348 System.Web.UI.CompiledTemplateBuilder
1cb9b2c4     5595      1566600 SoF.Web.Controls.DataControlPagerExtender
791293b4    68360      1640640 System.Collections.Generic.List`1[[System.String, mscorlib]]
7a74da98   109651      1754416 System.ComponentModel.EventHandlerList
663b9534    47083      2071652 System.Web.UI.Control+ControlRareFields
663b835c    32902      2105728 System.Web.UI.HtmlControls.HtmlGenericControl
648f0e74   106655      2133100 System.Configuration.ConfigurationValue
1c6cc8ec    68160      2181120 NBear.Common.Entity+QueryProxyHandler
1c6cc7cc    68160      2181120 NBear.Common.Entity+PropertyChangedHandler
6641160c    78330      2193240 System.Web.UI.WebControls.ListItem
663b631c    39171      2193576 System.Web.UI.WebControls.ContentPlaceHolder
7912273c    10349      2333704 System.Byte[]
663daa3c   127788      2555760 System.Web.UI.ScriptKey
1d4295f4    80531      2576992 Lucene.Net.Documents.Field
663b6f88   162409      2598544 System.Web.UI.AttributeCollection
7910c0f4    83555      2673760 System.EventHandler
6639b014   139791      2795820 System.Web.VirtualPath
663bd1f8    78022      2808792 System.Web.UI.DataSourceSelectArguments
1d38c240   179183      2881432 KTDictSeg.T_INNER_POS[]
1c1f2f44    27975      2909400 *.DataSources.HelpDataSources
653ba904    68162      3544424 System.Collections.Generic.Dictionary`2[[System.String, mscorlib],[System.Object, mscorlib]]
1cf424dc    30282      3633840 System.Web.UI.WebControls.SoFRepeater
790fdb60   336963      4043556 System.Int32
6640f3ec   127279      4072928 System.Web.UI.BuildTemplateMethod
79122414    40873      4332792 System.Int32[]
663ca710    42532      4423328 System.Web.UI.WebControls.Repeater
66410058   327377      5238032 System.Web.UI.StateBag
790fd8b4    94095      5269320 System.Collections.Hashtable
663dabb0   269441      6466584 System.Web.HttpServerVarsCollectionEntry
02805218   136320      7088640 System.Collections.Generic.Dictionary`2[[System.String, mscorlib],[System.Collections.Generic.List`1[[System.Object, mscorlib]], mscorlib]]
7910234c   312379      7497096 System.Collections.ArrayList
7a7603a4   475247      7603952 System.Collections.Specialized.NameObjectCollectionBase+NameObjectEntry
1d38c17c   308770      8645560 FTAlgorithm.T_DfaUnit
7a752890   470437      9408740 System.Collections.Specialized.HybridDictionary
663c4b3c   629654     10074464 System.Web.UI.StateItem
7a752968   360636     10097808 System.Collections.Specialized.ListDictionary
1bd4e58c    63806     13016424 *.Entities.SimpleProduct
66412704   304939     18296340 System.Web.UI.LiteralControl
7a752a34   916368     18327360 System.Collections.Specialized.ListDictionary+DictionaryNode
663b70f0   515385     18553860 System.Web.UI.ControlCollection
663c00b8   285831     19436508 System.Web.UI.DataBoundLiteralControl
663ed42c   307365     20900820 System.Web.UI.WebControls.RepeaterItem
79122610    94101     32575176 System.Collections.Hashtable+bucket[]
000e1888      130     37305432      Free
6641cf70   922079     40571476 System.Web.UI.Control+OccasionalFields
7912254c  1433851     69899636 System.Object[]
790f9244  3565568    348747316 System.String
Total 15584404 objects
Fragmented blocks larger than 0.5 MB:
    Addr     Size      Followed by
473ac50c    1.3MB         4750245c Lucene.Net.Search.TermScorer
4750491c    0.9MB         475e44dc System.Byte[]
6e317958    1.9MB         6e4fa058 System.Byte[]

奇了怪了？怎么都是System.Web.UI空间的对象？难道页面被请求后没有被及时释放？造成有大量的页面实例被存放在拖管堆当中。从!dumpheap -min 8500命令得到的那些对象选择一个有代表意义的对象，来看看里面究竟是什么东西：

0:011> !gcroot 0x3ef16668
Note: Roots found on stacks may be false positives. Run "!help gcroot" for
more info.
Scan Thread 9 OSTHread c8
Scan Thread 17 OSTHread 354
Scan Thread 18 OSTHread 12f8
Scan Thread 19 OSTHread 14d4
Scan Thread 20 OSTHread 10d4
Scan Thread 22 OSTHread f58
Scan Thread 10 OSTHread d2c
Scan Thread 11 OSTHread 1180
ESP:277eef4:Root:06942b80(*.ServiceImpls.SearchImpls.InformationSearchService)->
6e31491c(System.EventHandler`1[[*.ServiceInterfaces.SearchedEventArgs, *.ServiceInterfaces]])->
39f76528(System.Object[])->
4614dc40(System.EventHandler`1[[*.ServiceInterfaces.SearchedEventArgs, *.ServiceInterfaces]])->
4614db74(*.DataSources.InformationSearchDataView)->
3ef5d91c(*.DataSources.InformationSearchDataSource)->
3ef57f38(ASP.product_sortproductlist_aspx)->
3ef02d08(System.Web.HttpContext)->
3ef35a60(System.Web.CachedPathData)->
3ef57d08(System.Web.Configuration.HandlerMappingMemo)->
3ef43e10(System.Web.Configuration.HttpHandlerAction)->
3ef1fde0(System.Configuration.RuntimeConfigurationRecord)->
3ef0e920(System.Configuration.RuntimeConfigurationRecord)->
3ef0ef18(System.Collections.Hashtable)->
3ef15af8(System.Collections.Hashtable+bucket[])->
3ef1e6bc(System.Configuration.SectionRecord)->
3ef1e6e4(System.Configuration.SectionInput)->
3ef1e67c(System.Configuration.SectionXmlInfo)->
3ef16668(System.String)

还真的是页面实例，但是引用链条的根部是在，SearchImpls.InformationSearchService 这个类的实例上。也就是说，只要这个实例无法被释放，那么被引用的InformationSearchDataSource就无法被释放，由于InformationSearchDataSource本身又有Page的引用，而Page又被其它的UI控件和上下文对象所引用。造成了，整个页面实例的对象都无法被释放？那么是什么原因造成了这样的一个引用链条无法被分离呢？

突破口就在 6e31491c(System.EventHandler`1[[*.ServiceInterfaces.SearchedEventArgs, *.ServiceInterfaces]])-> 上面。它是一个事件代理？那么为什么它有这么大的能耐呢？要清楚的解释这个问题，我还得解释一下我这个类的结构。

我这里是有使用NBear.IoC，设计一个搜索接口，名为ISearchService。这个接口上有OnSearching和OnSearched事件。专门用于挂载，搜索之前和搜索之后的事件代理。然后在DataSource中是这样使用这个接口服务的：

NBear.IoC.ServiceFactory.GetService<ISearchService>().OnSearched += new EventHandler(Searched);

这里的Searched是DataSource里的一个实例函数。又由于NBear.IoC中，对组件默认使用的单实例的方式。解释到这里，不知道你知道问题的大概了没？

由于asp.net对每个用户访问的请求，都会对页面进行实例化。一个页面可能会被创建很多很多的实例。不同的页面实例，会创建不同的DataSource实例，而不同的DataSource实例都往ISearchService的接口服务上挂自己实例的Searched方法。而又因为NBear.IoC对组件使用的是单实例的方式的，也就是说，随着时间的推进，ISearchService的接口服务的Searched事件会被挂上很多DataSource不同实例的Searched代理。而如果ISearchService的接口服务不释放，就意味的这些事件代理的不会变成不可达对象，而这个代理的链条一直就这么连接着，直接地就影响了DataSource实例的释放，进而影响Page实例的释放。

OK，怎么感觉就像是在绕圈子呢？如果这时你还是一头雾水的话，建议你去了解一下.NET拖管对象的回收机制。建议读《.NET 框架程序设计修订版》。

到这里，我的分析就基本结束了。剩下的工作就是验证分析的结果了。修改了程序，升级上去以后。程序的起步价要求明显降低了很多，而且内存的上升步长单位也比较少，过一段时间稳定后，也基本就在260多M上下浮动。总之一切看起来都那么美！

从这个Case中，我总结出了自己的东西。对于单实例的设计，比如单件实例模式。我们始终要把一点记在心里，一旦单件实例创建后。它就会随着进程永驻内存。它所引用到的所有对象也会跟着它一样存在和消失，应用程序域未被卸载前，GC就不能把它们咋地！

这篇加上前面两篇，就是我这两天初试WinDbg的“辉煌”结果。我很惊奇，我在很多概念都还没有了解清楚，不知道都有哪些命令的情况，也能利用WinDbg来解决我的实际问题。所以通过这三篇博客，我希望能给一个像我这样的新手一个启发。我们也能自己排错了。但这只是开始，如果WinDbg都像我说这样简单的话，那微软就不用专门有这样的团队了。呵呵

前两篇的链接：

WinDbg初始体验2，抓住不放的恶棍

WinDbg初始体验，问题来了怎么办？

阿不