JVM 정복하기

📍 JVM이란?

JVM(Java Virtual Machine)은 Java 플랫폼의 초석입니다. 이는 하드웨어 및 운영 체제의 독립성, 컴파일된 코드의 작은 크기, 악성 프로그램으로부터 사용자를 보호하는 기능을 담당하는 기술의 구성 요소 입니다.

JVM은 추상 컴퓨팅 머신입니다. 실제 컴퓨팅 머신처럼 명령어 세트가 있으며 실행 시 다양한 메모리 영역을 조작합니다.

JVM은 java 프로그래밍 언어에 대해 아무것도 알지 못하며, 특정 바이너리 형식인 클래스 파일 형식만 알고 있습니다. 클래스 파일에는 java Virtual Machine 명령어(또는 바이트 코드)와 심볼 테이블 및 기타 보조 정보가 포함되어 있습니다.

 

Q. JVM이 어떻게 악성 프로그램으로부터 사용자를 보호하는가?

바이트 코드 검증, 클래스 로더 보안, 메모리 관리, 네이티브 코드 제어를 통해서 이루어집니다.

 

바이트 코드 검증 : Java프로그램의 바이트 코드가 실행되기 전에 검증하여 안전한 코드인지 확인합니다.

클래스 로더 보안 : 클래스 로더는 Java에서 사용하는 클래스를 로드하는 역할을 하며, 클래스 파일의 출처와 무결성을 확인합니다.

메모리 관리 : 가상 메모리 환경을 제공하여, 프로그램이 직접 메모리를 조작하거나 다른 프로그램의 메모리에 접근하지 못하도록 제한합니다.

네이티브 코드 제어 : Java 애플리케이션이 C/C++로 작성된 네이티브 코드를 실행할 수 있도록 JNI를 제공합니다. JVM은 네이티브 코드 사용 시에도 보안을 강화합니다.

 

네이티브 코드 : 운영체제 및 하드웨어에서 실행되는 코드로, 주로 C/C++이 사용됩니다.

 

Q. 네이티브 코드는 왜 사용하는가?

운영체제와 하드웨어의 기능을 효율적으로 활용하기 위해서 네이티브 코드를 다양한 작업에 사용합니다.

I/O 작업(파일 및 디렉토리 작업, 네트워크 통신, 표준 입력/출력), 메모리 관리(GC), 스레드 관리, 프로세스 관리, 하드웨어 상호 작용, 네이티브 라이브러리 연동, GUI 그래픽 처리, 보안 기능, 암호화 및 키 관리, 자바 가상 머신 자체 동작시 사용됩니다.

 

Q. Java에서 네이티브 코드는 어떻게 사용하는가?

JNI(Java Native Interface)를 통해 사용할 수 있습니다. JNI는 Java 프로그램이 C, C++ 등으로 작성된 네이티브 코드를 호출하거나 네이티브 코드에서 Java 메서드를 호출 할 수 있도록 지원하는 네이티브 코드입니다.

 

Q. 왜 네이티브 코드가 기능을 효율적으로 만드는가?

네이티브 코드는 운영체제와 하드웨어에서 직접 실행되는 기계어 수준의 코드입니다.

언어의 저수준 제어 능력과 운영체제 및 하드웨어와의 밀접한 통합 덕분이다.

 

Q. 어떻게 네이티브 코드 사용시 보안을 강화하는가?

네이티브 호출은 JVM의 보안 관리자의 승인을 받아서 무단으로 네이티브 코드를 실행하는 것을 방지한다.

또한 네이티브 코드는 JVM 외부에서 실행되며, JVM의 메모리 환경을 손상시킬 수 없습니다.

 

Q. C랑 C++만 네이티브 코드인가?

C랑 C++외에도 Rust, Go, 어셈블리어와 같은 다른 언어도 네이티브 코드로 사용할 수 있습니다.

 

📍 JVM 동작 방식

JVM의 동작방식은 자바 애플리케이션을 실행하기 위해 바이트 코드를 로드하고 해석하거나 컴파일하여 기계어로 변환한 뒤 실행하는 과정으로 진행됩니다.

 

Q. 바이트 코드란 무엇이며, 왜 바이트 코드를 사용하는가?

바이트 코드는 자바 소스 파일(.java)를 컴파일하여 생성되는 중간 언어입니다.

