큰 객체 할당, TLAB 요약 TLAB( Thread Local Allocation Buffer ) 보다 큰 객체들은 TLAB 바깥에 할당되서 TLAB 안에 할당되는 객체보다 처리가 느리다. TLAB 은 스레드 내의 로컬 영역으로, TLAB 안에 할당된 객체는 스레드 동기화 등의 추가적인 처리를 하지 않고 로컬 변수처럼 처리할 수 있기 때문에 더 빠르다. TLAB 은 에덴내의 한 영역으로 에덴의 크기에 좌우된다. TLAB 을 튜닝하려면 JFR을 사용해서 TLAB 밖에 할당되는 객체들의 크기를 확인한 뒤, TLAB이 최대한 많은 객체들을 포함할 수 있도록 TLAB의 크기를 늘리면 된다. 주의할 점은 JFR의 TLAB 확인 기능은 어플리케이션에 많은 부하가 발생해서 기본적으로 꺼져있으며 프러뎍선 환경에서 사..

크다? JVM의 TLAB 크기에 좌우 TLAB 이란? TLAB : Thread Local Allocation Buffer , 스레드 로컬 할당 버퍼 - 에덴 내에 있는 한 영역 - 스레드 마다 할당되는 객체 버퍼 - 하나의 스레드가 처리할 수 있는 객체의 최대 크기 - 각 스레드마다 스레드 로컬에 할당되므로, 동기화에 신경쓰지 않아도 된다. - TLAB에 할당되지 못하는 크기가 큰 객체들은 TLAB 밖에 할당된다. - TLAB 밖에 할당된 객체들은 스레드 동기화등 여러가지 절차가 추가적으로 필요하기 때문에 처리하는데 TLAB 안에 있는 객체보다 처리가 느리다. TLAB이 가득차면, 일정 크기의 객체는 더이상 TLAB안에 할당될 수 없다. 이 시점에서 JVM에게는 두 가지 선택사항이 있다. 1) TLAB ..

1. 서바이버 스페이스 이해하기 Young Generation에서 객체들의 이동은 다음과 같다. 2. 서바이버 스페이스의 존재 이유 - 몇번의 Minor GC 동안 영 제너레이션 내에 객체가 남아있도록 설계하여, 올드 제너레이션으로 승격될 만큼 오래 살아남지 못한 객체들은 그 전에 제거한다. - S0S1을 핑퐁을 쳐가며 오래 살아남지 못할 객체들은 Old Generation 전에 소거한다. 3. 서바이버 스페이스 오버플로우 서바이버 스페이스가 작아서 또는 어떤 이유로 꽉차게 되면 Minor GC발생 시, 객체가 에덴에서 올드 제너레이션으로 바로 승격된다. 오랫동안 사용되지 않을 객체라도 서바이버의 필터링을 거치지 못하기 때문에 올드 제너레이션으로 이동하게 되어 Full GC를 초래한다. 서바이버 스페이스..

튜닝 목표 : 잘 튜닝된 G1은 Full GC가 발생하지 않아야 한다! Full GC 예방 방법 1) 힙 전체 크기 늘리기 & 제너레이션 간의 비율 조정 2) 백그라운드 스레드의 개수 늘리기 3) 백그라운드 스레드 자주 실행하기 4) 혼합 GC의 작업량 늘리기 MaxGCPauseMillis 를 통한 쉬운 튜닝 G1을 튜닝하는 방법은 많지만, G1의 목표중 하나는 손 쉬운 튜닝이다. G1은 Throughput Collector 에서 봤던 플래그인 -XX:MaxGCPauseMillis=N 을 통해서 간단히 튜닝할 수 있도록 제공한다. -XX:MaxGCPauseMillis = N (디폴트 200ms) G1은 어떤 단계인지 상관없이 Stop-the-world가 발생하면 플래그 값을 읽고, 플래그가 기준값을 넘어..

G1(Garbage First) 이해하기 힙을 디폴트 2048개의 영역으로 나누어서 영역마다 가비지 컬렉을 실행한다. 각 영역은 영, 올드 제너레이션 어떤 용도든지 사용될 수 있다. 각 영역은 서로 인접할 필요 없다. 영역을 많이 나눔으로써, 미참조 객체를 일부 영역들에 모아서 남겨둘 수 있다. 따라서 가비지만 모인 영역들만 집중적으로 처리하여 가비지 컬렉을 빠르게 끝낼 수 있다. 가비지를 우선(Garbage First, G1)이다. G1 기본동작 1) Minor GC : Stop-the-world를 발생시킴 2) Concurrent GC 2-1) 표시 2-2) 혼합 컬렉션 3) Full GC : 피하는 것이 목적 1) Minor GC - 빈 공간은 어디에도 속하지 않는다. G1이 필요하다고 생각하면 아..

고려사항 - 전체 힙 크기 - 올드 / 영 제너레이션의 비율 - GC로 인한 중단시간 - 트레이드 오프 : 힙크기 증가 => Full GC 중단 횟수 감소 => Full GC 중단시간 증가 처리율 / 힙크기 그래프 - 힙크기는 크다고 좋은게 아니다 - 256MB의 작은 힙에서는 전체시간의 35%정도를 GC를 수행한다 - 힙크기가 일정크기를 넘어서면 처리율이 하락 => Full GC 수행시간 증가! - 최적의 처리율을 갖는 힙 크기를 결정하는 것이 중요 최적의 힙 크기 결정하기 - 어플리케이션 실행 & 모니터링의 반복? (X) - Adaptive Size Policy 자동크기조정 기능을 사용하고 JVM이 알아서 결정하도록 내버려두자! 무엇이 "최적"일까? - JVM에게 "최적"이 무엇인지 성능 목표를 제시..

해당 내용은 이펙티브 자바 3판 (조슈아 블로크 지음, 이복연 옮김)를 읽고 나같은 초심자의 눈으로 이해한 내용을 정리해보았다. 책에 있는 내용을 기반으로 썼지만 책에 없는 내용도 조금 적었다. (익명클래스와 람다 비교, 성능적 관점, 함수형 인터페이스와 default메소드, 코드블록-람다블록 비교, Collectors API의 구체적 설명 등) 7장의 아이템 목록 익명 클래스보다는 람다를 사용하라 람다보다는 메소드 참조를 사용하라 표준 함수형 인터페이스를 사용하라 스트림은 주의해서 사용하라 스트림에서는 부작용없는 함수를 사용하라 반환 타입으로는 스트림보다 컬렉션이 낫다 스트림 병렬화는 주의해서 적용하라 아이템42. 익명 클래스보다는 람다를 사용하라 람다는 이름이 없고 문서화도 못한다. 따라서 코드 자체..