我正在使用的C＃/。NET應(yīng)用程序正遭受緩慢的內(nèi)存泄漏。我已經(jīng)將CDB與SOS一起使用來(lái)嘗試確定正在發(fā)生的事情，但是數(shù)據(jù)似乎沒(méi)有任何意義，因此我希望你們中的一個(gè)以前可能已經(jīng)經(jīng)歷過(guò)這種情況。該應(yīng)用程序在64位框架上運(yùn)行。它正在不斷地計(jì)算數(shù)據(jù)并將其序列化到遠(yuǎn)程主機(jī)，并且相當(dāng)大地達(dá)到了大對(duì)象堆（LOH）。但是，我希望大多數(shù)LOH對(duì)象都是瞬態(tài)的：一旦計(jì)算完成并將其發(fā)送到遠(yuǎn)程主機(jī)，就應(yīng)該釋放內(nèi)存。但是，我看到的是大量（活動(dòng)的）對(duì)象數(shù)組與空閑的內(nèi)存塊交錯(cuò)，例如，從LOH中獲取隨機(jī)段：0:000> !DumpHeap 000000005b5b1000  000000006351da10         Address               MT     Size...000000005d4f92e0 0000064280c7c970 16147872000000005e45f880 00000000001661d0  1901752 Free000000005e62fd38 00000642788d8ba8     1056       <--000000005e630158 00000000001661d0  5988848 Free000000005ebe6348 00000642788d8ba8     1056000000005ebe6768 00000000001661d0  6481336 Free000000005f214d20 00000642788d8ba8     1056000000005f215140 00000000001661d0  7346016 Free000000005f9168a0 00000642788d8ba8     1056000000005f916cc0 00000000001661d0  7611648 Free00000000600591c0 00000642788d8ba8     105600000000600595e0 00000000001661d0   264808 Free...顯然，如果我的應(yīng)用程序在每次計(jì)算過(guò)程中都創(chuàng)建了長(zhǎng)壽命的大對(duì)象，我希望情況會(huì)如此。（這樣做是可以的，我接受會(huì)有一定程度的LOH碎片，但這不是問(wèn)題所在。）問(wèn)題是您在上述轉(zhuǎn)儲(chǔ)中看到的對(duì)象數(shù)組非常?。?056字節(jié)），我在代碼中看不到被創(chuàng)建，并以某種方式保持根源。還要注意，轉(zhuǎn)儲(chǔ)堆段時(shí)CDB不會(huì)報(bào)告類(lèi)型：我不確定這是否相關(guān)。如果我轉(zhuǎn)儲(chǔ)標(biāo)記的（<-）對(duì)象，CDB / SOS會(huì)很好地報(bào)告它：對(duì)象數(shù)組的元素都是字符串，從我們的應(yīng)用程序代碼中可以識(shí)別出這些字符串。另外，由于！GCRoot命令掛起并且再也沒(méi)有回來(lái)，所以我找不到他們的GC根目錄（我什至試圖將其放置一夜）。因此，如果有人能解釋為什么這些小的（<85k）對(duì)象數(shù)組最終出現(xiàn)在LOH上，我將不勝感激：.NET在什么情況下會(huì)在其中放置一個(gè)小的對(duì)象數(shù)組？而且，有人碰巧知道確定這些對(duì)象根源的另一種方法嗎？更新1我昨天晚些時(shí)候提出的另一種理論是，這些對(duì)象數(shù)組起初很大，但是已經(jīng)縮小了，留下了內(nèi)存轉(zhuǎn)儲(chǔ)中明顯的可用內(nèi)存塊。使我感到懷疑的是，對(duì)象數(shù)組總是看起來(lái)長(zhǎng)1056字節(jié)（128個(gè)元素），引用的長(zhǎng)度為128 * 8，開(kāi)銷(xiāo)為32字節(jié)。想法是，庫(kù)中或CLR中的某些不安全代碼可能破壞了數(shù)組頭中元素?cái)?shù)量的字段。我知道遠(yuǎn)射...應(yīng)用程序首先在循環(huán)中創(chuàng)建和取消引用唯一的字符串。這只是為了證明在這種情況下內(nèi)存不會(huì)泄漏。顯然，它不應(yīng)該也不應(yīng)。在第二個(gè)循環(huán)中，創(chuàng)建并插入了唯一的字符串。此操作將它們根植在實(shí)習(xí)表中。我沒(méi)有意識(shí)到實(shí)習(xí)表是如何表示的?？雌饋?lái)它由在LOH中創(chuàng)建的一組頁(yè)面（由128個(gè)字符串元素組成的對(duì)象數(shù)組）組成。這在CDB / SOS中更為明顯：請(qǐng)注意，對(duì)象數(shù)組的大小為528（而不是1056），因?yàn)槲业墓ぷ髡臼?2位，而應(yīng)用程序服務(wù)器是64位。對(duì)象數(shù)組仍為128個(gè)元素長(zhǎng)。因此，這個(gè)故事的寓意是要非常小心地進(jìn)行實(shí)習(xí)。如果未知您正在實(shí)習(xí)的字符串是有限集的成員，則您的應(yīng)用程序?qū)⒁騆OH的碎片而泄漏，至少在CLR版本2中會(huì)這樣。在我們的應(yīng)用程序的情況下，反序列化代碼路徑中存在通用代碼，可在解組期間實(shí)習(xí)實(shí)體標(biāo)識(shí)符：我現(xiàn)在強(qiáng)烈懷疑這是罪魁禍?zhǔn)?。但是，開(kāi)發(fā)人員的意圖顯然是好的，因?yàn)樗麄兿氪_保如果對(duì)同一實(shí)體進(jìn)行多次反序列化，則只有一個(gè)標(biāo)識(shí)符字符串實(shí)例將保留在內(nèi)存中。