Java 구동 원리 및 JVM(Java Virtual Machine)
Java 구동원리와 JVM의 개념 및 원리에 대해 조사해보고 정리해보려 합니다.
자바 프로그램 구동 원리
1. 자바 소스코드를 작성한다.(.java 확장자 소스파일)
2. JDK안의 컴파일러(javac.exe)가 소스코드를 바이트코드(.class 확장자 클래스 파일)로 변환한다.
3. 런처(java.exe)로 자바 가상 머신을 구동시킨다.
4. 자바 가상 머신이 바이트코드를 해석하여 자바 프로그램이 실행된다.
바이트코드(bytecode)는 자바 가상 머신이 이해할 수 있는 언어로 변환된 코드다. 자바 가상 머신만 설치되어 있다면 바이트코드는 어떤 운영체제에서라도 실행될 수 있다.
추가적으로 위 그림에서 자바코드가 JVM에 전달되는 과정을 단계별로 살펴보자면
1) 컴파일 과정 이후 컴파일된 바이트코드를 JVM의 클래스로더(Class Loader)에게 전달한다.
2) 클래스로더는 동적로딩(Dynamic Loading)을 통해 필요한 클래스들을 로딩 및 링크하여 런타임 데이터 영역(Runtime Data area), 즉 JVM의 메모리에 올린다.
3) 실행엔진(Execution Engine)은 JVM메모리에 올라온 바이트 코드들을 명령어 단위로 하나씩 가져와서 실행한다.
이제 작성한 자바 소스가 어떻게 동작하는 건지 파악했으니 본격적으로 JVM의 속을 들여다 보자.
JVM이란 무엇인가?
JVM은 Java Virtual Machine, 즉 자바 가상 머신의 약자를 따서 줄여 부르는 용어이다. JVM은 OS와 Java 애플리케이션 사이의 중개자 역할을 한다. JVM은 자바 바이트코드를 실행할 수 있는 환경을 제공해준다. 이를 통해 자바 바이트 코드가 플랫폼에 독립적으로 어디서든 실행될 수 있게 한다. 즉, JVM 덕분에 OS에 상관없이 어디서든 JAVA 애플리케이션을 실행할 수 있게 된다.
JVM 이 만들어진 이유
일반적인 프로그램의 경우 하드웨어 > 운영체제 > 어플리케이션 의 구조로 운영체제가 프로그램을 실행시킨다.
그렇기 때문에 컴파일 플랫폼과 타겟 플랫폼이 다른 경우 프로그램이 동작하지 않는다.
예) 리눅스에서 컴파일 된 프로그램은 윈도우 에서는 정상적으로 동작하지 않는다.
이런 경우 타겟 플랫폼에 맞춰 컴파일 하는 크로스 컴파일로 해당 문제를 해결했지만 자바의 경우에는
하드웨어 > 운영체제 > JVM > 자바 프로그램 의 구조로 한 번 만들기만 하면 어느 운영체제에서든 실행 할 수 있도록 했다.
즉, 자바 프로그램의 클래스 파일들은 운영체제에서 직접 동작하는 것이 아니라 JVM 위에서 동작한다. 그래서 윈도우에서 개발한다면 윈도우용 가상 머신을 설치하고 맥에서 개발한다면 맥용 가상 머신을 설치하는 등의 운영체제용 가상 머신만 설치가 되어 있다면 자바 프로그램은 한 번 만들기만 하면 윈도우든 리눅스든 맥이든, 어느 운영체제에서나 실행할 수 있다. 이런 점을 플랫폼 독립성이 높고 또는 이식성이 높다고 한다.
왜 JVM을 알아야 할까?
JVM을 알아야 하는 이유는 바로 성능과 연관되어 있기 때문이다.
동일한 기능의 프로그램이라고 해도 한정되어 있는 메모리 용량의 관리가 되지 않으면 속도 저하 현상이나 튕김 현상이 일어날 수 밖에 없다. 자바 가상 머신의 구성과 메모리를 알면 관리하는 것에 따라 프로그램의 성능이 달라진다.
JVM의 구조
JVM의 구조는 크게 Class Loader / Execution Engine / Runtime Data Area 로 나눌 수 있다.
클래스 로더가 클래스 파일을 동적으로 로드 해 런타임 데이터 영역에 배치하면 런타임 데이터 영역은 파일들을 각각의 위치에 저장하고 실행엔진이 런타임 데이터 영역에 배치되어 있는 바이트 코드를 해석하여 실행한다.
Class Loader
클래스 로더는 .class 파일을 동적으로 로드하고, 해당 바이트 코드들을 JVM 의 메모리 영역인 Runtiem Data Area 에 배치한다. 동적로드라는 것은 클래스를 한번에 메모리에 올리지 않고, 어플리케이션에서 필요한 경우만 동적으로 메모리에 적재한다는 의미이다.
클래스 로더의 로딩 순서는 Loading > Linking > Initialization 순서로 이뤄진다.
Runtime Data Area
클래스 로더에서 분석된 클래스 파일의 데이터를 저장하고 실행 도중에 필요한 데이터를 저장한다. 메모리를 효율적으로 관리하기 위해 크게 5개의 영역(스태틱, 힙, 스택, PC 레지스터, 네이티브 메서드 스택)으로 구분하며, 간단히 메모리 영역이라고도 부른다.
Execution Engine
런타임 데이터 영역에 배치된 바이트코드를 해석하며 실행한다. 이 때 인터프리터 방식과 JIT 컴파일 방식을 혼합혀 해석한다.
- 인터프리터 방식 : 컴파일된 바이트코드를 한 줄씩 읽고 해석한다.
- JIT 컴파일 방식 : 바이트코드를 런타임 시점에 바로 기계어로 변환한다.
=> 최초의 가상 머신은 인터프리터 방식만 써서 실행 속도가 느렸지만, JIT 컴파일 방식을 추가하여 이를 보완하고자 했다. 그런데 JIT 컴파일은 바이트코드를 기계어로 바꾸기 때문에 실행 속도가 빠르지만 변환하는 데 캐시를 사용하기 때문에 비용이 발생하게 된다. 그래서 인터프리터 방식을 사용하다가 일정한 기준이 넘어가면 JIT 컴파일 방식으로 실행한다.
자바 메모리 영역
Runtime Data Area 는 실제 클래스 파일들이 배치되는 곳으로, 자바 프로그램을 실행하기 위해서 가상 머신이 운영 체제로부터 메모리에 데이터 및 명령어를 저장할 공간을 할당받는 곳이다. 5개의 영역으로 분류되지만 주로 메서드, 힙, 스택 영역이 언급된다.
Method Area(= Static Area / = Class Area)
1. Field Information: 멤버변수의 이름, 데이터 타입, 접근 제어자에 대한 정보
2. Method Information: 메서드의 이름, 리턴 타입, 매개변수, 접근제어자에 대한 정보
3. Type Information: Type의 속성이 Class인지 Interface인지의 여부 저장
- Type의 전체 이름(패키지명 + 클래스명)
- Type의 Super Class의 전체 이름(단, Type이 Interface이거나 Object Class인 경우 제외)
- 접근 제어자 및 연관된 interface의 전체 리스트 저장
4. Constant Pool(상수 풀)
- Type에서 사용된 상수를 저장하는 곳(중복이 있을 시 기존의 상수 이용)
- 문자 상수, 타입, 필드, Method의 Symbolic Reference(객체 이름으로 참조)도 상수풀에 저장
5. Class Variable
- Static 변수라고도 불림
- 모든 객체가 공유 할 수 있고, 객체 생성없이 접근 가능
6. Class 사용 이전에 메모리 할당
- final class 변수의 경우(상수로 치환되어) 상수 풀에 값 복사
Heap Area
- new 키워드로 생성된 객체와 배열이 저장되는 영역
- Method Area에 로드된 클래스만 생성이 가능하다.
- GC(가비지 컬렉터)의 주요 대상이 된다.
- 효율적인 GC를 위해 메모리 영역이 분리되어 있다.(Eden, Survivor1,2, Old)
- 런타임시 할당된다.
Stack Area
- 지역변수, 파라미터, 리턴값, 연산에 사용되는 임시값등이 생성되는 영역
- 메소드를 호출할 때마다 개별적으로 스택이 생성되며 종료 시 영역에서 해제된다.
- 컴파일 타입 시 할당된다.
PC Register
- 스레드가 생성될때마다 생성되며 현재 스레드가 실행되는 부분의 주소와 명령을 저장하는 영역
- 이를 이용해서 스레드를 돌아가면서 수행 할 수 있게 한다.
Native Method Stack
- 자바 외 언어로 작성된 네이티브 코드를 위한 메모리 영역(JNI)
참고)