Preskoči na sadržaj

Curenje memorije u aplikaciji: osnove i kako ga otkriti

Srednje 30 min Ažurirano:

Kratak odgovor

Curenje memorije nastaje kada aplikacija zauzme memoriju i ne oslobodi je nakon upotrebe. Prepoznaje se po stalnom rastu potrošnje memorije i usporavanju. Otkriva se alatima za praćenje memorije i analizom koda, a rešava uklanjanjem uzroka, najčešće zaboravljenih referenci.

Kako se problem prepoznaje

  • Potrošnja memorije aplikacije stalno raste tokom rada
  • Aplikacija vremenom usporava i postaje nestabilna
  • Program se ruši sa greškom nedostatka memorije
  • Operativni sistem počinje da koristi swap i koči se

Najčešći uzroci

Zaboravljene reference

Objekti ostaju u memoriji jer na njih i dalje pokazuje referenca, iako više nisu potrebni. To je najčešći uzrok curenja.

Neuklonjeni event listener-i

Listener-i i callback funkcije koji se dodaju bez uklanjanja zadržavaju objekte u memoriji. Posebno je često u dugotrajnim aplikacijama.

Keševi bez ograničenja

Keš koji raste bez granice ili bez isteka unosa vremenom zauzme svu dostupnu memoriju. Isto važi za globalne kolekcije.

Ciklusi referenci

Objekti koji međusobno referenciraju jedan drugog mogu ostati u memoriji ako garbage collector ne može da ih očisti. U jezicima i okruženjima koja koriste brojanje referenci ciklusi su čest uzrok curenja.

Rešenje korak po korak

  1. 1

    Potvrdite da je reč o curenju

    Pokrenite aplikaciju i pratite potrošnju memorije kroz Task Manager (Windows) ili Activity Monitor (macOS). Ako memorija raste tokom vremena, a ne pada nakon završetka operacija, verovatno je curenje. Zabeležite početnu vrednost i ponovite istu radnju više puta.

  2. 2

    Izolujte scenario koji izaziva rast

    Ponavljajte jednu po jednu funkcionalnost (otvaranje ekrana, učitavanje podataka, slanje zahteva) i posmatrajte memoriju. Cilj je da pronađete najmanji niz koraka koji izaziva stalni rast. Zapišite korake da biste kasnije mogli da ih ponovite.

  3. 3

    Koristite alat za praćenje memorije

    U pregledaču otvorite DevTools > Memory i napravite heap snapshot pre i posle sumnjive radnje. Uporedite snimke i potražite objekte koji ostaju. U Node.js koristite node --inspect i Chrome DevTools, a u .NET Visual Studio Diagnostic Tools.

  4. 4

    Analizirajte heap snapshot

    U alatu pregledajte listu objekata sortiranu po veličini ili broju instanci. Obratite pažnju na objekte koji bi trebalo da budu uklonjeni. Pratite lance referenci (retainers) da biste videli šta drži objekat u memoriji.

  5. 5

    Proverite event listener-e i tajmere

    Pretražite kod za mesta gde dodajete listener-e (addEventListener, on, subscribe) i proverite da li ih uklanjate (removeEventListener, off, unsubscribe). Isto važi za setInterval i setTimeout, koje treba zaustaviti pomoću clearInterval i clearTimeout kada više nisu potrebni.

  6. 6

    Ograničite keševe i kolekcije

    Za keševe koristite ograničenje veličine ili vreme isteka (npr. LRU keš). Izbegavajte globalne nizove i mape koje rastu bez kontrole. Redovno čistite stare unose.

  7. 7

    Uklonite uzrok i testirajte

    Nakon što pronađete uzrok, izmenite kod tako da se reference oslobode. Ponovite isti test i pratite memoriju: treba da ostane stabilna. Ako je potrebno, dodajte automatski test koji proverava da memorija ne raste.

Ako ništa ne pomogne

Ako ne možete da pronađete uzrok, razmotrite da pojednostavite deo koda koji sumnjate i ponovo testirate. Ponekad curenje potiče iz biblioteke treće strane; proverite da li je ažurirana i da li je poznat problem. U produkciji pratite memoriju kroz alate za monitoring i postavite alarm kada potrošnja pređe granicu. Za složene slučajeve koristite napredne alate kao što su heap profiler i alati za analizu alokacija. Ako se curenje javlja samo pod opterećenjem, testirajte sa simulacijom više korisnika.

Kako da sprečite da se ponovi

  • Redovno pregledajte kod na mesta gde se dodaju listener-i i tajmeri
  • Koristite ograničene keševe i čistite kolekcije
  • Testirajte memoriju pre puštanja u produkciju
  • Pratite potrošnju memorije u produkciji

Kada je bolje pozvati stručnjaka

Ako curenje izaziva padove u produkciji ili ne možete da ga reprodukujete, obratite se IT podršci ili iskusnijem developeru za analizu.

Razvoj softvera i proizvoda · Aplikacije po meri, SaaS i MVP za 4 do 8 nedelja

Česta pitanja

Kako da znam da li aplikacija curi memoriju ili je samo zahtevna?

Ako memorija raste konstantno tokom rada i ne oslobađa se nakon završetka operacija, verovatno je curenje. Zahtevna aplikacija može koristiti više memorije, ali bi trebalo da je oslobodi kada joj više nije potrebna.

Da li je curenje memorije opasno po bezbednost?

Može biti. Curenje može dovesti do iscrpljivanja resursa i pada sistema, što napadači mogu iskoristiti za uskraćivanje usluge (DoS). Takođe, memorija koja sadrži osetljive podatke može ostati duže dostupna, što povećava rizik od curenja informacija.

Koliko često treba proveravati memoriju?

Preporučuje se provera pri svakoj većoj izmeni i redovno u produkciji. Automatizovani testovi mogu pomoći da se curenje otkrije rano.

Podeli
Niste našli rešenje?AI IT asistent je dostupan 24/7. Opišite problem ili pošaljite screenshot greške i dobićete uputstvo za vaš slučaj.Pitajte AI IT asistenta