Unit 2.1 — 메서드 호출의 2단계 처리
F-LAB JAVA · 2주차 · Phase 2 · JVM 메서드 실행 메커니즘
🚀 Phase 2 시작 — Phase 1의 메모리 구조 위에서 메서드 호출 추적
📌 학습 목표
이 Unit을 끝내면 다음을 답할 수 있어야 한다.
- 메서드 호출은 왜 1단계가 아니라 2단계로 분리되어 있나?
- Method Resolution 과 Method Invocation 의 차이는?
- 컴파일 시점에 결정되는 메서드와 런타임에 결정되는 메서드를 어떻게 구분하나?
-
s.calculate()한 줄이 JVM에서 정확히 어떤 순서로 처리되나? - 다형성·오버라이딩이 이 2단계 구조에 어떻게 의존하나?
- Spring AOP, JPA Proxy가 이 메커니즘을 어떻게 활용하나?
🎯 핵심 한 문장
모든 메서드 호출은 "무엇을 호출하는가"(시그니처 확인) 와 "그 실체는 어디에 있는가"(바이트코드 실행) 의 2단계로 분리된다.
Class Metadata Zone에서 시그니처를 확인하고, Static/Non-Static Zone에서 실제 바이트코드를 실행한다.
이 분리가 다형성·AOP·동적 프록시를 모두 가능하게 만드는 근본 메커니즘이다.
비유 — 식당 주문 처리
| 단계 | 식당 비유 | JVM |
|---|---|---|
| 1단계 | 손님이 "스파게티 하나" 라고 외침 | "calculate() 호출하자" — 시그니처 |
| 2단계 | 주방에서 "스파게티 레시피" 찾아 조리 | 실제 바이트코드 실행 |
- 메뉴(시그니처)와 레시피(바이트코드)는 별도 보관
- 같은 메뉴라도 주방장(객체 타입)이 다르면 다른 레시피 사용 → 다형성
🧭 9개 섹션 로드맵
1. 우리가 보는 한 줄 vs JVM이 하는 작업
2. 1단계 — Method Resolution (시그니처 확인)
3. 2단계 — Method Invocation (바이트코드 실행)
4. Static Dispatch vs Dynamic Dispatch
5. 메서드 영역 — 시그니처와 바이트코드 매핑
6. 다형성·오버라이딩이 의존하는 2단계
7. ILIC 실무 — Spring AOP · JPA Proxy의 비밀
8. 흔한 실수 + 성능 이슈
9. 면접 질문 + 자기 점검1️⃣ 우리가 보는 한 줄 vs JVM이 하는 작업
1.1 단순해 보이는 코드 한 줄
Shipment s = repository.findById(1L).orElseThrow();
BigDecimal fare = s.calculate(100); // ← 이 한 줄우리가 보기에:
"s 객체의 calculate 메서드를 100 인자로 호출"
JVM이 실제로 하는 일은 훨씬 많다.
1.2 JVM이 내부적으로 하는 일
"s.calculate(100)" 한 줄을 만났을 때:
🔍 Phase A: Method Resolution (메서드 결정)
1. s의 참조 따라가서 Heap의 객체 찾기
2. 객체의 Class Pointer → Shipment Klass
3. Klass의 Class Metadata Zone에서 "calculate(int)" 시그니처 찾기
4. 메서드 접근 권한 검증 (public? private?)
5. 메서드 호출 방식 결정 (virtual? special? static?)
🚀 Phase B: Method Invocation (메서드 실행)
1. 해당 메서드의 바이트코드 위치 찾기 (Static or Non-Static Zone)
2. 새 스택 프레임 생성 (LVA 크기 결정, Operand Stack 초기화)
3. 매개변수와 this 전달
4. PC를 메서드 첫 명령으로 이동
5. 바이트코드 실행 시작→ "무엇을 부를지" 와 "어떻게 부를지" 는 다른 단계.
1.3 왜 분리되어 있나 — 3가지 이유
이유 1 — 다형성을 가능하게 함
Cargo c = getCargo(); // DryCargo? ReeferCargo? HazmatCargo?
c.calculateFee(); // 어느 메서드 호출?만약 1단계만으로 끝나면 컴파일 시점에 모든 게 결정돼야 함.
2단계 구조 덕에 1단계(시그니처)는 컴파일 타임에, 2단계(실제 메서드)는 런타임에 결정 가능.
이유 2 — AOP·Proxy 같은 메타 프로그래밍
@Transactional
public Shipment save(Shipment s) { ... }Spring은 이 메서드 호출을 가로채서 @Transactional 동작을 추가.
어떻게? → 1단계(시그니처)는 그대로 두고 2단계(실행)를 프록시 객체로 바꿔치기.
이유 3 — 클래스 로딩 지연(Lazy Loading)
// 컴파일 시점:
SomeClass.someMethod(); // ← 호출만 컴파일
// 런타임 시점:
// 1단계에서 SomeClass가 처음 로딩됨
// 2단계에서 실제 메서드 바이트코드 실행→ 호출되지 않는 클래스는 메모리에 로딩 안 됨. JVM의 lazy loading 전략.
2️⃣ 1단계 — Method Resolution
2.1 Class Metadata Zone에서 일어나는 일
Unit 1.3에서 본 Class Metadata Zone 의 내용 중:
Shipment 클래스의 Metadata:
...
├─ 메서드 시그니처 목록:
│ ├─ calculate(int) : BigDecimal (public)
│ ├─ setBlNo(String) : void (public)
│ ├─ validate() : void (private)
│ ├─ getId() : Long (public)
│ └─ ...
└─ 상수 풀 (Constant Pool)이 시그니처 목록에서 호출하려는 메서드를 찾는 작업이 1단계.
2.2 시그니처가 뭔가
자바에서 메서드 시그니처 = 이름 + 매개변수 타입 (순서대로).
반환 타입은 시그니처에 포함 안 됨 (오버로딩 규칙).
public BigDecimal calculate(int weight) // calculate(I)
public BigDecimal calculate(int weight, BigDecimal rate) // calculate(I, BigDecimal)
public Integer calculate(int weight) // ❌ 시그니처 충돌 (반환 타입만 다름)JVM 내부 표기:
calculate(I)Ljava/math/BigDecimal;
↑ ↑
매개변수 디스크립터 반환 디스크립터
I = int
Ljava/math/BigDecimal; = BigDecimal 객체
V = void→ 1단계에서 JVM은 이 디스크립터로 정확한 메서드를 식별.
2.3 Resolution의 세부 단계
1단계 — Method Resolution 흐름:
┌─────────────────────────────────────────┐
│ 1. 호출 사이트(call site)의 상수 풀 인덱스 │
│ 예: invokevirtual #15 │
└──────────────┬──────────────────────────┘
▼
┌─────────────────────────────────────────┐
│ 2. 상수 풀의 #15 항목 = MethodRef │
│ → "Shipment.calculate(I)BigDecimal" │
└──────────────┬──────────────────────────┘
▼
┌─────────────────────────────────────────┐
│ 3. Shipment 클래스의 Method Table 검색 │
│ → calculate(I) 발견 │
└──────────────┬──────────────────────────┘
▼
┌─────────────────────────────────────────┐
│ 4. 접근 권한 / abstract 여부 검증 │
└──────────────┬──────────────────────────┘
▼
┌─────────────────────────────────────────┐
│ 5. 메서드 항목(Method 구조체) 반환 │
│ → 바이트코드 위치 포함 │
└─────────────────────────────────────────┘→ 상수 풀의 인덱스 → 실제 메서드 객체 로 변환되는 과정.
→ Phase 3에서 상수 풀과 함께 더 깊이 본다.
2.4 부모 클래스 탐색
해당 클래스에 메서드가 없으면 부모 체인을 따라 탐색.
class BaseEntity {
public void touch() { lastModifiedAt = LocalDateTime.now(); }
}
class Shipment extends BaseEntity {
// touch() 안 정의
}
Shipment s = new Shipment();
s.touch(); // 호출됨Resolution 흐름:
Shipment.touch() 검색
→ 없음
→ 부모 BaseEntity.touch() 검색
→ 발견
→ 그 메서드 사용→ 상속 관계는 Resolution 단계에서 처리.
2.5 한 번 Resolve된 결과는 캐시됨
for (int i = 0; i < 1000000; i++) {
shipment.calculate(100); // 100만 번 호출
}매번 Resolution하면 너무 비싸. JVM은 한 번 Resolve된 결과를 인라인 캐시에 저장.
첫 호출: Resolution 수행 (느림)
이후 호출: 캐시된 메서드 직접 호출 (매우 빠름)→ Resolution 비용은 첫 호출에서만. 이후는 빠른 호출.
3️⃣ 2단계 — Method Invocation
3.1 Static/Non-Static Zone에서 일어나는 일
1단계에서 결정된 메서드의 바이트코드를 실제로 실행하는 단계.
2단계 — Method Invocation 흐름:
┌─────────────────────────────────────────┐
│ 1. 메서드의 바이트코드 위치 확정 │
│ → Static Zone (static) 또는 │
│ Non-Static Zone (instance) │
└──────────────┬──────────────────────────┘
▼
┌─────────────────────────────────────────┐
│ 2. 새 스택 프레임 생성 │
│ - LVA 크기 결정 (메타데이터에서 읽음) │
│ - Operand Stack 초기화 │
│ - Return Address 저장 │
└──────────────┬──────────────────────────┘
▼
┌─────────────────────────────────────────┐
│ 3. 매개변수 전달 │
│ - 호출자 Operand Stack → 새 LVA │
│ - 인스턴스 메서드면 this도 함께 │
└──────────────┬──────────────────────────┘
▼
┌─────────────────────────────────────────┐
│ 4. PC 이동 + 바이트코드 실행 시작 │
└─────────────────────────────────────────┘→ Unit 1.4에서 본 스택 프레임 동작 + Unit 1.5의 invoke 명령이 결합.
3.2 바이트코드 실행은 Unit 1.4의 연장
public BigDecimal calculate(int weight) {
BigDecimal base = new BigDecimal("100");
return base.multiply(BigDecimal.valueOf(weight));
}2단계 실행 흐름:
PC=0: new BigDecimal ← Heap에 BigDecimal 객체 생성
PC=N: ldc "100" ← 상수 풀에서 String 푸시
PC=N: invokespecial <init> ← 생성자 호출 (재귀적으로 2단계 발생)
PC=N: astore_2 ← base에 저장
PC=N: aload_2 ← base 로드
PC=N: iload_1 ← weight 로드
PC=N: invokestatic BigDecimal.valueOf ← 또 다른 메서드 호출 (재귀적 2단계)
PC=N: invokevirtual multiply ← 또 다른 메서드 호출
PC=N: areturn ← 결과 반환→ 메서드 안에서 또 메서드를 호출하면 또 1+2단계 발생. 재귀적.
3.3 메서드 종료 시
1. 반환값을 호출자의 Operand Stack에 push
2. 현재 프레임 pop
3. Return Address로 PC 복원
4. 호출자가 자기 코드 계속→ Unit 1.4의 메서드 반환과 정확히 동일.
4️⃣ Static Dispatch vs Dynamic Dispatch
4.1 두 가지 디스패치 방식
| Static Dispatch | Dynamic Dispatch | |
|---|---|---|
| 결정 시점 | 컴파일 타임 | 런타임 |
| 사용 명령 | invokestatic, invokespecial | invokevirtual, invokeinterface |
| 대상 | static, private, final, super, 생성자 | 일반 인스턴스 메서드 |
| 다형성 | ❌ | ✓ |
| 속도 | 빠름 | 빠름 (인라인 캐시 후) |
4.2 Static Dispatch — 컴파일 타임 결정
// 컴파일러가 알 수 있는 것:
Math.max(10, 20); // ← Math 클래스의 static max
super.toString(); // ← 부모 클래스 명확
new Shipment(); // ← 생성자, Shipment 클래스 명확
this.privateMethod(); // ← private, 다른 클래스에서 못 부름
final void finalMethod() {} // ← override 불가이런 호출은 컴파일러가 정확한 메서드를 미리 알 수 있다.
→ 1단계 Resolution이 컴파일 타임에 끝남.
4.3 Dynamic Dispatch — 런타임 결정
Cargo c = getCargo(); // 어떤 서브타입?
c.calculateFee(); // ← 컴파일러는 Cargo의 메서드인 줄만 앎컴파일 시점:
바이트코드 → invokevirtual Cargo.calculateFee
런타임 시점:
c가 가리키는 객체의 Class Pointer 확인
→ DryCargo Klass의 VMT에서 calculateFee 슬롯 찾기
→ DryCargo.calculateFee 실제 실행→ Unit 1.5의 VMT가 정확히 이 메커니즘.
4.4 두 방식이 한 메서드 안에서 섞임
public BigDecimal processCargo(Cargo cargo) {
BigDecimal fee = cargo.calculateFee(); // Dynamic (invokevirtual)
BigDecimal vat = Math.multiplyExact( // Static (invokestatic)
fee.longValue(), 10);
log.info("Fee: {}", fee); // Dynamic (invokeinterface)
return new BigDecimal(vat); // Static (invokespecial)
}같은 메서드 안에서 4가지 invoke 모두 등장.
→ JVM이 매번 어떤 디스패치 방식을 쓸지 결정.
4.5 컴파일러의 똑똑함 — devirtualization
JIT 컴파일러는 일부 dynamic dispatch를 static처럼 최적화.
// 코드는 dynamic이지만
animal.sound();
// 만약 animal이 항상 Dog만 들어온다면
// JIT가 추론: "거의 항상 Dog이니, Dog.sound를 직접 부르자"
// → 인라이닝까지 가능이게 인라인 캐시 + 인라이닝. 다형성의 성능 비용을 거의 0으로.
→ "다형성은 성능이 느리다"는 잘못된 통념. JIT 덕에 거의 차이 없음.
5️⃣ 메서드 영역 — 시그니처와 바이트코드 매핑
5.1 큰 그림 다이어그램
Method Area:
┌──────────────────────────────────────────────────┐
│ Shipment Klass │
│ ┌────────────────────────────────────────────┐ │
│ │ Class Metadata Zone │ │
│ │ • Method Table (시그니처 목록) │ │
│ │ [0] calculate(I)BigDecimal → ref #A │ │
│ │ [1] getId()Long → ref #B │ │
│ │ [2] setBlNo(String)V → ref #C │ │
│ │ [3] validate()V (private) → ref #D │ │
│ └────────────────────────────────────────────┘ │
│ ┌────────────────────────────────────────────┐ │
│ │ Non-Static Zone │ │
│ │ ref #A: calculate 바이트코드 │ │
│ │ 0: new │ │
│ │ 3: ldc │ │
│ │ ... │ │
│ │ ref #B: getId 바이트코드 │ │
│ │ 0: aload_0 │ │
│ │ ... │ │
│ └────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────┘핵심 통찰:
- Class Metadata Zone의 Method Table은 "시그니처 → 바이트코드 위치" 매핑
- 1단계는 Method Table에서 시그니처를 찾고
- 2단계는 매핑된 바이트코드 위치로 점프
5.2 1단계와 2단계의 연결 — Method 구조체
JVM 내부에서 메서드 1개는 Method 구조체로 표현.
Method 구조체 (calculate 메서드):
├─ 이름: "calculate"
├─ 시그니처: "(I)Ljava/math/BigDecimal;"
├─ 접근 플래그: public, not static, not final
├─ 바이트코드 시작 주소: 0x...
├─ 바이트코드 크기: 47 bytes
├─ LVA 크기: 3 슬롯
├─ Operand Stack 최대 크기: 4
├─ Exception Table: (try-catch 정보)
└─ Local Variable Table: (디버깅 정보)→ 1단계의 결과 = 이 Method 구조체.
→ 2단계는 이 구조체의 정보로 프레임 만들고 실행.
5.3 인터페이스의 추가 복잡성 — itable
public interface Calculable {
BigDecimal calculate(int weight);
}
public class Shipment implements Calculable {
@Override
public BigDecimal calculate(int weight) { ... }
}Shipment의 Method Table은:
Shipment Method Table:
[0] calculate(I)BigDecimal (Calculable 인터페이스 구현)
[1] getId()Long
...invokeinterface로 호출 시:
Calculable c = new Shipment();
c.calculate(100);
→ c의 객체 → Shipment Klass
→ Shipment의 itable에서 Calculable 인터페이스 슬롯 찾기
→ 그 슬롯의 calculate 메서드 호출추가 단계가 있어서 invokevirtual 보다 살짝 느리지만 실무에선 차이 무시 가능.
5.4 정리 — Phase 1과의 연결
Unit 1.3 — Method Area의 3개 존
→ Metadata Zone에 시그니처, Static/Non-Static Zone에 바이트코드 분리
Unit 1.5 — Object Header의 Class Pointer
→ 객체 → Klass로 가는 다리
Unit 2.1 (이번) — Method Resolution & Invocation
→ 그 Klass의 Metadata에서 시그니처 찾고 → 바이트코드 실행→ Phase 1의 메모리 구조 위에서 메서드 호출이 정확히 어떻게 일어나는지 추적 완성.
6️⃣ 다형성·오버라이딩이 의존하는 2단계
6.1 오버라이딩의 본질
class Cargo {
public BigDecimal calculateFee() {
return BigDecimal.ZERO;
}
}
class DryCargo extends Cargo {
@Override
public BigDecimal calculateFee() {
return weight.multiply(new BigDecimal("100"));
}
}JVM에서의 모습:
Cargo Klass:
Method Table:
[N] calculateFee → ref #C1 (Cargo의 바이트코드)
DryCargo Klass (Cargo 상속):
Method Table:
[N] calculateFee → ref #D1 (DryCargo의 바이트코드) ← 같은 슬롯 N같은 시그니처, 같은 Method Table 슬롯 위치.
다른 클래스가 다른 바이트코드를 같은 슬롯에 매핑.
6.2 다형성 호출의 실제
Cargo c = new DryCargo();
c.calculateFee();1단계:
- 컴파일러: "Cargo.calculateFee를 호출하는 invokevirtual"
- 슬롯 N에서 메서드 호출하라는 명령
2단계:
- 런타임: c가 가리키는 객체의 Class Pointer 확인
- DryCargo Klass 발견
- DryCargo의 Method Table[N] = ref #D1
- ref #D1의 바이트코드 (DryCargo.calculateFee) 실행핵심: 1단계는 "슬롯 N의 메서드"라고만 결정. 실제 어느 클래스의 메서드인지는 2단계에서 객체에 따라 결정.
6.3 만약 2단계가 분리되어 있지 않다면?
가설: 컴파일 시점에 모든 게 결정된다면?
Cargo c = new DryCargo();
c.calculateFee(); // 컴파일러가 Cargo.calculateFee로 결정
// 이 경우 무조건 Cargo의 메서드 실행 → DryCargo 메서드 안 불림
// → 다형성 깨짐→ 2단계 분리 = 다형성의 본질.
6.4 super 호출의 특수성
class DryCargo extends Cargo {
@Override
<public BigDecimal calculateFee() {
BigDecimal base = super.calculateFee(); // ← 부모 명시적 호출
return base.add(weight.multiply(...));
}
}super.calculateFee()는 invokespecial 로 컴파일.
→ 동적 디스패치 안 함. 무조건 Cargo의 calculateFee 실행.
→ "이 객체가 사실 DryCargo이지만, Cargo의 메서드를 강제로 호출".
→ static dispatch의 정확한 사례. 1단계에서 결정 끝.
6.5 final 메서드의 최적화
class Cargo {
public final BigDecimal calculateBase() {
return weight.multiply(BASE_RATE);
}
}final 키워드는 "이 메서드는 오버라이드 불가" 라는 약속.
JIT는 이걸 보고 static dispatch처럼 처리 + 인라이닝.
→ 다형성 비용 0.
// JIT 최적화 결과 (개념적)
class Cargo {
public void doSomething(Cargo c) {
BigDecimal base = weight.multiply(BASE_RATE); // ← 인라인됨, 메서드 호출 사라짐
// ...
}
}7️⃣ ILIC 실무 — Spring AOP · JPA Proxy의 비밀
7.1 Spring AOP — 2단계 분리의 활용
@Service
public class ShipmentService {
@Transactional
public Shipment save(Shipment s) {
return repository.save(s);
}
}@Transactional이 어떻게 동작하나?
Spring의 답: 프록시 객체를 만들어 실제 ShipmentService 호출을 가로채기.
일반 호출:
controller → shipmentService.save()
→ ShipmentService 클래스의 save 메서드 직접 실행
AOP 호출:
controller → shipmentServiceProxy.save()
→ ShipmentService$$EnhancerBySpringCGLIB.save() 실행
1. 트랜잭션 시작
2. 진짜 ShipmentService.save() 호출
3. 트랜잭션 커밋/롤백메모리에서 일어나는 일:
Heap:
ShipmentServiceProxy 객체 ← Controller가 받음
└─ target = 진짜 ShipmentService 객체
Method Area:
ShipmentService 클래스 (원본)
ShipmentService$$EnhancerBySpringCGLIB 클래스 (프록시)
└─ save() 시그니처가 같음 → invokevirtual로 호출되면 프록시 메서드 실행→ Method Resolution은 그대로, Invocation 단계에서 프록시 메서드가 실행.
→ 2단계 분리가 만드는 메타 프로그래밍.
7.2 AOP self-invocation 문제
이 분리 메커니즘 때문에 흔히 마주치는 함정:
@Service
public class ShipmentService {
public void process() {
save(shipment); // ❌ AOP 동작 안 함!
}
@Transactional
public Shipment save(Shipment s) { ... }
}왜?
- 외부에서
shipmentService.save()→ Spring 프록시 호출 → AOP 동작 ✓ - 같은 클래스 안에서
save()→ this의 메서드 직접 호출 → 프록시 안 거침 → AOP 무시 ❌
메모리 추적:
shipmentServiceProxy.process() 호출
→ 프록시 메서드 실행
→ 진짜 ShipmentService.process() 호출
→ 그 안의 save() 호출
→ this 가 진짜 객체이므로 this.save() 직접 호출
→ 프록시 안 거침
→ @Transactional 무시해결:
// 1. 별도 빈으로 분리
@Service
public class TransactionalService {
@Transactional
public Shipment save(Shipment s) { ... }
}
@Service
public class ShipmentService {
private final TransactionalService tx;
public void process() {
tx.save(shipment); // ✓ 프록시 거침
}
}
// 2. 또는 self-injection (안티 패턴 가까움)
@Autowired
private ShipmentService self;
public void process() {
self.save(shipment); // ✓
}→ 이 함정의 원인은 정확히 메서드 호출의 2단계 메커니즘 이해 부족.
7.3 JPA Lazy Loading의 원리
@Entity
public class Shipment {
@OneToMany(fetch = FetchType.LAZY)
private List<Cargo> cargoes;
}
Shipment s = repository.findById(1L).get();
s.getCargoes().size(); // ← 이 시점에 DB 쿼리 발생Hibernate의 트릭:
s.getCargoes()
→ Hibernate가 List 자리에 실제 ArrayList가 아닌 PersistentBag (Proxy) 넣어둠
→ PersistentBag이 List 인터페이스 구현
→ size() 호출 시 invokeinterface → PersistentBag.size()
→ "아직 로딩 안 됨, DB 쿼리 실행"
→ 결과 채우고 size 반환invokeinterface의 2단계 분리가 Lazy Loading을 가능하게 함.
7.4 Mockito도 같은 원리
@Test
void test() {
ShipmentRepository mockRepo = Mockito.mock(ShipmentRepository.class);
when(mockRepo.findById(1L)).thenReturn(Optional.of(testShipment));
// mockRepo의 모든 메서드 호출이 가로채짐
mockRepo.findById(1L); // → 미리 설정한 값 반환
}Mockito도 프록시 클래스를 동적 생성.
→ 1단계 Resolution은 정상, 2단계 Invocation에서 mock 동작.
7.5 @SpringBootApplication의 마법
@Configuration
public class AppConfig {
@Bean
public ShipmentService shipmentService() {
return new ShipmentService();
}
}Spring은 AppConfig도 CGLIB 프록시로 감쌈.
→ shipmentService() 호출 시 단순히 새 객체 만들지 않고, 캐시된 싱글톤 반환.
@Bean
public Foo foo() {
return new Foo(bar()); // ← 매번 새 Bar?
}
@Bean
public Bar bar() {
return new Bar();
}답: 아님. bar()도 프록시를 통해 호출 → 싱글톤 보장.
→ 2단계 분리로 가능한 메타 프로그래밍.
8️⃣ 흔한 실수 + 성능 이슈
실수 1 — AOP self-invocation
@Service
public class ShipmentService {
public void doAll() {
save(s); // ❌ @Transactional 무시
}
@Transactional
public void save(Shipment s) { ... }
}→ 7.2 참조. 가장 흔한 함정.
실수 2 — final 클래스/메서드를 AOP 적용
@Service
public final class ShipmentService { // ❌ AOP 못 함
@Transactional
public final Shipment save(Shipment s) { ... }
}Spring CGLIB AOP는 클래스 상속으로 프록시 생성.
final 클래스/메서드는 상속/오버라이드 불가 → 프록시 못 만듦.
해결: final 제거 또는 인터페이스 기반 JDK Proxy 사용.
실수 3 — private 메서드에 @Transactional
@Service
public class ShipmentService {
@Transactional
private void save(Shipment s) { ... } // ❌ 무시됨
}private 메서드는 invokespecial (static dispatch).
프록시가 가로챌 수 없음.
→ @Transactional 은 반드시 public 메서드에.
실수 4 — Reflection 호출이 느리다는 오해
Method m = clazz.getMethod("calculate", int.class);
BigDecimal result = (BigDecimal) m.invoke(obj, 100);Reflection 호출도 결국 invoke 명령으로 변환.
첫 호출은 Resolution이 비싸지만, 반복 호출은 캐시되어 빨라짐.
→ 한 번만 부르면 느림, 반복 호출은 일반 호출과 큰 차이 없음.
실수 5 — invokedynamic 무시
람다와 String concat이 사용하는 invokedynamic:
Runnable r = () -> System.out.println("hello");내부적으로 invokedynamic → 1단계 Resolution을 런타임에 동적으로 수행.
→ 5번째 invoke (Java 7+, Unit 1.5에서 다룬 4종 외에 추가).
람다가 익명 클래스보다 메모리 효율이 좋은 이유.
실수 6 — 가상 호출의 성능 과대평가
// "다형성은 느리다" — 잘못된 인식
Animal a = getAnimal();
a.sound(); // 느릴 거라 생각하지만JIT의 인라인 캐시 + devirtualization + 인라이닝.
→ 거의 항상 같은 타입이면 정적 호출만큼 빠름.
성능을 의심하기 전에 측정. 보통 다형성이 병목이 아님.
디버깅 — 호출 경로 추적
# 1. JIT가 어떤 호출을 인라이닝 했는지 보기
java -XX:+PrintInlining -XX:+UnlockDiagnosticVMOptions MyApp
# 2. 메서드 호출 카운트
java -XX:+CountInvocations MyApp
# 3. Async-Profiler로 호출 hot path 확인
async-profiler -d 30 -f profile.html <PID>운영에서 메서드 호출 병목 의심 시 위 도구들로 측정.
9️⃣ 면접 질문 + 자기 점검
9.1 면접 단골 질문 매핑
| Q | 핵심 답변 |
|---|---|
| 메서드 호출의 2단계? | Resolution(시그니처 확인) + Invocation(바이트코드 실행) |
| 왜 2단계로 분리? | 다형성·AOP·동적 프록시 가능. lazy class loading |
| Static vs Dynamic Dispatch? | 컴파일 타임 결정 vs 런타임 결정 |
invokespecial 사용 시점? | 생성자, private, super 호출 |
| 다형성이 2단계에 의존하는 이유? | 1단계는 슬롯 결정, 2단계에서 객체 타입 따라 실제 메서드 |
| Spring AOP 동작 원리? | 프록시 객체로 invoke 단계에서 가로채기 |
| AOP self-invocation 함정? | this의 메서드 호출은 프록시 안 거침 |
| final 메서드 최적화? | static dispatch + 인라이닝 가능 |
| Reflection이 정말 느린가? | 첫 호출만 느림. 반복 호출은 일반 호출과 큰 차이 없음 |
| invokedynamic 사용처? | 람다, String concat, switch pattern (Java 21+) |
9.2 자기 점검 체크리스트
기본 이해
- Method Resolution과 Invocation의 차이를 안다
- Static과 Dynamic Dispatch의 결정 시점을 안다
- 4가지 invoke 명령이 어느 디스패치에 해당하는지 안다
- Method Table과 바이트코드 위치의 매핑을 설명할 수 있다
- 다형성이 2단계에 의존하는 메커니즘을 안다
실전 적용
- AOP self-invocation 함정을 인식하고 회피할 수 있다
- @Transactional이 동작하지 않는 케이스를 진단할 수 있다
- final/private과 AOP의 충돌을 안다
- JPA Proxy의 Lazy Loading 원리를 설명할 수 있다
- JIT 최적화 효과를 측정할 수 있다
면접 대비 — 5분 답변
- 메서드 호출 2단계 구조의 의미
- Static vs Dynamic Dispatch 결정 기준
- Spring AOP의 메모리 메커니즘
- AOP self-invocation 함정의 원인과 해결
- invokedynamic이 만드는 람다의 효율성
🎯 핵심 요약 — 3줄 정리
1. 메서드 호출은 반드시 2단계로 분리
- 1단계 (Resolution): Class Metadata Zone에서 시그니처 확인
- 2단계 (Invocation): Static/Non-Static Zone의 바이트코드 실행
- 이 분리가 다형성·AOP·Proxy의 근본 메커니즘
2. Static vs Dynamic Dispatch
- Static: 컴파일 타임 결정 (
invokestatic,invokespecial) - Dynamic: 런타임 결정 (
invokevirtual,invokeinterface) - JIT 덕에 둘의 성능 차이는 사실상 없음
3. ILIC 실무 직결
- Spring AOP = 2단계의 Invocation을 프록시로 가로채기
- AOP self-invocation 함정의 근본 원인
- JPA Lazy Loading, Mockito, @Bean 캐싱 모두 같은 원리
📚 다음으로...
Unit 2.2 — Static vs 인스턴스 메서드 호출 경로
이번 Unit에서 메서드 호출의 일반론을 봤다면, 다음은 Static과 Instance의 호출 경로를 정확히 비교.
- Static → Static: 가장 단순
- Static → Instance: 객체 필요
- Instance → Static: 자유
- Instance → Instance: this 매개변수
- 메모리 그림으로 4가지 경우 모두 추적
2주차 진행 상황
✅ Phase 1 — 자바 변수 ↔ 메모리 매핑 (1.1 ~ 1.6 완주)
🚀 Phase 2 — JVM 메서드 실행 메커니즘
✅ Unit 2.1 메서드 호출의 2단계 처리 ← 여기
⏭ Unit 2.2 Static vs 인스턴스 호출 경로
⏭ Unit 2.3 인스턴스 메서드 호출의 전 과정 (Case Study)
⏭ Unit 2.4 new 연산자의 실제 동작
⏭ Phase 3 — 바이트코드와 상수 풀 ★ 2주차의 정점Phase 3까지의 거리
이번 Unit에서:
- "invokevirtual #15" 같은 명령
- 상수 풀의 메서드 참조
Phase 3에서:
#15가 정확히 무엇인지- 상수 풀의 모든 종류
- 심볼 참조 → 실제 참조 해소 메커니즘
javap -v로 클래스 파일 완전 분해
→ Phase 2 끝나면 Phase 3 정점.
Software Developer