JVM

JVM 구성요소

• 유저모드 어플리케이션 프로세스, 가상 메모리 공간을 활용, 머신으로서 연산, os의 일부기능
• jvm 구성요소
  • 클래스 로더(Class Loader)
    • 자바 클래스 파일(.class)을 로드하고 링크하는 역할
    • 로딩, 링킹, 초기화 단계로 구성됨
    • 부트스트랩 클래스 로더, 확장 클래스 로더, 애플리케이션 클래스 로더로 구성
    • 클래스 로딩 링킹등이 런타임에 일어날 수 있다.
  • 런타임 데이터 영역(Runtime Data Area)
    • 메서드 영역(Method Area): 클래스 구조, 메서드 데이터, 상수, 정적 변수 등 저장
    • 힙(Heap): 객체와 인스턴스 변수가 저장되는 공간
    • 스택(Stack): 스레드마다 별도로 존재하며 지역 변수, 매개변수, 리턴 값 등 저장
    • PC 레지스터(Program Counter Register): 현재 실행 중인 명령어 주소 저장
    • 네이티브 메서드 스택(Native Method Stack): 네이티브 코드를 위한 스택
  • 실행 엔진(Execution Engine)
    • 인터프리터(Interpreter): 바이트코드를 한 줄씩 해석하고 실행
    • JIT 컴파일러(Just-In-Time Compiler): 자주 사용되는 코드를 네이티브 코드로 컴파일하여 성능 향상
    • 가비지 컬렉터(Garbage Collector): 더 이상 사용되지 않는 메모리 자동 정리
  • 네이티브 메서드 인터페이스(JNI, Java Native Interface)
    • 자바 코드가 네이티브 애플리케이션이나 C, C++ 등의 라이브러리와 상호작용할 수 있게 함
  • 네이티브 메서드 라이브러리(Native Method Libraries)
    • C, C++ 등으로 작성된 라이브러리 모음

클래스로더

.class file(실행 바이너리)

ClassFile {
    u4             magic;              // 매직넘버(0xCAFEBABE), JVM이 유효한 클래스 파일인지 식별
    u2             minor_version;      // 클래스 파일 포맷의 마이너 버전
    u2             major_version;      // 클래스 파일 포맷의 메이저 버전
    u2             constant_pool_count; // 상수 풀 항목 수 + 1
    cp_info        constant_pool[constant_pool_count-1]; // 상수 풀 테이블
    u2             access_flags;       // 클래스의 접근 제어자
    u2             this_class;         // 현재 클래스를 나타내는 상수 풀 인덱스
    u2             super_class;        // 부모 클래스를 나타내는 상수 풀 인덱스
    u2             interfaces_count;   // 구현된 인터페이스 수
    u2             interfaces[interfaces_count]; // 구현된 인터페이스들의 상수 풀 인덱스
    u2             fields_count;       // 필드 수
    field_info     fields[fields_count]; // 필드 정보
    u2             methods_count;      // 메서드 수
    method_info    methods[methods_count]; // 메서드 정보
    u2             attributes_count;   // 속성 수
    attribute_info attributes[attributes_count]; // 클래스의 추가 속성 정보
}

• 추가적으로 .class를 보고 실제 네이티브 머신코드로 interprete, 반복되는 애들을 미리 번역해놓는(컴파일) 애들이 jit compiler
• 이름을 알고 있는 특정 클래스에 대한 정의(byte stream)을 가져오는 역할을 수행
• 가져온다는 것은 네트워크를 통해 가져오는것을 포함
  • 부트스트랩 클래스 로더
    • (비유하자만, 실제 cpu의 부트로더가 필요한일을 마치고, os코드의 진입지점을 실행시키고 종료되는데 마찬가지)
    • jvm에서 라이브러리로 취급되는것들(rt.jar, tools.jar)을 로드
  • 플랫폼 클래스 로더 (기존 확장 클래스 로더)
    • 클래스 라이브러리 로드
  • 어플리케이션 클래스 로더
• Java 클래스 로딩
  • java는 실행과정에 링킹 과정이 포함되어있음
  • 기존의 컴파일 - 링크 - 런타임보다는
  • 실제 바이트코드를 로딩하고, 링크 런타임이 실행단계에 분류되어있음
  • 실질적으로는 Loading -> Linking -> Using -> Unloading(GC)
  • 해석 (Resolution)단계는 동적 바인딩(혹은 lazy binding)을 지원할 목적으로 초기화 후로 지연될 수있음

