JDK, JRE, JVM 총정리(feat. 자바 컴파일 과정)

1. JDK

• JDK(Java Development Kit)는 자바 프로그램을 개발하고 실행할 수 있는 환경을 제공하는 도구이다.
• JDK는 JRE(JVM, Java Class Library), Java Development Tools(javac, java, javap, apt, jar, ...)을 포함한다.
• 예를 들어,
  1. 소스 코드 컴파일러(javac): .java 파일을 바이트코드(.class)로 변환
  2. 디버깅 도구(jdb): 디버깅 및 오류 분석
  3. JAR 생성 도구(jar): 클래스 파일들을 하나의 JAR 파일로 묶음

• C:\Program Files\Java 안에 JDK 폴더를 확인할 수 있고, JRE, Java Dev Tools가 있다.
  JDK 1.8(Java 8) 이전인 경우, JDK 폴더와 JRE 폴더로 따로 있다.

현재 지원하는 JDK LTS는 자바 공식 홈페이지인 https://www.java.com/releases/에서 확인할 수 있다.

2. JRE

• JRE(Java Runtime Environment)는 자바 애플리케이션 실행 환경을 제공하는 소프트웨어 패키지이다.
• JVM, 표준 라이브러리(Java Class Library)를 포함한다.
• 자바 애플리케이션을 실행하기 위한 런타임 환경이다.

3. 자바의 특징

1. 운영체제에 독립적이다.
   • 자바는 자바 가상 머신(JVM, Java Virtual Machine)을 사용하여 어느 운영체제에서나 동일한 형태로 실행될 수 있다.
2. 객체지향 프로그래밍이다.
   • OOP - Object Oriented Programing
   • 계층 구조, 캡슐화, 상속, 추상화, 다형성 등을 구현한 객체지향 언어이다.
3. 메모리를 자동으로 관리한다.
   • Garbage Collection을 통해 불필요한 메모리를 자동으로 제거한다.
4. 오픈 소스가 풍부하다.
   • 오픈 소스로 풍부한 라이브러리가 제공된다.
   • 오라클에 인수된 후에는 사용 목적에 따라 일부는 유료이다.
5. 멀티스레드 구현이 가능하다.
   • 공통 스레드 API를 제공해서 운영체제에 관계없이 멀티스레드를 쉽게 구현할 수 있다.

4. 자바 동작 과정

1. 자바 클래스 파일(.java)은 자바 컴파일러에 의해 자바 바이트 코드(.class)로 변환
2. JVM에 의해 자바 바이트 코드는 기계어인 바이너리 코드(1011 0011)로 컴파일 수행
3. 바이너리 코드는 바로 CPU에서 실행한 후에 사용자에게 서비스 제공

• 자바 컴파일러자바를 설치하면 javac.exe라는 실행 파일 형태로 자바 컴파일러가 설치된다.
• 자바 컴파일러(Java compiler)는 자바를 가지고 작성한 자바 소스 코드(.java)를 자바 가상 머신(JVM, Java Virtual Machine)이 이해할 수 있는 자바 바이트 코드(.class)로 변환한다.
• 자바 바이트 코드
• 자바 바이트 코드(Java byte code)란 JVM이 이해할 수 있는 언어로 변환된 자바 소스 코드를 의미한다. 자바 컴파일러에 의해 변환되는 코드의 명령어 크기가 1바이트라서 자바 바이트 코드라고 불리고 있다. 이러한 자바 바이트 코드의 확장자는 .class이다. 자바 바이트 코드는 자바 가상 머신만 설치되어 있으면, 어떤 운영체제에서라도 실행될 수 있다.
• 자바 가상 머신
• 자바 가상 머신(JVM, Java Virtual Machine)이란 자바 바이트 코드를 실행시키기 위한 가상의 기계라고 할 수 있다. 자바로 작성된 모든 프로그램은 자바 가상 머신에서만 실행될 수 있으므로, 자바 프로그램을 실행하기 위해서는 반드시 자바 가상 머신이 설치되어 있어야 한다.

5. JVM

5.1 JVM 동작 방식

