Anatomy of a "Memory Leak"

szavazat
159

A .NET szempontjából:

  • Mi a Memory Leak ?
  • Hogyan lehet megállapítani, hogy a kérelem szivárog? Milyen hatásai vannak?
  • Hogyan lehet megakadályozni a memóriavesztés?
  • Ha az alkalmazás memóriavesztés, nem is megy el, amikor a folyamat kilép, vagy meghal? Vagy memóriavesztés az alkalmazás befolyásolhatja más folyamatokat a rendszer után is folyamatban befejezése?
  • És mi a helyzet menedzselt kód keresztül érhető COM együttműködéshez és / vagy P / Indítsa?
A kérdést 01/08/2008 16:12
a forrás felhasználó
Más nyelveken...                            


15 válasz

szavazat
14

Gondolom felügyelt környezetben, a szivárgás lenne akkor tartása szükségtelen hivatkozás egy nagy darab memória körül.

Válaszolt 01/08/2008 16:19
a forrás felhasználó

szavazat
9

Én egyetértek Bernard, hogy a .net, amit egy mem szivárgás lenne.

Lehet profil az alkalmazás, hogy a memória használatát, és meghatározzák, hogy ha az ügyvezetést sok memóriát, ha nem kellene azt is mondhatnánk, hogy van egy szivárgás.

A kezelt szempontjából Adom nyakam a sorban azt mondani, hogy nem megy el, ha a folyamat megölt / eltávolítható.

Menedzselt kód saját vadállat, és ha a szivárgás van benne, akkor kövesse a szokásos mem. szivárog meghatározása.

Válaszolt 01/08/2008 16:23
a forrás felhasználó

szavazat
106

A legjobb magyarázat, amit láttam a 7. fejezetében szabad Foundations of Programming e-book .

Alapvetően, a .NET memóriavesztés lép fel, amikor a hivatkozott objektumok gyökerezik, és így nem lehet szemetet gyűjtött. Ez akkor fordul elő véletlenül, ha ragaszkodnak a referenciák túl a tervezett hatályát.

Tudni fogod, hogy van szivárgás, amikor elkezd szerzés OutOfMemoryExceptions vagy a memória használat felmegy túl, amit elvárnánk ( PerfMon Szép memória működése).

Megértése .NET memóriája modell a legjobb módja annak, hogy elkerüljék azt. Pontosabban, hogy miként lehet a szemétgyűjtő működik, és hogyan referenciák működik - ismét utalok, hogy a 7. fejezet az e-book. Is, legyen tudatában a leggyakoribb buktatókat, talán a leggyakoribb, hogy eseményeket. Ha tárgy A regisztrálva van egy esemény objektumot B , akkor az objektum egy fog maradni, amíg tárgy B megszűnik, mert B tart hivatkozás A . A megoldás az, hogy regisztrációját az eseményeket, ha végeztél.

Persze, a jó memória profil láthasson az objektumot grafikonok és fedezze fel a fészkelő / referenciái a tárgyakat, hogy hol hivatkozások jönnek, és milyen gyökér objektum felelős ( piros-gate hangyák profil , JetBrains dotMemory, memprofiler tényleg jó választás, vagy használhatja a csak szöveges WinDbg és SOS , de én azt javasoljuk, a kereskedelmi / vizuális termék, ha te egy igazi guru).

Úgy vélem, nem felügyelt kód alá jellegzetes memóriavesztés, kivéve azt, hogy a közös referenciák által kezelt szemétgyűjtő. Lehet, hogy tévedek ebben az utolsó pontot.

Válaszolt 01/08/2008 16:28
a forrás felhasználó

szavazat
32

Szigorúan véve, memóriavesztés fogyaszt memória, amely „már nem használt” a program.

„Többé már használt” egynél több jelentése van, ez azt jelentheti, „nincs több utalás”, azaz teljesen javíthatatlan, vagy azt is jelentheti, a hivatkozott, behajtható használt, de a program megőrzi a hivatkozások egyébként. Csak a későbbi vonatkozik .NET tökéletesen kezelt objektumok . Azonban nem minden osztály tökéletes, és egy bizonyos ponton az alatta menedzselt végrehajtási lyhat erőforrások állandó jelleggel ezt a folyamatot.