클래스 로더가 하는 일

• 클래스 검증
  • 규칙과 제약을 만족하는지
    • 파일형식
    • 메타데이터
    • 바이트코드
    • 심벌참조
  • 보안위협에 대한 검증 포함
• 준비 및 해석
  • java.lang.Class 인스턴스(메타데이터)가 힙 영역에 생성, 클래스 변수 메모리를 0으로 초기화
    • 로드되는 클래스의 인스턴스는 Using단계에서 힙사용
    • final선언된 변수 정리
  • 생성자 호출 전 상태
    • 필드 초깃값은 생성자 호출시 정의
    • 정적필드에 초기값 할당
  • 해석은 상수풀의 심벌 참조를 직접 참조로 대체하는 과정
• Heap 영역에 객체 생성
  • jvm은 객체 저장을 위한 메모리 공간을 확보 후 0으로 초기화 (객체 헤더 제외)
  • 객체 초기화를 위한 구성설정 실시
    • 기본적으로 object header, instance data, padding으로 되어있음
      • object header(의 klass word)를 통해 아까 로드한 metadata에 접근
    • 클래스 이름 및 메타 정보 확인 방법
    • 객체에 대한 해시코드
    • GC세대 나이
  • 생성자 호출

런타임 데이터 영역

프로그램 카운터

• 프로그램 카운터 레지스터는 작은 메모리 영역으로 현재 실행중인 스레드의 ‘바이트 코드 줄 번호 표시기’라고 생각하면 쉽다.
• 바이트코드 인터피르터는 이 카운터 값을 바꿔 다음에 실행할 바이트코드 명령어를 선택하는식으로 동작
• 프로그램의 제어 흐름, 분기, 순환, 점프등을 표현
• 예외처리나 스레드복원같은 기능이 이 표시기를 활용해 동작
• jvm의 멀티스레딩은 cpu코어를 여러 스레드가 교대로 사용하는 방식으로 구현되기 때문에, 특정 시각에 한 코어는 한 스레드의 명령어만 실행하게 된다. 따라서 스레드 전환 후 이전에 실행하다 멈춘 지점을 정확하게 복원하려면 스레드 각각에는 고유한 프로그램 카운터가 필요하다.
• 따라서 각 스레드의 카운터는 서로 영향을 주지 않는 독립된 영역에 저장된다. 이 메모리 영역을 프라이빗 메모리라고 한다.
• 스레드가 자바 메서드를 실행중일 때는 실행중인 바이트코드 명령어의 주소가 프로그램 카운터에 기록된다.
• 한 편 스레드가 네이티브 메서드를 실행중일 때 프로그램 카운터 값은 undefined다 프로그램 카운터 메모리 영역은 oom 조건이 명시되지 않은 유일한 영역이기도 하다.

자바 가상 머신 스택

• 마찬가지로 스레드 프라이빗하며, 스레드와 수명주기가 같다.
• 가상머신스택은 메서드를 실행하는 스레드의 메모리 모델을 설명해준다.
• 메서드 호출시 스택프레임만들고, 지역변수 테이블, 피연산자 스택, 동적 링크, 메서드 반환값등의 정보를 저장한다.
• 그다음 스택프레임을 가상머신 스택에 푸시하고, 메서드가 끝나면 팝하는일을 반복한다.
• 지역 변수 테이블에는 jvm이 컴파일타임에 알수있는 다양한 기본데이터타입, 객체 참조, 반환주소 타입을 저장한다.
• 이걸 저장하는 공간을 지역 변수 슬롯이라 하고 슬롯의 크기는 일반적으로 32비트이다.
• 지역 변수 테이블을 구성하는데 필요한 데이터 공간은 컴파일 과정에 할당된다. 자바 메서드는 스택프레임에서 지역변수용으로 할당받아야 할 공간의 크기가 이미 완벽하게 결정되어있다.

네이티브 메서드 스택

• jvm 스택과 비슷!
• 네이티브 메서드를 사용할때 실행된다. (보통 다른 언어로 작성된 메서드, jni를 통해 호출됨, 즉 jvm이 직섭 실행할수없는 네이티브 코드를 실행하기 위한 메서드)

