메모리 모델과 관리

자바 메모리 모델

공유 멀티프로세서 아키텍처
- CPU 코어마다 L1, L2 캐시가 존재한다.
- CPU 캐시에 존재하는 내용과 RAM에 존재하는 내용이 동기화되지 않는 상태가 존재할 수 있다.

final 필드는 별도의 동기화 처리가 필요 없기 때문에 세이프한 불변 객체 구현을 지원하며 JIT 컴파일러는 레지스터에 최종 캐시 값을 유지할 수 있다.
스레드 간 레이스 컨디션일 때에도 불변이다.

static field 객체가 사용되지 않는 경우 누수 발생 가능
사용한 리소스를 해제하지 않아 발생할 수 있으므로, try-with-resourcse 혹은 finally 블록을 통해 리소스 해제하도록 한다.
equals, hashcode 메서드를 재정의하지 않으면 불필요한 참조가 발생할 수 있다.
아우터 클래스를 참조하는 이너 클래스가 있을 때 이너 클래스를 사용하려면 항상 아우터클래스를 참조해야 한다. 이때 아우터 클래스를 사용하지 않는다면 누수 발생 가능
- 아우터 클래스를 참조하지 않는 경우 이너클래스를 static클래스로 구현하면 바깥 클래스에 대한 참조를 가지지 않아 메모리 누수가 발생하지 않는다.
ThreadLocal 클래스를 사용해 데이터를 스레드별로 사용할 때 명시적으로 값 제거해주지 않으면 참조가 유지되어 누수 발생 가능
- ThreadLocal.remove() 메서드 호출해 명시적으로 참조 제거 필요

VisualVM, YourKit 등과 같은 프로파일러를 활용한 모니터링 또는 `-verbose:gc` 옵션 사용으로 GC 모니터링을 통해 예방할 수 있다.
참조 객체(java.lang.ref 패키지)를 통해 메모리 누수를 방지할 수 있다.
벤치마크를 통해 성능 모니터링을 미리 진행해 예방할 수 있다.
코드리뷰도 중요하다.

특정 순간에 JVM 메모리 상에 있는 모든 객체에 대한 스냅샷을 떠 확인할 수 있다.
앱 실행 시 힙 메모리 사용량 분석 가능 
메모리 누수, GC 이슈 등을 해결하는 데 활용
jmap, VisualVM을 사용하거나 java -XX:+HeapDumpOnOutOfMemoryError <ClassName> 설정으로 OutOfMemoryError 발생 시 자동으로 힙 덤프를 수행할 수 있다.

APM
- 앱의 성능, 가용성 등을 모니터링 또는 관리하는 것
- 프로파일링보다 한단계 높은 어플리케이션 수준에서 성능을 모니터링, 분석
프로파일링
- 메모리 사용량, 시간복잡도, 특정 명령의 호출 빈도 등을 측정해 분석하는 것
- 런타임 동안에 어떤 일이 발생하는 지에 대한 정보를 제공
- APM과 달리 개발자의 코드 레벨에서 성능을 최적화하는 데에 유용
- Newrelic, VisualVM 등의 툴이 있다

Last updated 5 months ago