바이트 코드는 JVM에서 실행되기 위한 이진 명령어의 집합입니다. 사람이 읽을 수 없고, JVM이 이해하고 실행할 수 있는 명령어들로 구성되어 있습니다.

 

바이트 코드 변환후, 확인해보기

 

CastingDTO.java

package org.example.part2.chapter3;

import java.io.Serializable;

public class CastingDTO implements Serializable {
    private Object object;

    public CastingDTO() {
    }

    public void setObject(Object object) {
        this.object = object;
    }

    public Object getObject() {
        return this.object;
    }
}

 

먼저, CastingDTO.class의 바이트 코드를 보기 위해서 아래와 같이 컴파일을 해줍니다.

javac CastingDTO.class // 바이트 코드를 보기 위해서 컴파일 하는 명령어

 

역어셈블러(javap)로 해당 클래스를 실행하여 바이트 코드를 출력해줍니다.

javap -v -p -s Car.class

 

 

ByteCode

Classfile /Users/developer/Downloads/godofjava/godofjava/build/classes/java/main/org/example/part2/chapter3/CastingDTO.class
  Last modified 2025. 1. 8.; size 593 bytes
  SHA-256 checksum dc5354bc08e763940b823e63cb933e557c8335d103ce41acbb99334b5020c312
  Compiled from "CastingDTO.java"
public class org.example.part2.chapter3.CastingDTO implements java.io.Serializable
  minor version: 0
  major version: 61
  flags: (0x0021) ACC_PUBLIC, ACC_SUPER
  this_class: #8                          // org/example/part2/chapter3/CastingDTO
  super_class: #2                         // java/lang/Object
  interfaces: 1, fields: 1, methods: 3, attributes: 1
Constant pool:
   #1 = Methodref          #2.#3          // java/lang/Object."<init>":()V
   #2 = Class              #4             // java/lang/Object
   #3 = NameAndType        #5:#6          // "<init>":()V
   #4 = Utf8               java/lang/Object
   #5 = Utf8               <init>
   #6 = Utf8               ()V
   #7 = Fieldref           #8.#9          // org/example/part2/chapter3/CastingDTO.object:Ljava/lang/Object;
   #8 = Class              #10            // org/example/part2/chapter3/CastingDTO
   #9 = NameAndType        #11:#12        // object:Ljava/lang/Object;
  #10 = Utf8               org/example/part2/chapter3/CastingDTO
  #11 = Utf8               object
  #12 = Utf8               Ljava/lang/Object;
  #13 = Class              #14            // java/io/Serializable
  #14 = Utf8               java/io/Serializable
  #15 = Utf8               Code
  #16 = Utf8               LineNumberTable
  #17 = Utf8               LocalVariableTable
  #18 = Utf8               this
  #19 = Utf8               Lorg/example/part2/chapter3/CastingDTO;
  #20 = Utf8               setObject
  #21 = Utf8               (Ljava/lang/Object;)V
  #22 = Utf8               getObject
  #23 = Utf8               ()Ljava/lang/Object;
  #24 = Utf8               SourceFile
  #25 = Utf8               CastingDTO.java
{
  private java.lang.Object object;
    descriptor: Ljava/lang/Object;
    flags: (0x0002) ACC_PRIVATE

  public org.example.part2.chapter3.CastingDTO();
    descriptor: ()V
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         4: return
      LineNumberTable:
        line 5: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       5     0  this   Lorg/example/part2/chapter3/CastingDTO;

  public void setObject(java.lang.Object);
    descriptor: (Ljava/lang/Object;)V
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=2, locals=2, args_size=2
         0: aload_0
         1: aload_1
         2: putfield      #7                  // Field object:Ljava/lang/Object;
         5: return
      LineNumberTable:
        line 10: 0
        line 11: 5
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       6     0  this   Lorg/example/part2/chapter3/CastingDTO;
            0       6     1 object   Ljava/lang/Object;

  public java.lang.Object getObject();
    descriptor: ()Ljava/lang/Object;
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: getfield      #7                  // Field object:Ljava/lang/Object;
         4: areturn
      LineNumberTable:
        line 14: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       5     0  this   Lorg/example/part2/chapter3/CastingDTO;
}
SourceFile: "CastingDTO.java"

 

Q. 바이트 코드를 로드한다는게 무슨 의미인가?

JVM이 자바 애플리케이션의 컴파일된 .class 파일(바이트 코드)을 메모리로 읽어 들이는 과정을 의미합니다.

