Garbage Collection

1. Garbage Collection 이란

                                                                                                                                                    

프로그램이 사용하지 않게 된 메모리(객체)를 자동으로 찾아서 회수해 주는 메모리 관리 기능

 

자바처럼 객체를 new로 계속 만들면 힙(Heap)에 쌓이는데,
그 객체를 더 이상 참조(사용)하지 않으면 메모리를 계속 차지합니다.
GC는 이런 “도달 불가능(unreachable)” 객체를 정리해서 힙 공간을 회수합니다.

 

장점

• 메모리 해제 실수 방지(누수, 이중 해제 등)
• 개발 생산성 ↑

단점

• GC가 돌 때 **일시 정지(STW: Stop-The-World)**가 발생할 수 있어 성능/지연에 영향
• “GC가 알아서 해주겠지”로 설계하면 참조를 오래 잡고 있어서 메모리 사용량이 커질 수 있음

 

해당 개념이 실무에서 없다면

1) 진짜로 GC가 없는 환경이라면 (수동 메모리 관리)

GC가 없으면 “자동 청소”가 없어서, 아래를 개발자가 직접 책임져야 합니다.

• 메모리 누수(Leak): 할당하고 해제를 안 하면 점점 RAM 먹고 죽음
• 이중 해제(Double free): 같은 메모리를 두 번 해제 → 크래시/취약점
• 댕글링 포인터(Dangling pointer): 해제한 메모리를 다시 사용 → 미정의 동작
• Use-after-free: 보안 이슈로도 이어짐
• 소유권(누가 해제 책임?) 설계가 코드 전반의 핵심이 됨

2) GC가 있지만, “없다고 생각하고” 개발한다면 (자바/코틀린/Go 등)

GC가 자동으로 해주긴 하지만, 개념을 모르면 실무에서 자주 터지는 게 있어요.

• OOM(OutOfMemoryError): 참조를 오래 잡아두면 GC가 못 치움
  예: static 컬렉션에 계속 쌓기, 캐시 무한 성장, 세션/리스너 미해제
• 지연/끊김(Stop-the-world): 트래픽 많은 서버에서 GC가 길어지면 응답이 튐
  → “가끔 2~5초 멈춤” 같은 장애 원인
• 성능 저하: 객체를 너무 많이/자주 만들면 GC가 바빠짐
  예: 문자열/컬렉션 남발, 불필요한 박싱, 큰 객체 반복 생성
• 리소스 누수: 메모리 말고도
  파일/소켓/DB커넥션 같은 건 GC가 “즉시” 닫아주지 않음
  → try-with-resources 같은 걸로 명시적으로 닫아야 함

즉

• GC가 없으면: 메모리 생명주기 관리가 개발의 핵심 리스크가 됨
• GC가 있는데 개념을 모르면: OOM/지연/성능/리소스 누수로 실무 장애가 나기 쉬움