JAVA

[Java] JVM 구조에 대한 설명. 그리고 버전에 따라 무엇이 바뀌는가?

로춘남 2022. 2. 22. 20:41
728x90


자바 공부를 할때마다 볼 수 있는 JVM. 오늘은 JVM의 구조와 버전에 따른 변경을 한 번 살펴보고자 한다.

 

먼저 JVM이란?

JVM이란 Java Virtual Machine의 약자로 자바 가상 머신을 뜻한다. 여기서 가상 머신이란 프로그램의 실행을 위한 물리적 머신과 유사한 머신을 소프트웨어로 구현을 한것이다.

JVM의 역할은 자바 애플리케이션을 Class Loader를 통해 읽어 Java API와 함께 실행을하고, JVM은 Java와 OS사이에서 중개자 역할을 수행하며 Java가 OS에 구애받지 않고 재사용을 가능하게 해준다.

그리고 가장 중요한 메모리 관리, Garbage Collection을 수행한다. 또한 JVM은 스택기반의 가상 머신이다.

 

그럼 우리는 왜 JVM를 알아야하는가?

한정된 메모리를 효율적으로 사용하여 최고의 성능을 내기 위함이다. 메모리의 효율성을 위해 메모리 구조를 알아야하는것처럼 동일한 기능의 프로그램이라 할지라도 메모리 관리에 따라 그 성능이 달라진다. 메모리 관리가 개선되지 않을경우 속도저하 혹은 흔히 말하는 튕김이 발생 할 수도 있기때문에 우리는 JVM를 알아두는것이 좋다.

 

Java의 실행과정

Java가 동작하는 과정을 한 번 살펴보면,

  1. 프로그램이 실행되면 JVM은 OS로부터 이 프로그램이 필요로 하는 메모리를 할당 받는다. JVM은 이 메모리를 용도에 따라 여러 영역으로 나누어 관리한다.
  2. 자바 컴파일러(javac)가 자바 소스코드(.java)를 읽어들여 자바 바이트 코드(.class)로 변환시킨다.
  3. Class Loader를 통해 class 파일들을 JVM으로 로딩한다.
  4. 로딩된 class 파일들은 Execution Engine을 통해 해석된다.
  5. 해석된 바이트 코드는 Runtime Data Area에 배치되어 실질적인 수행이 이루어지게 된다.
  6. 이러한 실행과정 속에서 JVM은 필요에 따라 Thread Synchronization과 GC같은 관리작업을 수행한다.

JVM의 구성

  • Class Loader(클래스 로더)

JVM내로 클래스(.class파일)를 로드하고, 링크를 통해 배치하는 작업을 수행하는 모듈이다. Runtime시에 동적으로 클래스를 로드하며, jar 파일 내 저장된 클래스들을 JVM위에 탑재하고 사용하지 않는 클래스들은 메모리에서 삭제한다. 자바는 동적코드, 컴파일 타임이 아닌 런타임에 참조한다. 즉, 클래스를 처음으로 참조할때, 해당 클래스를 로드하고 링크를 하게되는 것이다. 이러한 역할을 바로 클래스 로더가 수행을 한다. 

.java -(javac가 컴파일) .class - (JVM) → Runtime Data Area로 적재

 

  • Execution Engine(실행 엔진)

클래스를 실행시키는 역할이다.  클래스 로더가 JVM내의 런타임 데이터 영역에 바이트 코드를 배치시키고,

이것은 Execution Engine(실행엔진)에 의해 실행된다. 자바 바이트 코드는 기계가 바로 수행 할 수 있는 언어보다는 비교적 인간이 보기 편한 형태로 기술된것이다. 그래서 실행 엔진은 이와 같은 바이트 코드를 실제로 JVM내부에서 기계가 실행 할 수 있는 형태로 변경한다. 이때 명령어 실행방식 2가지를 사용하게 된다.

 

1) Interpreter(인터프리터)

실행 엔진은 자바 바이트 코드를 명령어 단위로 읽어서 실행한다. 하지만 이 방식은 인터프리터 언어의 단점을 그대로 갖고 있다. 한 줄 씩 수행하기 때문에 느리다는 것이다. 명령어를 하나씩 수행하는 기본적인 방식이지만, 전체 수행은 느린편. 단, 명령어 하나의 동작만큼은 빠르다.

 

2) JIT(Just - In - Time)

인터프리터 방식의 단점을 보완하기 위해 도입된 JIT 컴파일러. 인터프리터 방식으로 실행하다가 적절한 시점에 바이트 코드 전체를 컴파일하여 네이티브 코드로 변경하고, 이후에는 해당 더 이상 인터프리팅 하지 않고 네이티브 코드로 직접 실행하는 방식이다. 

