어떤 프로그램을 다운로드할 때 "Windows용", "Mac용"을 따로 받아야 했던 경험, 한 번쯤은 있으실 것입니다. 컴퓨터 세상에서는 이게 당연한 규칙이었습니다.
그런데 Java는 조금 특별합니다.
한 번 작성하면, 어디서든 실행된다 (Write Once, Run Anywhere)
개발자가 코드를 딱 한 번만 작성하면, 그 코드가 어떤 컴퓨터에서든 마법처럼 딱 맞게 돌아갑니다. 어떻게 가능할까요? 바로! JVM(Java Virtual Machine) 덕분입니다.
이번 편에서는 java 명령어 뒤에 숨겨진 JVM의 시동 과정을 함께 뜯어보려 합니다.
우리가 Java 코드를 작성하면
우리가 작성하는 .java 파일은 어떻게 JVM에 전달될까요?
- 코드를 작성하면 javac 컴파일러가 Bytecode로 변환합니다.
- 변환된 .class file을 만들고,
- 각 OS에 설치된 JVM이 이 .class 파일을 읽어(로딩)들입니다.
- 해당 운영체제가 이해할 수 있는 기계어(Machine Code)로 번역하며 실행합니다.
다음으로는 .class 파일이 JVM으로 전달된 후의 내부 동작에 대해서 알아보겠습니다.
JVM 내부 동작 - 실행 3인방
JVM은 아래와 같은 내부 구조를 가지고 있습니다.
1. Class Loader (클래스 로더)
클래스 파일을 찾아 그 내용(바이트코드)을 JVM의 메모리(Runtime Data Area)로 가져옵니다. 가져온 코드가 유효하고 안전한지 확인하는 과정이 있습니다. 이 과정이 없으면 어떤 코드도 실행될 수 없고 잠재적 보안 위험에 노출될 수 있습니다.
역할
-
로딩(Loading):
.class파일에서 바이트코드를 읽어와 JVM의 메소드 영역에 클래스 정보를 저장합니다. -
연결(Linking)
- 검증(Verification): 로드된 바이트코드가 Java 언어 사양과 JVM 규약을 준수하는지 확인하여 악성 코드나 잘못된 코드가 실행되는 것을 방지합니다.
- 준비(Preparation): 클래스의 static 필드(변수)에 필요한 메모리를 할당하고 기본값으로 초기화합니다.
- 해결(Resolution): 심볼릭 참조(예: System.out.println)를 실제 메모리 주소로 변환합니다.
- 초기화(Initialization): static 필드에 개발자가 명시한 실제 값을 할당하고, static 블록을 실행합니다.
2. Runtime Data Area (런타입 데이터 공간)
JVM이 프로그램을 실행하는 과정에서 발생하는 모든 종류의 데이터(클래스 정보, 변수, 객체 등)를 효율적인 데이터 저장 및 접근, 그리고 생명 주기 관리를 위해 저장하고 관리할 체계적인 메모리 공간이 필요합니다.
나누어진 메모리 영역을 간단히 설명하면,
-
메소드 영역 (Method Area) : 클래스 정보, static 변수, 메소드 코드 등이 저장됩니다. JVM 프로세스 시작 시에 생성되고 종료 시까지 유지됩니다. 이 영역은 모든 스레드가 공유합니다.
-
힙 영역 (Heap Area) :
new연산자로 생송된 객체(인스턴스)와 배열이 저장됩니다. 모든 스레드가 공유하고, 가비지 컬렉터(Garbage Collector; GC)의 주요 관리 대상입니다. -
스택 영역 (Stack Area) : 각 스레드마다 별도로 생성되며, 메소드 호출 정보(스택 프레임), 지역 변수, 매개변수 등이 임시적으로 저장됩니다.
메소드가 호출되면 프레임이 푸시되고, 종료되면 팝(pop)되어 사라집니다.
3. Execution Engine (실행 엔진)
클래스 로더가 바이트코드를 메모리에 적재하고 런타임 데이터 영역에 데이터가 준비되어도, 실제로 그 바이트코드를 CPU가 이해할 수 있는 기계어로 변환하고 명령을 실행하는 주체가 없다면 프로그램은 동작할 수 없습니다.
실행 엔진이 바이트코드를 한 줄 한 줄 읽어내려가며 컴퓨터가 이해할 수 있는 기계어로 번역하고 실행합니다. 이때 주로 두 가지 방식을 사용합니다.
1. 인터프리터(Interpreter) 방식
바이트코드를 한 명령어씩 읽어 즉시 기계어로 변환하고 실행합니다.
- 장점: 컴파일 과정 없이 바로 실행할 수 있어 프로그램 시작 시간이 빠릅니다.
- 단점: 동일한 코드가 반복될 때마다 매번 해석해야 하므로 비효율적일 수 있습니다.
2. JIT 컴파일러 (Just-In-Time Compiler) 방식
인터프리터 방식의 비효율을 해결하기 위한 방식입니다.
자주 실행되는 코드(Hotspot)를 프로파일링(Profiling) 하여 식별합니다.
이 식별된 바이트코드 블록을 런타임에 네이티브 코드(기계어) 로 컴파일하여 메모리에 저장합니다.
이후 동일한 코드가 호출될 때는 인터프리터를 거치지 않고 미리 컴파일된 네이티브 코드를 직접 실행하여 성능을 대폭 향상시킵니다.
결론
실행 엔진은 처음 보는 코드는 인터프리터로 한 줄씩 처리하다가, 자주 쓰는 중요한 코드는 JIT 컴파일러로 통째로 최적화하는 두 가지 전략을 함께 사용합니다.
Java는 처음에는 약간 느리게 시작하더라도, 실행될수록 점점 더 빨라지는 '동적 최적화'의 특징을 가지게 됩니다.
마무리
지금까지 뒤에서 일어나는 JVM의 내부 동작 과정을 살펴봤습니다.
다음 편에서는 '런타임 데이터 영역(JVM 메모리)' 의 스택과 힙 메모리에 대해서 알아보겠습니다.
