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:
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?
"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:
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 © 2024, 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!