이 과정은 JVM 애플리케이션을 실행하기 위한 첫번째 단계로, 클래스 로더가 담당하게 됩니다.

 

 

JVM의 동작 흐름은 다음과 같습니다.

(1)JVM이 실행되는 순간, JVM은 OS로부터 메모리를 할당받습니다.

이 메모리 영역은 Runtime Data Area를 의미하며,

Method Area, Heap, Stack, PC Register, NativeMethod Stack으로 구분됩니다.

 

Q. 각 영역에 저장되는 데이터는 무엇인가?

Method Area : 클래스 메타데이터, 정적 변수, 상수 풀 저장

Heap: 객체와 배열 저장

Stack: 각 스레드별로 생성되며, 메서드 호출과 관련된 지역 변수, 연산 스택 저장

PC Register: 현재 실행 중인 명령의 주소 저장

Native Method Stack: 네이티브 코드(C/C++ 등) 실행시 사용

 

(2) 자바 컴파일러(javac)가 자바 소스 코드(.java)를 플랫폼 독립적인 바이트 코드(.class)로 변환합니다.

이 단계는 JVM 외부에서 수행되고, 실행 시점의 JVM 동작에 포함되지 않습니다.

 

(3) Class Loader는 자바 프로그램 실행 중 필요한 클래스를 동적으로 메모리(Runtime Data Area)에 로드합니다.

이 단계는 크게 로딩(Loading), 링킹(Linking), 초기화(initialization) 세 단계로 나뉘게 됩니다.

 

로딩 단계에선 .class 파일을 찾아 메모리에 로드합니다.

링킹 단계에선 검증(바이트 코드 JVM 명세에 맞는지 검증), 준비(정적 변수와 기본값을 할당), 해결(상수 풀의 심볼릭 레퍼런스를 실제 모리 주소로 변환) 합니다.

초기화 단계에서는 정적 변수 초기화 및 클래스 초기화 블록을 실행합니다.

 

Q. 동적 로딩은 무엇이고, 왜 사용하는가?

동적 로딩은 자바 프로그램 실행 시 필요한 시점에만 클래스 파일을 메모리에 로드하는 방법을 말합니다.

이 방법을 사용하면, 필요한 클래스만 메모리에 로드하다 보니 메모리가 효율적으로 사용되고, 필요한 클래스만 로드하기 때문에 프로그램 초기 로딩 시간이 단축되어 성능 최적화가 되고, 실행 중에 새로운 클래스를 로드하거나 플러그인, 확장 모듈 등을 추가하는 기능을 제공하거나 실행 중 특정 조건에 따라 다른 클래스를 로드하거나 다른 동작을 수행하도록 코드를 유연하게 작성할 수 있습니다.

 

Java Reflection API는 동적 로딩을 사용하는 대표적인 사례입니다.

런타임에 클래스를 동적으로 로드하고, 클래스의 메서드, 필드, 생성자 등에 접근할 수 있는 기능을 제공합니다.

이를 통해 애플리케이션은 컴파일 시점에 클래스의 구조를 알지 못하더라도, 실행 시점에 동적으로 해당 클래스를 사용할 수 있습니다.

 

(4) Execution Engine이 Runtime Data Area에 로드된 바이트 코드를 실행합니다.

실행 방식은 인터프리터 방식, JIT(Just-In-Time) 컴파일러 방식이 존재합니다.

인터프리터 방식은 바이트 코드를 한 줄씩 해석하여 실행하는 방식이고, JIT 컴파일러 방식은 반복 실행되는 바이트 코드를 기계어로 변환하여 캐싱을 하기 때문에, 성능 최적화가 되고 인터프리터보다 더 빠른 방식입니다.

 

(5) 이 과정에서 Execution Engine에 의해 Garbage Collector와 Thread 동기화가 이루어집니다.

Garbage Collector는 JVM 내부에서 자동으로 메모리의 힙 영역을 관리하며, 더 이상 참조되지 않는 객체를 정리합니다.

 

Q. 왜 Thread 동기화를 해주는가?

Thread 동기화가 필요한 이유는 멀티스레딩 환경에서 공유 자원에 동시에 접근하는 경우 데이터 충돌이나 경쟁 상태가 발생할 수 있기 때문입니다.

synchronized 키워드와 같은 동기화 매커니즘이 (5)번 과정에서 동작하게 됩니다.

synchronized : 메서드나 코드 블록에 락(Lock)을 걸어 한 번에 하나의 스레드만 접근하도록 제한합니다.

 

