The Nirsa Way

[Java GC] Old Generation은 어떻게 수집될까: Parallel GC와 Full GC, 할당 성능이전 포스팅에서는 Young Generation에서 객체가 어떻게 할당되고, Young GC에서 살아남은 객체가 Survivor Space를 거쳐 Old Generation으로 승격되는 과정을 살펴봤습니다.이번 글에서는 그다음 단계인 Old Generation을 다룹니다.Old Generation에는 Young GC에서 여러 번 살아남았거나, Survivor Space에 보관하기 어려워 승격된 객체가 주로 저장됩니다. 이러한 객체는 Young Generation의 객체보다 오래 살아 있을 가능성이 높으므로, Young GC와 같은 복사 방식만으로 설명하기 어렵습니다.또한 Old Generati..

Young Generation의 객체 할당과 수집: TLAB과 Survivor Space의 복사 수집새로운 객체는 Young Generation 안에서 실제로 어떻게 만들어질까요? 여러 스레드가 동시에 객체를 생성하면 같은 메모리 공간을 두고 충돌하지는 않을까요?또한 Young GC가 발생했을 때 살아남은 객체는 어디로 이동하며, Survivor 영역을 두 개 사용하는 이유는 무엇일까요?이 질문을 이해하려면 다음 두 가지 구조를 함께 봐야 합니다.TLAB : 여러 스레드가 객체를 빠르게 할당하기 위한 구조Survivor Space의 복사 수집 : Young GC에서 살아남은 객체를 다른 Survivor Space나 Old Generation으로 이동시키는 방식먼저 정리하자면 아래와 같습니다.대부분의 새 ..

객체 수명과 약한 세대 가설: 힙을 세대로 나누는 이유자바의 가비지 컬렉션을 공부하다 보면 다음과 같은 용어가 반복해서 등장합니다.Eden 영역Survivor 영역Old GenerationMinor GC객체 승격힙을 여러 영역으로 나누는 이유는 객체마다 살아남는 시간이 다르기 때문입니다.어떤 객체는 생성된 직후 잠깐 사용되고 사라집니다. 반면 애플리케이션이 실행되는 동안 계속 참조되면서 오랫동안 살아남는 객체도 있습니다.public void process() { String message = "임시 메시지"; User user = userRepository.findById(1L);}위 코드에서 message처럼 메서드 내부에서 잠깐 사용하는 객체는 비교적 빠르게 필요 없어질 수 있습니다.반면 ..

핫스팟의 객체 표현과 가비지 컬렉션 루트가비지 컬렉션은 힙에 생성된 객체 중 더 이상 사용할 수 없는 객체가 차지한 메모리를 회수합니다.그렇다면 JVM은 힙에 있는 객체를 어떤 형태로 관리하고, 어떤 객체가 살아 있는지 어디서부터 확인할까요?이 질문에 답하려면 다음 두 가지를 구분해서 이해해야 합니다.객체 표현→ 힙에 생성된 객체가 어떤 구조로 저장되는가객체 탐색→ 가비지 컬렉터가 어디서부터 객체를 찾아가는가핫스팟 JVM에서는 힙의 객체를 내부적으로 OOP라는 구조를 통해 다룹니다. 객체의 앞부분에는 객체 상태와 클래스 정보를 담는 객체 헤더가 위치합니다.가비지 컬렉터는 객체 구조만 보고 생존 여부를 판단하지 않습니다. GC Root라고 부르는 시작점에서 객체 참조를 따라가며 도달 가능한 객체를 찾습니다..

가비지 컬렉션은 왜 필요한가: 활성 객체와 Mark and Sweep자바에서는 객체를 생성할 때 개발자가 직접 메모리를 할당하거나 반환하지 않습니다.User user = new User();위 코드처럼 new 키워드를 사용하면 객체가 생성되지만, C나 C++처럼 사용이 끝난 메모리를 직접 해제하는 코드는 작성하지 않습니다.이러한 메모리 관리를 대신 수행하는 기능이 가비지 컬렉션(Garbage Collection, GC)입니다.하지만 가비지 컬렉션을 단순히 “사용하지 않는 객체를 자동으로 삭제하는 기능”이라고만 이해하면 다음과 같은 의문이 생길 수 있습니다.JVM은 어떤 객체가 사용 중인지 어떻게 판단할까요?변수가 null이면 객체가 바로 제거될까요?객체끼리 서로 참조하고 있다면 계속 살아남을까요?객체가 ..