JVM의 역할은 자바 애플리케이션을 클래스 로더를 통해 읽어 자바 API와 함께 실행하는 것이다.
다음은 자바 소스 파일을 어떤 동작으로 코드를 읽는지에 대한 간단한 요약 도식이다.

1. 자바 프로그램을 실행하면 JVM은 OS로부터 메모리 공간을 할당받는다.
2. 컴파일러(javac)에 의해 자바 소스코드(.java)는 자바 바이트 코드(.class)로 컴파일을 수행한다.
3. Class Loader는 동적 로딩을 통해 필요한 클래스들을 로딩 및 링크하여 Runtime Data Area(실질적인 메모리를 할당 받아 관리하는 영역)에 로드한다.
4. Runtime Data Area에 로딩된 바이트 코드는 Execution Engine을 통해 해석된다.
5. 이 과정에서 Execution Engine에 의해 Garbage Collector의 작동과 Thread 동기화가 이루어진다.

5.2 JVM 내부 구조

다음은 위에서 다뤄본 JVM 동작 과정 중 Class Loader ↔ Execution Engine ↔ Runtime Data Area 부분을 좀더 상세화 한 도식이다.

이처럼 JVM은 아래와 같이 구성되어 있다.

1. 클래스 로더(Class Loader)
2. 실행 엔진(Execution Engine)
   • JIT 컴파일러(Just-in-Time)
   • 인터프리터(Interpreter)
   • 가비지 콜렉터(Garbage collector)
3. 런타임 데이터 영역 (Runtime Data Area)
   • 메소드 영역
   • 힙 영역
   • PC Register
   • 스택 영역
   • 네이티브 메소드
4. JNI - 네이티브 메소드 인터페이스 (Native Medthod Interface)
5. 네이티브 메소드 라이브러리 (Native Method Library)

6. 클래스 로더

클래스 로더(Class Loader)는 JVM 안에 있으며 클래스 파일(*.class)을 동적으로 로드(Loading)하고, 링크(Linking)를 통해 배치(Initialization)하는 작업을 수행하는 모듈이다. 즉, 로드된 바이트 코드(.class)들을 엮어서 JVM의 메모리 영역인 Runtime Data Areas에 배치한다. 클래스를 메모리에 올리는 로딩 기능은 한번에 메모리에 올리지 않고, 애플리케이션에서 필요한 경우 동적으로 메모리에 적재하게 된다.

• 클래스 파일의 로딩 순서는 다음과 같이 3단계로 구성된다. (Loading → Linking → Initialization)

• Loading(로드) : 클래스 파일을 가져와서 JVM의 메모리에 로드한다.
• Linking(링크) : 클래스 파일을 사용하기 위해 검증하는 과정이다.
  1. Verifying(검증) : 읽어들인 클래스가 JVM 명세에 명시된 대로 구성되어 있는지 검사한다.
  2. preparing(준비) : 클래스가 필요로 하는 메모리를 할당한다.
  3. Resolving(분석) : 클래스의 상수 풀 내 모든 심볼릭 레퍼런스를 다이렉트 레퍼런스로 변경한다.
• Initialization(초기화) : 클래스 변수들을 적절한 값으로 초기화한다. ( static 필드들을 설정된 값으로 초기화 등 )

5. 실행 엔진

실행 엔진(Execution Engine)은 클래스 로더를 통해 런타임 데이터 영역에 배치된 바이트 코드를 명령어 단위로 읽어서 실행한다. 자바 바이트 코드(*.class)는 기계가 바로 수행할 수 있는 언어가 아닌 자바 가상 머신이 이해할 수 있는 중간 레벨로 컴파일 된 코드이다. 그래서 실행 엔진은 바이트 코드를 실제로 JVM 내부에서 기계가 실행할 수 있는 형태로 변경해준다.

• 이 수행 과정에서 실행 엔진은 인터프리터와 JIT 컴파일러 두 가지 방식을 혼합하여 바이트 코드를 실행한다.

• 인터프리터(Interpreter)
  1. 바이트 코드 명령어를 하나씩 읽어서 해석하고 바로 실행한다.
  2. JVM 안에서 바이트 코드는 기본적으로 인터프리터 방식으로 동작한다.
  3. 단, 같은 메서드라도 여러번 호출이 된다면 매번 해석하고 수행해야 되서 전체적인 속도는 느리다.
