JVM 분석을 통한 스프링 프로젝트 로드 속도 최적화

[sngbmYu]

주제 선정 이유

프로젝트에 새로운 기능이 추가될수록 서버 부팅 시간이 점점 느려지는 현상을 발견하여, JVM 분석을 통해 프로젝트의 어느 지점에서 실행 속도를 저하시키는지 확인하고 이를 개선하고자 합니다.

08/29 딥다이브

방향성 정리

1. JVM에 대해 공부
2. JVM 프로파일러(JFR, VisualVM 등)로 스프링 프로젝트 분석
3. 스프링 프로파일러(Startup Analysis, Actuator 등)로 분석
4. 성능 튜닝

JVM 공부

자료 모음

1. JVM은 무엇이며 자바 코드는 어떻게 실행하는 것인가
2. JVM 구조와 자바 런타임 메모리 구조
3. JVM Internal
4. Java Garbage Collection
5. JVM이란? 개념 및 구조

9/12 딥다이브

JVM 정리

JVM이란?

• Java Virtual Machine, Java 바이트코드를 해석하고 실행하는 가상 머신
  • 가상 머신(Virtual Machine): 프로그램을 실행하기 위해 물리적인 머신(컴퓨터)와 유사한 머신을 소프트웨어로 구현한 것
• WORA(Write Once Run Anywhere)를 구현하기 위해 하드웨어와 자바 프로그램 사이에 가상 머신을 하나 두어, 프로그램이 하드웨어나 OS에 종속되지 않도록 해준다.
• JVM의 특징
  • 스택 기반의 가상 머신: 대표적인 컴퓨터 아키텍터인 x86 아키텍처나 ARM 아키텍처가 레지스터 기반으로 동작하는 데 비해 JVM은 스택 기반으로 동작한다.
    • JVM이 스택 기반 아키텍처를 사용하는 이유: 스택 기반 명령어는 하드웨어에 독립적이어서 다양한 플랫폼에서 쉽게 실행할 수 있다. 대신 레지스터 기반 아키텍처에 비해 추가적인 메모리가 필요하고 연산 속도가 비교적 느리다.
  • 심볼릭 레퍼런스: 기본 자료형(primitive type)을 제외한 모든 타입을 명시적인 메모리 주소 기반의 레퍼런스가 아니라 심볼릭 레퍼런스를 통해 참조한다.
    • 심볼릭 레퍼런스: 실제 메모리 주소나 구체적인 객체를 직접 참조하는 대신 이름이나 심볼로 참조하는 방식
  • 가비지 컬렉션(Garbage Collection): 클래스 인스턴스는 사용자 코드에 의해 명시적으로 생성되고 가비지 컬렉션에 의해 자동으로 파괴된다.
  • 기본 자료형을 명확하게 정의하여 플랫폼 독립성 보장: C나 C++ 등 전통적인 언어는 플랫폼에 따라 int형의 크키가 변한다. 하지만 JVM은 기본 자료형을 명확하게 정의하여 호환성을 유지하고 플랫폼 독립성을 보장한다.
  • 네트워크 바이트 오더(Network Byte Order): 자바 클래스 파일은 네트워크 바이트 오더를 사용한다. x86 아키텍처는 리틀 엔디안을 사용하고, RISC 아키텍처는 빅 엔디안을 사용하기 때문에, 이 사이에서 플랫폼 독립성을 유지하기 위해 표준화된 방식인 네트워크 바이트 오더(빅 엔디안)를 사용한다.
    • 바이트 오더: 다중 바이트 데이터를 메모리나 파일에 어떻게 나워서 정렬할 것인지를 정의하는 방식
    • 리틀 엔디안: LSB(Least Significant Byte)가 가장 앞에 저장되는 방식, 즉 바이트 순서를 반대로 저장
    • 빅 엔디안: MSB(Most Significant Byte)가 가장 앞에 저장되는 방식, 즉 바이트 순서대로 저장

자바 바이트코드(Bytecode)란?

• 자바 소스 코드를 컴파일한 후에 생성되는 중간 형태의 기계어, JVM이 이해하고 실행할 수 있는 명령어들로 이루어져 있다.
• 특정 OS나 하드웨어에 종속되지 않으며, 자바 프로그램의 플랫폼 독립성을 보장하는 핵심 요소이다.
• 자바 컴파일러javac에 의해 변환되는 코드의 명령어 크기가 1바이트라서 바이트코드이며, 확장자는 .class를 쓴다.

