자바 프로그램은 어떻게 실행되는걸까?(+ 코틀린)

💡 자바 프로그램이 실행되는 전체 흐름과, 실행 중일 때 JVM이 어떻게 메모리를 다루는지를 간단하게 정리해보려고 합니다.

 

1. 개발자의 코드 작성과 실행

• 우리가 IDE를 통해 작성한 코드 파일이 .java 확장자로 저장됩니다.

 

2. .java 파일에서 .class 파일로 컴파일

• 우리가 실행할 자바 코드는 모두 JVM 위에서 동작합니다.
• JVM이 읽고 실행할 수 있으려면 JVM이 이해할 수 있는 바이트코드로 변환이 필요합니다.
  • 따라서 우리가 작성한 자바 파일(.java)은 실행 전에 반드시 컴파일 과정을 거칩니다.
  • JDK에 포함된 javac라는 컴파일러가 .java 파일을 읽고, 바이트코드(Bytecode)로 변환해 .class 파일을 만들어줍니다.
• 대부분의 IDE(IntelliJ, Eclipse 등)는 우리가 코드 작성 중일 때도 javac 컴파일러를 자동으로 백그라운드에서 실행시켜 컴파일을 수행합니다.
  그래서 우리는 코드를 실행하기 전에 컴파일 에러가 있는지 미리 감지하고 알 수 있는 것입니다.

💡 컴파일(Compile)
고급 언어(사람이 읽을 수 있는 코드)를 기계가 이해할 수 있는 중간 언어나 기계어로 바꾸는 과정입니다.

💡 JDK (Java Development Kit)
자바 개발에 필요한 도구들이 모여 있는 개발 도구 모음집입니다.
javac, java, javadoc, 라이브러리 등 필수 도구들이 포함되어 있습니다.

💡 javac (Java Compiler)
자바 소스 파일(.java)을 바이트코드로 변환해 .class 파일을 만들어주는 자바 컴파일러입니다.

 

3. JVM(Java Virtual Machine)의 등장

• 바이트 코드로 변환이 끝나면 이제 JVM이 중심이 되어 작업을 수행합니다.

 

🔸 클래스 로딩

• 변환된 .class 파일을 JVM이 읽고 메모리에 올립니다.
  • 이때 클래스 로더가 동작하여 클래스 정보를 JVM의 메서드 영역(Method Area)에 저장합니다.
  • 이 과정에서 로딩 -> 링킹 -> 초기화 단계를 거칩니다.

💡 클래스 로더(Class Loader)
자바 프로그램이 실행 될 때 필요한 클래스를 JVM에 동적으로 로드하는 역할을 합니다.
이 과정에서 로딩(Loading), 링킹(Linking), 초기화(Initialization)라는 단계가 차례로 진행됩니다.

💡 로딩(Loading)
.class 파일을 JVM 메모리로 가져오는 단계입니다.

💡 링킹(Linking)
로드된 .class 파일을 JVM에서 사용할 수 있도록 연결하는 과정입니다.
이 단계는 크게 검증(Verification), 준비(Preparation), 해결(Resolution)로 나눌 수 있습니다.
검증은 클래스 파일의 바이트 코드가 JVM 규격에 맞는지 검사합니다.
준비는 클래스 변수(정적 변수)에 기본값을 할당하는 과정입니다. 예를 들어 int 타입의 변수에는 0, 객체는 null로 초기화됩니다.
해결은 클래스에 선언된 메서드나 변수를 실제 메모리 위치에 연결하는 과정입니다.
링킹은 단순히 필드 공간을 만들고 기본값으로만 초기화하는 것입니다.

💡 초기화(Initialization)
클래스의 정적 초기화 블록과 정적 필드를 클래스가 실제로 사용되기 직전에 초기화하는 과정입니다.
예를 들어 static 필드가 있다면 해당 필드는 클래스가 사용 시 링킹 때 기본값으로 할당된 것에서 static 필드에 사용자가 명시한 값으로 설정되는 것입니다.

💡 링킹에서 기본값으로 초기화하고, 클래스 사용 직전에 실제 코드에 입력된 값으로 초기화하는 이유는?
준비 단계에서 기본값으로 빠르게 클래스 로딩을 끝내고, 실제 사용될 때 실제값으로 초기화(지연 초기화)하여 성능을 높일 수 있습니다.

 

