Antigravity Agent
43 lines
4.6 KiB
Markdown
43 lines
4.6 KiB
Markdown
---
|
|
id: P-REINFORCE-AUTO-E3AFF4
|
|
category: "10_Wiki/💡 Topics/Programming & Language"
|
|
confidence_score: 0.90
|
|
tags: [auto-reinforced]
|
|
last_reinforced: 2026-04-20
|
|
github_commit: "[P-Reinforce] Continuous Worker - Heap Snapshot"
|
|
---
|
|
|
|
# [[Heap Snapshot|Heap Snapshot]]
|
|
|
|
## 📌 한 줄 통찰 (The Karpathy Summary)
|
|
> Heap Snapshot은 특정 시점에 V8 엔진 및 JavaScript 애플리케이션의 전체 메모리 상태(객체 그래프)를 캡처하는 도구 및 기법입니다 [1, 2]. 주로 JavaScript 객체와 관련된 DOM 노드의 메모리 분포를 보여주며, 가비지 컬렉션(GC) 루트에서 도달할 수 있는 객체들만 캡처합니다 [3, 4]. 개발자는 여러 스냅샷을 비교하고 참조 유지 체인을 추적하여 프로그램 내에서 발생하는 메모리 누수를 찾아내고 원인을 분석하는 데 이 도구를 필수적으로 사용합니다 [1, 3, 5].
|
|
|
|
## 📖 구조화된 지식 (Synthesized Content)
|
|
- **작동 원리 및 객체 고유 식별:**
|
|
스냅샷 캡처는 메모리에 남은 실제 객체만 분석하기 위해 항상 가비지 컬렉션(GC) 수행으로 시작됩니다 [4]. 수집된 각 객체에는 `@` 기호가 붙은 고유 ID가 부여되는데, 이 ID는 여러 번의 스냅샷 생성 간에도 계속 유지되므로 개발자가 힙 상태와 객체의 변화를 정밀하게 추적하고 비교할 수 있습니다 [6-8].
|
|
- **핵심 메모리 평가 지표:**
|
|
스냅샷은 객체가 차지하는 메모리 크기를 주로 두 가지 기준으로 나누어 보여줍니다.
|
|
- *Shallow Size (얕은 크기):* 객체 자체가 직접적으로 점유하는 메모리 크기입니다. 일반적으로 배열과 문자열이 큰 Shallow Size를 가집니다 [9].
|
|
- *Retained Size (유지된 크기):* 해당 객체를 삭제하여 이에 종속된 다른 객체들이 더 이상 GC 루트에서 접근할 수 없게 되었을 때, GC를 통해 최종적으로 확보할 수 있는 전체 메모리 크기입니다 [9].
|
|
- **데이터 분석 뷰 (Chrome DevTools 기준):**
|
|
- *Summary View (요약 뷰):* 객체를 생성자(Constructor) 이름과 소스별로 그룹화하여 보여줍니다 [10, 11]. Detached DOM 노드 등 비효율적인 메모리 사용 패턴을 식별하고 필터링하는 데 유용합니다 [12].
|
|
- *Comparison View (비교 뷰):* 특정 작업의 수행 전후 등 두 개 이상의 스냅샷 간 차이를 비교합니다 [10, 13]. 해제된 메모리와 참조 횟수(Reference count)의 델타값을 조사하여 누수를 찾아내며, 보통 신뢰성을 높이기 위해 3번의 스냅샷을 찍어 비교하는 기법(Three-snapshot technique)이 권장됩니다 [5, 13].
|
|
- *Containment View (포함 뷰):* 애플리케이션 객체 구조에 대한 '조감도' 역할을 합니다 [14]. 클로저(Closure) 내부를 들여다보거나, 전역 네임스페이스(Window 등)에서 참조되는 VM 내부 객체의 세부적인 메모리 사용을 분석할 수 있습니다 [10, 14].
|
|
- *Statistics View (통계 뷰):* 코드, 문자열, JS 배열, 시스템 객체 등에 할당된 메모리의 상대적 크기를 파이 차트로 나타냅니다 [10].
|
|
- **Retainers (유지자) 추적:**
|
|
스냅샷에서 특정 객체를 선택하면 하단의 Retainers 패널에 해당 객체를 메모리에 살려두고 있는 참조 체인(GC 루트로부터의 경로)이 표시됩니다 [1, 15]. 개발자는 이 체인을 역추적하여 제거되지 않은 이벤트 리스너나 타이머 등 메모리 누수의 근본적인 원인을 정확히 짚어낼 수 있습니다 [1, 16].
|
|
|
|
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
|
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
|
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
|
|
|
## 🔗 지식 연결 (Graph)
|
|
- **Related Topics:** [[Garbage Collection (GC)|Garbage Collection (GC)]], [[Memory Leak|Memory Leak]], Shallow Size, Retained Size, Retainer Tree
|
|
- **Projects/Contexts:** [[Chrome DevTools|Chrome DevTools]], [[Node.js|Node.js]], [[V8 Engine|V8 Engine]]
|
|
- **Contradictions/Notes:** 모든 데이터가 JavaScript 힙 스냅샷에 기록되는 것은 아닙니다. 네이티브 코드를 실행하는 Getter를 통해 구현된 속성이나 숫자와 같은 비문자열(non-string) 값은 스냅샷에 캡처되지 않습니다 [11]. 또한, 원시 힙 데이터에는 수천 개의 V8 내부 객체가 포함되므로, 실제 애플리케이션의 메모리 누수를 찾으려면 "Constructor(생성자)" 필터를 사용하여 분석 대상을 좁혀야 합니다 [17].
|
|
|
|
---
|
|
*Last updated: 2026-04-19*
|
|
- Raw Source: 00_Raw/2026-04-20/Heap Snapshot.md
|
|
---
|