equals는 일반 규약을 지켜 재정의하라 - equals의 일반 규약 알아보기Object 명세에 작성된 내용을 확인해보면 equals 메서드는 널이아닌 객체들에 대해 동치 관계(equivalence relation)을 만족해야 하며 아래의 조건들을 지켜야 한다는 내용이 있습니다. 아래와 같이 크게 5가지로 이루어집니다.반사성(Reflexivity)대칭성(Symmetry)추이성(Transitivity)일관성(Consistency)non-null5가지 규약들에 대하여 설명을 보면 은근히 헷갈리게 써있지만 예시 코드를 확인해 보시면 당연하다면 당연한 이야기들이라 이해하기 어렵지 않을 것 입니다. 이제 각 항목들에 대한 예시 코드를 작성해가며 확인해볼텐데, 예시 코드는 이전 포스팅인 [Effective Jav..

equals는 일반 규약을 지켜 재정의하라 - equals를 재정의해야 하는 상황과 인스턴스 통제 클래스주로 Value Object들이 equals()를 재정의할 상황을 가집니다. Object의 equals()는 기본적으로 참조 동일성 비교(==)를 사용하게 되는데 값을 주로 저장하는 Value Object의 경우 논리적 동치성(값이 동일한가)을 검사할 상황이 발생합니다. 즉 "같은 값을 가지고 있는가?"를 판단해야 한다면 equals()를 재정의할 필요가 있을 것 입니다.아래의 코드는 금액(amount)과 통화(currency) 값을 저장하는 Value Object 입니다. equals()를 재정의하여 값이 일치하는지 비교하는 로직이 추가된 상태입니다.public class Money { priv..

equals는 일반 규약을 지켜 재정의하라 - equals를 재정의하지 않아야 할 4가지 상황 일반적으로 equals는 아래의 상황 중 하나에 해당한다면 재정의 하지 않는 것이 좋습니다.각 인스턴스가 본질적으로 고유하다.인스턴스의 논리적 동치성(logical quality)을 검사할 일이 없다.상위 클래스에서 재정의한 equals가 하위 클래스에도 딱 들어맞는다.클래스가 private 이거나 pacakge-private이고 equals를 호출할 일이 없다. 1. 각 인스턴스가 본질적으로 고유하다.값을 표현하는 클래스가 아니라 동작을 수행하는 개체일 경우 equals의 재정의하지 않는 것이 적절합니다. 예를 들어 Thread, Excutor, Rannable, Connection, Stream 같은 객체..

try-finally 보다는 try-with-resources를 사용하라try-finally의 경우 인스턴스를 명시적으로 close()를 호출하여 닫아주어야 합니다. 만약 개발자의 실수로 자원을 제대로 닫지 않는다면 성능의 문제가 발생할 가능성이 있으며 try와 finally 모두 예외가 발생된다면 try에서 발생한 예외가 덮어씌워질 수 있습니다.file.txt의 첫번째 줄을 읽은 후 출력하는 코드를 try-finally를 사용하여 구현한다고 하면 아래와 같이 될겁니다.finally를 주의 깊게 본다면 reader가 null이 아닌지 체크(NPE 방지)를 하고 close()를 수행합니다. 하지만 close() 수행 중 IOException이 발생할 가능성이 있으므로 또 다시 try-catch를 사용하여..

finalizer와 cleaner 사용을 피하라객체 소멸자 finalizer와 cleaner는 GC에 의해 실행되며 실행 시점 보장이 없기에 예측되지 않습니다. 즉 GC의 알고리즘에 따라 천차만별이며 테스트 과정의 JVM에서는 잘 동작 했지만 배포된 서버에서는 정상적인 동작을 하지 않아 문제가 발생할 수 있습니다.아래의 코드는 finalize()의 예시 코드이며 객체 생성한 다음 참조 해제하여 gc를 요청하는 코드입니다. 즉 gc는 obj 객체의 참조가 비워져 있으므로 메모리를 수거하려고 할 것 입니다. 또한 finalize()를 오버라이딩 했음으로 GC가 해당 객체를 수거할 때 finalize() 메서드가 호출됩니다.public class Test { @Override protected vo..