주제: JVM, GC가 뭐고 — 왜 자바로 개발하냐?
JVM
Java Virual Machine은 자바 바이트코드(.class)를 운영체제/CPU와 상관없이 실행해 주는 가상 컴퓨터.
내 노트북이든 EC2리눅스든 같은 .jar를 돌릴 수 있게 해 주는 번역기+실행기
자바 프로그램을 실행시키는 가상 컴퓨터
JVM이 하는 일
-
바이트코드 실행
-
자바 코드를 .java → javac 컴파일 → .class 바이트코드
-
JVM은 이 바이트코드를 읽어서 OS/CPU가 이해할 수 있는 명령으로 변환
-
-
메모리 관리
-
JVM은 프로그램 실행에 필요한 메모리를 나눠서 관리
-
Heap 영역: 객체 저장
-
Stack 영역: 메서드 호출, 지역변수 저장
-
Method 영역: 클래스 코드, 메서드, 상수 저장
-
-
MyCode.java ──(javac 컴파일)──> MyCode.class(바이트코드)
↓
JVM이 읽음
[클래스 로더] → [실행 엔진(인터프리터+JIT)] → [OS/CPU]
│
[메모리 관리(GC)]
JVM 안의 핵심 부품(이름 정도만 기억하자)
클래스 로더
.class 파일을 JVM메모리로 적재
실행엔진
- 인터프리터: 바이트코드를 한 줄씩 읽어 즉시 싱행(빠른 시작)
- JIP 컴파일러: 자주 실행되는 코드를 기계어로 바꿔 캐시해 둠(따듯해질수록 빨리 사라짐)
런타임 메모리 구역
- 스택(stack): 메서드 호출/ 지역변수(원시타입 int, long등). 매우 빠르지만 짧게 씀
- 너무 깊게 재귀 돌리면 stackOverFlowError
- 힙(Heep): new로 만든 객체들이 오래 사는 공간, GC가 치워줌
- 다 차면 OutOfMemoryError: Java heap space - 메타스페이스(Metaspace): 클래스의 설계도 정보
- 이게 차면 OutOfMemoryError: Metaspace
포인트
- 스택=짧고 빠름
- 힙=객체가 모여 사는 곳
- GC=힙 청소부
GC(가비지 컬렉션)
GC는 더 이상 쓰지 않는 객체(어느 곳에서도 참조하지 않음)를 자동으로 찾아서 힙에서 채워주는 기능
메모리 안정성, 개발속도가 향상된다.
기본 동작 원리(진짜 핵심만)
-
“GC 루트(실행 중인 스레드 스택, static 변수 등)”에서 닿을 수 없는 객체는 쓰레기다 → 청소
-
청소할 때는 잠깐 stop-the-world(모든 스레드 멈춤) 구간이 꼭 생김
-
세대별(Generational) GC:
Young(금방 생긴 객체; 금방 죽음) / Old(오래 사는 객체)로 나눠 효율적으로 청소- Minor GC: Young만 빠르게 치움
- Major/Full GC: Old 포함 큰 청소 (보통 더 무거움)
GC 종류(이름만 익히기)
-
Serial/Parallel: 옛날 방식, 단순/스루풋 지향
-
G1 GC: 요즘 기본값(자바 9+ 핫스팟)—적당히 빠르고 멈춤시간 짧게 만들려고 고안됨
-
ZGC / Shenandoah: 아주 짧은 멈춤시간이 필요할 때(고급/특수 상황)
현업 기본값: 그냥 G1 쓰고 힙 크기만 맞추면 90%는 충분합니다.
왜 자바로 프로그래밍할까?
장점
-
한 번 빌드하면 어디서나 실행(JVM 덕분) — 윈도우/리눅스/ECS/EC2 가리지 않음
-
GC로 메모리 안전성 확보 — 메모리 해제 실수로 뻗을 일이 적음
-
성능 안정성 — JIT로 뜨거워질수록 빠름, 서버에서 충분히 고성능
-
거대한 생태계 — Spring Boot, Maven/Gradle, 라이브러리, 예제가 넘침
-
채용/학습 자료 풍부 — 팀 꾸리기, 유지보수, 문서, 커뮤니티가 매우 강함
-
장기 지원(LTS) — JDK 17/21 같은 장기 버전으로 안정적 운영
단점
-
GC 멈춤이 아예 0은 아님(튜닝으로 줄임)
-
메모리 사용량이 비교적 큼
-
“처음 기동”이 스크립트 언어보다 느릴 수 있음(하지만 서버는 오래 떠 있음)
결론: 서비스를 오래, 안정적으로, 많은 사람이 협업해야 한다? → 자바/스프링은 매우 안전한 선택.
