본격 JVM 해부하기

🤓 새로운 정보를 찾으면 계속 업데이트 될 글입니다!

• 자바의 실행 과정
  • 자바는 JVM이 OS로부터 이 프로그램이 필요로 하는 메모리를 할당받는다.
  • 자바 파일이 자바 컴파일러에 의해 자바 바이트 코드(.class)로 변환된다.
  • 클래스 로더를 통해 자바 바이트 코드를 JVM으로 로딩한다.
  • 해석된 바이트 코드는 런타임 데이터 영역에 배치된다.
  • 실행 엔진을 통해 실행된다.
  • JVM은 필요에 따라 GC와 같은 작업을 수행한다.

 

JVM의 구조

클래스 로더

자바는 동적 로드, 즉 런타임에 클래스를 로드하고 링크하는 특징이 있다. 이 동적 로드를 담당하는 부분이 JVM의 클래스로더이다.

• 로드
  • 우선 클래스 로더는 .class 파일을 읽고, 그 내용에 따라 적절한 바이너리 데이터를 만들고, 메소드 영역에 저장하는 동작을 수행한다.
• 링크
  • 검증: 읽어들인 클래스가 자바 언어,JVM 명세에 명시된 대로 잘 구성되어 있는지 검사한다.
  • 준비: 클래스가 필요하는 메모리를 할당하고, 클래스에서 정의된 필드, 메소드, 인터페이스를 나타내는 메모리 구조를 준비한다.
  • 분석: 심볼릭 메모리 레퍼런스(참조하는 대상의 이름만을 갖고 있음)를 메소드 영역에 있는 실제 레퍼런스로 교체한다. 즉, 그 이름에 맞는 객체의 주소를 찾아서 연결하는 작업을 진행한다.
• 초기화
  • 클래스 변수들을 설정된 값으로 초기화한다. (static 변수)
  • 클래스가 로딩될 때 static 변수가 생성되고, 메모리에 딱 한번만 올라간다. public을 붙이면 같은 프로그램 어디서든 접근할 수 있다.

한마디로 요약하면 클래스 로더는 바이트 코드를 읽고 메소드 영역에 저장하고, 클래스를 검증하고, 클래스가 필요로 하는 메모리를 할당하고,객체의 주소를 연결하는 작업을 한 후, 클래스 변수 들을 적절한 값으로 초기화한다.

 

실행 엔진

• 인터프리터
  • 자바는 플랫폼 독립적이고, 이식성이 높다.
  • 각 플랫폼에 맞는 인터프리터가 바이트 코드를 실행하기 때문에 어떤 OS에서든지 실행될 수 있다.
  • 인터프리터는 바이트 코드를 한 줄씩 읽고, 운영체제가 실행할 수 있도록 기계어로 변경하는 역할을 수행한다. 그러나 인터프리터는 반복 호출되는 메소드를 매번 인터프리팅 해야 해서 비효율적이다.
  • 자바는 javac 명령어를 통해 컴파일하고, 이 컴파일 된 바이트 코드를 인터프리터가 한 줄씩 읽으면서 수행한다. 따라서 자바는 컴파일 언어이면서 인터프리팅 언어이다.
  • Compiler VS Interpreter: https://velog.io/@jaeyunn_15/OS-Compiler-vs-Interpreter
• JIT 컴파일러
  • 자주 실행되는 바이트 코드 영역을 런타임 중에 기계어로 컴파일하여 Native Method Stack에 저장되며, 변환된 부분은 인터프리터에 의해 실행되지 않고 native code 형태로 곧바로 실행된다. 인터프리터의 단점을 극복하기 위해 고안된 방법이다.
• GC
  • 메모리 영역을 관리하는 역할을 한다. 우선 자세한 것은 힙 영역을 다루고 밑에서 설명하겠다.

실행 엔진에 대해 정말 잘 정리해놓으신 글! : https://junhyunny.github.io/information/java/jvm-execution-engine/

 

메모리 영역

 

모든 스레드가 공유하는 부분

대부분 수명이 긴 것들을 다루는 공간 이라고 생각하면 된다.

• 힙
  • new 연산자로 생성된 객체, Array와 같은 동적으로 생성된 데이터가 저장되는 공간.
  • Reference Type(Integer, String, ArrayList..) 데이터가 저장되는 공간이다.
  • Heap에 저장된 데이터는 Garbage Collector가 참조되지 않는 메모리를 확인하고 제거하는 영역이다.