Q. 경쟁 상태는 무엇인가?

여러 스레드가 공유 자원을 동시에 읽거나 수정하려고 할 때, 실행 순서에 따라 예기치 못한 결과가 발생하는 상태를 말합니다. 

ex) 두 스레드가 같은 변수의 값을 동시에 증가시키는 작업을 수행하는 경우

 

📍 JVM 구조

 

JVM은 다음과 같이 구성되어 있습니다.

 

클래스 로더(Class Loader)

 

실행 엔진(Execution Engine)

• 인터프리터
• JIT 컴파일러
• 가비지 콜렉터

런타임 데이터 영역(Runtime Data Area)

• 메소드 영역
• 힙 영역
• PC Register
• 스택 영역
• 네이티브 메소드 스택

(아래 2개는 이미지로 나타내지 않았다.)

JNI - 네이티브 메소드 인터페이스 (Native Method Interface)

네이티브 메소드 라이브러리 (Native Method Library)

 

Q. PC Register는 무엇이고, 왜 사용하는가?

PC Register는 JVM의 Runtime Data Area에서 각 스레드가 실행할 명령어의 주소를 저장하는 메모리 영역으로, 현재 스레드가 어떤 명령어를 실행하고 있는지를 추적하기 위해, 명령어의 주소나 실행 중인 명령어의 위치를 저장합니다. 또한 스레드 별로 독립적으로 존재합니다. 

 

Q. 명령어 실행 흐름을 제어한다는건 어떤 의미인가?

JVM이 프로그램 실행 중 명령어의 순서와 위치를 정확히 관리하여, 프로그램이 올바른 논리적 흐름으로 실행될 수 있도록 한다는 것을 의미합니다.

 

클래스 로더(Class Loader)

 

Class Loader는 JVM의 구성 요소 중 하나로, 자바 애플리케이션 실행시 클래스를 동적으로 메모리에 로드하는 역할을 합니다.

자바의 런타임 동적 로딩을 가능하게 하며, 프로그램 실행 중 필요한 클래스를 적재하고 관리합니다.

 

Java에는 기본적으로 3가지 주요 클래스 로더인 Bootstrap ClassLoader, Extension ClassLoader, Application ClassLoader가

있습니다.

 

Bootstrap ClassLoader

JVM에 내장된 가장 기본적인 클래스 로더입니다. 역할로는 Java의 핵심 클래스들을 로드합니다.

예시로 java.lang, java.util, java.io 같은 Java 표준 라이브러리가 이에 해당됩니다. Java 8이하에서는 rt.jar가 JDK 9 이상에서는 모듈 시스템(java.base)에 포함된 클래스를 로드합니다.

 

네이티브 코드로 작성되어 있고, C와 C++로 구현되어 있습니다.

클래스 로더 체계의 최상위에 존재하며, 다른 클래스 로더에 의해 확장되지 않습니다.

클래스 로더 계층 구조의 시작점이므로, 개발자가 직접 접근하거나 제어할 수 없습니다.

 

Extension ClassLoader

확장 클래스 로더라고도 불리며, 부트스트랩 클래스 로더의 다음 단계에 위치합니다.

JAVA_HOME/lib/ext 디렉토리나 java.ext.dirs 시스템 속성에 정의된 경로에 있는 확장 클래스를 로드합니다.

주로 추가적인 기능을 제공하는 확장 라이브러리(JAR파일)들을 로드하는 데 사용합니다.

 

개발자가 확장 라이브러리를 추가하거나 커스터마이징 할 수 있습니다.

 

Application Class Loader

개발자가 가장 많이 사용하고 익숙한 클래스 로더입니다.

응용 프로그램의 클래스 패스를 기준으로 클래스 파일을 로드합니다. 

 

개발자가 작성한 사용자 정의 클래스, 라이브러리, 외부 JAR 파일 등을 로드합니다.

가장 하위에 위치하며, 클래스 로더 계층 구조의 마지막 단계로 동작합니다.

 

클래스 로더 계층 구조

클래스 로더는 계층 구조를 가지고 있으며, 부모-자식 관계로 구성됩니다. 이 구조는 위임 모델을 기반으로 동작합니다.

 

(1) 클래스 로더는 먼저 부모 클래스 로더에게 클래스를 로드할 수 있는지 요청합니다.

(2) 부모가 클래스를 로드하지 못한 경우에만 자신이 클래스를 로드합니다.

 