자바 힙

• 모든 스레드 공유
• 다른 언어의 힙과 동일
• 거의 모든(사실상 모든)객체가 힙에 저장됨.
• gc가 관리하는 메모리 영역이기에, gc힙이라고 함
• 객체 할당 효율을 높이고자 스레드 로컬 할당 버퍼 여러개로 나뉜다. (그래도 모든 객체가 힙에 저장된다는 사실은 마찬가지, 일부 메모리회수와 할당을 조금 더 빠르게 하기위해 일정한 세부영역이 있을 뿐)
• 힙은 물리적으로 떨어진 메모리에 위치해도 상관없으나 논리적으로는 연속되어야 한다.

메서드 영역

• 모든 스레드가 공유하는 영역으로, JVM이 시작될 때 생성됨
• 런타임 상수 풀, 필드와 메서드 데이터, 메서드와 생성자 코드, 클래스와 인터페이스 초기화에 사용되는 코드 등을 포함
• 클래스 로더가 클래스 파일을 로드할 때, 해당 클래스의 메타데이터를 이 영역에 저장
• JDK 8까지는 이 영역을 “영구 생성(Permanent Generation)” 또는 “PermGen"이라고 불렀음
• JDK 8 이후에는 메서드 영역의 구현이 “메타스페이스(Metaspace)“로 변경됨
• 메타스페이스는 기존 PermGen과 달리 OS가 관리하는 네이티브 메모리 영역을 사용하므로 더 이상 JVM 힙 메모리의 일부가 아님
• 이 변경으로 OutOfMemoryError: PermGen Space 오류가 발생하지 않게 됨
• 클래스 메타데이터, 메서드의 바이트코드, static 변수와 상수 정보 등이 저장됨
• 런타임 상수 풀은 리터럴 상수, 필드 참조, 메서드 참조 등을 포함하며 심볼릭 참조를 실제 참조로 변환하는 데 사용됨
• 클래스의 정적 변수는 여기에 저장되지만, Java 8 이후에는 static 변수의 실제 데이터는 힙에 저장됨
• JIT컴파일러가 컴파일한 코드를 캐싱한다.

런타임 상수 풀

• 클래스 버전, 필드, 메서드, 인터페이스등 클래스파일에 포함된 정보 및 리터럴, 심볼참조가 저장되는 영역
• 클래스로더가 클래스 로드시 상기 정보를 저장
• 동적으로 운영되며 런타임에 새로운 상수가 추가될 수 있음

JVM 스택 구조

• 지역변수 테이블, 피연산자 스택, 메서드 반환값등을 저장
• 보통 지역변수 테이블을 스택으로 지칭
• 지역변수 테이블은 슬롯으로 이루어지며, 기본형 변수 하나가 슬롯한개를 사용
• java 스택의 크기는 메모리 용량이 아닌 슬롯의 개수
• jvm이 허용하는 스택의 크기를 초과할경우 stackoverflow

스택 프레임 구조

JVM 힙 구조

• GC가 관리하는 메모리 영역
• 객체의 인스턴스 및 배열이 저장되는 공간
• 설정에따라 크기 변경 고정 가능
• 세대별 컬렉션 이론 (Generational collection thory)을 기반으로 설계 및 운영
  • Eden, Survivor
  • New/Old Generation
  • 영구 세대 (Metaspace)

JVM GC

• Heap영역에서 참조되지 않는 개체를 수집 및 제거해 메모리 회수
• Minor/Major(Full) GC
  • GC수행시 프로그램 일시 정지
  • stop-the-world
• GC 속도
  • Minor GC 보통 1초이내
  • Full GC 1초이상 지연되기도 함 -> 문제는 db커넥션이 끊기거나 하는 운영문제가 생길 수 있음

GC가 처리해야할 문제의 핵심 3요소

• 회수 대상을 판단하는 것
• 메모리를 회수하는 시점
• 메모리 회수 방법

세대 단위 컬렉션 이론

바탕이 되는 가설

