Kan der opstå hukommelseslækager i sprog, der indsamles af affald?

Ja. Og at forstå hvorfor kræver, at man aflærer en af ​​de mest vedvarende myter inden for softwareudvikling.

Myten: Garbage Collection forhindrer hukommelseslækager. Virkeligheden: Garbage Collection forhindrer én specifik type hukommelsesproblem, den dinglende reference, hvor et program mister alle pointere til en hukommelsesblok og ikke har nogen måde at frigøre den på. Hvad garbage Collection ikke forhindrer og ikke kan forhindre, er det modsatte problem: et program, der beholder en reference til et objekt, det ikke længere har brug for. Garbage Collection ser en live reference og lader korrekt objektet være i fred. Udvikleren havde til hensigt at stoppe med at bruge det objekt. Hukommelsen vokser. Effekten er identisk med en traditionel lækage, ubegrænset hukommelsesvækst, eventuelle OOM-fejl, genstart af tjenesten, men mekanismen er anderledes.

Denne sondring er vigtig, fordi den ændrer, hvor du leder efter problemet, og hvordan du løser det. I C og C++ betyder en hukommelseslækage en manglende free() or deleteI Java, Python, C#, Go eller JavaScript betyder det en reference, der burde have været slettet, men ikke blev det. Garbage collectoren fungerer ikke som den skal. Den respekterer korrekt en reference, som programmet ikke burde have beholdt.

Hvad skraldesamlere rent faktisk laver

En garbage collectors opgave er at identificere og genvinde hukommelse, der ikke længere kan nås fra programmets rødder, globale variabler, stakvariabler og trådens lokale tilstand. Ethvert objekt, der kan nås fra en rod, betragtes som aktivt. Ethvert objekt, der ikke kan nås, er berettiget til indsamling.

De tre dominerende GC-strategier definerer hver især tilgængelighed forskelligt:

Markér og fej (bruges af Javas HotSpot, Go, C#/.NET) starter fra rodsættet og gennemløber alle tilgængelige objektreferencer. Objekter, der ikke nås under gennemløbet, scannes. Dette håndterer cirkulære referencer korrekt, hvor to objekter, der peger på hinanden, men som kan nås fra intet andet sted, begge indsamles. Hvad den ikke kan håndtere: en rodtilgængelig container (en statisk HashMap, et klasseniveau List) der vokser uden grænser, fordi poster tilføjes og aldrig fjernes.

Referenceoptælling (CPythons primære mekanisme) sporer, hvor mange referencer der peger på hvert objekt. Når antallet når nul, frigives objektet med det samme. Den klassiske fejltilstand: cirkulære referencer, hvor A refererer til B, og B refererer til A. Begge har et referenceantal på mindst 1 og frigives aldrig. CPython adresserer dette med en supplerende cyklusopsamler, men cyklusopsamleren har kanttilfælde, der involverer objekter med __del__ metoder.

Generations-GC (bruges af de fleste moderne runtime-systemer i kombination med ovenstående) opdeler objekter i unge og gamle generationer baseret på, hvor længe de har overlevet. Kortlivede objekter indsamles ofte til lave omkostninger. Langlivede objekter indsamles sjældent. Konsekvensen af ​​hukommelseslækager: objekter, der burde være blevet kortlivede, men som ved et uheld bevares, flytter ind i den gamle generation og indsamles sjældnere og sjældnere, hvilket gør lækagen sværere at observere og diagnosticere.

Ingen af ​​disse mekanismer kontrollerer, om programmet stadig skal bruge et objekt, kun om det kan nå det.

De fem mekanismer, der forårsager hukommelseslækager i GC-sprog

1. Statiske samlinger og samlinger på klasseniveau

Et statisk felt i Java, en klassevariabel i Python, en statisk egenskab i C# – disse lever i hele applikationsprocessen. Enhver samling, der er gemt i et statisk felt, akkumulerer objekter i hele programmets levetid, medmindre de eksplicit ryddes.

Java

// Java: static cache that grows without bound
public class SessionManager {
    // Lives for the lifetime of the JVM process
    private static final Map<String, UserSession> sessions = new HashMap<>();

    public void createSession(String userId) {
        sessions.put(userId, new UserSession(userId));
        // Session is added but never removed when it expires
    }
    // Missing: cleanup when session expires or user logs out
}

sessions kortet kan nås fra klasseindlæseren, som kan nås fra roden. Hver UserSession nogensinde skabt akkumuleres. I en langvarig tjeneste udtømmer dette bunken over timer eller dage. Løsningen kræver enten aktiv fjernelse (kald sessions.remove(userId) ved logout eller udløb) eller skift til en struktur med automatisk udsættelse, såsom en tidsbegrænset cache.

2. Hændelseslyttere og tilbagekald

Registrering af en observatør, lytter eller tilbagekald opretter en reference fra hændelseskilden til lytteren. Hvis lytteren aldrig er afregistreret, holder hændelseskilden lytteren i live, så længe hændelseskilden eksisterer, hvilket kan være meget længere end tilsigtet.

python

# Python: listener retained by long-lived event source
class DataSource:
    def __init__(self):
        self._listeners = []

    def add_listener(self, listener):
        self._listeners.append(listener)

    # Missing: remove_listener method

class DataProcessor:
    def __init__(self, source: DataSource):
        self.source = source
        source.add_listener(self._on_data)   # strong reference held in source

    def _on_data(self, data):
        pass

# Each DataProcessor created is never collected because
# DataSource._listeners holds a reference to its bound method
source = DataSource()
for _ in range(10000):
    processor = DataProcessor(source)
    # processor goes out of scope here
    # but source._listeners still holds 10,000 bound method references

3. Trådlokale variabler i trådpuljer

Trådlokal lagring er begrænset til en tråd, ikke til en bestemt opgave. I applikationer, der bruger trådpuljer, hvor tråde genbruges på tværs af mange anmodninger, forbliver trådlokale variabler, der er indstillet under én anmodning, indstillet for hver efterfølgende anmodning, der håndteres af den samme tråd.

Java

// Java: ThreadLocal leak in a thread pool
public class RequestContextHolder {
    private static final ThreadLocal<RequestContext> context = new ThreadLocal<>();

    public static void setContext(RequestContext ctx) {
        context.set(ctx);
    }

    public static RequestContext getContext() {
        return context.get();
    }

    // Missing: clearContext() method called after each request
}

// In a servlet or request handler:
public void handleRequest(HttpRequest req) {
    RequestContextHolder.setContext(new RequestContext(req));
    // ... process request
    // Missing: RequestContextHolder.clearContext();
    // The RequestContext stays associated with this thread indefinitely
}

I en trådpulje på 50 tråde, der håndterer millioner af anmodninger, indeholder hver tråd til sidst en RequestContext med henvisning til den seneste anmodnings data, forbindelsesdetaljer, brugerlegitimationsoplysninger og anmodningsparametre. Disse indsamles aldrig, fordi selve trådene aldrig indsamles.

4. Lukninger, der indfanger store objektgrafer

Lukninger indfanger referencer til variabler i deres omsluttende omfang. Især i JavaScript og Python kan et lille callback eller en handler utilsigtet indfange et stort objekt, et helt DOM-træ, et request-objekt eller et stort datasæt, hvilket forhindrer det i at blive indsamlet længe efter, det burde.

javascript

// JavaScript: closure capturing large object in event listener
function setupHandler() {
    const largeDataset = fetchLargeDataset(); // 50MB of data

    document.getElementById('btn').addEventListener('click', function() {
        // Only uses one field, but captures entire largeDataset in closure
        console.log(largeDataset.summary);
    });

    // largeDataset cannot be collected as long as the button exists
    // because the event listener closure holds a reference to it
}

// Fix: capture only what you need
function setupHandlerFixed() {
    const largeDataset = fetchLargeDataset();
    const summary = largeDataset.summary; // extract only needed data

    document.getElementById('btn').addEventListener('click', function() {
        console.log(summary); // closure captures only the string
    });
    // largeDataset is now eligible for collection
}

5. Ubegrænsede caches uden udsættelse

Caches er en af ​​de mest almindelige kilder til hukommelseslækager i produktionstjenester. En cache, der vokser uden en udsættelsespolitik, er en akkumulering af objekter, der ikke kan indsamles, fordi selve cachen altid er tilgængelig.

csharp

// C#: unbounded dictionary used as cache
public class PriceService {
    // Growing forever -- no eviction, no size limit
    private static Dictionary<string, decimal> _priceCache = new();

    public decimal GetPrice(string productId) {
        if (!_priceCache.TryGetValue(productId, out var price)) {
            price = FetchPriceFromDatabase(productId);
            _priceCache[productId] = price;
        }
        return price;
    }
    // After processing 1 million unique product IDs, the cache
    // holds 1 million entries and grows with every new product
}

// Fix: use a cache with eviction policy
using Microsoft.Extensions.Caching.Memory;

public class PriceService {
    private readonly IMemoryCache _cache;

    public PriceService(IMemoryCache cache) {
        _cache = cache;
    }

    public decimal GetPrice(string productId) {
        return _cache.GetOrCreate(productId, entry => {
            entry.AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(10);
            entry.SizeLimit = 1;  // bounded by cache size configuration
            return FetchPriceFromDatabase(productId);
        });
    }
}

Hukommelseslækager efter sprog

Java

Javas mest almindelige lækagemønstre, ud over statiske samlinger, involverer finalize() metode og indre klasser. Ikke-statiske indre klasser indeholder en implicit reference til den omsluttende ydre klasseinstans. En anonym klasse defineret i en aktivitet eller et fragment (i Android) indeholder en reference til den pågældende aktivitet, hvilket forhindrer den i at blive indsamlet efter rotation eller navigation.

Java's WeakHashMap løser problemet med statisk indsamling i tilfælde, hvor nøglerne er de meningsfulde objekter: når nøglen bliver utilgængelig fra andre steder, fjernes posten automatisk. For værdier, der skal frigives, når de ikke længere refereres til, WeakReference og SoftReference ombryde objekter uden at oprette stærke referencer, der forhindrer indsamling.

Detektionsværktøjer: Java VisualVM, Eclipse Memory Analyzer (MAT), JProfiler, YourKit og HeapHero til analyse af heapdumps. Led efter byte[], char[]og Object[] vækst i heaphistogrammer, disse understøtter typisk datastrukturerne i voksende samlinger.

Python

Pythons GC har to lag: referencetælling (primær) og en cycle collector (supplerende). Referencetællingslaget frigiver objekter med det samme, når tællingen når nul, hvilket er hurtigt og forudsigeligt. Cycle collector håndterer cirkulære referencer, men kører sjældnere og har undtagelser.

python

# Python circular reference with __del__ -- historically problematic
class Node:
    def __init__(self):
        self.child = None

    def __del__(self):
        print("Node deleted")

a = Node()
b = Node()
a.child = b
b.child = a   # circular reference
del a, b      # neither freed in Python 2; freed by cycle collector in Python 3.4+

Python 3.4+ håndterer de fleste cirkulære referencer korrekt. De resterende lækagemønstre er: objekter gemt i globaler på modulniveau, voksende defaultdict or dict strukturer brugt som registre, og hukommelse i C-udvidelsesmoduler, der ikke er eksponeret for Python GC.

Opdagelse: tracemalloc (standardbibliotek), memory_profiler, objgraph. Det objgraph.show_most_common_types() og objgraph.show_growth() Funktioner identificerer hvilke typer der akkumuleres.

C# og .NET

C#-lækager opstår oftest gennem: hændelseshandlere, der ikke er afmeldt, statiske hændelseskilder, der indeholder referencer til abonnementsinstanser, og IDisposable-objekter, der ikke er slettet.

csharp

// C#: event handler leak
public class Publisher {
    public static event EventHandler DataChanged;  // static event
}

public class Subscriber {
    public Subscriber() {
        Publisher.DataChanged += OnDataChanged;  // strong reference
    }

    private void OnDataChanged(object sender, EventArgs e) { }

    // Missing: Dispose() calling Publisher.DataChanged -= OnDataChanged
}

Subscriber bliver aldrig indsamlet så længe Publisher eksisterer (som, da den er statisk, er for evigt), fordi den statiske hændelse indeholder en delegeret, der refererer til abonnentinstansen. Rettelsen implementerer IDisposable og afmelding i Dispose()eller ved hjælp af WeakEventManager.

Detektion: .NET Memory Profiler, dotMemory, Visual Studio Diagnostic Tools og WinDbg med SOS-udvidelse til produktionsheapdumps.

Go

Go bruger mark-and-sweep GC med en meget lav stop-verden-pause. På trods af dette udvikler Go-programmer hukommelseslækager gennem goroutine-lækager, goroutiner der startes og aldrig afsluttes.

go

// Go: goroutine leak -- channel never closed, goroutine blocked forever
func processItems(items []Item) {
    results := make(chan Result)

    go func() {
        for _, item := range items {
            results <- process(item)
        }
        // Missing: close(results)
        // This goroutine blocks on the send if no one reads after items run out
    }()

    for result := range results {
        handleResult(result)
    }
    // If the goroutine blocks and results is never closed,
    // the loop here also blocks -- both goroutines leak
}

Hver lækkede goroutine indeholder sin stak (i ​​starten 2KB, som vokser efter behov) og eventuelle heap-objekter, den refererer til. En tjeneste, der lækker én goroutine pr. anmodning, akkumulerer tusindvis over tid.

Opdagelse: runtime.NumGoroutine() metrisk, pprof goroutine profil slutpunkt (/debug/pprof/goroutine), og goleak til test. Pprof-profilen viser hver goroutines stakspor, hvilket gør det nemt at identificere, hvilke funktioner der blokerer på ubestemt tid.

JavaScript og Node.js

I Node.js involverer de mest almindelige lækagemønstre globale variabler, event emitter-lyttere, der akkumuleres uden fjernelse, og buffere/streams, der ikke er korrekt lukket.

javascript

// Node.js: EventEmitter listener leak
const EventEmitter = require('events');
const emitter = new EventEmitter();

function createHandler() {
    emitter.on('data', (data) => {
        // This listener is never removed
        // Each call to createHandler adds another listener
        console.log(data);
    });
}

// Called once per request in a server:
// After 11 calls, Node prints MaxListenersExceededWarning
// After thousands of calls, thousands of listeners accumulate

// Fix: use emitter.once() for one-time listeners
// or explicitly remove with emitter.off()

Detektion: Chrome DevTools heap snapshots (til browser JS), node --inspect med Chrome DevTools (til Node.js), clinic.js til Node.js-profilering i produktion, og heapdump npm-pakke til at indfange og variere heap-snapshots over tid.

Forebyggelsesmønstre på tværs af GC-sprog

I stedet for at fejlfinde lækager, efter de er opstået i produktionen, forhindrer disse strukturelle mønstre de mest almindelige årsager:

Svage referencer tillade, at et objekt refereres til uden at forhindre dets indsamling. Når GC'en har brug for hukommelse, er svagt refererede objekter berettigede til indsamling, selvom der findes referencer til dem. WeakReference<T> i Java og C#, weakref.ref() i Python, og WeakRef i JavaScript til cacher og observer-registreringer, hvor det refererende objekt ikke bør forlænge levetiden for det refererede objekt.

Størrelsesbegrænsede cacher med udsættelse erstat rå HashMap or dict med specialbyggede cache-implementeringer: Guavas CacheBuilder i Java, functools.lru_cache or cachetools i Python, IMemoryCache med størrelsesbegrænsninger i C#, og node-lru-cache i Node.js.

Eksplicit livscyklusstyring sikrer, at objekter med registrerede lyttere, åbne ressourcer eller trådlokal tilstand implementerer en close(), dispose()eller tilsvarende metode, der udfører oprydning, og som kaldere altid kalder den, via try-with-resources i Java, with udsagn i Python, using deklarationer i C#, og defer i Go.

Aflysning af Goroutine i Go bruger context.Context med aflysning for at sikre, at alle goroutines har en vej til afslutning. Goroutines, der vælger på ctx.Done() kan signaleres til at udgå, hvilket forhindrer ophobning.

Hvordan statisk analyse finder potentielle lækager før produktion

Hukommelsesprofilering finder lækager, efter de manifesterer sig. Statisk analyse finder de strukturelle mønstre, der forårsager dem, før koden kører.

SMART TS XL's statisk kodeanalyse undersøger de strukturelle karakteristika for kodebaser på tværs af Java, Python, C#, JavaScript og andre sprog og identificerer mønstre forbundet med utilsigtet tilbageholdelse: statiske samlinger uden dokumenteret udsættelse, registreringer af eventlyttere uden tilsvarende afregistrering, ThreadLocal-brug uden oprydning og ressourceallokeringer uden tilsvarende bortskaffelse.

Funktionen til kortlægning af applikationsafhængighed afslører de lange referencekæder, som GC-sprogshukommelseslækager typisk involverer. Det er objekter, der kan nås fra programrødder gennem flere niveauer af indirektion, hvor stien til roden passerer gennem en langlivet container, der var beregnet til midlertidigt at indeholde objekter.

For organisationer, der administrerer store ældre kodebaser, hvor hukommelsesstyringsmønstre blev etableret for år eller årtier siden, SMART TS XL's konsekvensanalyse Funktionen gør afhjælpning omfangsrig og systematisk: identificer alle steder, hvor et specifikt antimønster (ubegrænset statisk cache, ikke-fjernet lytter) forekommer, opregn de berørte komponenter, og planlæg afhjælpning i rækkefølge efter risiko i stedet for at opdage instanser én produktionshændelse ad gangen.