• 메소드 영역
  • 모든 스레드가 공유하는 메모리 영역으로, 메소드 영역을 클래스, 인터페이스, 메소드, 필드, static 변수 등의 바이트 코드를 보관한다.
  • JVM은 메인 메소드를 호출하는 것으로 프로그램을 시작한다. 우리가 메인 메소드에서 사용하는 클래스와 static 변수가 있고, 그것들이 메소드 영역에 올라온다.
  • Runtime Constant Pool에 Type, Field, Method로의 모든 레퍼런스를 저장하며, JVM은 여기를 활요해서 실제 메모리상 주소를 찾아 참조한다.

스레드마다 하나씩 생성되는 부분

• 스택
  • 스택 안에는 지역변수, 매개변수, 리턴 값등과 같이 잠시 사용되고 필요 없어지는 데이터가 저장된다.
  • 원시 타입의 데이터들에 대해서 실제 값을 스택에 직접 저장된다.
  • 지역 변수이지만 참조 자료형 데이터들은 heap에 저장된 데이터의 주소값을 스택에 저장해서 사용하게 된다.
  • 메소드를 호출하면 stack 프레임이 하나 새로 생성되어 push되고, 그 안에서 메소드와 관계된 지역변수, 매개 변수 등을 스택 영역에 저장한다. 호출이 완료되면 pop된다.
• PC Register
  • 스레드가 어느 명령어를 처리하고 있는지 주소를 등록한다.
  • JVM이 실행하고 있는 현재 위치를 저장하는 공간 : 스택의 위치를 나타내고 있다.
• Native Method Stack
  • 자바 외 언어로 작성된 네이티브 코드를 위한 메모리 영역이다.

 

Garbage Collector

• Garbage Collector(이하 GC)는 왜 필요할까?
  • 프로그램을 개발하다 보면 유효하지 않은 메모리인 Garbage가 발생하게 된다. c++같은 언어를 사용하면 개발자가 직접 메모리를 해제해줘야하지만, java나 코틀린을 사용하면 JVM의 GC가 불필요한 메모리를 알아서 정리해준다.

• GC의 원리를 설명하기 위해선 Heap의 구조를 이해해야 한다.
  • JVM의 Heap 영역은 처음 설계될 때  2가지를 전제로 하고 설계되었다.
    • 대부분의 객체는 금방 접근 불가능한 상태가 된다.
    • 오래된 객체에서 새로운 객체에서 새로운 객체로의 참조는 아주 드물다.
  • 객체는 대부분 일회성이며, 메모리에 오래 남아있는 경우가 드물다는 것이다. 그렇기 때문에 객체 생존 기간에 따라 물리적인 Heap 영역을 나누게 되었다.
  • JVM의 GC는 Unreachable Object를 우선적으로 메모리에서 제거하여 메모리 공간을 확보한다. Unreachable Object란 Stack에서 도달할 수 없는 Heap 영역의 객체를 말한다.
• GC 알고리즘
  • Stop The World
    • 가비지 컬렉션을 실행하기 위해 JVM이 어플리케이션의 실행을 멈추게 된다. 당연히 모든 스레드들의 작업이 중단되면 어플리케이션이 멈추게 되고, GC의 성능 개선을 위해 튜닝을 한다는 것은 이 Stop the world 시간을 줄이려고 하는 것이다. 
  • Mark And Sweep
    • JVM의 GC가 스택의 모든 변수를 스캔하면서 각각 어떤 Object를 레퍼런스하고 있는지 찾는 과정이 Mark다. Reachable Object가 레퍼런스하고 있는 Object또한 마킹한다.
    • 그리고 Mark되지 않은 모든 오브젝트들을 힙에서 제거하는 과정이 Sweep이다.
  • Mark And Sweep의 과정 (Java 8기준)
    • 먼저 Eden 영역이 꽉 차면 Minor GC가 발생한다.
      • 이때 Reachable이라고 판단된 객체는 Surivival 0 영역으로 옮겨진다. minor gc에서 살아남은 객체는 age bit가 1씩 증가한다.
      • 또다시 Eden 영역이 꽉 차면 Minor GC가 발생하고, Reachable이라고 판단된 객체들을 Survival 1 영역으로 이동한다.
      • 이를 계속 반복하다가 일정 수준의 age bit가 넘어가면 Old Generation으로 넘겨주는데, 이를 Promotion이라고 하며, age bit가 15가 되면 Promotion이 진행된다.
    • 이때 Old Generation이 다 차면 Major GC가 발생한다.
      • Major GC는 객체들이 계속 프로모션되어 Old 영역의 메모리가 부족해지면 발생한다. Young 영역은 old 영역에 비해 크기 작기 때문에 보통 1초 안에 끝나기 때문에 Minor GC는 성능에 큰 영향을 주지 않지만, Major GC는 일반적으로 Minor GC에 비해 10배 이상으로 시간이 오래 걸린다. 

 