네이티브 코드는 캐시에 보관하기 때문에 한 번 컴파일된 코드는 빠르게 수행하게 된다. 물론 JIT컴파일러가 컴파일하는 과정은 바이트 코드를 인터프리팅하는것보다 훨씬 오래걸리므로 한 번만 실행되는 코드라면 컴파일하지 않고 인터프리팅하는것이 유리하다.

따라서 JIT컴파일러를 사용하는 JVM들은 내부적으로 해당 메서드가 얼마나 자주 수행되는지 체크하고, 일정 정도를 넘을 때에만 컴파일을 수행한다.

바이트 코드 네이티브 코드로 변환 후 인터프리팅하지 않으며 네이티브 코드로 실행(실행 동작은 빠르지만 컴파일하는데 시간이 많이 소요됨)

 

  • Garbage Collector

GC를 수행하는 모듈(쓰레드)이 있다. GC는 Heap 메모리 영역에 생성된 객체들 중 참조되지 않은 객체들을 제거하는 역할을 한다. GC의 동작시간은 일정하지 않고, 언제 객체를 정리 할 지 모른다. 바로 참조가 없어지자마자 동작하는것은 아니다. GC를 수행하는 동안 GC 스레드를 제외한 다른 모든 스레드 정지. 수초간 GC로 인하여 다른 스레드가 정지한다면 큰 장애를 유발하게 된다.

 

  • Runtime Data Area

JVM Memory 구조 (출처: https://mirinae312.github.io/develop/2018/06/04/jvm_memory.html)

프로그램을 수행하기 위해 OS에서 할당받은 메모리 공간이다.

1. Method Area( = Class area = Static area) 
클래스 정보를 처음 메모리 공간에 올릴 때 초기화되는 대상을 저장하기 위한 메모리 공간.
올라가게 되는 메소드의 바이트 코드는 프로그램의 흐름을 구성하는 바이트 코드. 자바 프로그램은 main 메소드의 호출에서부터 계속된 메소드의 호출로 흐름을 이어가기 때문이다. 대부분 인스턴스의 생성도 메소드 내에서 명령하고 호출한다. 사실상 컴파일 된 바이트 코드의 대부분이 메소드 바이트 코드이기 때문에 거의 모든 바이트 코드가 올라간다고 봐도 상관없다. 이 공간에는 Runtime Constatn Pool이라는 별도의 관리 영역도 함께 존재한다.
이는 상수 자료형을 저장하여 참조하고 중복을 막는 역할을 수행한다. Method Area는 클래스 데이터를 위한 공간이라면 Heap영역이 객체를 위한 공간이다. Heap과 마찬가지로 GC의 관리 대상에 포함된다.

올라가는 정보의 종류로는
1) Field Information : 멤버 변수의 이름, 데이터 타입, 접근 제어자에 대한 정보
2) Method Information : 메소드의 이름, 리턴 타입, 매개변수, 접근제어자에 대한 정보
3) Type Information : class인지 interface인지 여부 저장 /Type 속성, 전체 이름, super class의 전체 이름(interface이거나  object인 경우 제외)

2. Heap Area(힙 영역)
객체를 저장하는 가상 메모리 공간이다. new 연산자로 생성된 객체와 배열을 저장한다. 물론 class area영역에 올라 온 클래스들만 객체로 생성 할 수 있다. 힙은 세 부분으로 나눌 수 있다.

JVM Heap 구조 (출처 : https://mirinae312.github.io/develop/2018/06/04/jvm_memory.html )

1) Permanent Generation
생성된 객체들의 정보의 주소값이 저장된 공간이다. Class Loader에 의해 Load 되는 Class, Method 등에 대한 Meta 정보가 저장되는 영역이고 JVM에 의해 사용된다. Reflection을 사용하여 동적으로 클래스가 로딩되는 경우에 사용된다. 내부적으로 Reflection 기능을 자주 사용하는 Spring Framework를 이용할 경우 이 영역에 대한 고려가 필요하다. 클래스 로더에 의해 로드된 클래스들이 저장되는 공간이다.
Java 8에서는 이 영역이 바뀌어 Meraspace라는 영역으로 바뀌었다.

2) New / Young 영역
- Eden : 객체들이 최초로 생성되는 공간. 새로 생성된 객체가 처음 위치하는 영역. 정기적으로 GC가 발생한 후, 살아남은 객체들의 Survivor 0, 1 영역으로만 이동하여 계속 쌓인다.
- Survior 0 / 1 : Eden에서 참조되는 객체들이 저장되는 공간. Survivor 0,1이 가득차면 그 중 살아남은 객체가 비워진 Survivor영역으로 이동. 이때 참조가 없는 객체들을 메모리에서 정리된다. 이러한 매커니즘으로 인해 Survivor 0이나 1은 항상 비워진 상태가 되며, 영역중 하나가 비워지지 않는다면 문제가 발생한것이다. 