• JIT 컴파일러(Just-In-Time Compiler)
  위의 인터프리터(Interpreter)의 단점을 보완하기 위해 도입된 방식으로 반복되는 코드를 발견하여 바이트 코드 전체를 컴파일하여 Native Code로 변경하고 이후에는 해당 메서드를 더 이상 인터프리팅 하지 않고 캐싱해 두었다가 네이티브 코드로 직접 실행하는 방식이다.
• 하나씩 인터프리팅하여 실행하는 것이 아니라, 컴파일된 네이티브 코드를 실행하는 것이기 때문에 전체적인 실행 속도는 인터프리팅 방식보다 빠르다.하지만 바이트코드를 Native Code로 변환하는 데에도 비용이 소요되므로, JVM은 모든 코드를 JIT 컴파일러 방식으로 실행하지 않고 인터프리터 방식을 사용하다 일정 기준이 넘어가면 JIT 컴파일 방식으로 명령어를 실행하는 식으로 진행한다.

네이티브 코드(Native Code)란, JAVA에서 부모가 되는 C, C++, 어셈블리어로 구성된 코드를 의미한다.

6. 가비지 컬렉터

자바 가상 머신은 가비지 컬렉터(Garbage Collector ,GC)를 이용하여 Heap 메모리 영역에서 더는 사용하지 않는 메모리를 자동으로 회수해 준다. C언어 같은 경우 직접 개발자가 메모리를 해제해줘야 되지만, JAVA는 이 가비지 컬렉터를 이용해 자동으로 메모리를 실시간 최적화 시켜준다.

따라서 개발자가 따로 메모리를 관리하지 않아도 되므로, 더욱 손쉽게 프로그래밍을 할 수 있도록 해준다. 일반적으로 자동으로 실행되지만, 단 GC(가비지 컬렉터) 가 실행되는 시간은 정해져 있지 않다. 특히 Full GC가 발생하는 경우, GC를 제외한 모든 스레드가 중지되기 때문에 장애가 발생할 수 있다.

수동으로 GC(가비지 컬렉터)를 실행하기 위해 System.gc()라는 메소드를 사용할 수 있지만, 함수 실제 실행은 보장되지는 않는다.

7. 런타임 데이터 영역

런타임 데이터 영역은 쉽게 말하면, JVM의 메모리 영역으로 자바 애플리케이션을 실행할 때 사용되는 데이터들을 적재하는 영역이다.
런타임 데이터 영역은 위 그림과 같이 크게 Method Area, Heap Area, Stack Area, PC Register, Native Method Stack로 나눌 수 있다.

7.1 Method (Static) Area

• 클래스 로더에 의해 로드된 클래스 정보
• 클래스의 메서드 코드(Static 메서드 포함)
• Static 변수
• 인터페이스 및 필드 정보

모든 스레드에서 공유되며, 프로그램 시작 시 로드되고 종료 시 해제된다. 클래스 수준의 고정된 정보들이 저장된다.

7.2 Runtime Constant Pool

• 상수 값(문자열 상수, 숫자 상수 등)
• 클래스, 메서드, 필드의 참조 주소
• 모든 스레드에서 공유되며, Method Area의 일부이다. 상수와 메서드 참조 정보를 저장하는 공간이다. 런타임에 필요한 상수 값과 참조를 관리한다.

7.3 Heap Area

• 객체(instance)와 배열
• 객체의 필드 값(예: 멤버 변수)

모든 스레드에서 공유되며, 프로그램 실행 중 new 키워드로 생성된 모든 객체가 저장된다. GC(Garbage Collection)에 의해 사용하지 않는 객체가 정리된다.

7.4 Stack Area (JVM Stack)

• 메서드 호출 시 생성된 스택 프레임
  • 지역 변수
  • 매개변수
  • 리턴 값

스레드마다 독립적으로 생성되며, 메서드 호출 시 생성된다. 호출이 종료되면 제거되는 후입선출(LIFO) 구조이다.