Java 컴파일 과정

1. .java 파일을 빌드하면 javac가 바이트코드.class로 변환
2. 바이트코드가 클래스 로더에 의해 메모리에 로드된다. 클래스 로더는 프로그램이 실행될 때마다 필요한 클래스를 동적으로 로드한다.
3. JVM 실행 엔진이 바이트코드를 기계어로 해석하면서 프로그램을 실행시킨다. 이때 실행 엔진은 기본적으로 인터프리터를 사용해 바이트코드를 해석하다가, 자주 수행되는 메서드를 만나면 JIT 컴파일러를 통해 바이트코드를 해석한다.

JVM의 구성요소

• 클래스 로더 (Class Loader): 프로그램을 실행할 때 동적으로 클래스를 로드하고, 메모리에 배치하는 역할
  • 로딩: 자바 바이트코드 파일.class을 메모리에 로드하고, 런타임 데이터 영역의 메서드 영역에 로드된 클래스의 메타데이터를 저장한다.
  • 링크: 로드된 클래스가 JVM의 명세에 맞는지 검증하고, 클래스static 변수의 메모리를 할당하고 자바의 기본값을 초기화한 뒤, 심볼릭 레퍼런스를 실제 메모리 주소로 변환한다.
  • 초기화: 클래스 변수를 사용자 지정값으로 초기화하고, 정적 초기화 블럭을 실행시킨다.
• 실행 엔진 (Execution Engine): 클래스 로더가 로드한 바이트코드 해석하여 기계어로 변환한 후에 프로그램을 실행시키는 역할
  • 인터프리터: 바이트코드를 한 줄씩 읽어 즉시 해석하고 실행, 속도가 비교적 느리다.
  • JITJust In Time 컴파일러: 자주 실행되는 바이트코드를 기계어로 변환한 후 캐싱하여 반복되는 코드를 빠르게 실행한다.
  • 두 가지 방식을 사용하는 이유: 컴파일된 코드를 실행하는 것이 인터프리터로 한 줄씩 해석하는 것보다 훨씬 빠르지만 컴파일 과정 자체가 오래 걸리기 때문에, 한 번만 실행되는 코드는 바로 해석하고 반복적으로 실행되는 코드는 컴파일하여 실행 성능을 최적화한 것이다.
  • 가비지 콜렉터(Garbage Collector): 런타임 데이터 영역 중 힙 영역에서 더 이상 참조되지 않는 객체들을 탐색한 후에 제거하여 메모리를 확보하는 역할을 한다.
• 런타임 데이터 영역 (Runtime Data Area)
  • 메서드 영역 (Method Area): 클래스와 인터페이스의 메타데이터, 즉 클래스명, 상속 클래스 정보, 메서드 및 필드 정보, Constant Pool, static 변수 등 클래스 수준의 데이터를 저장하며, 모든 스레드가 공유하는 영역이다.
    • 런타임 상수 풀 (Runtime Constant Pool): 클래스 파일 내의 상수 뿐만 아니라, 심볼릭 레퍼런스를 저장하는 영역이다.
  • 힙 영역 (Heap Area): new 키워드로 생성한 인스턴스와 배열이 생성되며, 모든 스레드가 공유하는 영역이다. GC가 관리하는 영역이기도 하다.
  • 스택 영역 (Stack Area): 각 스레드마다 할당되는 영역으로, 지역 변수, 파라미터, 반환값, 중간 계산값 등 임시로 사용하는 데이터를 저장하는 영역이다.
  • PC 레지스터 (Program Counter Register): 각 스레드가 현재 실행하고 있는 JVM 명령어의 주소를 저장하는 영역으로, 각 스레드마다 할당된다.
  • 네이티브 메서드 스택 (Native Method Stack): 자바 외의 다른 언어(C/C++)로 작성된 메서드Native Code를 실행할 때 사용되는 영역으로, JNI(Java Native Interface)를 통해 호출되는 메서드와 관련된 메모리를 관리한다.

[startupcodekr]

JVM 심층 분석을 통한 스프링 프로젝트 병목 구간 파악: Controller 파라미터 매핑 어노테이션의 작동 원리와 최적 사용 전략