검증할 결과

수정 전 OOME를 만들었던 입력과 부하를 그대로 사용하고, 기존 정상 workload도 함께 실행합니다. 오류가 한 번 사라진 것보다 같은 처리량을 유지하면서 해당 resource가 안정되는지가 기준입니다.

원인별로 볼 값

OutOfMemoryError는 Java heap 부족뿐 아니라 Metaspace·direct buffer 같은 메모리 자원이나 native allocation 실패에서도 발생할 수 있으므로, detail message를 실제로 고갈된 자원과 연결해 확인해야 합니다. heap 문제는 GC 뒤 live set·allocation rate와 객체 보유 경로를, Metaspace 문제는 loaded class와 class loader 수명을, direct memory 문제는 direct buffer와 전체 RSS를 봅니다. thread 생성 실패는 thread 수·stack 크기·OS 제한을 확인합니다.

통과 기준

충분한 반복 시간 동안 OOME가 재발하지 않고 memory 사용이 정한 상한 안에서 안정돼야 합니다. 단순히 -Xmx를 늘려 실패 시점만 늦춘 경우나 처리량이 크게 줄어 allocation 자체가 사라진 경우는 같은 조건의 해결로 보지 않습니다.

남겨 둘 회귀 점검

가장 작은 실패 입력, runtime 옵션과 기대하는 memory 상한을 자동 test 또는 부하 점검으로 남깁니다. JDK, collector, container limit이나 workload가 바뀌면 같은 기준을 다시 측정합니다.

공식 문서와 적용 범위

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