🔸 실행 준비

• 클래스 로딩이 끝나면 JVM의 실행 엔진(Execution Engine)이 바이트 코드를 최종적으로 실행합니다.
• 여기서 중요한 점이 있습니다.
  • 앞서 컴파일한 바이트코드(.class)는 컴퓨터가 바로 이해할 수 있는 코드가 아닙니다.
  • 바이트 코드는 JVM이 이해하도록 만들어진 중간 단계의 코드이기 때문입니다.
  • 따라서 이를 컴퓨터가 이해할 수 있는 기계어로 바꾸는 과정이 필요합니다.
• 그렇다면 왜 자바는 이런 번거로운 방식으로 동작할까요?

 

🔹 JVM이 굳이 바이트코드를 사용하는 이유

• 바로 운영체제(OS)나 하드웨어에 관계없이 실행될 수 있게 하기 위해서입니다.
• 자바는 "한 번 작성하면, 어디서든 실행된다(Write Once, Run Anywhere)"는 철학을 가지고 있습니다.
• 이걸 가능하게 해주는 것이 바로 바이트코드입니다.
• 즉, 자바 코드는 일단 바이트코드(.class) 로 변환되고, 이 바이트코드를 실행하는 역할은 JVM이 맡습니다. 운영체제나 CPU 아키텍처가 다르더라도, 해당 환경에 맞는 JVM만 있다면 바이트코드를 실행할 수 있습니다.
  • JVM이 각 플랫폼마다 존재해서 해당 환경에 맞는 기계어로 번역해 주기 때문입니다.
  • 컴퓨터는 오직 0과 1로 이루어진 기계어(Binary Code)만 이해할 수 있습니다.
• 그래서 JVM 내부에서는 바이트코드를 컴퓨터가 이해할 수 있는 기계어로 바꾸는 과정이 필요합니다.
• 이때 사용되는 기술이 바로 인터프리터(Interpreter) 와 JIT 컴파일러(Just-In-Time Compiler)입니다.

 

🔹 인터프리터(Interpreter)

한 줄 읽음 → 해석 → 실행 → 다음 줄...

• 인터프리터는 바이트코드를 한 줄씩 읽고 즉시 실행합니다.
• 시작이 빠르다는 장점이 있지만, 매번 해석해야 하므로 전체 성능은 느릴 수 있습니다.

 

🔹 JIT 컴파일러 (Just-In-Time Compiler)

자주 쓰는 메서드를 감지  → 전체를 기계어로 바꿔놓음 → 다음엔 그대로 실행

• JIT 컴파일러는 인터프리터와는 달리 자주 실행되는 코드(HotSpot)를 감지해서 한 번에 통째로 기계어로 변환하고, 캐시에 저장해버립니다.
• 인터프리터에 비해 시작은 느리지만 한 번 변환된 이후엔 기계어 상태로 바로 실행되므로 성능이 매우 좋아집니다.

 

😼 코틀린(Kotlin)의 실행 과정

1. 코틀린 소스 파일 작성 (.kt)
   → .kt 확장자의 코틀린 파일을 작성
2. 코틀린 컴파일러(kotlinc)가 .kt 파일을 .class 파일로 컴파일
   → 이 .class 파일은 자바의 바이트코드와 동일한 형태로 생성
   → 즉, Kotlin → Bytecode → JVM 실행
   → kotlinc는 내부적으로 자바 바이트코드를 생성하는 코틀린 전용 컴파일러
3. 이후 실행 과정은 자바와 동일함
   → .class 파일을 JVM이 로딩
   → 실행 엔진이 바이트코드를 기계어로 변환(JIT / 인터프리터 사용)
   → 실행됨

 

🥸 정리

1. 작성한 소스 코드가 javac를 통해 바이트코드(.class)로 컴파일되고,
2. JVM이 이 바이트코드를 메모리에 로드하며,
3. 실행 엔진이 바이트코드를 기계어로 변환하여 최종적으로 실행합니다.

 자바 프로그램은 바이트코드를 기반으로 동작하는 JVM 덕분에 어떤 운영체제든지 JVM만 있다면 동일하게 실행될 수 있습니다.

또한 인터프리터와 JIT 컴파일러의 조합을 통해 자바는 빠른 시작과 높은 실행 성능을 동시에 추구합니다.

 

 

 

 

 

참고

chatGPT