Minden esetben az alkalmazás fogyaszt több memóriát feltétlenül szükséges. Az oldalon hatások függően ammount kiszivárgott lehetett menni sem, a lassulás okozta túlzott gyűjtemény, egy sor memória kivételek és végül egy végzetes hiba, majd az erőltetett folyamat megszüntetése.

Tudod egy alkalmazás a memória problémát, ha a megfigyelés azt mutatja, hogy egyre több és több memóriát a folyamat után szemétgyűjtő ciklusban . Ebben az esetben, akkor sem tartja túl sok memóriát, vagy valamilyen mögöttes menedzselt végrehajtás szivárog.

A legtöbb szivárgás, a források vissza, amikor a folyamat befejeződik, azonban egyes erőforrások nem mindig vissza egyes konkrét esetekben, GDI kurzor fogantyúk hírhedt ezt. Természetesen, ha van egy közti kommunikációs mechanizmus lefoglalt memória a másik folyamat nem szabadult addig, amíg ez a folyamat szabadít meg, vagy megszűnik.

Válaszolt 01/08/2008 18:52
a forrás felhasználó

szavazat
18

Azt határozza meg memóriavesztés, mint egy tárgy nem szabadít fel az összes lefoglalt memória miután befejeződött. Azt találtuk, hogy ez megtörténhet az alkalmazás, ha a Windows API és a COM (azaz nem felügyelt kód olyan hibát, vagy nem kezeli helyesen), a keret és a harmadik féltől származó összetevők. Azt is megállapítottuk, nem Takarítás után a bizonyos tárgyak, mint a tollak okozhat problémát.

Én személy szenvedett Out of Memory kivételes ennek oka lehet, de nem kizárólag a memóriavesztés dot net alkalmazásokat. (OOM is származhatnak fűznek lásd Pinning Artical ). Ha nem kapok OOM hibát, vagy meg kell erősítenie, ha ez egy memóriavesztés okozza, akkor az egyetlen módja az, hogy bemutassa alkalmazás.

Azt is megpróbálja biztosítani a következőket:

a) Minden, ami megvalósítja Idisposable van elhelyezve vagy finally blokk vagy a használó nyilatkozat ezek közé ecsetek, tollak, stb (egyesek azt állítják, hogy állítson mindent semmi mellett)

b) Bármi, ami szoros eljárást lezárva újra a véglegesen vagy a használó nyilatkozat (bár én találtam használ nem mindig közel attól, ha deklarált objektum kívül a kimutatás)

c) Ha nem felügyelt kód / windows API, hogy ezek kezelik megfelelően, miután. (Néhány megtisztítása módszereket, hogy kiadja erőforrások)

Remélem ez segít.

Válaszolt 01/08/2008 18:57
a forrás felhasználó

szavazat
9

Minden memóriavesztés oldják meg a program megszüntetését.

Szivárgás elég memória és az operációs rendszer úgy dönthet, hogy oldja meg a problémát az Ön nevében.

Válaszolt 04/08/2008 15:09
a forrás felhasználó

szavazat
10

Gondolom felügyelt környezetben, a szivárgás lenne akkor tartása szükségtelen hivatkozás egy nagy darab memória körül.

Teljesen. Továbbá, nem használja a .Dispose () módszer az eldobható tárgyak, amikor a megfelelő okozhatnak mem szivárgást. A legegyszerűbb módja annak, hogy ez a használó blokk, mert automatikusan végrehajtja .Dispose () a végén:

StreamReader sr;
using(sr = new StreamReader("somefile.txt"))
{
    //do some stuff
}

És ha osztályt hozunk létre, amely segítségével felügyelt objektumok ha nem végrehajtási IDisposable rendesen, akkor lehet okozva memóriavesztés a osztály számára.

Válaszolt 05/08/2008 23:47
a forrás felhasználó

szavazat
7

Is szem előtt tartani, hogy a NET két halom, az egyik a nagy objektum kupac. Úgy vélem, tárgyakat durván 85k vagy nagyobb kerülnek ilyen kupac. Ez kupac egy másik életre szabályok, mint a rendes kupac.

