JVM에 대해

🎯 배경

자바에서 제일 중요하다는게 무엇이냐고 물어보면 대부분 JVM이라고 말한다. 왜냐하면 JVM은 자바에서 핵심 동작이라 생각한다. 그런데 우리는 JVM에 대해 잘 알지 못한다. 왜냐하면 JVM을 몰라도 JAVA를 사용할 수 있기 때문이다. 그럼에도 불구하고 JVM을 학습하는 목적은 다른 지식을 학습 하기 위해서는 JVM을 아는것이 유리하기 때문이다.

⚙️ 핵심 내용 (What & How)

• 🏗️ JVM에 대해
• ⚙️ JVM 동작방식

🔑 결과와 인사이트 (So what?)

🏗️ JVM에 대해

JVM은 Java Virtual Machine의 약자로, 자바 프로그램을 실행하기 위한 가상 머신이라고 한다. 지금이야 많은것들이 발전해서 어디에서든지 코드를 실행이 가능했지만, 자바가 탄생했을때는 1995년도로 알고 있다. 그때는 윈도우에서 작성한 코드와 리눅스에서 작성한 코드의 실행환경에 따라 다르게 동작하는 경우도 있다고 했다. 그래서 탄생한것이 JVM이라 알고 있다. 그렇다면, JVM은 어떻게 해서 모든 환경에서 실행을 시킬 수 있는 걸까?

위에서 언급했듯이, JVM은 자바의 가상머신이다. 어디에서 가능하다는 뜻은 JVM내에서 무언가를 처리했기 때문이라 이것이 가능하지 않았나 싶다. 이제 이거에 대해 알아보자.

⚙️ JVM 동작방식

다음과 같은 코드가 있다고 가정해보자.

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello World");
    }
}

아쉽게도 이 코드는 사람이 읽기 쉬운 고급 언어(Java 소스코드)로 작성되었기 때문에, 컴퓨터는 이 코드를 직접 실행할 수 없다. 그래서 이 코드를 어딘가에서 해석해주는 과정이 필요한데, 이 역할을 수행하는 것이 바로 JVM(Java Virtual Machine)이다.

그런데 JVM이 이 코드를 곧바로 실행할 수 있을까? 애석하게도 JVM도 이 소스코드를 직접 이해할 수는 없다. 그래서 그 전에 반드시 컴파일이라는 과정을 거쳐야 한다. 이 과정은 .java 파일을 .class 파일로 변환해주는 작업이며, 우리는 이를 컴파일이라고 부른다.

지금까지, Java 코드를 컴파일러를 통해 바이트코드로 변환하는 과정까지 살펴보았다.

그러면 JVM은 바이트코드를 어떻게 실행할까?

일반적으로 JVM은 스택 기반 구조를 사용하여 바이트코드를 한 줄씩 해석하며 실행한다. 바이트코드는 명령어 단위로 구성되어 있으며, JVM은 이를 순차적으로 해석하면서 동작을 수행한다. 이 방식을 우리는 인터프리팅(Interpreting)이라고 부른다.

하지만 이런 방식은 비효율적이다. 왜냐하면 동일한 바이트코드를 매번 해석해서 실행해야 하고, 그에 따라 소모되는 리소스 비용도 무시할 수 없기 때문이다.

그래서 JVM은 자주 실행되는 바이트코드 영역을 탐지하여, 이 부분을 JIT(Just-In-Time) 컴파일러를 통해 네이티브 코드(기계어)로 변환한다. 이렇게 변환된 코드는 해석 없이 바로 실행되기 때문에 성능이 훨씬 향상된다.

이러한 최적화 대상이 되는 자주 실행되는 코드 영역을 흔히 Hot Method라고 부른다. (참고로, HotSpot이라는 용어는 JVM의 대표적인 구현체 이름이다.)

결국 컴파일러가 Java 소스코드를 바이트코드로 변환하고, JVM은 이 바이트코드를 해석하거나 네이티브 코드로 변환해 실행함으로써 Java 코드는 실제 하드웨어 위에서 동작할 수 있게 되는 것이다.

이제 하나의 질문을 던져보자. Java에는 변수, 메서드, 클래스 등 다양한 요소가 존재한다. 그렇다면 이 모든 요소를 하나의 공간에서 관리하는 것이 좋을까? 아니면 각 요소의 특성에 따라 분리하여 관리하는 것이 더 효율적일까?

