1.자바로 개발된 프로그램을 실행하면 JVM은 OS로부터 메모리를 할당받는다. (JVM은 이 메모리를 용도에 따라 여러 영역으로 나누어 관리한다.)
2.컴파일(Compile): 작성한 자바 소스코드(.java)를 자바 컴파일러를 사용하여 컴파일한다. 컴파일은 소스 코드를 기계어가 아닌 중간 단계의 바이트 코드(Bytecode)로 변환하는 과정이다. 컴파일된 바이트 코드는 .class 확장자를 가진 파일에 저장된다.
3. 클래스 로딩: 자바 가상 머신(Java Virtual Machine, JVM)은 프로그램을 실행하기 전에 컴파일된 바이트 코드를 클래스로 로딩한다. 클래스 로더(Class Loader)는 필요한 클래스들을 찾아서 메모리(JVM Runtime Data Area)에 적재하고, 실행에 필요한 클래스들의 정보를 JVM에 제공한다.
4. 바이트 코드 해석: JVM은 메모리(Runtime Data Area)에 로드된 클래스의 바이트 코드(.class)를 Execution Engine을 통해 해석하여 실행한다. 바이트 코드는 JVM이 이해할 수 있는 기계어에 가까운 형태로, JVM은 이를 실행하여 프로그램을 동작시킨다.
5.실행: JVM은 바이트 코드를 한 줄씩 실행한다. 프로그램은 main 메서드가 있는 클래스에서 시작되며, main 메서드는 프로그램의 진입점 역할을 한다. 실행 중에 필요한 데이터나 객체들은 메모리에 생성되며, JVM은 이들을 관리한다.
이 과정에서 Execution Engine에 의해 Garbage Collector의 작동과 Thread 동기화가 이루어진다. (ex. Garbage Collector)
자바 가상 머신(JVM)의 구조
JVM 동작 방식을 간략하게 알아봤으니 이제 구성 요소를 알아보자.
다음은 위에서 다뤄본 JVM 동작 과정 중 Class Loader ↔ Execution Engine ↔ Runtime Data Area 부분을 좀더 상세히 도식화 한 것이다.
앞서 말했다시피 클래스 로더에 의해 JVM으로 로드된 .class 파일(바이트코드)들은 Runtime Data Areas의 Method Area에 배치되는데, 배치된 이후에 JVM은 Method Area의 바이트 코드를 실행 엔진(Execution Engine)에 제공하여, 정의된 내용대로 바이트 코드를 실행시킨다. 이때, 로드된 바이트코드를 실행하는 런타임 모듈이 실행 엔진(Execution Engine)이다. Execution Engine은 바이트코드를 명령어 단위로 읽어서 실행한다.
자바 실행엔진이 어떻게 동작하는 지는 JVM 명세에 작성되어 있지 않다. JVM 명세에도 “명령 실행에 대한 구체적인 사항은 구현자의 창의력을 저해시킬 수 있기 때문에 JVM에 명시하지 않겠다.” 라고만 적혀있다. 즉 자바 실행 엔진은 JVM마다 다른 것이다. 그렇다면 Oracle의 Hotspot은 어떻게 자바 명령을 실행하는지 간단하게 살펴보자
A standard interpreter is used to launch the applications.
일반적인 인터프리터가 어플리케이션을 시작하는데 사용된다.
When the application runs, the code is analyzed to detect performance bottlenecks, or hot spots. The Java HotSpot VM compiles the performance-critical portions of the code for a boost in performance, but does not compile the seldom-used code (most of the application).
어플리케이션이 동작할 때, 코드를 분석하여 bottleneck 또는 HotSpot을 탐지한다. HotSpot 가상머신은 성능 향상을 위해 코드의 성능에 중요한 부분을 컴파일하지만 거의 사용되지 않는 코드(대부분의 어플리케이션)는 컴파일하지 않는다.
The Java HotSpot VM uses the adaptive compiler to decide how to optimize compiled code with techniques such as inlining.
HotSpot 가상머신은 코드를 컴파일 하는 방법을 최적화 하기 위해 라인별 adaptive compiler를 사용한다.
즉 HotSpot 가상머신은 라인별로 바이트 코드를 읽어 기계어로 변환해 실행하며 기본적으로는 인터프리터를 통해 실행을 하지만 자주 등장하는 바이트 코드일 경우 JIT 컴파일러를 사용해 컴파일을 하는 방법을 통해 실행 방법을 최적화 시킨다. 자세한 내용은Java Virtual Machine Guide을 참고하자
인터프리터(Interpreter)
바이트 코드 명령어를 하나씩 읽어서 해석하고 바로 실행한다. 하나씩 해석하고 실행하기 때문에 바이트코드 하나하나의 해석은 빠른 대신 인터프리팅 결과의 실행은 느리다는 단점을 가지고 있다. 흔히 얘기하는 인터프리터 언어의 단점을 그대로 가지는 것이다.
즉, JVM안에서 바이트코드는 기본적으로 인터프리터 방식으로 동작한다. 다만 같은 메소드 라도 여러번 호출이 된다면 매번 해석하고 수행해야 되서 전체적인 속도는 느리다.
JIT 컴파일러(Just-In-Time Compiler)
위의 Interpreter의 단점을 보완하기 위해 도입된 방식으로 반복되는 코드를 발견하여바이트 코드 전체를 컴파일하여 Native Code로 변경하고 이후에는 해당 메서드를 더 이상 인터프리팅 하지 않고 캐싱해 두었다가네이티브 코드로 직접 실행하는 방식이다. 하나씩 인터프리팅하여 실행하는것이 아니라, 컴파일된 네이티브 코드를 실행하는 것이기 때문에 전체적인 실행 속도는 인터프리팅 방식보다 빠르다. 하지만 바이트코드를 Native Code로 변환하는 데에도 비용이 소요되므로, JVM은 모든 코드를 JIT 컴파일러 방식으로 실행하지 않고 인터프리터 방식을 사용하다 일정 기준이 넘어가면 JIT 컴파일 방식으로 명령어를 실행하는 식으로 진행한다.
※ 참고
네이티브 코드란 .JAVA에서 부모가 되는 C언어나, C++, 어셈블리어로 구성된 코드를 의미한다.
가비지 컬렉터 (Garbage Collector ,GC)
자바 가상 머신은 가비지 컬렉터(garbage collector)를 이용하여Heap 메모리 영역에서 더는 사용하지 않는 메모리를 자동으로 회수해 준다.
C언어 같은 경우 직접 개발자가 메모리를 해제해줘야 되지만, JAVA는 이 가비지 컬렉터를 이용해 자동으로 메모리를 실시간 최적화 시켜준다. 따라서 개발자가 따로 메모리를 관리하지 않아도 되므로, 더욱 손쉽게 프로그래밍을 할 수 있도록 해준다.
일반적으로 자동으로 실행되지만, GC(가비지 컬렉터) 가 실행되는 시간은 정해져 있지 않다.
특히 Full GC 가 발생하는 경우, GC 를 제외한 모든 스레드가 중지되기 때문에 장애가 발생할 수 있다.
※ 참고
수동으로 GC(가비지 컬렉터)를 실행하기 위해 System.gc() 라는 메소드를 사용할 수 있지만, 함수 실제 실행은 보장되지는 않는다.
런타입 데이터 영역은 쉽게 말하면 JVM의 메모리 영역으로자바 애플리케이션을 실행할 때 사용되는 데이터들을 적재하는 영역이다.
런타임 데이터 영역은 위 그림과 같이 크게 Method Area, Heap Area, Stack Area, PC Register, Native Method Stack로 나눌 수 있다.
이때 Method Area, Heap Area 는 모든 쓰레드(Thread)가 공유하는 영역이고, 나머지 Stack Area, PC Register, Native Method Stack 은 각 쓰레드 마다 생성되는 개별 영역이다.
따라서 위의 그림을 좀더 자세히 표현하자면 다음과 같은 도식이 된다.
메서드 영역 (Method Area)
메서드 영역은 JVM이 시작될 때 생성되는 공간으로바이트 코드(.class)를 처음 메모리 공간에 올릴 때 초기화되는 대상을 저장하기 위한 메모리 공간이다.
JVM이 동작하고 클래스가 로드될 때 적재되서 프로그램이 종료될 때까지 저장된다.
※ 참고
메서드 영역(Method Area) 은 Class Area 나 Static Area 로도 불리운다.
모든 쓰레드가 공유하는 영역이라 다음과 같이 초기화 코드 정보들이 저장 된다.
Field Info : 멤버 변수의 이름, 데이터 타입, 접근 제어자의 정보
Method Info : 메소드 이름, return 타입, 함수 매개변수, 접근 제어자의 정보
Type Info : Class 인지 Interface 인지 여부 저장, Type의 속성, 이름 Super Class의 이름
간단히 말하자면 메서드 영역에는 정적 필드와 클래스 구조만을 갖고 있다고 할수있다.
※ 참고
메소드 영역 / 런타임 상수 풀의 사용기간 및 스레드 공유 범위 - JVM 시작시 생성 - 프로그램 종료 시까지 - 명시적으로 null 선언 시
※ 참고
[ Runtime Constant Pool ] - 메서드 영역에 존재하는 별도의 관리영역. - 각 클래스/인터페이스 마다 별도의 constant pool 테이블이 존재하는데, 클래스 생성할때 참조해야할 정보들을 상수로 가지고 있는 영역이다. - JVM은 이 Constant Pool을 통해 해당 메소드나 필드의 실제 메모리 상 주소를 찾아 참조한다. - 정리하면 상수 자료형을 저장하여 참조하고 중복을 막는 역할을 수행한다.
힙 영역 (Heap Area)
힙 영역은 메서드 영역와 함께 모든 쓰레드가 공유하며, JVM이 관리하는 프로그램 상에서 데이터를 저장하기 위해 런타임 시 동적으로 할당하여 사용하는 영역이다.
즉,new 연산자로 생성되는 클래스와 인스턴스 변수, 배열 타입 등 Reference Type이 저장되는 곳이다.
당연히 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를 통해 새로 생성된 객체가 위치. 정기적인 쓰레기 수집 후 살아남은 객체들은 Survivor로 이동
Survivor 0 / Survivor 1 : 각 영역이 채워지게 되면, 살아남은 객체는 비워진 Survivor로 순차적으로 이동
Old Generation : 생명 주기가 긴 객체를 GC 대상으로 하는 영역. Youn Generation에서 마지막까지 살아남은 객체가 이동
이 영역에서 어떻게 가비지 컬렉션 동작이 일어나는지 알아보고 싶으면 다음 포스팅을 참고하기 바란다.