3) Old 영역
New Area에서 일정 시간 참조되고 있는, 살아남은 객체들이 저장되는 공간 Eden 영역에 객체가 가득차게 되면 첫 번째 GC(minor GC)가 발생한다. Eden영역에 있는 값들을 Survivor 1영역에 복사하고 이 영역을 제외한 나머지 영역의 객체를 삭제한다. Survivor 0 또는 1영역을 왔다갔다 하다가 끝까지 살아남은 객체만이 Old 영역으로 이동하게 된다. Old 영역은 Young영역보다 크게 할당 되며, 이러한 이유로 Old영역의 GC는 Young영역보다 적게 발생한다.
인스턴스는 소멸 방법과 소멸 시점이 지역 변수와는 다르기에 힙이라는 별도의 영역에 할당된다. 자바 가상 머신은 매우 합리적으로 인스턴스를 소멸시킨다. 더 이상 인스턴스의 존재 이유가 없을때 소멸 시킨다.

3. Statck Area
프로그램 실행과정에서 임시로 할당되었다가 메소드를 빠져나가면 바로 소멸되는 특성의 데이터를 저장하기 위한 영역. 각종 형태의 변수나 임시 데이터, 스레드나 메소드의 정보를 저장한다. 메소드 호출 시마다 각각의 스택 프레임(그 메서드만을 위한 공간)이 생성된다. 메서드 수행이 끝나면 프레임 별로 삭제를 한다. 메소드 안에서 사용 되는 값들(Local Variable)을 저장한다. 또 호출된 메소드의 매개변수, 지역변수, 리턴 값 및 연산시 일어나는 값들을 임시로 저장한다.

4. PC Register
Thread가 시작될 때 생성되며 생성될 때마다 생성되는 공간으로 스레드마다 하나씩 존재한다. Thread가 어떤 부분을 어떤 명령으로 실행할지에 대한 기록을 하는 부분으로 현재 수행중인 JVM 명령의 주소를 갖는다. 스레드가 생성될 때마다 할당되는 영역으로 PC(Program Counter)이다. 쓰레드가 실행할 JVM 명령(바이트 코드의 명령)의 주소를 저장. 여러 바이트 코드 명령어들이 나열된 형태가 되고 JVM은 명령을 하나씩 실행해나가며 Java 어플리케이션을 실행한다.
현재 쓰레드가 실행되는 부분의 주소와 명령을 저장하는 영역.(쓰레드를 돌아가면서 수행)

5. Native Method Stack
자바 프로그램이 컴파일되어 생성되는 바이트 코드가 아닌 실제 실행 할 수 있는 기계어로 작성된 프로그램을 실행 시키는 영역이다. Java가 아닌 다른 언어로 작성된 코드를 위한 공간이다. Java Native Interface를 통해 바이트 코드로 전환하여 저장하게 된다. 일반 프로그램처럼 커널이 스택을 잡아 독자적으로 프로그램을 실행시키는 영역이다. 이 부분을 통해 C code를 실행시켜 Kernel에 접근 할 수 있다. 자바의 언어로 작성된 네이티브 코드를 위한 메모리 영역. 보통 C/C++ 등의 코드를 수행하기 위한 스택(JINI)

※ JVM메모리 영역에서의 객체의 Life Cycle


버전에 따른 변경사항

Java 8에서 JVM의 변화는 PermGen이 사라지고 Metaspace가 등장했다. Permanent Generation 메모리 영역이 없어지고, Metaspace 영역이 생김.

  • Permanent Generation
    • class 혹은 Method Code가 저장되는 영역이다.
    • Heap 영역에 속한다.
    • Default 제한된 크기를 가지고 있다.
  • Metaspace
    • Java의 클래스로더가 현재까지 로드한 class들의 metadata가 저장되는 공간
    • Native 메모리 영역 위치
    • Default 크기가 아니다.

JVM에 관리되는 Heap이 아닌 OS레벨에서 관리되는 Native 영역. metaspace가 native 메모리를 이용함으로써 개발자는 영역 확보의 상한을 크게 의식 할 필요가 없게 된다.

 

Metaspace의 장점

- 이제는 더 이상 java.lang.OutOfMemoryError : PermGen space와 같은 문제를 더 이상 야기하지 않는다는 것.

- tunning과 monitoring을 통해서 이러한 memory space를 조절할 필요가 없다는 것.

Metaspace의 단점

- class의 메모리 공간을 줄여주거나 클래스 로더의 memory leak를 줄여주지 못하는 것.


참 조 : (https://asfirstalways.tistory.com/158 // https://byeongyeon.tistory.com/46)

728x90