7.5 PC Register

• 현재 실행 중인 명령어의 주소

스레드마다 하나씩 생성된다. JVM이 현재 실행 중인 명령어를 추적하기 위해 사용된다.

7.6 Native Method Stack Area

• Native 메서드 호출과 관련된 데이터
  • 매개변수, 지역 변수, 네이티브 코드 실행에 필요한 정보
• 자바 외의 언어(C, C++)로 작성된 네이티브 코드 실행을 지원하는 메모리 공간이다. Native 메서드가 호출될 때 생성되고 종료 시 제거된다.

---

7.7 요약

• Method Area와 Runtime Constant Pool: 클래스와 메서드 정보, 상수 및 참조를 저장. 프로그램 전역에서 공유
• Heap Area: 객체와 배열 데이터를 저장하는 공용 영역
• Stack Area: 메서드 실행에 필요한 데이터를 저장하며 스레드마다 독립적으로 관리
• PC Register: 현재 실행 중인 명령어를 추적하는 데 사용
• Native Method Stack: 자바 외의 네이티브 코드를 실행하기 위한 별도 스택

이때 Method Area, Heap Area는 모든 스레드(Thread)가 공유하는 영역이고, 나머지 Stack Area, PC Register, Native Method Stack은 각 쓰레드 마다 생성되는 개별 영역이다. 좀 더 자세히 살펴보자면 다음과 같은 도식이 된다.

8. 메서드 영역

메서드 영역은 JVM이 시작될 때 생성되는 공간으로 바이트 코드(.class)를 처음 메모리 공간에 올릴 때 초기화되는 대상을 저장하기 위한 메모리 공간이다. JVM이 동작하고 클래스가 로드될 때 적재되서 프로그램이 종료될 때까지 저장된다. 메서드 영역(Method Area)은 Class Area나 Static Area으로도 부르고 있다.

모든 쓰레드가 공유하는 영역이기 때문에 다음과 같이 초기화 코드 정보들이 저장된다.

1. 필드 정보 : 멤버 변수의 이름, 데이터 타입, 접근 제어자의 정보
2. 메서드 정보 : 메소드 이름, return 타입, 함수 매개변수, 접근 제어자의 정보
3. 타입 정보 : Class 인지 Interface 인지 여부 저장, Type의 속성, Super Class의 이름

간단히 말하자면 메서드 영역에는 정적 필드와 클래스 구조만을 갖고 있다고 할 수 있다.

※ 메소드 영역(런타임 상수 풀 포함)의 사용기간 및 스레드 공유 범위

• JVM 시작 시 생성
• 프로그램 종료 시 까지
• 명시적으로 null 선언 시

[ Runtime Constant Pool ]

- 메서드 영역에 존재하는 별도의 관리 영역이다. 각 클래스 혹은 인터페이스마다 별도의 constant pool 테이블이 존재한다. 클래스를 생성할 때 참조해야 할 정보들을 상수로 가지고 있는 영역이다. JVM은 이 Constant Pool을 통해 해당 메소드나 필드의 실제 메모리 상 주소를 찾아 참조한다. 정리하면 상수 자료형을 저장하여 참조하고 중복을 막는 역할을 수행한다.

9. 힙 영역

힙 영역(Heap Area)은 메서드 영역와 함께 모든 스레드가 공유하며, JVM이 관리하는 프로그램 상에서 데이터를 저장하기 위해 런타임 시 동적으로 할당하여 사용하는 영역이다. 즉, new 연산자로 생성되는 클래스와 인스턴스 변수, 배열 타입 등 참조형 타입이 저장되는 곳이다. 당연히 Method Area 영역에 저장된 클래스만이 생성이 되어 적재된다.

※ 힙 영역의 사용기간 및 스레드 공유 범위

• 객체가 더 이상 사용되지 않거나 명시적으로 null 선언 시
• GC(Garbage Collection) 대상

유의할 점은 힙 영역에 생성된 객체와 배열은 참조 타입(Reference Type)으로서, JVM 스택 영역의 변수나 다른 객체의 필드에서 참조된다는 점이다. 즉, 힙의 참조 주소는 "스택"이 가지고 있으며 스택 안에 저장된 해당 객체(주소)를 통해서만 힙 영역에 있는 인스턴스를 핸들링할 수 있는 것이다.