계층 구조 순서는 다음과 같습니다.

Bootstrap ClassLoader → Extension ClassLoader → Application ClassLoader

 

사용자 정의 클래스 로더

ClassLoader를 필요에 따라서 확장하여 사용자 정의 클래스 로더를 만들 수 있습니다. 

특수한 방식으로 클래스 로드 시 유용합니다.

 

예시로는 네트워크 경로에서 클래스 로드, 암호화된 클래스 파일 로드가 있습니다.

 

클래스 파일 로딩 순서는 3단계로 나뉩니다.

Loading → Linking → Initialization

 

 

(1) 로드(Loading)

클래스 파일(.class)을 찾아 Method Area에 로드합니다. 

 

(2) 링크(LInking)

클래스 로드 후, JVM이 클래스를 실행할 수 있도록 준비하는 과정입니다.

• 검증(Verification) - 바이트코드가 JVM 명세에 맞는지 검증합니다.
• 준비(Preparation) - 클래스의 정적 변수를 메모리에 할당하고 기본값으로 초기화하는 과정입니다.
• 해결(Resolution) - 상수 풀 내의 심볼릭 참조를 실제 메모리 주소로 변환합니다.

(3) 초기화(Initialization)

정적 변수 초기화 및 클래스 초기화 블록을 실행합니다.

 

Q. 심볼릭 참조는 무엇이고, 왜 사용하는가?

심볼릭 참조는 JVM에서 바이트코드 내에서 클래스, 메서드, 필드, 인터페이스 등을 참조할 때 문자열 형태로 저장된 참조 방식을 의미합니다. 심볼릭 참조를 사용하는 이유는 하드웨어나 운영체제에 종속된 메모리 주소를 사용하는 대신, 문자열 형태로 참조를 저장해서 플랫폼 독립성을 보장하고, 실행 시점에 필요한 클래스와 메서드를 동적으로 로드할 수 있습니다.

 

 

예시) JDBC 드라이버를 동적으로 로드하는 경우

Class.forName()

동적(Dynamic)이고 런타임에 클래스 이름(문자열)을 사용해 해당 클래스를 JVM으로 로드합니다.

Class.forName("com.mysql.cj.jdbc.Driver");
// "com.mysql.cj.jdbc.Driver" : 심볼릭 참ㅈ

 

 

실행 엔진(Execution Engine)

바이트 코드를 실제 실행 가능한 형태로 변환하고 실행하는 역할을 담당합니다. 즉, 바이트 코드를 실제로 JVM 내부에서 기계가 실행할 수 있는 형태로 변경해줍니다.

 

실행 엔진은 인터프리터와 JIT 컴파일러 두 방식을 합쳐서 바이트 코드를 실행합니다.

 

인터프리터(Interpreter)

바이트 코드 명령어를 하나씩 읽어서 해석하고 바로 실행합니다.

 

JIT 컴파일러(Just-In-Time Complier)

바이트코드 전체를 네이티브 코드로 컴파일하고, 이후엔 캐싱된 네이티브 코드를 재사용하는 방식입니다.

기존에 반복된 부분이더라도 중복 인터프리팅하는 인터프리터 방식의 약점을 보완해줍니다.

 

Q. 왜 두 방식을 합쳐서 사용하는가?

JIT 컴파일러는 바이트코드 전체를 네이티브 코드로 변환해야 하는데, 변환 비용이 너무 큽니다.

따라서, JVM은 인터프리터를 먼저 사용해서 빠르게 코드를 실행하고, 반복 실행되거나 중요한 코드가 감지되면 JIT 컴파일러를 사용합니다. 빠른 초기 실행과 높은 장기 실행 성능을 모두 만족시킬 수 있기 위해선 두 방식을 혼합하여 사용해야 합니다.

 

Q. JVM은 어떻게 반복 실행되는 코드를 감지하는가?

JVM 내부적으로 코드 실행을 프로파일링하여 핫스팟을 탐지하고 JIT 컴파일을 합니다.

여기서 말한 핫스팟은 반복적으로 실행되거나, 실행 빈도가 높은 코드 영역을 의미합니다.

 

 

가비지 컬렉터(Garbage Collector)

JVM은 가비지 컬렉터를 사용해서 Heap 메모리 영역에서 더는 참조되지 않는 객체의 메모리를 자동으로 회수합니다.

