조용한 개발 노트

2편에서는 JVM 런타임 데이터 영역을 통해 코드가 실행되기 위한 무대를 살펴봤습니다.이번 편에서는 그 무대 위에서 코드가 실제로 어떻게 실행되는지, 즉 JVM의 실행 모델(Execution Model)을 다룹니다.“JVM은 바이트코드를 어떻게 실행할까?”이 질문에 대한 답을 이해하면, 왜 JVM에 웜업 시간이 존재하는지, 왜 처음 요청이 느린지를 자연스럽게 설명할 수 있습니다.JVM은 처음부터 기계어로 실행하지 않는다Java 코드는 컴파일되면 CPU가 바로 실행할 수 있는 기계어가 아니라 바이트코드(Bytecode)가 됩니다.JVM은 이 바이트코드를 실행하기 위해 두 가지 방식을 함께 사용합니다.인터프리터(Interpreter)JIT 컴파일러(Just-In-Time Compiler)이 구조는 우연이 아..

Kotlin, Spring, Spring Boot, JPA, Transaction까지 공식 문서를 따라가다 보면 결국 이런 질문으로 돌아오게 됩니다.“이 모든 코드는 어디에서, 어떻게 실행되고 있는가?”그 답이 바로 JVM(Java Virtual Machine)입니다. 이번 시리즈는 막연한 JVM 설명이 아니라, 공식 문서가 정의한 JVM을 기준으로 우리가 운영하고 튜닝하는 JVM을 이해하는 것을 목표로 합니다.JVM은 “자바 실행기”가 아니다보통 JVM을 이렇게 요약합니다.“자바 바이트코드를 실행해주는 가상 머신”하지만 공식 문서 기준에서 JVM은 단순 실행기가 아닙니다. JVM은 다음을 명확히 규정합니다.어떤 메모리 구조를 가져야 하는가클래스는 어떤 절차로 로딩되는가스레드와 동기화는 어떤 규칙을 따라..

로 감쌈-->Kubernetes 환경에서 Spring Boot 애플리케이션을 운영하다 보면, Pod가 readiness 상태가 된 직후 트래픽이 유입되었을 때 초기 몇 초~수십 초 동안 API 응답이 유난히 느렸다가 이후 안정화되는 현상을 종종 겪습니다.처음엔 “readiness가 통과했는데 왜 느리지?”라는 의문이 생기죠. 결론부터 말하면, readiness는 ‘프로세스가 요청을 받을 준비가 됐다’는 신호일 뿐, 우리가 기대하는 “실전 트래픽을 안정적으로 처리할 준비 완료”를 완전히 보장하지는 않습니다.1. 현상: readiness 직후 첫 호출들이 유독 느리고, 시간이 지나면 안정화대체로 관측되는 패턴은 다음과 같습니다.Pod 재배포/재시작 → 애플리케이션 기동 → readiness probe 통..