[자바] 스택이 충분히 크면 힙은 없어도 될까?

※ 이 글은 화이트보드 스케치를 바탕으로, 이해를 돕기 위해 제 관점에서 재구성한 내용입니다.

 

Intro

개발하면서 문득 이런 생각이 들었다.

 

"스택 메모리를 무한히 쓸 수 있다면, 굳이 힙이 필요할까?"

 

GC도 안 돌리고, 다 스택에 넣고 쓰면
성능도 빠르고 깔끔하지 않을까 싶었다.

 

그런데 공부해보니까, 그렇게 단순한 얘기가 아니었다.

 

 

스택과 힙의 역할은 명확히 다르다

자바에서 스택은 메서드 호출 시 생기는
지역 변수, 매개변수 등을 저장하는 공간이다.

 

스레드마다 따로 존재하고,
메서드가 끝나면 스택 프레임도 바로 날아간다.

 

반면 힙은 new로 만든 객체들이 저장되는 공간이다.
객체가 참조되지 않으면 GC가 알아서 지운다.

 

즉, 프로그램이 돌아가는 동안
계속 살아있을 수도 있는 공간이다.

 

 

스택만 커지면 힙 없이도 될까?

이론적으로는 가능할 수도 있다.

모든 데이터를 지역 변수로 만들고,
공유도 안 하고,  수명도 짧다면.

 

그런데 현실은 다르다.

• 메서드가 끝나면 스택 프레임도 사라진다.
  오래 살아야 하는 데이터는 못 쓴다.
• 스택은 스레드마다 따로다.
  다른 스레드에서 접근하려면 결국 힙에 올려야 한다.
• GC가 없다.
  복잡한 참조 구조나 동적 메모리 제어가 불가능하다.

 

결론은 하나다.

스택이 아무리 커져도, 힙은 필요하다.

 

 

싱글톤 객체는 왜 괜찮은 걸까?

스프링을 기준으로 보면,

대부분의 서비스 클래스들은 싱글톤으로 관리된다.

 

그럼 여러 스레드가 동시에 이 객체를 호출해도 괜찮은 걸까?

 

공유되는 객체니까 위험해 보이지만,

생각보다 문제 없다.

 

왜냐면 객체 자체는 힙에 있지만
메서드 안에서 쓰는 변수들은 스택에 따로 생긴다.

 

즉, 서로 충돌 안 한다. 안전하다.

 

다만, 그 객체가 내부 상태를 갖고 있고

그걸 여러 스레드가 동시에 바꾼다면?

 

동기화 처리는 해줘야 한다.

 

 

그럼 GC는 언제 객체를 지우는 걸까?

예를 들어 메서드 안에서 만든 객체는

그 메서드가 끝나면 참조가 끊긴다.

 

GC 입장에서는 "이제 더 이상 접근 불가"한 객체다.

삭제 대상이 되는 거다.

 

근데 그게 바로 지워진다는 뜻은 아니다.

 

GC는 메모리 상황을 보고

필요할 때 알아서 작동한다.

 

지워질 수는 있지만,

언제 지워질지는 GC 맘이다.

 

 

그럼 static은 어떤 역할?

`static` 변수는 클래스가 로딩될 때

메서드 영역에 올라가고, 프로그램 종료 시까지 살아있다.

 

GC 대상도 아니고, 어디서든 접근 가능하다.

 

상수나 공통 설정값 저장할 땐 좋다.

 

근데 객체를 static으로 저장해서

전역처럼 써버리면?

 

의존성 관리가 꼬인다.

스프링의 DI 철학과도 안 맞는다.

 

 

마무리

스택이 아무리 커져도

힙을 완전히 대체하긴 어렵다.

 

스택은 메서드 실행에 최적화된 공간이고,

힙은 장기적으로 객체를 유지할 수 있는 공간이다.

 

GC, 싱글톤, IoC 컨테이너까지 엮어서 생각해보면

 

자바의 메모리 구조는 단순히
"어디에 저장하느냐" 문제를 넘어서

 

• "언제까지 살아야 하느냐"
• "누가 관리하느냐"
• "어떻게 공유하느냐"

 

까지 고려된 설계라는 걸 알게 됐다.

 

 

참고 자료:

Oracle Offical Docs – Understanding Memory Management

Understanding Memory Management

 

Jenkov.com – “Java Memory Model”

Java Memory Model