만일 참조하는 변수나 필드가 없다면 의미 없는 객체가 되기 때문에 변수나 필드가 없는 객체를 쓰레기로 취급하고 JVM은 쓰레기 수집기인 Garbage Collector를 실행시켜 쓰레기 객체를 힙 영역에서 자동으로 제거된다. 이처럼 힙 영역은 가비지 컬렉션에 대상이 되는 공간이다. 그리고 효율적인 가비지 컬렉션을 수행하기 위해서 세부적으로 다음과 같이 5가지 영역으로 나뉘게 된다.

이렇게 다섯가지 영역(Eden, survivor 0, survivor 1, Old, Permanent)으로 나뉜 힙 영역은 다시 물리적으로 Young Generation 과 Old Generation 영역으로 구분되게 되는데 다음과 같다.

• Young Generation : 생명 주기가 짧은 객체를 GC 대상으로 하는 영역.
• Eden : new를 통해 새로 생성된 객체가 위치. 정기적인 쓰레기 수집(GC) 후 살아남은 객체들은 Survivor로 이동
  Survivor 0 / Survivor 1 : 각 영역이 채워지게 되면, 살아남은 객체는 비워진 Survivor로 순차적으로 이동
• Old Generation : 생명 주기가 긴 객체를 GC 대상으로 하는 영역. Young Generation에서 마지막까지 살아남은 객체가 이동

10. 스택 영역 (Stack Area)

스택 영역은 int, long, boolean등 기본 자료형을 생성할 때 저장하는 공간으로, 임시적으로 사용되는 변수나 정보들이 저장되는 영역이다.

자료구조에서 Stack이란, 마지막에 들어온 값이 먼저 나가는 후입선출(LIFO) 구조로 push와 pop 기능 사용방식으로 동작한다. Runtime Data Area 안의 Stack 영역 또한 동일하다. 메서드 호출 시마다 각각의 스택 프레임(해당 메서드만을 위한 공간)이 생성되고 메서드 안에서 사용되는 값들을 저장하고, 호출된 메서드의 매개변수, 지역변수, 리턴 값 및 연산 시 일어나는 값들을 임시로 저장한다. 그리고 메서드 수행이 끝나면 프레임 별로 삭제된다.

[ 스택 프레임(stack frame) ]

메서드가 호출될 때마다 프레임이 만들어지며, 현재 실행중인 메소드 상태 정보를 저장하는 곳이다. 메서드 호출 범위가 종료되면 스택에서 제거된다. 스택 프레임에 쌓이는 데이터는 메서드의 매개변수, 지역변수, 리턴값, 연산시 결과값 등이 있다.

단, 데이터의 타입에 따라 스택(stack)과 힙(heap)에 저장되는 방식이 다르다는 점은 유의해야 한다.

기본(Primitive, 원시)타입 변수는 스택 영역에 직접 값을 적재한다. 참조타입 변수는 힙 영역이나 메소드 영역의 객체 주소를 가진다. 예를 들어 Person p = new Person(); 와 같이 클래스를 생성할 경우, new에 의해 생성된 클래스는 Heap Area에 저장되고, Stack Area에는 생성된 클래스의 참조 변수인 p만 저장된다.

스택 영역은 각 스레드마다 하나씩 존재하며, 스레드가 시작될 때 할당된다. 프로세스가 메모리에 로드 될 때 스택 사이즈가 고정되어 있어, 런타임 시에 스택 사이즈를 바꿀 수는 없다. 만일 고정된 크기의 JVM 스택에서 프로그램 실행 중 메모리 크기가 충분하지 않다면 StackOverFlowError가 발생하게 된다. 스레드를 종료하면 Runtime Data Area 안의 Stack Area에서 사라진다.

여기까지 배운 메소드 영역, 힙 영역, 스레드 영역을 한 그림으로 표시하자면 다음과 같이 도식이 그려지게 된다.

11. PC Register