• 대다수 객체는 일찍 사라짐(약한 세대 가설)
• gc과정에서 살아남은 횟수가 늘어날수록 (앞으로도) 생존 가능성이 높아짐(강한세대 가설)
• 다른세대에 속한 객체간 참조는 같은세대에 속한 객체간 참조보다 훨씬 적음 (세대 간 참조 가설)
• 핫스팟 vm에서 에덴과 생존자 공간비율은 보통 8:1
  • IBM 연구에 따르면 보통 첫 GC에 대략 98% 객체가 소멸
  • 10% 메모리 파편화 방지를 위해 활용 (Overhead)

jvm heap 영역 세대별 space 출처 : https://medium.com/@khurshidbek-bakhromjonov/java-memory-management-understanding-the-jvm-heap-method-area-stack-24a4d4fa2363

Young generation

• eden
  • 객체 생성직후 저장되는 영역
  • Minor GC 발생시 Survivor 영역으로 이동
  • Copy & Scavenge 알고리즘
• Survivor 0,1
  • Minor GC 발생시 Eden, S0에서 살아남은 객체는 S1 (S0, S1 서로 교대)
  • S1에서 살아남은 객체는 Old로
  • age bit 사용 (참조 계수)

Old generation

• Young generation 영역에서 소멸하지 않고 남은 개체들이 사용하는 영역
• Full GC 발생시 개체 회수 (비용이 크고 디테일함, 실제로 정말 사용되는지 찾음)
• Mark & Compact 알고리즘

Permanent

• Metaspace
  • 로드되는 클래스, 메소드 등에 관한 메타 정보 저장
  • java heap이 아닌 native메모리 영역사용
  • 리플렉션 클래스 로드시 사용

GC 알고리즘

Mark and sweep

• 1단계 마크(회수대상 판단)
• 2단계 회수
• 단점
  • 효율이 일정하지 않음 (힙이 많이 채워져있을경우 특히)
  • 메모리 파편화 발생

Mark and copy

• 가용 메모리 공간을 둘로 나눈후 한쪽만 사용 (S0, S1)
• 살아남은 인스턴스를 옮길때 옮김 (Copy)
  • 즉 살아남은 인스턴스를 다른 영역으로 복사하고
  • 사용했던 공간을 모두 비운다.
• 단점
  • 가용메모리 공간이 절반으로 줄어듦
  • Andrew Appen의 제안으로 개선 (위의 연구)

Mark and compact

• 생존한 객체를 모음 (copy 과정에서 compact)
• 단점
  • 살아남은 객체가 많을수록 부담이 크게 증가 (사실상 모든 알고리즘 공통)
  • 인스턴스 이동 과정에서 응용프로그램의 연산이 일시정지 (Stop the world!) (사실상 모든 알고리즘 공통)

도달 가능성 분석

• 도달 가능성 분석 알고리즘에 기초해 회수 대상 인스턴스를 판단
• GC 루트 객체들을 기점으로 참조하는 다른 객체들을 탐색하는 방식

GC 루트 객체가 될 수 있는 것들

• jvm stack frame 지역변수 테이블에서 참조하는 객체
• Synchronized 키워드로 잠겨있는 객체
• JNI가 참조하는 객체
• 메서드 영역에서 클래스 정적 필드로 참조하는 객체
• 메서드 영역에서 상수로 참조되는 객체
• JVM 내부에서 사용되는 참조

Garbage First GC

클래식 GC 종류 일부

• Serial
  • 단일 스레드로 작동, 회수가 끝낼때까지 모두 멈춤
  • 간단하고 효율적이며 알고리즘 수준에서 리소스 사용량 적음
• ParNew
  • 시리얼 컬렉터를 병렬처리
• Parallel scavenge
  • 사용자 코드 처리 실행 효율 극대화를 목표로 설계
• CMS GC
  • java 14까지 사용되었음
• G1 GC
  • 4gb 이상 대용량 heap 메모리를 사용하는 멀티스레드 기반 응용 프로그램에 특화된 GC
  • Heap을 영역 (1~32mb)단위로 분할한 후 멀티스레드 스캔 G1 GC
• jdk 9부터
• 서버용 응용 프로그램에 집중한 GC
• JVM 힙을 세대단위가 아닌 독립 영역으로 구분했음
• 힙의 모든 영역을 회수 집합 (Collection set)에 포함시켜 영역단위 처리
  • 가장 쓰레기가 많은 영역을 파악
  • 회수시 가장 득이 되는 영역 파악

객체 메모리 레이아웃과 해시코드