개발자가 따로 메모리를 관리해주지 않아도 되므로, 비즈니스 로직에 더욱 집중할 수 있습니다.

위 그림과 같이 참조가 되지 않는 경우에는 Garbage Collector가 자동적으로 메모리 회수를 하게 됩니다.

 

런타임 데이터 영역(Runtime Data Area)

JVM이 프로그램 실행 중 사용하는 메모리 구조로 자바 애플리케이션을 실행할 때, 사용되는 데이터들을 저장하는 영역입니다.

 

메서드 영역(Method Area)

Runtime Data Area 내에서 클래스 관련 데이터를 저장하는 메모리 영역입니다.

클래스가 JVM에 로드되면, 클래스의 메타데이터(클래스 이름, 메서드 정보, 필드 정보 등)와 정적 데이터가 저장되고, 모든 스레드가 공유하여 사용합니다.

JVM이 동작하고 클래스가 로드될 때 적재되고 프로그램이 종료 직전까지 저장됩니다.

 

Q. 클래스 메타데이터는 어떤값이 존재하는가?

클래스 정의 정보 :  클래스의 이름, 접근 제어자, 패키지 정보, 클래스의 부모 클래스 정보, 클래스가 구현하는 인터페이스 정보가 존재합니다.

필드 정보 :  인스턴스 변수 정보(각 필드 이름, 데이터 타입, 접근 제어자)와 정적 변수 정보가 존재합니다.

메서드 정보 :  메서드 이름, 반환 타입, 매개변수 타입, 접근 제어자 정보가 존재합니다.

타입 정보 :  Class인지 Interface인지 여부 저장, Type의 속성, Super Class의 이름이 존재합니다.

VM의 Method Area에 로드된 각 클래스 를 나타낸 그림

 

Q. Runtime Constant Pool은 무엇이고, 왜 사용하는가?

각 클래스와 인터페이스마다 별도의 constant pool 테이블이 존재하며, 클래스 생성 시 참조해야 할 정보(클래스의 상수, 심볼릭 참조)를 상수 형태로 가지고 있는 영역입니다. JVM은 Constant Pool을 통해서 해당 메소드나 필드의 실제 메모리 상 주소를 찾아 참조합니다.

상수 자료형을 저장하여 참조하고 중복을 막는 역할도 수행합니다.

 

Q. RunTime Constant Pool을 통해서 어떻게 실제 메모리 상 주소를 찾을 수 있는가?

RunTime Constant Pool에 심볼릭 참조를 저장하고, 이를 통해 메서드나 필드의 실제 메모리 주소를 찾습니다.

 

추가로 알아야 할 점

Runtime Constant Pool이 클래스별로 관리되는 것은 맞지만, Method Area에서 관리가 됩니다.

 

Q. 중복을 막는 역할이 무엇을 의미하는가?

동일한 상수를 여러 번 저장하지 않고, 한 번만 저장하여 메모리를 절약하는 것을 의미합니다.

 

힙 영역(Heap Area)

 

힙 영역은 모든 쓰레드가 공유하며, 런타임 시 동적으로 생성되는 객체와 배열 등의 데이터를 저장하기 위해 사용됩니다.

이 영역에는 클래스의 인스턴스, 배열 등 Reference Type이 저장 됩니다.

 

힙 객체의 참조 주소는 JVM 스택에 저장된 변수를 통해 관리됩니다. 따라서, 힙 객체는 스택의 참조 주소를 통해 간접적으로 접근 및 조작이 가능합니다.

 

Q. 힙 영역에 저장된 객체는 언제까지 사용가능한가?

프로그램 실행 중 객체가 참조되거나 사용되는 동안 유지되며, 참조가 되지 않는 객체는 Garbage Collector에 의해 자동으로 정리됩니다.

 

힙 영역 구조

힙 메모리는 5가지 영역으로 나누어져 있습니다. 크게 Young Generation과 Old Generation 영역으로 구분됩니다.

 

YongGeneration은 생명 주기가 짧은 객체를 GC 대상으로 하는 영역이고, Old Generation은 생명 주기가 긴 객체를 GC 대상으로 하는 영역이다. Young Generation에서 끝까지 살아남은 객체가 Old Generation으로 이동하게 된다.

 

Eden 영역

새로 생성된 객체가 가장 먼저 저장되는 공간입니다. 대부분의 객체는 수명이 짧아 이 단계에서 제거됩니다.

 

Survivor 영역

