Unit 1.4 — Stack Area의 동작
F-LAB JAVA · 2주차 · Phase 1 · 자바 변수 ↔ 메모리 영역의 매핑
📌 학습 목표
이 Unit을 끝내면 다음을 답할 수 있어야 한다.
- 스택 프레임의 3개 구성 요소(Local Variable Array · Operand Stack · Frame Data)는?
-
int sum = a + b;한 줄이 Operand Stack에서 어떻게 처리되는가? - PC Register는 무엇을 가리키며, 왜 스레드별로 있어야 하는가?
- 메서드가 끝나면 반환값이 어떻게 호출자에게 전달되는가?
-
StackOverflowError가 발생하는 정확한 메커니즘은? - Stack Trace의 각 줄은 어디서 오는 정보인가?
- 운영 서버 thread dump를 어떻게 읽어야 하는가?
🎯 핵심 한 문장
Stack은 "메서드 호출의 발자취"를 담는 LIFO 자료구조다.
호출 한 번 = 프레임 push, 반환 한 번 = 프레임 pop.
각 프레임 안에는 지역 변수 배열 · 피연산자 스택 · 프레임 데이터가 있고,
JVM의 모든 산술/논리 연산은 피연산자 스택 위에서 일어난다.
비유 — 책상 위의 메모지 더미
| Stack 요소 | 비유 |
|---|---|
| Stack | 책상 위에 쌓은 메모지 더미 (LIFO) |
| Stack Frame | 메모지 1장 (메서드 1번 호출 = 1장) |
| Local Variable Array | 메모지의 상단 — 변수 이름과 값 (이 회의의 참석자/안건) |
| Operand Stack | 메모지의 하단 — 계산용 임시 메모 (계산 중인 숫자) |
| Frame Data | 메모지의 모서리 — 끝나면 어디로 돌아갈지 표시 |
| PC Register | 펜이 가리키는 줄 — "지금 여기 읽는 중" |
회의(메서드)가 끝나면 그 메모지(프레임)를 통째로 버리고, 이전 회의 메모지를 다시 봄.
🧭 9개 섹션 로드맵
1. Stack 복습 + 정밀화 — 1.2/1.3에서 본 것 위에 쌓기
2. 스택 프레임의 3가지 구성 요소
3. Local Variable Array — 지역 변수의 진짜 저장 방식
4. Operand Stack — JVM은 스택 머신이다
5. PC Register와 명령 추적 — 한 줄씩 명령을 따라가는 메커니즘
6. 메서드 호출과 반환의 전체 흐름
7. 멀티스레드와 Stack — 컨텍스트 스위칭의 핵심
8. ILIC 실무 + 디버깅 — Stack Trace · Thread Dump 읽기
9. 면접 질문 + 자기 점검1️⃣ Stack 복습 + 정밀화
1.1 1.2 / 1.3에서 본 것
Stack:
┌───────────────────────┐
│ add() 프레임 │ ← 현재 실행 중
│ 매개변수, 지역변수 │
├───────────────────────┤
│ run() 프레임 │
├───────────────────────┤
│ main() 프레임 │
└───────────────────────┘→ 메서드 호출마다 프레임이 쌓이고, 종료하면 사라진다.
→ 지역 변수와 매개변수가 그 안에 있다.
이번 Unit에서 정밀화할 것:
- 프레임 안에 정확히 무엇이 들어있는가
- 어떻게 계산이 일어나는가
- 다음 명령은 어떻게 찾는가
1.2 한 단계 더 들어간 그림
Stack Frame 1개:
┌────────────────────────────────────┐
│ 1. Local Variable Array │ ← 매개변수 + 지역 변수 (배열 형태)
│ [0]: this │
│ [1]: weight (매개변수) │
│ [2]: base (지역변수) │
│ [3]: ... │
├────────────────────────────────────┤
│ 2. Operand Stack │ ← 계산용 임시 스택
│ (현재 비어있음 또는 일부 값) │
├────────────────────────────────────┤
│ 3. Frame Data │ ← 메타 정보
│ Return Address: 호출자의 PC │
│ 상수 풀 참조 등 │
└────────────────────────────────────┘→ 이 3개가 모든 스택 프레임의 표준 구조.
2️⃣ 스택 프레임의 3가지 구성 요소
2.1 Local Variable Array (LVA)
지역 변수와 매개변수의 저장소. 배열 형태로 관리.
public BigDecimal calculate(int weight, BigDecimal rate) {
BigDecimal base = new BigDecimal("100");
BigDecimal result = base.multiply(rate);
return result;
}LVA의 모습:
Local Variable Array (인덱스 기반):
[0] this ← 인스턴스 메서드의 숨겨진 첫 매개변수
[1] weight ← 매개변수 1
[2] rate ← 매개변수 2
[3] base ← 지역 변수
[4] result ← 지역 변수static 메서드면
[0]부터 첫 매개변수가 시작.
바이트코드에서의 모습 (Phase 3 미리보기):
iload_1 ← LVA[1] 로드 (weight)
aload_2 ← LVA[2] 로드 (rate)
astore_3 ← LVA[3]에 저장 (base)iload_X, astore_X 같은 명령이 LVA의 인덱스로 변수에 접근한다.
2.2 Operand Stack (피연산자 스택)
JVM이 산술/논리 연산을 수행하는 임시 작업 공간.
int sum = 1 + 2;Operand Stack 동작:
Step 1: iconst_1 [1] ← 1을 푸시
Step 2: iconst_2 [1, 2] ← 2를 푸시
Step 3: iadd [3] ← 위 2개를 꺼내 더한 값 푸시
Step 4: istore_1 [] ← 결과를 LVA[1]에 저장핵심: JVM은 레지스터 머신이 아니라 스택 머신.
- x86 CPU:
add eax, ebx(레지스터끼리 직접 연산) - JVM:
값을 스택에 푸시 → 연산 명령 → 결과가 스택에 남음
2.3 Frame Data
프레임의 메타 정보가 들어가는 영역.
- Return Address: 메서드 종료 시 호출자의 어느 명령으로 돌아갈지 (PC 값)
- 상수 풀 참조: 이 메서드가 속한 클래스의 상수 풀 위치
- 예외 테이블 참조: try-catch의 catch 블록 위치
→ 이 영역은 JVM 구현체마다 세부 구조가 다름. 개념적으로 이해하면 충분.
2.4 정리 — 프레임 1개의 풀 그림
public class App {
public static int add(int a, int b) {
int sum = a + b;
return sum;
}
}add(10, 20) 호출 직후, 끝나기 직전의 프레임:
add() 프레임:
┌──────────────────────────────────┐
│ Local Variable Array │
│ [0] a = 10 │ ← (static이라 this 없음)
│ [1] b = 20 │
│ [2] sum = 30 │
├──────────────────────────────────┤
│ Operand Stack │
│ [bottom] ... [top: 30] │ ← ireturn 직전, 반환값 푸시 상태
├──────────────────────────────────┤
│ Frame Data │
│ Return Address → 호출자 PC │
│ 상수 풀 참조 │
└──────────────────────────────────┘3️⃣ Local Variable Array — 지역 변수의 진짜 저장 방식
3.1 배열 인덱스로 변수 접근
JVM 입장에서 변수 이름은 컴파일 시점에 사라진다. 바이트코드에는 인덱스만 남는다.
public void process(int x, int y) {
int sum = x + y;
String msg = "result";
}LVA:
[0] this ← 인스턴스 메서드의 숨은 매개변수
[1] x ← 첫 매개변수
[2] y ← 두 번째 매개변수
[3] sum ← 지역 변수 1
[4] msg ← 지역 변수 2→ "x" 라는 이름은 디버깅 정보에만 남음 (javac -g).
→ 실제 실행은 인덱스로.
3.2 long / double은 2칸 차지
public void method(int a, long b, double c, int d) {}LVA:
[0] this
[1] a ← int, 1칸
[2] b ← long, 2칸 차지 시작
[3] " ← (b의 두 번째 칸)
[4] c ← double, 2칸 차지 시작
[5] " ← (c의 두 번째 칸)
[6] d ← int, 1칸→ long과 double은 64비트라 2개의 슬롯 사용.
→ 면접에선 잘 안 나오지만, 바이트코드 읽을 때 알아두면 좋음.
3.3 슬롯 재사용
public void method() {
{
int a = 10; // LVA[1] 사용
} // 블록 끝 → a 사라짐
{
String b = "x"; // LVA[1] 재사용 가능!
}
}LVA의 슬롯은 스코프가 끝나면 재사용된다.
→ 메서드 안에서 변수 100개 선언해도, 같은 시점에 살아있는 것만 슬롯 차지.
→ 컴파일러가 최적화.
3.4 디버깅 시 — LocalVariableTable
javac -g App.java # 디버그 정보 포함
javap -v -p App.class출력 일부:
LocalVariableTable:
Start Length Slot Name Signature
0 6 0 this LApp;
0 6 1 x I
0 6 2 y I
3 3 3 sum I→ Slot이 LVA 인덱스, Signature가 타입(I=int, L...;=object).
→ IDE 디버거가 보여주는 변수 이름의 출처.
4️⃣ Operand Stack — JVM은 스택 머신이다
4.1 왜 스택 머신인가
JVM의 모든 계산은 피연산자 스택 위에서 일어난다.
레지스터 머신 (x86 CPU):
add eax, ebx ; eax = eax + ebx스택 머신 (JVM):
iload_1 ; 첫 번째 값을 스택에 푸시
iload_2 ; 두 번째 값을 스택에 푸시
iadd ; 위 두 개를 꺼내 더하고 결과를 푸시
istore_3 ; 스택 top을 LVA[3]에 저장장점:
- CPU 독립적: 어떤 CPU(x86, ARM, RISC-V)에서도 같은 바이트코드 동작
- 단순한 명령어 집합: 레지스터 할당 불필요
- 컴파일러 단순화: 표현식 트리 → 스택 명령으로 직선 변환
단점:
- 명령어 수가 많음 (레지스터 머신보다)
- → JIT 컴파일러가 런타임에 레지스터 기반 네이티브 코드로 최적화
4.2 핵심 명령어 카테고리
| 카테고리 | 명령어 예 | 동작 |
|---|---|---|
| 상수 로드 | iconst_0, iconst_1, bipush 100 | 스택에 상수 푸시 |
| 변수 로드 | iload_1, aload_2, lload_3 | LVA → 스택 푸시 |
| 변수 저장 | istore_1, astore_2 | 스택 pop → LVA 저장 |
| 산술 | iadd, isub, imul, idiv | 스택 top 2개 연산 |
| 메서드 호출 | invokestatic, invokevirtual, invokespecial | 스택 인자 사용, 결과 푸시 |
| 반환 | ireturn, areturn, return | 스택 top을 호출자 스택으로 |
| 분기 | ifeq, ifne, goto | PC 점프 |
i = int, a = address(reference), l = long, f = float, d = double.
4.3 추적 예시 — int sum = a + b;
public int add(int a, int b) {
int sum = a + b;
return sum;
}바이트코드:
0: iload_1 // a 로드
1: iload_2 // b 로드
2: iadd // a + b
3: istore_3 // sum에 저장
4: iload_3 // sum 로드
5: ireturn // 반환add(10, 20) 호출 시 Operand Stack 변화:
LVA: [this=ref, a=10, b=20, sum=?]
PC=0: iload_1
Stack: [10] ← a를 푸시
PC=1: iload_2
Stack: [10, 20] ← b를 푸시
PC=2: iadd
Stack: [30] ← 10과 20을 꺼내 더하고 30 푸시
PC=3: istore_3
Stack: [] ← 30 꺼내서 LVA[3]에 저장
LVA: [this, 10, 20, 30]
PC=4: iload_3
Stack: [30] ← LVA[3] 푸시
PC=5: ireturn
Stack: [] (호출자 스택에 30 푸시) ← 30을 반환→ 모든 연산이 스택 푸시 / 팝 패턴.
4.4 메서드 호출도 스택 위에서
String s = "Hello".toUpperCase();바이트코드:
0: ldc "Hello" // 상수 풀에서 "Hello" 로드
2: invokevirtual #N // toUpperCase // top의 String 객체로 메서드 호출
5: astore_1 // 결과 저장PC=0: ldc "Hello"
Stack: ["Hello"]
PC=2: invokevirtual toUpperCase
- "Hello" pop
- toUpperCase() 호출 (새 프레임 push)
- 반환값 "HELLO" 를 우리 스택에 push
Stack: ["HELLO"]
PC=5: astore_1
Stack: []
LVA: [this, "HELLO"]→ 메서드 호출 = 인자를 스택에 쌓고 invoke 명령 → 호출된 메서드는 그 인자들을 LVA로 받음 → 반환값은 호출자 스택에 다시 push.
5️⃣ PC Register와 명령 추적
5.1 PC Register란
Program Counter Register — JVM이 현재 실행 중인 바이트코드 명령의 위치를 가리키는 포인터.
add() 메서드의 바이트코드:
0: iload_1 ◄── PC가 여기를 가리키는 중
1: iload_2
2: iadd
3: istore_3
...명령이 실행될 때마다 PC가 다음 명령으로 이동.
분기(if, goto, return)는 PC를 다른 위치로 점프시킴.
5.2 왜 스레드별로 있어야 하는가
Thread 1 Thread 2
PC = method1+5 PC = method2+12
↓ ↓
각자 다른 명령을 동시에 실행각 스레드는 자기만의 실행 위치를 가진다.
공유하면 → 모두가 같은 위치에서 같은 명령을 실행 → 동시성 의미 없음.
→ Stack과 PC Register는 같이 스레드별. 한 세트.
5.3 메서드 호출 시 PC의 동작
public void caller() {
int x = 10; // PC=0~2
int y = callee(); // PC=3~5 (invoke)
use(y); // PC=6~...
}
public int callee() {
return 42;
}호출 흐름:
1. caller PC=3 — invokestatic callee
2. Frame Data에 Return Address = 6 저장 (호출자의 다음 PC)
3. callee 프레임 push, PC = callee의 0번
4. callee 실행 완료
5. ireturn — 반환값을 caller의 Operand Stack에 push
6. callee 프레임 pop
7. caller로 복귀 — PC를 Return Address (=6) 로 복원
8. caller PC=6부터 계속→ Frame Data의 Return Address가 정확히 이 메커니즘을 위해 존재.
5.4 Native 메서드와 PC
public native void method(); // JNINative 메서드 실행 중에는 PC Register는 undefined.
→ JVM 바이트코드가 아닌 C/C++ 코드를 실행 중이라, JVM의 PC가 의미 없음.
→ JNI 호출 정보는 Native Method Stack에 따로 저장.
5.5 PC를 직접 보는 도구
운영 중인 JVM의 현재 명령 위치는 thread dump에서 확인 가능.
jstack <PID>출력:
"http-nio-8080-exec-1" #25 daemon prio=5 tid=0x... nid=0x... runnable
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
...→ 각 줄이 스택의 한 프레임.
→ "현재 PC가 어느 메서드의 어느 줄을 가리키는가" 의 시각화.
6️⃣ 메서드 호출과 반환의 전체 흐름
6.1 호출 7단계
caller() {
...
int result = callee(10, 20);
...
}-
인자 준비: caller의 Operand Stack에 인자 push
Caller Stack: [10, 20] -
invoke 명령 실행:
invokestatic,invokevirtual등 -
새 프레임 생성: callee의 프레임 push
Stack: ┌────────────┐ │ callee │ ◄── 새 프레임 ├────────────┤ │ caller │ └────────────┘ -
인자 이동: caller의 Operand Stack top → callee의 LVA
callee LVA: [10, 20] Caller Stack: [] -
Return Address 저장: callee의 Frame Data에 caller의 다음 PC 저장
-
PC 이동: PC를 callee의 첫 명령으로
-
callee 실행 시작
6.2 반환 5단계
callee의 마지막: ireturn-
반환값 결정: callee의 Operand Stack top이 반환값
callee Stack: [30] ← 반환할 값 -
프레임 pop: callee 프레임 제거
-
PC 복원: Frame Data의 Return Address → PC
-
반환값 push: caller의 Operand Stack에 30 push
Caller Stack: [30] -
caller 계속: PC가 가리키는 곳부터 실행 (예:
istore_X)
6.3 void 반환
public void log(String msg) {
System.out.println(msg);
return; // 또는 생략
}→ 반환값 없음. 그냥 프레임 pop + PC 복원.
→ caller의 Operand Stack에는 아무것도 push되지 않음.
6.4 예외 발생 시
public int divide(int a, int b) {
return a / b; // b=0이면 ArithmeticException
}- ArithmeticException 객체 생성 (Heap)
- divide의 예외 테이블 검사 → 매칭되는 catch 없음
- 프레임 pop
- caller로 예외 전파
- caller의 예외 테이블 검사 → ...
- 반복하다 main까지 도달 → JVM 종료
→ 예외도 Stack을 거꾸로 거슬러 올라간다.
→ 이게 Stack Trace의 정체.
7️⃣ 멀티스레드와 Stack — 컨텍스트 스위칭
7.1 스레드별 Stack의 진정한 의미
Process (JVM)
├─ Thread A ──── Stack A + PC A
├─ Thread B ──── Stack B + PC B
└─ Thread C ──── Stack C + PC C
모두 공유:
Heap + Method Area각 스레드는:
- 자기 Stack (지역 변수 안 섞임)
- 자기 PC Register (실행 위치 따로)
- 자기 Native Method Stack
공유하는 것:
- Heap (객체)
- Method Area (클래스 정보)
→ 그래서 멀티스레드 환경에서 Heap의 객체 접근만 동기화하면 됨.
7.2 컨텍스트 스위칭
OS가 한 스레드에서 다른 스레드로 CPU를 넘기는 작업.
Thread A 실행 중:
CPU 레지스터 ← Thread A의 PC, SP, 작업 데이터
CPU 컨텍스트 스위칭:
1. Thread A의 CPU 상태를 메모리에 저장
2. Thread B의 저장된 CPU 상태를 레지스터에 복원
3. Thread B 실행 시작각 스레드가 자기 Stack과 PC를 따로 가지고 있어야 컨텍스트 스위칭이 가능.
7.3 ILIC에서 마주칠 멀티스레드 시나리오
@RestController
public class ShipmentController {
private final ShipmentService service; // 모든 스레드 공유
@GetMapping("/{id}")
public ShipmentResponse get(@PathVariable Long id) {
// 이 메서드는 톰캣의 worker thread 풀의 어떤 스레드가 실행
// - 각 요청마다 새 Stack 프레임
// - id는 그 스레드의 Stack에만 존재
return ShipmentResponse.from(service.findById(id));
}
}HTTP 요청 100개 동시 → 톰캣 worker 100개 (또는 NIO + 적은 worker)
각 worker:
자기 Stack
- id 변수
- shipment 지역 변수
자기 PC
- 지금 어디 실행 중인지
공유:
ShipmentController 인스턴스 (Heap)
ShipmentService 인스턴스 (Heap)
Shipment 클래스 정보 (Method Area)7.4 ThreadLocal — 스레드별 데이터의 또 다른 보관소
private static final ThreadLocal<String> userContext = new ThreadLocal<>();
// 스레드 A에서
userContext.set("user-001");
// 같은 스레드 A의 다른 메서드에서
userContext.get(); // "user-001"
// 스레드 B에서
userContext.get(); // null ← 다른 스레드는 못 봄→ Stack의 지역 변수는 메서드 종료 시 사라짐.
→ ThreadLocal은 스레드 단위로 살아남는 변수.
→ Spring Security, 트랜잭션 등에서 활용.
⚠️ 누수 위험: ThreadLocal은 Heap에 저장됨. Worker thread가 재사용되는 톰캣 환경에서 remove() 안 하면 메모리 누수.
try {
userContext.set(user);
process();
} finally {
userContext.remove(); // ★ 반드시
}→ 1주차 try-with-resources 패턴과 연결.
8️⃣ ILIC 실무 + 디버깅
8.1 Stack Trace 읽기 — 가장 기본
java.lang.NullPointerException
at com.ilic.shipment.ShipmentService.calculate(ShipmentService.java:45)
at com.ilic.shipment.ShipmentController.get(ShipmentController.java:23)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
...읽는 법:
- 위에서부터 아래로 = 호출 역순 (현재 → 호출한 곳)
- 가장 위의 줄 = 예외가 실제 발생한 위치 (45번 줄)
- 그 아래 줄 = 그 메서드를 호출한 곳 (23번 줄)
at= "여기에서 호출했음"
각 줄은 스택 프레임 1개. 예외 발생 시 위에서 아래로 Stack을 dump한 것.
8.2 Caused by와 Suppressed (1주차 Unit 7.1 연결)
java.lang.RuntimeException: 운임 계산 실패
at com.ilic.shipment.FareCalculator.compute(FareCalculator.java:78)
at com.ilic.shipment.ShipmentService.calculate(ShipmentService.java:45)
...
Caused by: java.sql.SQLException: ORA-01017
at oracle.jdbc.driver.OraclePreparedStatement.execute(...)
...
Suppressed: java.io.IOException: connection reset
at ...- Caused by: 원인 예외 (예외 체이닝)
- Suppressed: try-with-resources의 close에서 발생한 예외
→ 운영에서 Caused by를 추적해 진짜 원인 찾기.
8.3 운영 서버 Thread Dump
# 1. JVM PID 확인
jps -l
# 2. Thread dump 생성
jstack <PID> > thread-dump.txt
# 3. 시점을 여러 번 떠서 비교 (3~5초 간격, 3번 정도)
jstack <PID> > dump1.txt
sleep 3
jstack <PID> > dump2.txt
sleep 3
jstack <PID> > dump3.txt8.4 Thread Dump 분석 — Deadlock 탐지
"Thread-A" #11 prio=5 ... waiting for monitor entry [...]
java.lang.Thread.State: BLOCKED (on object monitor)
at com.ilic.LockService.methodA(LockService.java:30)
- waiting to lock <0x000000076c123000> (a java.lang.Object)
- locked <0x000000076c456000> (a java.lang.Object)
"Thread-B" #12 prio=5 ... waiting for monitor entry [...]
java.lang.Thread.State: BLOCKED (on object monitor)
at com.ilic.LockService.methodB(LockService.java:50)
- waiting to lock <0x000000076c456000> (a java.lang.Object)
- locked <0x000000076c123000> (a java.lang.Object)해독:
- Thread-A는 0x...456000을 잡고, 0x...123000을 기다림
- Thread-B는 0x...123000을 잡고, 0x...456000을 기다림
- → 데드락
jstack은 데드락을 자동 감지해서 출력 끝에 표시:
Found one Java-level deadlock:
=============================
"Thread-A": waiting to lock monitor 0x00..., which is held by "Thread-B"
"Thread-B": waiting to lock monitor 0x00..., which is held by "Thread-A"8.5 BLOCKED / WAITING 스레드 찾기
운영 장애 흔한 원인:
- 다수 스레드가 같은 모니터에서
BLOCKED→ 락 경합 - DB Connection Pool 대기 →
WAITING (on object monitor) - HTTP 외부 호출 무한 대기 →
RUNNABLE이지만socketRead멈춤
ILIC 시나리오:
- 톰캣 worker 200개가 모두 BLOCKED → 추가 요청 처리 불가 → 서비스 다운
- Thread dump를 떠서 어디서 막혔는지 추적
8.6 StackOverflowError 원인 분석
public BigDecimal calculateRecursive(int depth) {
return calculateRecursive(depth + 1); // 무한 재귀
}발생:
Exception in thread "main" java.lang.StackOverflowError
at ShipmentService.calculateRecursive(ShipmentService.java:10)
at ShipmentService.calculateRecursive(ShipmentService.java:10)
at ShipmentService.calculateRecursive(ShipmentService.java:10)
...
(수천 줄)해결 옵션:
1. 로직 수정: 종료 조건 추가
2. 반복문 변환: 재귀를 while/for로
3. -Xss 증가: 깊은 재귀가 필요한 경우 (최후의 수단)
java -Xss2m MyApp # 스택 크기 2MB로8.7 운영 가이드 — JVM 옵션 모음
# Stack 크기
-Xss512k # 기본 약 512KB ~ 1MB
# Thread Dump를 시그널로 받기 (Unix)
kill -3 <PID> # JVM이 stderr에 thread dump 출력
# Heap dump on OOM (1.2 Unit에서 본 것)
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/var/log/app/
# Async-profiler 같은 도구도 Stack 정보 활용9️⃣ 면접 질문 + 자기 점검
9.1 면접 단골 질문 매핑
| Q | 핵심 답변 |
|---|---|
| 스택 프레임의 3가지 구성 요소? | Local Variable Array · Operand Stack · Frame Data |
| JVM이 스택 머신이라는 의미? | 모든 산술 연산이 Operand Stack의 push/pop으로 일어남 |
int sum = a + b의 바이트코드? | iload_1 → iload_2 → iadd → istore_3 |
| Local Variable Array의 [0]은 보통 무엇? | 인스턴스 메서드의 this (static이면 첫 매개변수) |
| PC Register가 스레드별인 이유? | 각 스레드가 독립적으로 다른 명령을 실행 중. 공유하면 동시성 의미 없음 |
| 메서드 호출 시 Return Address는 어디에? | 새 프레임의 Frame Data에 저장 (호출자의 다음 PC) |
| 메서드 반환 시 반환값 전달? | callee의 Operand Stack top → caller의 Operand Stack에 push |
| StackOverflowError vs OutOfMemoryError 차이? | 전자는 Stack 영역, 후자는 Heap/Metaspace 등 다른 영역 |
| Thread Dump를 어떻게 읽나? | 위→아래가 호출 역순. 최상단이 현재 실행 위치 |
long이 LVA에서 2슬롯 차지하는 이유? | 64비트라 32비트 슬롯 2개 사용 |
9.2 자기 점검 체크리스트
기본 이해
- 스택 프레임의 3가지 구성 요소를 안다
- LVA가 배열 인덱스로 변수에 접근함을 안다
- Operand Stack의 동작(push/pop으로 연산)을 안다
- PC Register의 역할과 스레드별 분리 이유를 안다
- 메서드 호출과 반환의 전체 흐름을 그릴 수 있다
실전 적용
-
int sum = a + b의 바이트코드를 추적할 수 있다 - Stack Trace의 각 줄이 무엇을 의미하는지 안다
- Thread Dump를 만들고 BLOCKED 스레드를 찾을 수 있다
- Deadlock 패턴을 thread dump에서 식별할 수 있다
- StackOverflowError 원인을 코드와 dump로 분석할 수 있다
면접 대비 — 5분 답변
- 스택 프레임 구조와 동작
- JVM이 스택 머신인 이유
- PC Register와 컨텍스트 스위칭
- 예외와 Stack Trace의 관계
- ThreadLocal과 Stack의 차이
🎯 핵심 요약 — 3줄 정리
1. 스택 프레임 = LVA + Operand Stack + Frame Data
- LVA: 지역 변수와 매개변수 (배열 인덱스로 접근)
- Operand Stack: 연산 임시 공간 (JVM은 스택 머신)
- Frame Data: Return Address 등 메타 정보
2. JVM의 모든 연산은 Operand Stack 위에서
- 변수 → 스택 push → 연산 → 결과 스택 → 변수 저장
- 메서드 호출도 인자를 스택에 쌓고 invoke
- 반환값은 호출자 스택에 push
3. 멀티스레드 = 스레드별 Stack + PC
- 각 스레드는 자기 Stack과 PC를 가짐
- Heap과 Method Area만 공유 → 동기화 대상
- Thread Dump = 모든 스레드의 Stack 스냅샷
📚 다음으로...
Unit 1.5 — Heap과 객체-Metadata 연결
이번 Unit에서 메서드가 Stack에서 어떻게 실행되는지 봤다면, 다음은 Heap의 객체가 자기 클래스 메서드를 어떻게 찾아가는지 정밀하게 본다.
- Object Header의 Class Pointer
- VMT (Virtual Method Table)
- 메서드 호출 시 dispatch 메커니즘
invokevirtualvsinvokespecialvsinvokestaticvsinvokeinterface- 다형성의 메모리 구현 (1주차 Unit 2.4의 내부)
2주차 진행 상황
- ✅ Unit 1.1 자바 변수의 3종류
- ✅ Unit 1.2 변수별 저장 위치
- ✅ Unit 1.3 Method Area의 3개 존 ★
- ✅ Unit 1.4 Stack Area의 동작 — 이 문서
- ⏭ Unit 1.5 Heap과 객체-Metadata 연결
- ⏭ Unit 1.6 Literal Pool Area
- ⏭ Phase 2 (메서드 실행 메커니즘)
- ⏭ Phase 3 (바이트코드와 상수 풀) ★ 정점
Phase 3로 가는 길 — 점점 가까워지는 바이트코드
이번 Unit에서 iload_1, iadd, istore_3 같은 바이트코드를 자연스럽게 봤다.
Phase 3에서는 이런 명령들을 javap -c -v로 직접 디컴파일하면서 상수 풀과 함께 읽는다.
이번 Unit의 추상화 수준:
iload_1 → "LVA[1] 값을 스택에 푸시"
Phase 3에서 보게 될 수준:
3: invokespecial #1 // Method java/lang/Object."<init>":()V
→ #1이 상수 풀의 1번 항목 → "java/lang/Object"의 "<init>"의 시그니처 "()V"
Software Developer