PC Register는 스레드가 시작될 때 생성되며, 현재 수행중인 JVM 명령어 주소를 저장하는 공간이다. JVM 명령의 주소는 스레드가 어떤 부분을 무슨 명령으로 실행해야할 지에 대한 기록을 가지고 있다. 일반적으로 프로그램의 실행은 CPU에서 명령어(Instruction)을 수행하는 과정으로 이루어진다.

이때 CPU는 연산을 수행하는 동안 필요한 정보를 레지스터라고 하는 CPU 내의 기억장치를 이용하게 된다. 예를 들어, A와 B라는 데이터와 피연산 값인 Operand가 있고 이를 더하라는 연산 Instruction이 있다고 하자. A와 B, 그리고 더하라는 연산이 순차적으로 진행이 되게 되는데, 이때 A를 받고 B를 받는 동안 이 값을 CPU가 어딘가에 기억해 두어야 할 필요가 생긴다. 이 공간이 바로 CPU 내의 기억장치 Register이다.

하지만 자바의 PC Register는 위의 CPU Register와 다르다. OS나 CPU의 입장에서 자바는 결국 하나의 프로세스이기 때문에 가상 머신의 리소스를 이용해야 한다. 그래서 자바는 CPU에 직접 연산을 수행하도록 하는 것이 아닌, 현재 작업하는 내용을 CPU에게 연산으로 제공해야 하며, 이를 위한 버퍼 공간으로 PC Register라는 메모리 영역을 만들게 된 것이다.

따라서 JVM은 스택에서 비연산값 Operand를 뽑아 별도의 메모리 공간인 PC Register에 저장하는 방식을 취한다.

만약, 스레드가 자바 메소드를 수행하고 있으면 JVM 명령(Instruction)의 주소를 PC Register에 저장한다. 이때 자바가 아닌 다른 언어(C언어, 어셈블리)의 메소드가 수행 중이라면, undefined 상태가 된다. 왜냐하면 자바에서는 이 두 경우를 따로 처리하기 때문이다. 이 부분이 바로 뒤에 언급하게 될 Native Method Stack 공간이다.

12. 네이티브 메서드 스택

네이티브 메서드 스택(Native Method Stack)는 자바 코드가 컴파일되어 생성되는 바이트 코드가 아닌 실제 실행할 수 있는 기계어로 작성된 프로그램을 실행시키는 영역이다. 또한 자바 이외의 언어(C, C++, 어셈블리 등)로 작성된 네이티브 코드를 실행하기 위한 공간이기도 하다. 사용되는 메모리 영역으로는 일반적인 C 스택을 사용한다.

위에서 배운 JIT 컴파일러에 의해 변환된 Native Code 역시 여기에서 실행이 된다고 보면 된다.

일반적으로 메소드를 실행하는 경우 JVM Stack에 쌓이다가 Stack Frame에 네이티브 방식을 사용하는 메소드가 있다면, 해당 메소드는 Native Method Stack에 쌓인다. 그리고 Native Method의 수행이 끝나면 다시 자바 스택으로 돌아와 다시 작업을 수행한다. 그래서 네이티브 코드로 되어 있는 함수의 호출을 자바 프로그램 내에서도 직접 수행할 수 있고 그 결과를 받아올 수도 있는 것이다.

Native Method Stack은 바로 다음에 배울 네이티브 메소드 인터페이스(JNI)와 연결되어 있는데, JNI가 사용되면 네이티브 메서드 스택에 바이트 코드로 전환되어 저장되게 된다.

13. JNI

JNI(Java Native Interface)는 자바가 다른 언어로 만들어진 어플리케이션과 상호 작용할 수 있는 인터페이스를 제공하는 프로그램이다. 위에서 다뤄봤듯이, JNI는 JVM이 Native Method를 적재하고 수행할 수 있도록 한다. 하지만 실질적으로 제대로 동작하는 언어는 C / C++ 정도 밖에 없다고 한다.

• Native Method Library
  1. C, C++로 작성된 라이브러리를 칭한다.
  2. 만약 헤더 파일이 필요할 때, JNI는 Native Method Library를 로딩해 실행한다.