Eden 영역에서 GC(Garbage Collection) 후 살아님은 객체가 저장되는 공간입니다.

크게 S0(Survivor 0)와 S1(Survivor 1) 두가지 영역으로 나뉩니다. 두 개의 Survivor 영역은 번갈아 가며 사용됩니다.

 

Q.2가지의 Survivor 영역은 어떻게 동작하는가?

(1) Eden → Survivor(S0)

Eden 영역에서 객체가 Minor GC를 통과하면, 살아남은 객체는 Survivor 영역으로 이동합니다. 이때, Survivor 공간 중 하나만 현재 활성회된 영역으로 사용됩니다.

 

(2) S0 → S1 or S1 → S0

다음 Minor GC가 발생하는 경우, 현재 활성화된 Survivor 영역(S0)에서 살아님은 객체는 다른 Survivor 영역(S1)으로 이동합니다.

두 개의 영역은 From 영역과 To 영역으로 상황에 따라 동작합니다.

 

(3) Survivor → Old

Survivor 영역에서 GC를 여러 번 통과한 객체는 Old Generation으로 이동합니다.

 

이동 횟수는 객체의 생존 횟수에 따라서 결정하게 됩니다.

 

Old 영역

YG(Young Generation)의 Eden 및 Survivor 영역에서 오래 살아남은 객체가 저장되는 공간입니다.

한마디로 수명이 긴 객체가 여기 저장됩니다. 수명이 길기 때문에 Major GC 발생 빈도가 낮습니다.

YG에 비해 크기가 크고, Major GC 시 더 많은 시간이 소요됩니다.

 

Permanent 영역

Java 8버전 이상부터는 Metaspace로 불립니다.

이름 처럼 클래스의 이름, 메서드, 필드, 인터페이스 정보와 같은 클래스의 메타데이터가 저장되는 공간입니다.

 

Java 7 이하에서는 Permanent 영역이 힙 영역의 일부로 간주되었지만, Java 8 이후에는 Permanent이 제거되고 Metaspace가 네이티브 메모리로 이동했기 때문에, 더 이상 힙 영역의 일부가 아닙니다.

 

네이티브 메모리는 운영체제로부터 직접 할당받아 사용하는 메모리 입니다.

 

Q. Minor GC와 Major GC는 각각 무엇인가?

Minor GC는 Yong Generation에서 발생하는 가비지 컬렉션이고, 주로 Eden 영역에서 수행됩니다.

수행 속도가 빠르고, 객체가 자주 생성되고 제거되므로 빈번히 발생하게 됩니다. Stop-the-world(STW) 이벤트가 발생하지만, 시간이 짧아서 성능에 큰 영향을 주지는 않습니다.

 

Major GC는 Old Generation에서 발생하는 가비지 컬렉션입니다.

YG보다 수명이 길기 때문에 수행은 덜 빈번합니다. OG는 YG보다 크기가 크고, 객체가 오래 살아남아 복잡성이 높기 때문에 Minor GC에 비해 속도가 느립니다. 대부분의 이벤트에 Stop-the-world 이벤트를 동반하기 때문에, 애플리케이션 성능에 큰 타격을 줄 수 있습니다.

Major GC가 발생하는 경우 YG의 GC도 함께 수행되기 때문에 이를 Full GC라고도 부릅니다.

 

Q. Full GC란?

Full GC는 JVM의 전체 힙 영역(Young Generation + Old Generation + Metaspace)을 대상으로 가비지 컬렉션을 수행하는 것을 의미합니다.

Major GC가 발생할 때, 필요에 따라 Young Generation의 GC(Minor GC)도 동시에 수행됩니다 이 때문에 Major GC와 Minor GC가 동시에 수행되는 경우를 Full GC라고 부르는 경우가 많습니다.

 

스택 영역(Stack Area)

 

스택 영역은 기본 자료형 생성시 저장하는 공간으로, 지역 변수와 메서드 호출 정보(프레임)가 저장된다. 메서드 호출이 끝나는 경우엔 해당 스택 프레임은 제거됩니다. 스레드별로 부여되는 별도의 메모리 공간이기도 합니다. 스택의 사이즈는 런타임시 지정되기 때문에 바꿀 수 없습니다. 고정된 크기의 스택에서 프로그램 실행시 스택에 할당된 메모리 크기가 충분하지 않은 경우 StackOverFlowError가 발생하게 됩니다.

 