• Object Header
  • klass word : 메타스페이스에 있는 클래스 정보에 대한 참조자
  • Mark word
    • Hashcode는 Object.hashCode() 함수가 호출되는 시점에 계산
      • 자바는 메모리 접근을 못하니까 사용
      • 같은 인스턴스인지 식별 등
    • age는 GC에서 살아남은 횟수
    • Lock flag는 객체를 중심으로 멀티스레드 환경에서 경쟁조건이 발생하는 문제를 해결하기 위해서

• Instance Data
• Padding

Object 클래스

• java의 모든 클래스는 object의 파생형식
• equals()
  • 매개변수로 전달된 참조자와 this가 가리키는 대상이 같은 값인지 값만 비교
  • 즉 동등성 비교
• hashCode()
  • 객체 식별을 위한 고유 해시결과 값(Unique)
  • jvm의 힙영역에서 주소가 계속 달라지기때문에, 주소값이 아닌 hashCode로 인스턴스 식별
  • 동일성 비교에 사용
• toString()
  • 클래스명@해시코드
• getClass()

JVM Concurrent

JVM과 스레드

• 스레드의종류를 아래처럼 나눌수 있음
  • 플랫폼 스레드
  • 커널 스레드
  • 가상 스레드
• 기본적으로 네이티브 언어는 굳이 고려할 필요가 없는데, jvm은 실제 플랫폼 스레드와 커널스레드관련해서 볼 것들이 있음
• 스택 메모리는 스레드마다 할당
• 예를들어 오버헤드를 볼때
  • tcb를 저장/복원하는 오버헤드와
  • java thread를 jvm관련 비용들도 같이 봐야함

객체 메모리 레이아웃과 해시코드

• object header중 lock flag를 다시 볼 시간
  • lock flag는 누가 선정하는가?
  • 경쟁 상황시 락을 획들 못하면 해당값이 변하고 다른 스레드들이 blocked됨

JVM 메인 메모리와 작업메모리(working memory)

• 작업메모리는 스레드가 사용하는 변수의 사본이 저장되며

• 스레드 내부에 연산은 작업 메모리에만 반영

• 스레드는 jvm 메인 메모리에 직접 접근 불가

• 읽기 메인 메모리에서 변수의 값을 읽어 작업 메모리로 전송

• 적재 메인 메모리가 전송한 값을 작업메모리에 저장

• 저장 작업 메모리 변수의 값을 메인 메모리로 전송

• 쓰기 작업메모리의 값을 메인메모리에 씀

• 일반 변수의 동기화 시점

  • 명시적 (synchronized, volatile)
  • Thread.start(), join()
  • Lock, Atomic class
  • 클래스 로딩 과정에서 정적 변수 초기화시
  • 기타 jvm이 정한 최적화, 동기화 기준을 충족 시

• volatile

  • 멑티스레드 환경에서 여러 스레드가 접근하는 변수에 대해 가시성을 제공 (메인 메모리 동기화)

가상 스레드

• 실제로 한 (커널)스레드에서 분리된 여러 단위코드로 실행하는 개념
  • 스위칭 오버헤드를 줄이기 위함
• 마치 각각이 개별 스레드로 보이지만, 사실 하나의 스레드로 처리되도록
• 상호 의존성이 전혀 없는 코드여야함

동기화를 위한 OS수준 커널 객체

• 커널 객체를 이용함 (동기화 객체)
  • event
  • mutex
  • semaphore
  • 포인터 혹은 카운터로 사용되는 메모리로 생각할수있음
• 커널 객체는 생성할 수 있는 갯수가 제한적이며 spinlock에 비해 무거움 (위의것들)

동기화 메서드

• 임계영역 기반 동기화 기법으로 메서드 코드 전체를 임계영역으로 설정
• 여러 스레드에서 호출하더라도 동시 실행이 허용되지 않음

모니터락 동작 순서

• 스레드가 synchronized 메서드 호출시 모니터락을 요청
• 타 스레드가 모니터락을 이미 점유하고 있으면 스레드 상태를 blocked상태로 전환
• 기존 모니터 락 점유 스레드가 구간을 벗어나(임계영역을)면 모니터락을 해제하고 blocked상태로 대기중인 스레드중 하나가 락을 얻고 동기화 구간에 진입