문제

어떤 요청·batch·입력에서 OOME가 발생했고 기대한 처리량과 실제 종료 상태가 무엇인지 적습니다. 오류 직전 재시작이나 설정 변경이 있었다면 함께 기록하되, OOME라는 이름만으로 memory leak을 결론 내리지 않습니다.

먼저 확인할 사실

OutOfMemoryError는 Java heap 부족뿐 아니라 Metaspace·direct buffer 같은 메모리 자원이나 native allocation 실패에서도 발생할 수 있으므로, detail message를 실제로 고갈된 자원과 연결해 확인해야 합니다.

확인 순서

먼저 OOME의 전체 detail message, JDK/JVM version, 실제 실행 옵션, container·OS 제한과 발생 시각을 확보합니다. Java heap space라면 GC 뒤 live set과 객체 보유 경로를, Metaspace라면 class 수와 class loader 수명을, Direct buffer memory라면 direct buffer 사용과 상한을 봅니다. unable to create native thread라면 thread dump, thread 수, stack 크기와 OS process·thread 제한을 확인합니다. 현재 가설과 직접 연결되지 않는 지표는 한꺼번에 모으지 않습니다.

수정과 검증

오래 남는 참조, 무제한 queue·입력, class loader 수명, direct buffer 정리, 과도한 thread 생성처럼 증거로 확인된 경계만 수정합니다. heap을 무작정 늘리거나 process를 재시작해 오류 시점이 늦어진 것을 해결로 보지 않습니다. 같은 실패 workload에서 OOME가 사라지고 처리량·지연·GC 뒤 live set과 전체 RSS가 허용 범위에 머무는지 확인합니다.

공식 문서와 적용 범위

현재 JDK/JVM version, 실행 옵션, collector, container 제한과 실제 memory 사용 패턴에서 다시 확인합니다.