f8b21af4be
10_Wiki/Topics 대규모 정리: - 오류 캡처/미완성 stub 문서 227개 제거 - 교차폴더 중복 43클러스터 병합 (63파일 → redirect) - 링크명 정규화: 깨진 링크 수정·redirect 직결·개념 매핑 ~2,400건 - 카테고리 MOC 6개 신규 생성 - Graph 섹션 미해결 related-keyword 링크 10,058건 제거 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
5.8 KiB
5.8 KiB
id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack
| id | title | category | status | canonical_id | aliases | duplicate_of | source_trust_level | confidence_score | verification_status | tags | raw_sources | last_reinforced | github_commit | tech_stack | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| wiki-2026-0508-memory-leaks | Memory Leaks | 10_Wiki/Topics | verified | self |
|
none | A | 0.9 | applied |
|
2026-05-10 | pending |
|
Memory Leaks
매 한 줄
"매 reachable 한 garbage — 매 free 되지 않는 retained memory.". Memory leak 은 매 program 이 더 이상 필요 없는 memory 를 release 하지 못해서 매 heap 이 무한히 grow 하는 현상. 매 GC language (JS, Python, JVM) 에서도 매 reference 가 살아있으면 leak — 매 manual language (C/C++) 에서는 매 free() miss.
매 핵심
매 분류
- Unreachable leak (C/C++): 매 free() 누락 — pointer 잃어버림.
- Reachable leak (GC lang): 매 reference 가 살아있어서 GC 가 collect 안 함.
- Logical leak: 매 코드는 정상이지만 매 cache/list 가 무한 grow.
매 흔한 원인 (GC lang)
- Global variable: 매 process 끝까지 살아있음.
- Closure capture: 매 callback 이 매 큰 object 를 capture.
- Event listener: 매 removeEventListener 누락.
- Timer: 매 clearInterval 누락.
- DOM detach: 매 detached node 를 JS 가 still reference.
- Cache: 매 unbounded Map/dict.
매 진단 신호
- RSS 가 매 시간/일 단위로 매 monotonically grow.
- GC pause 가 매 frequent + long.
- OOM crash 결국.
💻 패턴
Node.js heap snapshot diff
// Take 3 snapshots, diff 2 vs 3
const v8 = require('v8');
const fs = require('fs');
function snapshot(label) {
const stream = v8.getHeapSnapshot();
const file = fs.createWriteStream(`heap-${label}-${Date.now()}.heapsnapshot`);
stream.pipe(file);
}
// Or via Chrome DevTools: chrome://inspect → Memory tab → Take snapshot
// Compare snapshots → "Allocations between snapshots" → find growing constructors
매 흔한 leak: closure capture
// BAD: closure captures huge `data` even though only `id` is used
function attach(data) {
document.getElementById('btn').addEventListener('click', () => {
console.log(data.id); // captures entire `data` (10MB)
});
}
// GOOD: extract only what's needed
function attach(data) {
const id = data.id; // only id is captured
document.getElementById('btn').addEventListener('click', () => {
console.log(id);
});
}
매 EventEmitter leak
const emitter = new EventEmitter();
emitter.setMaxListeners(20); // Node warns at >10
// BAD: each call adds a new listener
function onEachRequest(req) {
emitter.on('data', () => process(req)); // listener never removed
}
// GOOD: once() or remove
function onEachRequest(req) {
const handler = () => process(req);
emitter.once('data', handler);
// or: emitter.off('data', handler) when done
}
Python tracemalloc
import tracemalloc
tracemalloc.start(25) # store 25 frames
# ... run workload ...
snap1 = tracemalloc.take_snapshot()
# ... run more workload ...
snap2 = tracemalloc.take_snapshot()
stats = snap2.compare_to(snap1, 'lineno')
for stat in stats[:10]:
print(stat)
# → shows top 10 lines that allocated most new memory between snapshots
JVM heap dump
# Live process
jcmd <pid> GC.heap_dump /tmp/heap.hprof
# On OOM
java -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heap.hprof MyApp
# Analyze with Eclipse MAT or VisualVM
# → "Leak Suspects Report" auto-identifies likely retainers
매 detached DOM leak
// BAD: cache holds reference to detached node
const cache = new Map();
function showModal(id) {
const node = document.createElement('div');
cache.set(id, node); // never deleted
document.body.appendChild(node);
// later: document.body.removeChild(node) — but cache still holds it
}
// GOOD: WeakMap or explicit cleanup
const cache = new WeakMap(); // doesn't prevent GC
// or: cache.delete(id) when modal closes
매 unbounded cache
// BAD: grows forever
const cache = {};
function memoize(key, fn) {
if (!(key in cache)) cache[key] = fn();
return cache[key];
}
// GOOD: LRU with max size
import LRU from 'lru-cache';
const cache = new LRU({ max: 1000, ttl: 1000 * 60 * 5 });
매 결정 기준
| 증상 | 진단 도구 |
|---|---|
| Node RSS 증가 | Chrome DevTools heap snapshot diff |
| Python 증가 | tracemalloc compare_to |
| JVM OOM | jcmd heap dump → Eclipse MAT |
| C/C++ | Valgrind, AddressSanitizer (-fsanitize=address) |
| Browser tab | DevTools Memory → Allocation timeline |
기본값: 매 3 snapshot diff — between 2nd & 3rd 사이의 retained 만 보면 매 startup noise 제거됨.
🔗 Graph
- 부모: Memory Management · Garbage Collection
- 변형: Mark-Sweep · Reference Counting
- 응용: Performance_Profiling_and_Memory
- Adjacent: WeakRef
🤖 LLM 활용
언제: long-running service (Node server, Python daemon, JVM app), browser SPA 가 시간 흐를수록 느려질 때. 언제 X: short-lived script — process exit 시 OS 가 다 회수.
❌ 안티패턴
- "GC lang 은 leak 없다": 매 reachable leak 이 매 가장 흔함.
- 단일 snapshot: 매 baseline 없으면 무엇이 leak 인지 모름 — 매 diff 가 정답.
- Premature optimization: 매 RSS 가 stable 한데 매 leak 추적 — 매 시간 낭비.
- try/catch 없는 cleanup: 매 error path 에서 listener removal 누락.
🧪 검증 / 중복
- Verified (V8 docs, Chrome DevTools docs, MDN, Node.js docs, Eclipse MAT).
- 신뢰도 A.
🕓 Changelog
| 날짜 | 변경 |
|---|---|
| 2026-05-08 | Phase 1 |
| 2026-05-10 | Manual cleanup — leak 분류 + Node/Python/JVM 진단 패턴 |