Ha létrehoz nagy memória struktúrák (Dictionary vagy lista) lenne körültekintő menni lookup mi a pontos szabályok.

Ami visszaigényli a memória eljárás megszüntetése, kivéve, ha a futó Win98 vagy ekvivalens, minden visszakerül az operációs rendszer megszűnése. Az egyetlen kivétel a dolgok, amelyek nyitottak a határokon folyamat és a másik folyamat még az erőforrás nyitva.

COM objektumok is trükkös tho. Ha mindig a IDisposeminta, akkor biztonságban lesz. De én már futnak néhány interoperabilitási összeállítások végre IDispose. A kulcs itt az, hogy hívja Marshal.ReleaseCOMObject, ha végeztél vele. A COM objektumok mindig a szabványos COM hivatkozási számolás.

Válaszolt 07/08/2008 14:17
a forrás felhasználó

szavazat
18

Ha kell diagnosztizálni memóriavesztés .NET, ellenőrizze ezeket a linkeket:

http://msdn.microsoft.com/en-us/magazine/cc163833.aspx

http://msdn.microsoft.com/en-us/magazine/cc164138.aspx

Ezek a cikkek leírják, hogyan kell létrehozni egy memória dump a folyamatot, és hogyan kell elemezni úgy, hogy akkor először meg, ha a szivárgás nem felügyelt vagy felügyelt, és ha ez sikerült, hogyan kell kitalálni, ha jön.

A Microsoft is egy újabb eszköz, amely segíti a generátor összeomlás guba, hogy cserélje ADPlus, az úgynevezett DebugDiag.

http://www.microsoft.com/downloads/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en

Válaszolt 15/08/2008 00:16
a forrás felhasználó

szavazat
28

Azt hiszem, a „mi az a memóriavesztés” és „milyen hatással van” kérdésre már válaszolt is már, de azt akartam, hogy adjunk még néhány dolgot a másik kérdés ...

Hogyan értsük, hogy a kérelem szivárgás

Egy érdekes módja az, hogy nyissa PerfMon és adjunk hozzá nyomokat # bájt minden halmok és # Gen 2 gyűjtemények , minden esetben keresi éppen a folyamatot. Ha gyakorlása egy adott funkció hatására a teljes byte növelése, és a memória marad kiosztott után a következő Gen 2 gyűjteményt, akkor azt mondhatjuk, hogy ezt a funkciót memóriavesztést.

Hogyan lehet megelőzni

További jó véleményeket kaptak. Én csak hozzá, hogy talán a leggyakrabban figyelmen kívül hagyott oka .NET memóriavesztés van hozzá eseménykezelőt tárgyak eltávolítása nélkül őket. Eseménykezelő csatolt egy objektum formáját hivatkozással, hogy a tárgy, így megakadályozza gyűjtemény után is minden egyéb hivatkozásokat mentek. Mindig emlékezni, hogy leválassza eseménykezelőkkel (a -=szintaxis a C #).

Vajon a szivárgás megy el, amikor a folyamat kilép, és mi a helyzet a COM-integrációs?

Amikor a folyamat kilép, minden memóriára leképezett a címterébe visszaveszi az operációs rendszer, beleértve a COM objektumok szolgált DLL-ek. Viszonylag ritkán, COM-objektumokat lehet kézbesíteni különálló folyamatokat. Ebben az esetben, ha a folyamat kilép, akkor is felelős a lefoglalt memória bármilyen COM-kiszolgáló folyamatokat, amit használt.

Válaszolt 15/08/2008 17:11
a forrás felhasználó

szavazat
15

Használata CLR Profiler a Microsoft http://www.microsoft.com/downloads/details.aspx?familyid=86ce6052-d7f4-4aeb-9b7a-94635beebdda&displaylang=en egy nagyszerű módja annak, hogy meghatározza, hogy mely objektumokat tartja az emlékezet, mi végrehajtás áramlás vezet létrehozásához ezeket az objektumokat, valamint nyomon mely objektumok élő, ahol a halom (fragmentáció, LOH, stb.)

Válaszolt 16/08/2008 20:54
a forrás felhasználó

szavazat