JVM 메모리 구조 - 힙과 네이티브 메모리

Java 개발을 하다 보면 OutOfMemoryError를 한 번쯤 만나게 됩니다. 이 에러를 만났을 때 "메모리를 늘려야 하나?", "코드에 문제가 있나?"를 판단하려면 JVM이 메모리를 어떻게 관리하는지 알아야 합니다.

이 글을 쓰게 된 계기도 실무에서 만난 두 번의 메모리 장애였습니다.

첫 번째는 엑셀 파일 업로드/다운로드 기능에서 발생한 OutOfMemoryError였습니다. 수천 행의 엑셀 데이터를 한 번에 메모리에 올리다 보니 힙 메모리가 한계에 도달했고, 서버가 응답을 멈췄습니다. 전형적인 힙 메모리 문제였습니다.

두 번째는 더 찾기 어려운 문제였습니다. 외부 API를 호출하는 WebClient에서 매 요청마다 새로운 커넥션 풀과 SSL 컨텍스트를 생성하고 있었습니다. 힙 사용량은 정상이었지만, 서버의 실제 메모리(RES)는 계속 증가하다가 결국 OS가 프로세스를 강제 종료했습니다. 네이티브 메모리 누수였습니다.

두 문제 모두 JVM의 메모리 구조를 이해했다면 더 빠르게 원인을 찾을 수 있었을 것입니다. 이 글은 Java 메모리 시리즈 3편 중 첫 번째로, JVM의 메모리 구조를 초보자 눈높이에서 다룹니다.

메모리란 무엇인가

프로그램이 실행되려면 데이터를 어딘가에 저장해야 합니다. 그 "어딘가"가 바로 메모리(RAM)입니다.

Java 프로그램도 마찬가지입니다. 객체를 생성하고, 데이터를 처리하고, 네트워크 통신을 하려면 메모리가 필요합니다. Java는 이 메모리를 크게 두 가지 영역으로 나눠서 사용합니다.

JVM 메모리 구조 전체 그림

운영체제(OS)가 JVM 프로세스에 메모리를 할당하면, JVM은 그 메모리를 용도에 따라 나눠서 관리합니다.

크게 두 영역으로 나뉩니다. 힙 메모리와 네이티브 메모리입니다.

힙 메모리 상세

힙 메모리란?

new 키워드로 생성하는 모든 Java 객체가 저장되는 공간입니다. JVM이 자동으로 관리하며, 더 이상 사용하지 않는 객체는 가비지 컬렉터(GC)가 회수합니다.

// 이 객체들은 모두 힙 메모리에 저장됩니다
String name = new String("서버");       // 힙에 String 객체 생성
List<String> list = new ArrayList<>();  // 힙에 ArrayList 객체 생성
ServerDTO dto = new ServerDTO();        // 힙에 DTO 객체 생성

앞서 언급한 엑셀 파일 처리 중 발생한 OOM도 이 힙 영역의 문제였습니다. 수천 행의 데이터를 List<Row>로 한 번에 읽어들이면서 힙이 가득 찬 것입니다.

세대별 구조

JVM은 힙을 세대(Generation)로 나눕니다. "대부분의 객체는 금방 사라진다"는 관찰에 기반한 설계입니다.

이 가설에 따라, JVM은 "새로 만들어진 객체"와 "오래 살아남은 객체"를 분리해서 관리합니다.

객체의 생애주기

Java 객체가 생성부터 소멸까지 거치는 과정을 단계별로 살펴보겠습니다.

1단계: 객체 탄생 (Eden)

ServerDTO dto = new ServerDTO();  // Eden 영역에 생성됩니다

모든 새 객체는 Young Generation의 Eden 영역에 저장됩니다.

2단계: Minor GC 발생 — 살아남은 객체만 이동

Eden 영역이 가득 차면 Minor GC가 발생합니다. 이때 참조가 남아있는 객체만 Survivor 영역으로 이동하고, 참조가 없는 객체는 삭제됩니다.

// Minor GC 시점의 판단
ServerDTO dto = new ServerDTO();  // ← 변수가 참조 중 → 생존
new ServerDTO();                   // ← 아무도 참조하지 않음 → 삭제

살아남은 객체는 Survivor 영역으로 옮겨지면서 나이(age)가 1 증가합니다.

3단계: GC를 반복하며 살아남기

Minor GC가 반복될 때마다, 살아남은 객체는 Survivor 0 → Survivor 1 → Survivor 0... 을 오가며 나이가 계속 증가합니다.

4단계: Old Generation으로 승격

나이가 임계값(기본 15)에 도달하면 Old Generation으로 승격됩니다. 캐시 데이터, 싱글톤 빈, 커넥션 풀 등 오래 사용되는 객체들이 여기에 위치합니다.

5단계: Major GC 또는 Full GC

Old 영역이 가득 차면 Major GC가 발생합니다. 전체 힙을 스캔하는 Full GC는 가장 오래 걸리며, 이때 Stop-The-World가 발생합니다.

GC 종류 비교

힙 메모리 설정

JVM 실행 시 옵션으로 힙 크기를 지정할 수 있습니다.

java -Xms512m   # 초기 힙 크기 (시작할 때 확보)
     -Xmx2g     # 최대 힙 크기 (이 이상 사용 불가)
     -jar app.jar

네이티브 메모리 상세

네이티브 메모리란?

JVM이 아닌 운영체제(OS)에서 직접 할당받는 메모리 영역입니다. GC가 관리하지 않으므로, 사용 후 반드시 명시적으로 해제해야 합니다.

왜 네이티브 메모리를 사용하는가?

네트워크 통신을 예로 들어보겠습니다.

힙 버퍼를 사용하면 데이터를 보내기 위해 힙에서 임시 Direct 버퍼로 복사하고, 다시 OS 커널로 전달해야 합니다. 총 2회 복사가 발생합니다.

Direct 버퍼를 사용하면 네이티브 메모리에서 바로 OS 커널로 전달됩니다. 1회 복사로 끝납니다.

네트워크 I/O, 파일 I/O처럼 대량의 바이트를 처리하는 작업에서 이 차이가 큽니다.

앞서 언급한 WebClient 문제도 이 영역에서 발생했습니다. 매 요청마다 새로운 HttpClient와 SslContext를 생성하면, 그때마다 네이티브 메모리에 SSL 버퍼와 커넥션 풀이 할당됩니다. 힙에서는 래퍼 객체만 보이기 때문에 힙 모니터링만으로는 문제를 발견할 수 없었고, OS의 RSS(실제 메모리 사용량)가 계속 늘어나는 것을 보고서야 원인을 추적할 수 있었습니다.

네이티브 메모리를 사용하는 대표 사례

Direct ByteBuffer 예시

// 힙 버퍼: JVM 힙에 할당 → GC가 관리
ByteBuffer heapBuffer = ByteBuffer.allocate(1024);
 
// Direct 버퍼: 네이티브 메모리에 할당 → GC가 직접 관리하지 않음
ByteBuffer directBuffer = ByteBuffer.allocateDirect(1024);

네이티브 메모리 설정

정리

Java에서 new로 만든 객체는 GC가 알아서 치워주지만, 네이티브 메모리는 직접 관리해야 합니다. 다음 편에서는 이 두 영역에서 메모리 누수가 발생하는 패턴과 해결법을 다룹니다.