Unit 3.4 — 바이트코드 실전 분석
F-LAB JAVA · 2주차 · Phase 3 · 바이트코드와 상수 풀
🎯 2주차의 정점 —javap -c -v출력을 처음부터 끝까지 분석한다
📌 학습 목표
이 Unit을 끝내면 다음을 답할 수 있어야 한다.
-
javap -c -v ClassName.class출력의 모든 줄을 해독할 수 있는가? -
dup명령이 정확히 왜 필요한가? (커리큘럼 자기 점검 질문) -
invokespecial/invokevirtual/invokestatic/invokeinterface의 결정적 차이는? - 같은 자바 코드가 Java 8, 11, 17, 21 에서 어떻게 다르게 컴파일되나?
- 운영에서 클래스 파일을 받아 30분 안에 정확한 진단을 작성할 수 있는가?
- Phase 3 졸업 — 바이트코드 읽기 전문가 가 되었는가?
🎯 핵심 한 문장
Phase 3의 모든 학습이 이 한 줄에 응축된다:
javap -c -v -p ClassName.class이 출력을 박승제씨가 처음부터 끝까지 이해할 수 있다면, 2주차의 정점에 도달한 것이다.
Phase 1 메모리 구조, Phase 2 메서드 호출 메커니즘, Phase 3 바이트코드 + 상수 풀 + 심볼 참조 — 모든 것이 한 화면에서 만난다.
비유 — 의사의 X-Ray 판독 능력
| 단계 | 비유 |
|---|---|
| 소스 코드 작성 | 환자와 대화로 증상 듣기 |
.class 생성 | X-Ray 촬영 |
javap -v 출력 | X-Ray 사진 |
| 이번 Unit의 능력 | X-Ray를 보고 정확히 진단 |
비전문가도 X-Ray 사진은 볼 수 있다. 읽을 수 있는가가 차이.
박승제씨도 Phase 3까지 와서 이제 읽을 수 있는 능력을 갖춘다.
🧭 9개 섹션 로드맵
1. Phase 3 종합 — 정점 진입
2. 분석할 실전 ILIC 코드
3. .class 파일 헤더 완전 해독
4. Constant Pool 완전 해독
5. 생성자 바이트코드 — 한 줄씩
6. 인스턴스 메서드 바이트코드 — 한 줄씩
7. ILIC 운영 사고 시뮬레이션 — 실제 디버깅
8. Java 버전별 차이 + 흔한 함정
9. 면접 질문 + Phase 3 졸업 시험1️⃣ Phase 3 종합 — 정점 진입
1.1 지금까지 배운 것들 한자리에
Unit 3.1 — 바이트코드란 무엇인가
↓ 스택 머신, .class 구조, javap 도구, 8개 명령 카테고리
Unit 3.2 — 상수 풀의 생성과 구조
↓ 14가지 항목, Methodref의 5개 참조, 디스크립터
Unit 3.3 — 심볼 참조
↓ Symbolic vs Direct, Resolution 5단계, Late Binding
Unit 3.4 — 바이트코드 실전 분석 (이번)
↓ 모든 것을 종합한 한 클래스 분석1.2 박승제씨가 가질 능력
이 Unit이 끝나면:
- 운영에서 받은
.class파일을 즉시 분석 가능 - 라이브러리 버그 원인을 바이트코드로 추적 가능
- Spring AOP/JPA의 생성 코드 검증 가능
- 컴파일러 옵션 효과 직접 측정 가능
- 면접에서 바이트코드 질문 자신감
1.3 분석할 도구 — 다시 정리
# 가장 자주 쓸 명령
javap -c -v -p ClassName.class
# 옵션 의미:
# -c : 바이트코드 표시
# -v : verbose (상수 풀, 메타데이터)
# -p : private 멤버 포함대안:
- IntelliJ IDEA: View → Show Bytecode
- 또는: 외부 도구 (CFR, JD-GUI)
박승제씨는 IntelliJ를 쓰니까 IDE 통합이 가장 편할 것.
하지만 운영 서버에선 javap 명령어가 필수.
2️⃣ 분석할 실전 ILIC 코드
2.1 분석 대상
ILIC의 실전 클래스 (단순화 버전):
package com.ilic.shipment;
import java.math.BigDecimal;
public class ShipmentCalculator {
private static final BigDecimal FUEL_RATE = new BigDecimal("0.15");
private int callCount = 0;
public BigDecimal calculate(int weight, BigDecimal baseRate) {
callCount++;
BigDecimal subtotal = baseRate.multiply(BigDecimal.valueOf(weight));
return subtotal.multiply(BigDecimal.ONE.add(FUEL_RATE));
}
public int getCallCount() {
return callCount;
}
}2.2 왜 이 코드인가
이 한 클래스 안에 박승제씨가 배운 모든 메커니즘:
- 인스턴스 필드 (
callCount) → Unit 1.5 - static 필드 (
FUEL_RATE) → Unit 1.3 - static 초기화 블록 패턴 (필드 선언 초기값)
- 메서드 매개변수 (this 자동 전달) → Unit 2.2
- 인스턴스 메서드 (
calculate) → Unit 2.1 - static 메서드 호출 (
BigDecimal.valueOf) → Unit 1.5의 invokestatic - 인스턴스 메서드 호출 (
multiply) → invokevirtual - 객체 생성 (
new BigDecimal) → Unit 2.4 - 상수 풀 전 항목 → Unit 3.2
- 심볼 참조 → Unit 3.3
2.3 컴파일 및 분석
javac ShipmentCalculator.java
javap -c -v -p ShipmentCalculator.class > analysis.txt이제 출력을 한 줄씩 보자.
3️⃣ .class 파일 헤더 완전 해독
3.1 javap 출력 시작
Classfile /Users/seungje/ShipmentCalculator.class
Last modified May 15, 2026; size 567 bytes
SHA-256 checksum 8a3c2f1e...
Compiled from "ShipmentCalculator.java"
public class com.ilic.shipment.ShipmentCalculator
minor version: 0
major version: 65
flags: (0x0021) ACC_PUBLIC, ACC_SUPER
this_class: #21 // com/ilic/shipment/ShipmentCalculator
super_class: #2 // java/lang/Object
interfaces: 0, fields: 2, methods: 3, attributes: 13.2 각 줄 해독
minor version: 0
major version: 65→ Java 21로 컴파일. (Unit 3.1의 버전표: 65 = Java 21)
→ Java 17 서버에서 실행 시 UnsupportedClassVersionError 가능.
flags: (0x0021) ACC_PUBLIC, ACC_SUPER→ 클래스 접근 플래그:
ACC_PUBLIC= 0x0001 (public)ACC_SUPER= 0x0020 (구식 호환 플래그, Java 1.0 호환)- 합쳐서 0x0021
다른 플래그 값:
ACC_FINAL= 0x0010 (final class)ACC_INTERFACE= 0x0200 (인터페이스)ACC_ABSTRACT= 0x0400 (abstract)ACC_ENUM= 0x4000 (enum)
this_class: #21
super_class: #2→ 자기 클래스명 = Constant Pool의 #21
→ 부모 클래스명 = Constant Pool의 #2 (Object)
interfaces: 0, fields: 2, methods: 3, attributes: 1→ 구현 인터페이스 0개
→ 필드 2개 (FUEL_RATE static, callCount instance)
→ 메서드 3개 (생성자 + calculate + getCallCount)
→ attribute 1개 (SourceFile)
3.3 Magic Number 확인 (hexdump)
hexdump -C ShipmentCalculator.class | head -200000000 ca fe ba be 00 00 00 41 00 2c 0a 00 02 00 03 ...
↑ Magic ↑ Ver=65 ↑ Constant Pool 항목 수=440xCAFEBABE: Magic Number (Unit 3.1)0x41= 65 (Java 21)- 그 다음 2바이트가 Constant Pool 항목 개수
→ javap로 본 것과 일치.
4️⃣ Constant Pool 완전 해독
4.1 풀 항목 모두 보기
Constant pool:
#1 = Methodref #2.#3 // java/lang/Object."<init>":()V
#2 = Class #4 // java/lang/Object
#3 = NameAndType #5:#6 // "<init>":()V
#4 = Utf8 java/lang/Object
#5 = Utf8 <init>
#6 = Utf8 ()V
#7 = Class #8 // java/math/BigDecimal
#8 = Utf8 java/math/BigDecimal
#9 = String #10 // "0.15"
#10 = Utf8 "0.15"
#11 = Methodref #7.#12 // BigDecimal."<init>":(Ljava/lang/String;)V
#12 = NameAndType #5:#13 // "<init>":(Ljava/lang/String;)V
#13 = Utf8 (Ljava/lang/String;)V
#14 = Fieldref #21.#15 // ShipmentCalculator.FUEL_RATE:Ljava/math/BigDecimal;
#15 = NameAndType #16:#17 // FUEL_RATE:Ljava/math/BigDecimal;
#16 = Utf8 FUEL_RATE
#17 = Utf8 Ljava/math/BigDecimal;
#18 = Fieldref #21.#19 // ShipmentCalculator.callCount:I
#19 = NameAndType #20:#23 // callCount:I
#20 = Utf8 callCount
#21 = Class #22 // com/ilic/shipment/ShipmentCalculator
#22 = Utf8 com/ilic/shipment/ShipmentCalculator
#23 = Utf8 I
#24 = Methodref #7.#25 // BigDecimal.valueOf:(J)Ljava/math/BigDecimal;
#25 = NameAndType #26:#27 // valueOf:(J)Ljava/math/BigDecimal;
#26 = Utf8 valueOf
#27 = Utf8 (J)Ljava/math/BigDecimal;
#28 = Methodref #7.#29 // BigDecimal.multiply:(LBigDecimal;)LBigDecimal;
#29 = NameAndType #30:#31
#30 = Utf8 multiply
#31 = Utf8 (Ljava/math/BigDecimal;)Ljava/math/BigDecimal;
#32 = Fieldref #7.#33 // BigDecimal.ONE:LBigDecimal;
#33 = NameAndType #34:#17
#34 = Utf8 ONE
#35 = Methodref #7.#36 // BigDecimal.add:(LBigDecimal;)LBigDecimal;
...4.2 카테고리별 해독
Utf8 항목 (실제 텍스트 데이터)
#4 = Utf8 java/lang/Object ← 클래스명
#5 = Utf8 <init> ← 생성자 이름
#6 = Utf8 ()V ← 시그니처: void 반환
#10 = Utf8 "0.15" ← String 값
#16 = Utf8 FUEL_RATE ← 필드 이름
#17 = Utf8 Ljava/math/BigDecimal; ← 타입 디스크립터
#20 = Utf8 callCount ← 필드 이름
#23 = Utf8 I ← int 타입
#26 = Utf8 valueOf ← 메서드 이름
#27 = Utf8 (J)Ljava/math/BigDecimal; ← long 받아 BigDecimal 반환
#30 = Utf8 multiply
#31 = Utf8 (Ljava/math/BigDecimal;)Ljava/math/BigDecimal;
#34 = Utf8 ONE→ 모든 텍스트의 진짜 저장소.
Class 항목
#2 = Class #4 // java/lang/Object
#7 = Class #8 // java/math/BigDecimal
#21 = Class #22 // com/ilic/shipment/ShipmentCalculator→ 3개 클래스를 참조. Object(부모), BigDecimal(사용), 자기 자신.
NameAndType 항목
#3 = NameAndType #5:#6 // <init>:()V (Object 생성자)
#12 = NameAndType #5:#13 // <init>:(String)V (BigDecimal 생성자)
#15 = NameAndType #16:#17 // FUEL_RATE:BigDecimal
#19 = NameAndType #20:#23 // callCount:I
#25 = NameAndType #26:#27 // valueOf:(J)BigDecimal
#29 = NameAndType #30:#31 // multiply:(BigDecimal)BigDecimal→ 각 멤버 (메서드/필드)의 이름 + 시그니처 쌍.
Methodref 항목
#1 = Methodref #2.#3 // Object.<init>()
#11 = Methodref #7.#12 // BigDecimal.<init>(String)
#24 = Methodref #7.#25 // BigDecimal.valueOf(long)
#28 = Methodref #7.#29 // BigDecimal.multiply(BigDecimal)
#35 = Methodref #7.#36 // BigDecimal.add(BigDecimal)→ 호출하는 메서드들. 각 항목이 Class + NameAndType 조합.
Fieldref 항목
#14 = Fieldref #21.#15 // ShipmentCalculator.FUEL_RATE
#18 = Fieldref #21.#19 // ShipmentCalculator.callCount
#32 = Fieldref #7.#33 // BigDecimal.ONE→ 접근하는 필드들.
String 항목
#9 = String #10 // "0.15"→ String 리터럴. Utf8을 한 단계 감쌌음.
4.3 풀의 효율성 검증
java/math/BigDecimal 텍스트는 풀에 단 1번 (#8).
하지만 코드에서 BigDecimal을 여러 번 사용:
new BigDecimal("0.15")(생성자)BigDecimal.valueOf(weight)(static)baseRate.multiply(...)(인스턴스 메서드)BigDecimal.ONE(필드)BigDecimal.add(...)(인스턴스 메서드)
모두 #7 (Class) 또는 #8 (Utf8) 을 공유.
→ 중복 제거 효과 확실.
5️⃣ 생성자 바이트코드 — 한 줄씩
5.1 생성자 정의 (자동 생성)
ShipmentCalculator 클래스에 명시적 생성자 없음.
컴파일러가 자동으로 기본 생성자 생성:
public ShipmentCalculator() {
super();
this.callCount = 0; // 명시적이지만 0이라 생략 가능
}추가로 static 초기화 블록:
static {
FUEL_RATE = new BigDecimal("0.15");
}5.2 javap 출력 — 인스턴스 생성자
public com.ilic.shipment.ShipmentCalculator();
descriptor: ()V
flags: (0x0001) ACC_PUBLIC
Code:
stack=2, locals=1, args_size=1
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: iconst_0
6: putfield #18 // Field callCount:I
9: return
LineNumberTable:
line 9: 05.3 한 줄씩 해독
메타 정보:
descriptor: ()V ← 매개변수 없음, void 반환
flags: ACC_PUBLIC ← public
stack=2, locals=1, args_size=1stack=2: Operand Stack 최대 2 슬롯 사용locals=1: LVA 1 슬롯 (this 1개)args_size=1: 매개변수 1개 (this 포함)
바이트코드 한 줄씩:
0: aload_0- LVA[0]을 Operand Stack에 push
- LVA[0]은 항상 this (Unit 2.2)
- Stack: [this]
1: invokespecial #1 // Object.<init>()- 메서드 호출:
super() #1은 Constant Pool의 Methodref → Object의<init>- this를 인자로 (Stack에서 pop)
- → Object 생성자 실행 (사실상 빈 작업)
- Stack: []
4: aload_0- 다시 this 푸시 (다음 putfield용)
- Stack: [this]
5: iconst_0- int 상수 0 푸시
- Stack: [this, 0]
6: putfield #18 // callCount:I- 인스턴스 필드 쓰기
#18= Fieldref → ShipmentCalculator.callCount- Stack에서 2개 pop: this와 값
this.callCount = 0실행- Stack: []
9: return- void 반환
- 생성자 종료
5.4 callCount = 0 가 왜 명시적?
박승제씨가 작성한 코드:
private int callCount = 0;만약:
private int callCount; // 명시적 = 0 없이JVM은 어차피 0으로 초기화 (Unit 2.4). 그런데 컴파일러는 둘 다 putfield #18로 동일하게 처리.
→ 명시적이든 아니든 같은 바이트코드.
→ Unit 2.4에서 본 "컴파일러가 필드 초기값을 생성자에 자동 삽입"의 증거.
5.5 static 초기화 블록 (<clinit>)
static {};
descriptor: ()V
flags: (0x0008) ACC_STATIC
Code:
stack=3, locals=0, args_size=0
0: new #7 // class java/math/BigDecimal
3: dup
4: ldc #9 // String "0.15"
6: invokespecial #11 // BigDecimal.<init>(String)
9: putstatic #14 // FUEL_RATE
12: return<clinit> = class initializer. 클래스 초기화 시 1번만 호출.
한 줄씩:
0: new #7 // new BigDecimal- BigDecimal 클래스 정보 확인
- Heap에 메모리 할당
- Object Header 설정
- Stack: [obj_ref]
3: dup // 복제- 다음 invokespecial이 소비할 것 + putstatic이 쓸 것
- Stack: [obj_ref, obj_ref]
4: ldc #9 // "0.15"- String 리터럴 로드
- Stack: [obj_ref, obj_ref, "0.15"]
6: invokespecial #11 // BigDecimal.<init>(String)- 생성자 호출
- this(obj_ref) + "0.15"를 인자로
- Stack: [obj_ref]
9: putstatic #14 // FUEL_RATE- static 필드 쓰기
#14= ShipmentCalculator.FUEL_RATE- Stack의 obj_ref를 FUEL_RATE에 할당
- Stack: []
12: return→ Unit 2.4 6장 (new의 메모리 변화)을 직접 확인.
6️⃣ 인스턴스 메서드 바이트코드 — 한 줄씩
6.1 calculate 메서드
public BigDecimal calculate(int weight, BigDecimal baseRate) {
callCount++;
BigDecimal subtotal = baseRate.multiply(BigDecimal.valueOf(weight));
return subtotal.multiply(BigDecimal.ONE.add(FUEL_RATE));
}6.2 javap 출력
public java.math.BigDecimal calculate(int, java.math.BigDecimal);
descriptor: (ILjava/math/BigDecimal;)Ljava/math/BigDecimal;
flags: (0x0001) ACC_PUBLIC
Code:
stack=4, locals=4, args_size=3
0: aload_0
1: dup
2: getfield #18 // Field callCount:I
5: iconst_1
6: iadd
7: putfield #18 // Field callCount:I
10: aload_2
11: iload_1
12: i2l
13: invokestatic #24 // Method BigDecimal.valueOf:(J)LBigDecimal;
16: invokevirtual #28 // Method BigDecimal.multiply:(LBigDecimal;)LBigDecimal;
19: astore_3
20: aload_3
21: getstatic #32 // Field BigDecimal.ONE:LBigDecimal;
24: getstatic #14 // Field FUEL_RATE:LBigDecimal;
27: invokevirtual #35 // Method BigDecimal.add:(LBigDecimal;)LBigDecimal;
30: invokevirtual #28 // Method BigDecimal.multiply:(LBigDecimal;)LBigDecimal;
33: areturn
LineNumberTable:
line 12: 0
line 13: 10
line 14: 206.3 메타 정보
descriptor: (ILjava/math/BigDecimal;)Ljava/math/BigDecimal;→ (int, BigDecimal) → BigDecimal
stack=4, locals=4, args_size=3- Operand Stack 최대 4
- LVA 4 슬롯
- 매개변수 3개 (this + weight + baseRate)
LVA 레이아웃:
LVA[0] this
LVA[1] weight (int)
LVA[2] baseRate (BigDecimal)
LVA[3] subtotal (지역변수)6.4 callCount++ 의 5줄 분석 (PC 0~9)
0: aload_0- this 푸시
- Stack: [this]
1: dup- this 복제
- Stack: [this, this]
2: getfield #18 // callCount- top의 this에서 callCount 읽음
- Stack: [this, callCount값]
5: iconst_1- 1 푸시
- Stack: [this, callCount, 1]
6: iadd- 더하기 (top 2개)
- Stack: [this, callCount+1]
7: putfield #18 // callCount- this.callCount = 결과
- Stack: []
→ 5개 명령어로 callCount++ 표현.
→ Unit 2.3에서 본 패턴 정확히 재현.
6.5 baseRate.multiply(BigDecimal.valueOf(weight)) 분석 (PC 10~19)
10: aload_2- baseRate 푸시 (LVA[2])
- Stack: [baseRate]
11: iload_1- weight 푸시 (LVA[1])
- Stack: [baseRate, weight(int)]
12: i2l- int → long 변환
- Stack: [baseRate, weight(long)]
BigDecimal.valueOf(long)이라 long 필요
13: invokestatic #24 // BigDecimal.valueOf(J)- static 메서드 호출
- Stack의 long을 인자로
- 결과 BigDecimal을 push
- Stack: [baseRate, BigDecimal_from_weight]
16: invokevirtual #28 // BigDecimal.multiply(BigDecimal)- 인스턴스 메서드 호출
- Stack의 baseRate를 this로, BigDecimal_from_weight를 인자로
- →
baseRate.multiply(BigDecimal_from_weight)실행 - 결과 BigDecimal을 push
- Stack: [subtotal]
19: astore_3- subtotal에 저장 (LVA[3])
- Stack: []
→ invokestatic + invokevirtual 차이 직접 확인.
- invokestatic: 객체 없이 호출.
BigDecimal.valueOf - invokevirtual: 객체(top)를 this로 사용.
baseRate.multiply(...)
6.6 subtotal.multiply(BigDecimal.ONE.add(FUEL_RATE)) 분석 (PC 20~30)
20: aload_3 // subtotal
21: getstatic #32 // BigDecimal.ONE (static 필드)
24: getstatic #14 // FUEL_RATE (static 필드)
27: invokevirtual #35 // BigDecimal.ONE.add(FUEL_RATE)
30: invokevirtual #28 // subtotal.multiply(결과)
33: areturn // 반환Stack 변화:
PC 20: [subtotal]
PC 21: [subtotal, ONE]
PC 24: [subtotal, ONE, FUEL_RATE]
PC 27: [subtotal, ONE.add(FUEL_RATE)] ← invokevirtual이 ONE.add(...) 실행
PC 30: [subtotal.multiply(...)] ← invokevirtual이 subtotal.multiply(...) 실행
PC 33: [] ← areturn6.7 getter — getCallCount
public int getCallCount();
descriptor: ()I
flags: (0x0001) ACC_PUBLIC
Code:
stack=1, locals=1, args_size=1
0: aload_0
1: getfield #18 // callCount:I
4: ireturn3줄에 모든 게:
1. this 푸시
2. this의 callCount 읽기
3. int 반환
→ Java의 getter는 정말 단순.
→ JIT가 인라이닝 처리 → 거의 0 비용.
7️⃣ ILIC 운영 사고 시뮬레이션 — 실제 디버깅
7.1 시나리오 — 운영에서 에러 발생
2026-05-15 14:30:00 ERROR ShipmentService - 운임 계산 실패
java.lang.NoSuchMethodError:
'java.math.BigDecimal java.math.BigDecimal.multiply(java.math.BigDecimal)'
at com.ilic.ShipmentCalculator.calculate(ShipmentCalculator.java:13)박승제씨의 분석 시작.
7.2 1단계 — 에러 의미 파악
NoSuchMethodError:
- 컴파일 시점엔 메서드 있었음
- 런타임에 없음
- → Resolution 실패 (Unit 3.3)
특히 BigDecimal.multiply(BigDecimal):
- 표준 JDK 메서드
- 사라질 리 없음
의심:
- 잘못된 BigDecimal 클래스가 로딩되고 있다?
- ClassLoader 격리 문제?
7.3 2단계 — 바이트코드 분석
# 운영 서버에서 클래스 추출
ssh prod-server
cd /var/log/dump/
jcmd <PID> Thread.print > thread.dump
# 실행 중인 JAR의 ShipmentCalculator.class 추출
unzip -o app.jar com/ilic/ShipmentCalculator.class
javap -c -v com/ilic/ShipmentCalculator.class > local-analysis.txtlocal-analysis.txt의 Constant Pool 확인:
#28 = Methodref #7.#29
#7 = Class #8 // java/math/BigDecimal
#29 = NameAndType #30:#31
#30 = Utf8 multiply
#31 = Utf8 (Ljava/math/BigDecimal;)Ljava/math/BigDecimal;→ 우리 클래스는 정상. BigDecimal.multiply(BigDecimal) 호출.
7.4 3단계 — 실제 로딩된 BigDecimal 확인
# 어느 BigDecimal이 로딩됐나?
jcmd <PID> VM.classloader_stats
# 또는
jcmd <PID> GC.class_stats | grep BigDecimal출력:
java.math.BigDecimal loaded by com.malicious.BadClassLoader예상 외 결과: BigDecimal이 표준 JDK가 아닌 다른 ClassLoader에서 로딩됨!
7.5 4단계 — 원인 추적
# JAR 안에 BigDecimal이 있나?
unzip -l app.jar | grep BigDecimal발견:
com/malicious/BigDecimal.class→ 누군가가 BigDecimal 이름의 클래스를 JAR에 넣음.
- 우연한 충돌 (말도 안 됨)
- 의도된 공격? 또는 잘못된 import?
# 어떤 의존성에서 왔나?
./gradlew dependencyInsight --dependency BigDecimal→ 특정 라이브러리가 자체 BigDecimal 가지고 있음. 클래스 우선순위 문제.
7.6 5단계 — 해결
즉시 조치:
1. 문제 라이브러리 제거
2. 또는 ClassLoader 우선순위 조정
3. JDK BigDecimal이 먼저 로딩되게 보장
장기 조치:
1. 빌드 시 클래스 충돌 검출 도구 추가 (Maven Enforcer, Gradle Conflict Resolution)
2. JAR 무결성 검증
7.7 박승제씨의 능력
이 시나리오를 30분 내에 진단할 수 있게 된 것이 Phase 3 학습의 가치.
시간: 15:00 (에러 발생)
↓ 1분
에러 메시지 확인
↓ 5분
바이트코드 추출 + javap 분석
↓ 10분
ClassLoader 추적
↓ 10분
원인 발견 + 해결책 도출
시간: 15:30 (해결)이게 바이트코드 읽기 능력의 진짜 가치.
8️⃣ Java 버전별 차이 + 흔한 함정
8.1 같은 코드, 다른 바이트코드
String s = "Hello, " + name + "!";Java 8 컴파일:
new #1 // StringBuilder
dup
invokespecial #2 // StringBuilder.<init>()
ldc #3 // "Hello, "
invokevirtual #4 // StringBuilder.append(String)
aload_1 // name
invokevirtual #4 // StringBuilder.append(String)
ldc #5 // "!"
invokevirtual #4
invokevirtual #6 // StringBuilder.toString()
astore_2Java 9+ 컴파일:
ldc #3 // "Hello, "
aload_1
ldc #5 // "!"
invokedynamic #7 // makeConcatWithConstants
astore_2→ Java 9+ 는 invokedynamic + StringConcatFactory 사용 (JEP 280).
→ 런타임에 JVM이 최적 전략 선택.
8.2 enum의 진화
Java 16 이전 — switch 표현식 등장 전:
switch (status) {
case DRAFT: ...; break;
case ACTIVE: ...; break;
}lookupswitch { ... } // 일반적인 분기Java 17+ — pattern matching switch (preview):
return switch (obj) {
case Integer i -> "int: " + i;
case String s -> "str: " + s;
default -> "other";
};invokedynamic #N // SwitchBootstraps.typeSwitch→ 점점 더 invokedynamic 활용 증가.
8.3 record (Java 16+)
public record Shipment(String blNo, BigDecimal freight) {}javap -c -v 결과:
- 자동 생성된 메서드들:
blNo(),freight(),equals(),hashCode(),toString() - 각 메서드는
invokedynamic으로 ObjectMethods 부트스트랩 사용 - 매우 간결한 바이트코드
// 일반 클래스의 equals/hashCode/toString:
// 수십 줄의 바이트코드
// record:
0: aload_0
1: aload_1
2: invokedynamic #1 // ObjectMethods.bootstrap
7: areturn→ 같은 동작을 훨씬 짧은 바이트코드로.
8.4 sealed class (Java 17+)
public sealed class Cargo
permits DryCargo, ReeferCargo, HazmatCargo {}.class 파일에 새 attribute:
PermittedSubclasses:
DryCargo
ReeferCargo
HazmatCargo→ JVM이 컴파일 시점에 자식 클래스 목록 검증.
8.5 흔한 함정 1 — 디버그 정보 누락
javac App.java
javap -c App.classLocalVariableTable이 없으면:
0: aload_0
1: aload_1 // 변수 이름 모름-g 옵션으로 컴파일하면:
0: aload_0 // this
1: aload_1 // shipment→ 운영 디버깅 위해 -g:lines,vars 옵션 권장.
8.6 흔한 함정 2 — 인라인 캐시 무효화
// 호출 사이트
shipment.calculate(100); ← 항상 ShipmentImpl1만 옴JIT가 인라인 캐시 → 매우 빠름.
만약 어느 순간 다른 타입 등장:
shipment.calculate(100); ← 이번엔 ShipmentImpl2캐시 미스 → 재해소.
메가모픽(megamorphic) 호출 사이트가 되면 캐시 효과 사라짐.
→ 다형성을 너무 다양하게 쓰면 성능 손실. 보통 문제 안 됨.
8.7 흔한 함정 3 — Reflection 비용
Method m = clazz.getMethod("calculate", int.class);
m.invoke(obj, 100);내부적으로:
- 첫 호출: 매우 비쌈 (수십 μs)
- 두 번째 이후: 캐시 사용 (수 μs)
- JIT가 인라이닝하면: 거의 일반 호출만큼
→ Reflection 한 번 vs 매번 호출의 차이.
// ❌ 비효율
for (int i = 0; i < 100; i++) {
clazz.getMethod("calc", int.class).invoke(obj, i);
}
// ✓ Method 객체 캐시
Method m = clazz.getMethod("calc", int.class);
for (int i = 0; i < 100; i++) {
m.invoke(obj, i);
}9️⃣ 면접 질문 + Phase 3 졸업 시험
9.1 면접 단골 질문 매핑
| Q | 핵심 답변 |
|---|---|
dup 명령은 왜 필요? | new 후 객체 참조를 invokespecial이 소비. astore도 써야 해서 복제 |
invokevirtual vs invokespecial vs invokestatic 차이? | 다형성 / 정적 확정 / 객체 무관 (Unit 1.5 4종) |
getstatic vs getfield? | static 필드 / 인스턴스 필드 |
| Java 9+ String concat 바이트코드 차이? | StringBuilder → invokedynamic (JEP 280) |
| LocalVariableTable의 역할? | 디버그용 변수명 매핑 |
i2l 명령? | int → long 타입 변환 |
ireturn vs areturn? | int 반환 / 참조 반환 |
| record의 equals/hashCode 구현? | ObjectMethods.bootstrap + invokedynamic |
| 클래스 파일 verify의 역할? | 바이트코드 안전성 검증 (스택 일치, 점프 유효성) |
| Constant Pool 인덱스 시작? | #1부터 (#0은 reserved) |
9.2 자기 점검 체크리스트
Phase 3 종합
-
javap -c -v출력을 모든 줄 해독 가능 - Constant Pool 모든 항목 카테고리 식별 가능
- 생성자 바이트코드를 따라갈 수 있다
- 인스턴스 메서드 바이트코드를 따라갈 수 있다
-
dup,getfield,putfield,invoke*등을 안다
실전 적용
- 운영 클래스 파일을 분석해 사고 디버깅 가능
- Java 버전별 바이트코드 차이 인식 가능
- Spring AOP 프록시 클래스 분석 가능
- Reflection 사용 시 성능 함정 안다
- 인라인 캐시의 메가모픽 위험 안다
면접 대비
- 5분 안에 javap 출력 한 화면 해석
- dup이 필요한 이유 코드와 함께 설명
- invoke 4종 차이 명확히
- Java 8 vs 9 변화 (invokedynamic) 알기
- 운영 사고 시 바이트코드 분석 가능
9.3 🎯 Phase 3 졸업 시험
다음 질문에 즉답할 수 있다면 Phase 3 졸업:
- 한 자바 코드
String s = a + b;가 Java 8과 Java 11에서 어떻게 다르게 컴파일되는가? - 바이트코드
invokevirtual #20에서#20이 정확히 무엇을 가리키는가? dup명령이 새 객체 생성 시 왜 필요한가?- NoSuchMethodError 가 발생했을 때 바이트코드와 Constant Pool에서 무엇을 확인하는가?
- Java 17의 record가 어떻게 적은 바이트코드로 equals/hashCode/toString을 구현하는가?
즉답 가능 = Phase 3 졸업 + 2주차 정점 달성.
🎯 핵심 요약 — 3줄 정리
1. javap -c -v -p 한 줄이 바이트코드 분석의 전부
- Magic Number, Version, Constant Pool, Methods, Attributes
- 박승제씨는 이제 모든 줄을 해독 가능
2. 자바 코드 ↔ 바이트코드는 1:N 매핑
callCount++= 5개 바이트코드 명령new Shipment("BL")= new + dup + ldc + invokespecial+연산 = Java 9+에선 invokedynamic
3. 운영 사고 디버깅의 강력한 무기
- NoSuchMethodError → 바이트코드의 Methodref 확인
- ClassLoader 격리 → 어느 .class가 로딩됐는지 추적
- 라이브러리 버그 → 디컴파일 없이 바이트코드 직접 검증
🏆 Phase 3 완주 — 2주차의 정점 달성
🎯 Phase 3 — 바이트코드와 상수 풀
✅ Unit 3.1 바이트코드란 무엇인가
✅ Unit 3.2 상수 풀의 생성과 구조
✅ Unit 3.3 심볼 참조
✅ Unit 3.4 바이트코드 실전 분석 ← 여기, Phase 3 완주
→ 박승제씨는 이제 .class 파일 분석 전문가Phase 3 후 박승제씨가 가진 능력
- ✓
javap -c -v -p출력을 처음부터 끝까지 해석 - ✓ 모든 invoke 명령의 차이 명확히 구분
- ✓ Constant Pool의 모든 14가지 항목 인식
- ✓ 운영 사고 시 30분 내 바이트코드 진단
- ✓ Spring AOP/JPA 생성 코드 검증
- ✓ Java 버전별 컴파일 차이 분석
- ✓ 면접에서 바이트코드 질문에 자신감
📚 다음으로...
Phase 4 — G1 GC 심화
이번 Phase에서 클래스 파일과 메서드 호출의 모든 것을 봤다면, 다음은 운영 환경의 메모리 관리.
1주차에서 GC 기본을 봤지만, 2주차 Phase 4는:
- G1 GC의 리전(Region) 모델 정밀
- 거대 리전(Humongous Region)
- 정지시간 예측 모델
- 운영 서버 GC 튜닝
- GC 로그 분석
→ 박승제씨가 운영 서버의 OOM 트러블슈팅을 마스터하게 됨.
2주차 진행 상황
✅ Phase 1 — 자바 변수 ↔ 메모리 매핑 (1.1 ~ 1.6 완주)
✅ Phase 2 — JVM 메서드 실행 메커니즘 (2.1 ~ 2.4 완주)
✅ Phase 3 — 바이트코드와 상수 풀 (3.1 ~ 3.4 완주, 정점 달성)
🚀 Phase 4 — G1 GC 심화 (다음)
⏭ Phase 5 — 컬렉션 내부 구조
⏭ Phase 6 — Reflection & Iterator
⏭ Phase 7 — Buffer작성한 2주차 학습자료
Phase 1: 6개 Unit (1.1 ~ 1.6)
Phase 2: 4개 Unit (2.1 ~ 2.4)
Phase 3: 4개 Unit (3.1 ~ 3.4) ★ 정점
─────────────────────────────
누적: 14개 Unit
Software Developer