GC의 종류에는 어떤 것들이 있을까?

• Serial GC
  • Serial GC의 young 영역은 Mark Sweep 대로 수행되나, Old영역에서 Mark Sweep Compact 알고리즘이 사용된다. c추가된 Compact 단계는 Heap 영역을 정리하기 위한 단계로, 유용한 객체들이 연속되게 쌓이도록 힙의 가장 앞 부분부터 채워서 객체가 존재하는 부분과 존재하지 않는 부분으로 나누게 된다.
  • Serial GC는 서버의 CPU 코어가 1개일 때 사용하기 위해 개발되었으며, 모든 GC의 역할을 처리하기 위해 1개의 쓰레드만을 사용한다. 그렇기 때문에 CPU 코어가 여러 개인 운영 서버에서 Serial GC를 사용하는 것은 반드시 피해야 한다.

• Parellel GC
  • Java 8까지 Default GC로 사용되었다. 그럼에도 어플리케이션이 멈추는 것을 피할 수 없었고, 이러한 부분을 개선하기 위해 다른 알고리즘들이 등장하게 되었다. 
  • 기본적인 처리 과정은 Serial GC와 동일하나, Parallel GC는 여러 개의 스레드를 통해 Parellel하게 GC를 수행함으로써 GC의 오버헤드를 상당히 줄여준다. Parellel GC는 멀티 프로세서 또는 멀티 스레드 머신에서 중간 규모부터 대규모의 데이터를 처리하는 어플리케이션을 위해 고안되었다.

• CMS GC (Concurrent Mark Sweep)
  • 기존 GC와는 다르게 어플리케이션 스레드와 Mark-Sweep 알고리즘을 Concurrent하게 수행한다.
  • CMS GC는 어플리케이션의 지연 시간을 최소화하기 위해 고안되었으며, 어플리케이션이 구동중일 때 프로세서의 자원을 공유하여 이용할 수 있어야 한다. CMS GC가 수행 될 때는 자원이 GC를 위해서도 사용되므로, 응답이 느려질 수는 있으나 멈추진 않게 된다. 
  • CMS GC는 다른 GC보다 많은 메모리를 필요로 하며, Compaction 단계를 수행하지 않는다는 단점이 있다. 추후에 메모리 단편화로 인해 Compaction 작업을 수행하는데, 이 때의 Compaction 작업이 Parallel GC보다 오래 소요될 수 있다. 
  • 해당 방식은 java9버전부터 Deprecated되었다.

• G1 GC
  • Java 9에서부터 채택된 G1 GC는 우리가 알던 힙 구조와는 약간 다르게 동작한다. 
  • Eden, Survivor, Old 영역이 고정된 크기가 아니며, 전체 힙 메모리를 Region이라는 특정한 크기로 나눈다. Region의 상태에 따라 그 Region의 역할(Eden..)이 동적으로 변동한다. 또한 두 영역이 추가되어있다.
    • Humonogous : region 크기의 50%를 초과하는 큰 객체를 저장하기 위한 공간
    • Available/Unused: 아직 사용되지 않은 Region을 의미한다.
  • Minor GC
    • 한 지역에 객체를 할당하다가 해당 지역이 꽉 차면 다른 지역에 객체를 할당하고, Minor GC가 수행된다. G1 GC는 각 지역을 추적하고 있기 때문에 가비지가 가장 많은 지역을 찾아서 Mark and Sweep을 수행한다.
    • Eden 영역에서 GC가 수행되면 살아남은 객체를 mark하고, 메모리를 sweep한다. 그리고 살아남은 객체를 다른 지역으로 이동시키는데, 이 지역이 Available/unused 지역이면 이 영역이 이제 Survivor 영역이 되고, Eden 영역이 Available/Unused 지역으로 바뀐다.
  • Major GC
    • 시스템이 계속 운영되다가, 객체가 너무 많아 빠르게 메모리 회수가 안될 때 Major GC가 수행된다. 여기서 G1 GC와 다른 GC의 차이점을 발견할 수 있다. 기존의 다른 GC 알고리즘은 모든 heap의 영역에서 GC가 수행되었으며, 그에 따라 처리 시간이 상당히 오래걸렸다.
    • 그러나 G1 GC는 어느 영역에 가비지가 많은지를 알고 있기 때문에 GC를 수행할 영역을 조합하고, 해당 영역에서만 GC를 수행한다. 이러한 작업은 Concurrent하게 수행되기 때문에 지연이 크지 않으며, 가비지가 많은 지역을 정리하게 되므로 효율적이다.
  • G1 GC의 과정은 이보다 훨씬 복잡하다. 우선은 개념 정도를 알고 넘어가도록 하고 추후에 글을 하나 더 할당해서 적어보도록 하겠다.