LIFO 구조를 가지고, 메서드 호출 시마다 각각 스택 프레임이 생성되고 그 메서드 안에서 사용되는 값들을 저장하고, 호출된 메서드의 매개변수, 지역변수, 리턴 값 및 연산 시 생기는 값들을 임시로 저장해준다. 메서드가 종료되면 프레임은 삭제됩니다.

 

데이터 타입에 따라 저장되는 방식이 다릅니다.

우선, 기본(원시)타입 변수는 스택 영역에 직접 값을 갖게 되고, 참조 타입 변수는 힙 영역이나 메소드 영역의 객체 주소를 갖게 됩니다.

 

Q. 스택 프레임은 무엇인가?

메소드 호출시 프레임이 만들어 지고, 현재 실행중인 메소드 상태 정보를 저장하는 곳입니다.

 

PC 레지스터 (Program Counter Register)

쓰레드 시작시 생성되고, 현재 실행 중인 JVM 명령어의 주소를 저장하는 곳입니다.

저장된 주소를 기반으로 JVM은 다음에 실행할 바이트코드 명령어를 결정하게 됩니다. 각 스레드마다 개별적인 PC 레지스터를 할당합니다.

 

스레드가 자바 메소드를 수행중이라면 현재 명령어의 주소를 PC Register에 저장합니다. 추가로, JVM은 네이티브 메서드(운영체제 또는 하드웨어에서 직접 실행되는 메서드)를 지원하기 때문에  만약 JVM이 네이티브 메서드를 실행 중인 경우, PC 레지스터는 특정 명령어 주소를 가리키지 않고, undefined로 설정이 됩니다. 

 

Q. 왜 undefined로 설정이 되는가?

네이티브 메서드는 JVM 바이트 코드가 아닌 OS나 하드웨어의 명령어로 처리되기 때문입니다.

 

네이티브 메서드 스택 (Native Method Stack)

네이티브 메서드 스택은 JVM이 네이티브 메서드(기계어로 작성된 코드)를 실행하기 위해 사용하는 스택이고, 자바 스택과 독립적으로 작동하며, JNI(Java Native Interface)를 통해 호출되고, 네이티브 메서드 실행 후 다시 JVM 스택으로 돌아가 자바 코드의 실행을 이어갈 수 있습니다.

 

 

 

흐름 과정을 간단히 설명하면 다음과 같습니다.

(1) 자바 메서드 호출 :  자바 코드에서 메서드가 호출되면, 해당 메서드의 스택 프레임이 JVM 스택에 쌓입니다.

 

(2) 네이티브 메서드 호출: 자바 메서드 내부에서 JNI를 통해 네이티브 메서드가 호출되면,실행 흐름이 JVM 스택에서 네이티브 메서드 스택으로 넘어가고, 네이티브 메서드 스택에 호출 정보를 저장하고, 네이티브 코드를 실행합니다.

 

(3) 네이티브 메서드 실행 : 네이티브 메서드는 OS나 하드웨어에서 실행됩니다. 네이티브 메서드 스택에서 함수 호출 정보와 관련 데이터를 관리합니다.

 

네이티브 메서드 완료 후 : 네이티브 메서드 실행이 끝나면, 실행 흐름이 다시 JVM 스택으로 돌아오고, 이후 JVM 스택에 남아 있던 작업을 이어서 수행합니다.

 

JNI (Java Native Interface)

자바 프로그램과 네이티브 코드간의 상호작용을 가능하게 해주는 인터페이스 입니다. 이는 JVM이 네이티브 메서드를 호출하거나, 네이티브 코드가 자바 메서드를 호출할 수 있도록 지원합니다.

 

Native Method Library

Native Method Library는 자바 프로그램에서 호출할 수 있는 네이티브 메서드(Native Method)가 구현되어 있는 네이티브 코드로 작성된 라이브러리입니다. 이 라이브러리는 운영체제에서 실행 가능한 기계어로 컴파일되어 있으며, 보통 .dll(Windows), .so(Linux), 또는 .dylib(macOS) 같은 파일 형식으로 제공됩니다.

 

쓰레드를 기준으로 본 런타임 데이터 영역

런타임 데이터 영역을 쓰레드를 기준으로 보면 다음과 같습니다.

Method 영역과 Heap 영역은 모든 쓰레드가 공유하는 영역이고, Stack 영역, PC Register 영역, Native Method Stack 영역은 각 쓰레드마다 생성되는 개별 영역입니다.