Een memory leak is een bug waarbij software geheugen opeist om zijn werk te doen, maar dat nooit teruggeeft, zelfs niet als het geheugen niet meer nodig is. Elke ronde blijft er wat meer geheugen bezet, dus de beschikbare ruimte krimpt langzaam. Uiteindelijk wordt het programma loodzwaar of raakt het geheugen op en crasht het.
Stel je een keuken voor waar elk vuil bord in de gootsteen belandt, maar niemand ooit afwast. Even zijn er nog schone borden in de kast. Maar de stapel groeit door, en op een gegeven moment valt de bediening stil omdat er niks meer is om op uit te serveren. Een memory leak werkt net zo: eerst klein en onzichtbaar, dan plots een echt probleem. Dit is het soort bug dat dagen verborgen blijft, omdat hij alleen opduikt onder langdurige, echte belasting.
Een veelvoorkomende boosdoener is iets dat langer blijft hangen dan bedoeld: een event listener die wel wordt toegevoegd maar nooit verwijderd, of een lijst die op elke aanvraag stilletjes aangroeit en nooit wordt opgeschoond. De code ziet er op zichzelf prima uit, en juist daardoor zijn leaks zo glibberig. Talen met automatisch geheugenbeheer, zoals JavaScript of Python, ruimen het meeste vanzelf op, maar zodra ergens nog één verwijzing naar oude data hangt, kan de opruimer er niet bij en blijft het geheugen bezet.
Leaks doen het meeste pijn in software die continu draait, zoals een webserver of een achtergrondproces, omdat het geheugen nooit door een herstart wordt vrijgemaakt. Ze opsporen hoort bij debuggen: developers gebruiken profilingtools om het geheugen over uren te zien groeien en herleiden dat naar de exacte code die vergat op te ruimen.
Bij TopDevs draaien we performancetests onder realistische belasting voordat we live gaan, zodat leaks in onze omgeving opduiken en niet op een zaterdagavond in productie.