G1 GC를 적용했을 때의 힙 구조

 

🤕 그래서 메모리 관리가 왜 중요한데? 뭘 이렇게까지 다 알아야 해..? 가 궁금해진다면.. 이 앞서 떠든 긴긴 얘기들은 내가 몇 달 전 처음 만난 OOME라는 에러를 다루기 위한 밑밥이었다.

OOME란?

 java.lang.OutOfMemoryError는 jvm이 힙 메모리에 더이상 Object를 할당할 수 없을 때 발생한다.

• OOME의 종류
  • Java Heap Space : Java의 Heap 메모리 공간이 부족한 경우 (디폴트 64MB)
  • PermGen Space :  힙 메모리 영역 중 Permenant 영역은 String Pool, Class Method와 관련된 각종 메타 데이터등을 저장하는 용도로 사용된다. 따라서 JVM 기동 시에 로딩되는 Class 또는 String의 수가 많은 것이 원인이 된다.
• 내가 만난 OOME - Java Heap Space
• 해결 방법
  • -Xmx 옵션을 사용하여 Heap Memory의 크기를 증가시키는 방법이 있지만, GC Time을 증가시키기 때문에 사전 테스트가 필요하다.
  • 또는 OOME가 발생한 시점에 생성된 Heap Dump 분석을 기반으로 쓸데없이 많은 Memory를 사용하거나 Memory Leak를 유발하는 로직을 찾아내어 수정한다.
• Heap 모니터링 방법 - Heap Dump
  • VisualVM, MAT 등의 툴을 사용할 수도 있으나, IntellJ에서 VM option을 추가하면 자동으로 힙 덤프를 떠주는 기능을 사용했다.
  • 문제가 발생한 동영상 파일 업로드 API의 힙 덤프를 확인해본 결과 byte[] 배열이 과도하게 생성이 됐는데, byte[]는 금방 쓰고, 버리는 사용 빈도 수가 높기 때문에 GC가 자주 작동하게 되고, 성능에 영향을 준다. 로직의 문제점은 동영상 파일의 크기를 구하는 데서 사용한 라이브러리 내부를 뜯어보니, ByteArrayOutputStream을 사용하면서 모든 byte[] 배열을 메모리 안에 저장해두고 있었던 것이다. 따라서 해당 API로 굳이 MultipartFile을 byte array로 변경하고-> 그 배열의 크기를 리턴하는 대신 file의 크기를 바로 리턴하도록 사용하는 MulipartFile의 getSize() 메소드를 사용하도록 변경하였다.
  • https://linked2ev.github.io/java/2021/05/16/Java-FILE-(6)-ByteArrayInputStream-%EA%B3%BC-ByteArrayOutputStream-%EB%B0%94%EC%9D%B4%ED%8A%B8-%EB%B0%B0%EC%97%B4-%EC%8A%A4%ED%8A%B8%EB%A6%BC/
  • https://stackoverflow.com/questions/7255232/java-memory-efficient-bytearrayoutputstream
  • 뭐 대단한 로직을 수정한 것은 아니지만, 메모리 관리 또한 API 성능에 지대한 영향을 미칠 수 있다는 점을 깨닫고 한 번 메모리 영역에 대한 공부도 해보고 있는 중이다! 자바는 어렵다~

 

 

 

🙏 참고자료

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

JVM 메모리 구조란? (JAVA)

https://mangkyu.tistory.com/118

[Java] Garbage Collection(가비지 컬렉션)의 개념 및 동작 원리 (1/2)

https://jeong-pro.tistory.com/148

JVM 구조와 자바 런타임 메모리 구조 (자바 애플리케이션이 실행될 때 JVM에서 일어나는 일, 과정

https://blog.wanzargen.me/16

JAVA :: 자바의 메모리 구조 - 1. 메소드 영역(Method Area)