Skip to content
NeuralSkills
Fehlerbehebung

Speicherleck-Jaeger

Speicherlecks durch Heap-Analyse, Referenzverfolgung und Garbage-Collector-Verhaltensmuster aufspueren und beheben.

Experte Kostenlos Veroeffentlicht: 15. April 2026
Kompatible Tools claude-codechatgptgeminicopilotcursorwindsurfuniversal

Das Problem

Speicherlecks sind stille Killer — die Anwendung funktioniert stundenlang einwandfrei, wird dann schrittweise langsamer, bis sie mit einem Out-of-Memory-Fehler abstuerzt. Anders als Abstuerze, die auf eine Codezeile zeigen, hinterlassen Lecks keine direkte Spur. Ein nie entfernter Event-Listener, eine Closure, die ein grosses Objekt einfaengt, ein Cache ohne Auslagerungsstrategie — jedes fuegt einige Kilobytes hinzu, die nie freigegeben werden.

Der Prompt

Du bist ein Speicherleck-Forensik-Experte. Analysiere dieses Szenario und hilf mir, das Leck aufzuspueren:

RUNTIME: [z.B. Node.js, Python, Java, Browser-JavaScript, Go]
SYMPTOM: [z.B. "RSS waechst um 50MB/Stunde", "Heap-Nutzung sinkt nie nach GC", "OOM-Kill nach 6 Stunden"]
SPEICHERPROFIL-DATEN (falls verfuegbar):
[Heap-Snapshot-Diff, Speicher-Timeline oder Top-gehaltene Objekte einfuegen]

VERDAECHTIGER CODE:
[Codeabschnitte einfuegen, die Subscriptions, Event-Listener, Caches, Closures oder langlebige Objekte verwalten]

Fuehre eine Speicherleck-Analyse durch:
1. **Leck-Signatur-Klassifikation**: Basierend auf dem Symptommuster (lineares Wachstum, Treppenstufen, ploetzlicher Anstieg), den wahrscheinlichen Lecktyp klassifizieren.
2. **Referenzketten-Analyse**: Fuer die verdaechtigen Objekte die Referenzkette vom GC-Root zum geleckten Objekt verfolgen. Was haelt es am Leben?
3. **Akkumulationsmuster**: Leckrate berechnen — wie viel Speicher pro Operation/Request/Minute? Projiziere, wann OOM auftreten wird.
4. **Top 5 Leck-Verdaechtige**: Basierend auf Code und Symptom die wahrscheinlichsten Leckquellen mit Begruendung ranken.
5. **Chirurgischer Fix**: Fuer jeden Verdaechtigen die exakte Codeaenderung liefern, um die Referenzkette ohne Nebeneffekte zu unterbrechen.
6. **Verifikationsprotokoll**: Wie die Behebung zu bestaetigen ist — spezifische Heap-Snapshot-Vergleichsschritte.

Beispiel-Ausgabe

Leck-Signatur: Lineares Wachstum (~2MB/min) — klassische Event-Listener-Akkumulation
Referenzkette: GC-Root → WebSocket.listeners → anonyme Closure → Component-Instanz → DOM-Baum (50KB pro Komponente)
Akkumulation: Jede Routennavigation fuegt einen WS-Listener hinzu, entfernt ihn aber nie. 1000 Navigationen = 50MB geleckt
Fix: Cleanup hinzufuegen: return () => ws.removeEventListener('message', handler);
Verifikation: Heap-Snapshot nehmen, 100x navigieren, zweiten Snapshot nehmen — "Zwischen Snapshots allokierte Objekte" sollte 0 losgeloeste Listener zeigen

Wann verwenden

Diesen Skill einsetzen, wenn die Speichernutzung der Anwendung ueber die Zeit waechst, ohne zur Baseline zurueckzukehren, bei OOM-Abstuerzen in Produktion nach laengerer Laufzeit, oder wenn Heap-Snapshots eine ungewoehnliche Anzahl gehaltener Objekte zeigen.

Profi-Tipps

  • Zwei Heap-Snapshots vergleichen, nicht einen — ein einzelner Snapshot zeigt alles im Speicher. Der Diff zwischen zwei Snapshots zeigt nur, was HINZUGEFUEGT wurde — das Leck.
  • GC vor der Messung erzwingen — in Node.js mit --expose-gc ausfuehren und global.gc() vor Messungen aufrufen.
  • In Chrome DevTools nach “Detached” filtern — um DOM-Knoten zu finden, die nicht mehr im Dokument sind, aber noch von JavaScript referenziert werden.
  • WeakRef und WeakMap nutzen — fuer Caches und Observer-Muster schwache Referenzen verwenden, damit der GC Objekte zurueckfordern kann.