Memory leak/Garbage Collector probléma?
C#-ról van szó, de ez nem hiszem, hogy fontos lenne, a Garbage Collector más nyelvekben is hasonlóan működik (gondolom).
Van egy metódusom, ami egy listának az összes elemének felhasználásával létrehoz egy-egy objektumot, majd ezeket kirakja a képernyőre, miután a képernyőn eddig kint lévő ilyen objektumokat törölte.
Itt a kód képen, alá meg bemásolom ugyan azt szövegesen, biztos ami tuti ziher: [link]
public void CreateObject(List<Akarmi> list)
{
DeleteAllObjectFromScreen(); //eltávolítom a felületről az összes objektumot ami eddig ott volt
foreach (var item in list)
{
var objektum = new Objektum(item);
AddObjectToScreen(objektum); //kirakom az újakat egyesével
}
}
Ha ez a metódus többször lefut, akkor okoz memóriaszivárgást, vagy a GC kitakarítja ezeket a memóriából? Mert elvileg (szerintem) nem marad rájuk hivatkozás, szóval működnie kéne.
A másik kérdés: ha ezeknek az objektumoknak van egy click eseménye, akkor azokról is egyesével le kéne iratkozni amikor törlöm a képernyőről az objektumot, mert ha nem akkor mindig lesz, ami arra hivatkozik? Tehát kéne egy objektum -= objektum_Click?
Kép:
válasza:Feltételezem, hogy Objektum egy UI element, valamint, hogy a DeleteAllObjectsFromScreen maradéktalanul kipucolja a UI-ról ezeket a komponenseket. Ebben az esetben a GC-nek ki kellene takarítania.
Ha a metódusod azt csinálja, amit kell, akkor nem kéne referenciának maradnia a memóriában, miután lekaptad az elemeket a UI-ról.
Ha nem vagy biztos a dolgodban, érdemes lehet megnézni egy core dumpot.
Lehet hülye kérdés, de mi az a core dump?
Igen, UI elementek és az a metódus leszedi őket maradéktalanul.
Azért mertül fel bennem a kérdés, mert megnéztem egy memory profilerel amit csináltam, és szerintem indokolatlanul hízik az általa használt memória.
A kérdésem második részére tudsz valamit mondani? Ha az objektum fel van iratkozva egy eseményre, akkor ez is hivatkozásnak számít és egyesével le kéne róla szednem őket?
válasza:"Ha az objektum fel van iratkozva egy eseményre, akkor ez is hivatkozásnak számít és egyesével le kéne róla szednem őket?"
Nem ismerem a konkrét UI rendszert, és ezt bizony megvalósítása válogatja.
Ahol a root element propagál a childrennek, ugyanazon referencián keresztül, mint amelyen keresztül kirajzoltatik.
Egyszerűbben, egy eseményre azáltal iratkozol fel, hogy hozzáadod a UI-hoz, és azáltal iratkozol le, hogy eltávolítod azt onnan. Ha nem adsz meg eseménykezelőt, úgy az ősosztály szolgál egy defaulttal. Mivel OO környezetben dolgozol, ezt a variációt gyanítom itt is, de előfordulhat, hogy nem így működik.
A core dump a memória fájlba mentett állapota, de ha profilerrel megkapartad, akkor ez tkp. megvolt.
Ha a GC takarít, a memmgr általában nem adja vissza az operációs rendszernek a lefoglalt területet, mert sanszos, hogy még úgyis szükség lesz legalább egy részére, a kerneltől kérni meg költséges. Nem lehet, hogy ettől hízik a lefoglalt memória? A profilerben látnod kell(ene) a konkrét példányokat. Ha abból van indokolatlanul sok, akkor valóban memory leak lesz, de ha csak CLR tart fenn helyet a fizikai memóriában, az önmagában elvileg nem jelent semmit.
Ezeket nyálazd át, hátha megadják a választ:
válasza:Banyek... Megszivatott a touchpad.
"Ahol a root element propagál a childrennek, ugyanazon referencián keresztül, mint amelyen keresztül kirajzoltatik."
Szóval ahol "lefelé" van propagálva az event, ott többnyire nem kell külön leiratkozni, de nem mindenhol működik így.
Kapcsolódó kérdések:
Minden jog fenntartva © 2025, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!