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
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
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
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
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
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
14

A legjobb magyarázat arra, hogy a szemétgyűjtő működik Jeff Richters CLR via C # könyv, (Ch. 20). Reading ez ad egy jó alapot nyújt, hogy miként tárgyak továbbra is fennállnak.

Az egyik leggyakoribb oka a gyökereztető tárgyak véletlenül van a összejönni események üzemzavarokra egy osztály. Ha beköt egy külső esemény

például

SomeExternalClass.Changed += new EventHandler(HandleIt);

és felejtsd el, hogy akassza rá kidobja, majd SomeExternalClass egy ref az osztályban.

Mint már említettük, a SciTech memória profiler is kiválóan mutatja meg gyökerei tárgyak úgy gondolja, hogy szivárog.

De van még egy nagyon gyors módja annak, hogy ellenőrizze az adott típus csak használja WnDBG (akkor is használja ezt a VS.NET azonnali ablakon, míg csatolva):

.loadby sos mscorwks
!dumpheap -stat -type <TypeName>

Most tenni valamit, hogy úgy gondolja, gondoskodunk a ilyen típusú objektum (pl ablak bezárásához). Ez kéznél van, hogy van egy hibakereső gomb valahol, hogy futni fog System.GC.Collect()egy-két alkalommal.

Akkor fuss !dumpheap -stat -type <TypeName>újra. Ha a szám nem ment le, vagy nem megy le, mint azt várod, akkor van egy alapot a további vizsgálatot. (Kaptam ezt a tippet egy szemináriumon által Ingo Rammer ).

Válaszolt 27/08/2008 15:12
a forrás felhasználó

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
10

Miért hiszik, hogy a memóriavesztés .NET nem ugyanaz, mint bármely más szivárgás?

Memóriavesztés is, ha csatolja a forrás, és ne hagyjuk, hogy menjen. Megteheti ezt mind irányított és felügyelet nélküli kódolás.

Ami .NET és más programozási eszközök, ott már ötleteket szemétgyűjtés, és más módon minimalizálva helyzetek, melyek révén az alkalmazás szivárgás. De a legjobb módszer, hogy megakadályozzák a memóriavesztés, hogy meg kell értened, a mögöttes memória modell, és hogy a dolgok hogyan működik, a platform használ.

Abban a hitben, hogy a GC és egyéb mágikus tisztítsák meg a rendetlenség a rövid utat a memóriavesztés, és nehéz lesz megtalálni később.

Amikor kódolási felügyelt, akkor általában győződjön meg arról, hogy tisztítsák meg, tudod, hogy a forrásokat meg ragadja lesz az Ön felelőssége, hogy tisztítsák meg, és nem a takarító.

A .NET másrészt, egy csomó ember úgy gondolja, hogy a GC tisztítsák meg mindent. Nos, ez nem valami az Ön számára, de meg kell, hogy megbizonyosodjon arról, hogy ez így van. NET-nak csomagolja sok dolgot, így nem mindig tudom, ha van szó, egy irányított vagy irányítás nélküli forrás, és meg kell, hogy megbizonyosodjon arról, amit mi dolgunk. Kezelés betűtípusok, GDI erőforrás, az aktív könyvtár, adatbázisok stb jellemzően dolgot kell, hogy néz ki.

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

Látom sok ember ezt mégis, és nagyon remélem, ez lesz a vége. Nem lehet kérni a felhasználót, hogy megszünteti az alkalmazás, hogy tisztítsák meg a rendetlenség! Vessen egy pillantást a böngésző, amely lehet IE, FF, stb, akkor nyitott, mondjuk, a Google Reader, hadd maradjon néhány napig, és nézd meg, mi történik.

Ha ezután megnyit egy másik lapra a böngésző, surf néhány helyén, majd zárja be a lapot adott otthont a másik oldal tette a böngésző szivárgás, mit gondol a böngésző felszabadítja a memóriát? Nem így az IE. A számítógépen IE könnyen enni 1 GiB memória rövid ideig (3-4 nap), ha használom a Google Reader. Néhány newspages még rosszabb.

Válaszolt 01/09/2008 13:19
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
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
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
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
6

Találtam Net Memory Profiler egy nagyon jó segítség, amikor megállapította, memóriavesztés .Net. Ez nem szabad, mint a Microsoft CLR Profiler, de gyorsabb, és több a pont véleményem. A

Válaszolt 20/08/2008 19:39
a forrás felhasználó

szavazat
1

Az egyik meghatározás: Nem lehet befejezni elérhetetlen memória, amely már nem kell különíteni az új eljárás végrehajtása során elosztásának folyamatát. Ez többnyire gyógyítható GC technikával vagy detektálható automatizált eszközökkel.

További információért kérjük, látogasson el http://all-about-java-and-weblogic-server.blogspot.in/2014/01/what-is-memory-leak-in-java.html .

Válaszolt 27/08/2014 16:22
a forrás felhasználó

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more