좋은 자바 코드는 JVM을 신뢰하되, 감시한다

JVM이 최적화/GC/JIT 같은 일을 잘 해주긴 한다.
근데 그건 확률 게임이라, 운영 관측 없으면 바로 사고 난다.

즉 신뢰 = 기본값, 감시 = 필수 통제장치.

 

1) “신뢰한다”의 의미

자바에서 JVM이 잘해주는 영역이 있습니다.

• JIT 컴파일로 핫코드 최적화
• Escape Analysis / Scalar Replacement 같은 최적화
• GC로 메모리 회수
• 스레드/락 관련 최적화(편향 락 등, 버전에 따라)

그래서 “C처럼 모든 걸 수동으로 최적화”하려고 달려들면 대개 역효과가 납니다.

---

2) “감시한다”의 의미

JVM이 잘해주긴 해도, 운영에서는 이런 게 실제로 터집니다.

• 트래픽 피크에 STW 증가
• 특정 API에서 Humongous allocation
• 캐시/컬렉션 누적으로 Old 영역 고착
• JIT 워밍업 전후로 latency 패턴 변화
• 락 경합/스레드 폭증으로 TPS 급락

👉 이런 건 “코드만 보고” 못 잡습니다. 측정/관측이 답.

---

3) 그래서 “좋은 자바 코드”의 실무 기준

✅ JVM을 신뢰하는 코드

• 불필요한 마이크로 최적화 안 함
• 명확하고 읽히는 코드(추상화 과다 금지)
• 객체 수명/생성량을 의식(특히 루프/대량처리)
• 스트리밍/페이징/배치로 “한 번에 다” 방지

✅ JVM을 감시하는 운영 습관

관측 포인트 5개만 잡아도 급이 달라집니다.

1. GC 로그 (최소한 켜기)

• pause 시간, 빈도, 원인(Allocation Failure, Humongous 등)

1. Heap 사용률

• Old가 계속 우상향이면 설계/누수 의심

1. Latency p95/p99

• 평균 말고 꼬리 지연이 GC/STW에 직결

1. Thread/Lock

• 스레드 수 폭증, blocked 증가면 동시성 병목

1. CPU/Load

• CPU 낮은데 느리면 GC/STW/IO 대기 의심

---

4) 문장을 실무 언어로 번역하면

“JVM이 알아서 잘해줄 거라 가정하고 설계하되,
지표로 ‘진짜 잘하고 있는지’ 상시 확인하라.”

---

5) 르무엘님 작업 맥락(SI/스프링)에서 특히 중요한 케이스

• 엑셀/대량 다운로드/대량 JSON → Humongous + STW
• 공통모듈/AOP 과다 → 원인 추적 어려움 → 감시 없으면 망함
• 싱글톤 상태 공유 → 동시성 이슈 → 재현보다 관측