🏢 JVM 메모리 구조

메모리 구조로 보면 스택, PC Register, Native Method Stack, 힙, 메소드 영역이 이렇게 존재한다.

이것들이 어떤것인지 생각을 하기전에 이렇게 왜 구분이 되는지부터 생각을 해야 할거 같다.

잠시 다른 얘기를 하자면 이건 우리가 분리수거를 하는거와 굉장히 유사하다고 생각한다. 분리수거를 하기 위해서는 각 포지션에 맞게 넣어야 한다. 그거와 마찬가지로 메모리 구조도 각 포지션에 맞게 넣어야 된다고 생각한다.

📌 JVM 메모리 영역별 정보

메모리 영역	저장되는 정보	관련 바이트코드 명령어
스택	- 지역 변수 - 피연산자 스택 - 메서드 호출 프레임	bipush, iload, iadd invoke*, istore, aload astore
힙	- 객체 인스턴스 - 배열	new, getfield putfield, areturn
메서드 영역	- 클래스 메타데이터 - static 변수 - 상수 풀 - final 상수	getstatic, putstatic invokestatic
PC 레지스터	현재 실행 중인 JVM 명령어 주소	(JVM 자동 관리)
네이티브 스택	JNI를 통한 네이티브 메서드 호출 정보	native 키워드 메서드

결국 바이트 코드를 보고 메모리를 저장을 시킨다는것을 알 수 있다. 그러면 메모리는 영원히 저장이 되어질까?

생각을 해보면 메모리 정보가 영원히 저장이 된다면, java는 점점 느려질거라 생각한다. 결국 메모리들은 시간이 지나면 제거를 시켜야 한다는 소리인데 어떻게 제거를 시킬 수 있을까?

힙 -> GC(Garbage Collector)가 객체에 더 이상 참조 없을 때 Stack -> 메서드 종료 시점 Method Area -> 클래스 언로드 시점 (거의 없음) PC Register -> 스레드 종료 시 Native Method Stack -> 네이티브 호출 종료 시

이것을 잘 읽어보면 스택,메소드 영역, PC Register, 네이티브 스택은 종료시 삭제인걸 알수 있는 반면 GC같은 경우는 객체가 더 이상 참조하지 않을때 제거를 한다고 한다. 그렇다는 이야기는 객체같은 경우는 종료 시점을 파악하기가 쉽지 않다는 소리라 생각이 든다. 왜냐하면 객체는 new로 생성이 되어지면 언제든지 꺼내어서 사용 할 수 있기 때문이다.

하지만 다른 키워드 같은 경우는 종료 시점을 파악해 제거가 쉽다고 느껴진다. 예를들어 스택 같은 경우도 스택으로 쌓이기때문에 스택이 빠져나갈때 지우면 되기때문이다.

📝 요약 (One-liner)

JVM 메모리 구조와 관리

메모리 영역별 특징

• 스택: 메서드 호출 시 자동 생성/제거, 지역 변수와 연산 스택 관리
• 힙: 동적 할당된 객체와 배열 저장, GC의 주요 관리 대상
• 메서드 영역: 클래스 메타데이터, static 변수, 상수 풀 저장
• PC 레지스터: 현재 실행 중인 명령어 주소 추적
• 네이티브 스택: JNI 호출 시 사용

메모리 정리 방식

• 자동 정리: 스택, PC 레지스터, 네이티브 스택은 사용 종료 시 자동 정리
• GC 관리: 힙 영역은 참조가 없어질 때 GC가 회수
• 클래스 언로드: 메서드 영역은 거의 정리되지 않음

핵심 인사이트

• 메모리 영역을 분리함으로써 각각의 특성에 맞는 최적의 관리가 가능
• 객체는 참조 추적이 복잡하여 GC가 관리
• 나머지 영역은 명확한 생명주기에 따라 자동 정리

JVM은 메모리 효율성을 위해 각 영역을 구분하고, 각각의 특성에 맞는 관리 전략을 적용합니다. 
이는 마치 분리수거를 통해 자원을 효율적으로 관리하는 것과 유사합니다.

references

• https://steady-coding.tistory.com/305