어디에 사용할까
for문 객체 대량 생성에서 바꿀 결과와 유지할 기존 동작을 한 문장씩 적습니다. loop 안 단기 객체는 GC가 회수할 수 있지만 allocation rate가 높으면 GC CPU와 pause가 늘 수 있어 escape·JIT 최적화 뒤 실제 할당을 측정해야 합니다.
준비할 내용
메모리 문제는 한 시점의 사용률이 아니라 시간에 따른 할당률, 작업 종료 뒤 기준선과 참조 경로를 봐야 합니다. heap과 native·buffer·파일 캐시를 분리하면 제한을 늘려야 하는지, 참조를 끊어야 하는지가 달라집니다. 현재 version의 공식 문서와 실제 설정을 확인하고 대표·경계·실패 사례를 준비합니다. GC log, JFR, thread dump, class histogram, heap dump와 OS RSS를 같은 사건 기준으로 수집한다.
| 순서 | 할 일 |
|---|---|
| 1 | 수정 전 결과와 되돌릴 기준 저장 |
| 2 | 핵심 사실과 맞닿은 한 곳만 변경 |
| 3 | 같은 입력으로 수정 전후 비교 |
구현 흐름과 마무리
반복 횟수, 컬렉션, queue와 cache에 상한을 두고 상태를 만든 소유자가 listener·timer·handle까지 정리하게 합니다. 메모리 제한 상향은 원인 수정 뒤의 안전 여유로만 사용합니다. 객체 보유 경로와 lock 소유자를 증거로 확정하고 pool·queue·heap 제한을 전체 프로세스 메모리 예산에 맞춘다. 예상과 다르면 변경을 더 얹지 말고 처음 달라진 값으로 돌아갑니다. 장시간 부하에서 GC 후 live-set, allocation rate, pause, p99, thread 수와 native memory를 비교한다. 동일 부하를 충분히 오래 유지한 뒤 GC 이후 live set과 RSS 기준선, allocation rate, 처리량과 pause가 함께 안정되는지 확인합니다.
공식 문서와 적용 범위
문서의 기본값과 동작은 version에 따라 달라질 수 있습니다. 현재 JDK/JVM version, 실행 옵션, collector, runtime 환경과 실제 memory 사용 패턴에서 다시 확인합니다.