JVM Runtime GC Thread
3줄 요약
- JVM은 class loading, bytecode 실행, JIT, heap, GC, thread, native interface를 관리하는 Java 서버의 실행 엔진이다.
- GC와 JIT는 성능을 높이지만 pause, warm-up, CPU 사용, memory footprint 같은 운영 신호를 만든다.
- JFR, JMX, Actuator, jcmd를 연결하면 JVM 내부 상태를 장애 분석 지표로 바꿀 수 있다.
핵심 정리
- Class loading은 class를 읽고 검증하고 runtime에 연결하는 과정이며 startup과 dynamic loading 이슈와 연결된다.
- JIT는 자주 실행되는 코드를 native code로 최적화하지만 warm-up과 deoptimization 가능성이 있다.
- JVM memory는 heap, metaspace, code cache, thread stack, direct/native memory로 나뉜다.
- GC pause는 stop-the-world 구간을 만들 수 있으며 latency SLO와 함께 봐야 한다.
- JVM option은 성능 스위치가 아니라 운영 계약이므로 container memory, GC 종류, dump, log 정책과 함께 관리한다.
헷갈리는 지점
- JVM option을 많이 주면 성능이 좋아진다고 생각하기 쉽다.
- 옵션은 목적과 근거가 있어야 하며 잘못된 heap 크기나 GC 선택은 장애를 키운다.
- 기본값과 실제 지표를 먼저 확인해야 한다.
- GC log만 보면 모든 memory 문제를 알 수 있다고 오해하기 쉽다.
- GC log는 heap 회수와 pause 중심이다.
- Native memory, thread stack, direct buffer, RSS는 다른 지표가 필요하다.
- JFR은 운영에서 쓰기 위험한 도구라고만 보기 쉽다.
- 짧은 profiling 설정은 낮은 부담으로 유용한 증거를 줄 수 있다.
- 단, duration과 파일 크기, 저장 위치는 통제해야 한다.
확인 질문
- JIT를 운영에서 고려해야 하는 이유는 무엇인가?
- Warm-up과 최적화 상태에 따라 CPU 사용과 latency가 달라질 수 있기 때문이다.
- GC pause를 API 장애와 연결하려면 무엇을 봐야 하는가?
- GC pause 시간대와 latency spike, CPU, allocation rate, heap after GC 추세를 맞춰 봐야 한다.
- JVM option 변경 전 확인할 것은 무엇인가?
- 현재 VM.flags, heap/RSS, GC log, container limit, SLO, 재현 조건이다.