Java_tuning5

Reading time ~1 minute

java GC

Oracle

선택의 길

  1. 응답시간이 빨라야 하는가?
    • 웹, 클라이언트 애플리케이션
  2. 처리량이 많아야 하는가?
    • 주어진 시간에 얼마나 많은 트랜잭션을 완료할건가
    • 얼마나 많은

GC 단계

Marking

자바 객체는 순서대로 쌓인다. 큰거 작은거 모두 순서대로 쭉쭉쭉. 그러고 꽉 차면 GC는 쓰는 객체 안쓰는 객체를 마킹합니다.

Normal Deletion, Deletion with Compacting

안쓰는 놈들, 필요없는 놈들은 지워줍니다. 쓸모 없으니깐 근데 순서대로 쌓이다가 안쓰는 애들을 삭제하면 중간에 빈 곳이 생기니까 컴팩션~~ 한쪽으로 모으는거

처음 객체

처음 객체는 무조건! young영역에 생성된다. 그 중에 Eden으로. 그러다가 Eden이 꽉 찰 때까지 들어가고 마지막엔 GC가 돈다. 아까 봤던 (mark..) 한 Eden이 꽉 차고 GC가 돌면 Eden에 남아있는 객체는 없고 모두 survivor로 옮김

원래 survivor에 있던 애들은 다른 쪽의 survivor로 가고 옮길 때 카운트 값을 올림! 일명 age. 이 age가 Threshold을 넘으면 old

컴팩션 하는 이유

디스크 조각모음과 같은 이유. 데이터가 띡띡 떨어져 있으면 읽기 힘들어서 이걸 모아두면 빠르게 읽을 수 있다. 또, 빈 공간도 떨어져 있으면 큰 공간을 빨리 찾기도 어려우니까 한꺼번에 모아둔다.

물론 컴팩션 하는 오버헤드가 크긴하지만 영 영역은 무조건 하며 얻는 이득이 크다.

Young, old

처음 jvm 뜰 때 Xms, Xmx 설정해 줄 수 있는데 이걸 같게 설정해주는게 좋다. 왜냐하면 다르게 주면 young, old의 비율이 달라진다.

G1 Heap Allocation

바둑판으로 메모리가 한통채로 구성되어 있다. 근데 그 중에도 young, old가 나뉘어져 있다.

Java Option

X : 안바뀌는 것 XX : jdk 벤더마다 달라지는 것

jps

jstat -gcutil – ls

Dooray!

Dooray CalDav, IMAP 사용법 Continue reading

Vue.js

Published on February 10, 2018

Java_tuning4

Published on March 06, 2017