JVM 성능 개선 실전:당신 의 IntelliJ Idea 를 미 끄 러 지게 합 니 다.

본문 은 이미 Github 창고 에 수록 되 었 다.https://github.com/silently9527/JavaCore
머리말
앞에서 JVM 고장 진단 과 처리 도 구 를 정리 했다.대부분의 자바 프로그래머 들 이 IntelliJ Idea 를 사용 하 는 것 을 감안 하여 본 편 은 도 구 를 사용 하여 실전 연습 을 통 해 IntelliJ Idea 의 운행 속 도 를 향상 시 켰 다.
조정 전 운행 상태
 원본 구성 내용
아이디어 원본 프로필 의 경 로 를 조회 하려 면 VisualVM 의 개요 에서 볼 수 있 습 니 다.

원본 설정 내용:

-XX:ReservedCodeCacheSize=240m
-XX:+UseCompressedOops
-Dfile.encoding=UTF-8
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-Djdk.http.auth.tunneling.disabledSchemes=""
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow

-XX:ErrorFile=$USER_HOME/java_error_in_idea_%p.log
-XX:HeapDumpPath=$USER_HOME/java_error_in_idea.hprof

-Xmx512m

인쇄 시작 시간 플러그 인 개발
최적화 전과 최적화 후 시작 시간의 변 화 를 직관 적 으로 봐 야 하기 때문에 Idea 플러그 인 개발 을 간단하게 해 야 합 니 다.Idea 플러그 인 개발 절차 에 대해 제 가 예전 에 쓴 을 참고 하 십시오.
JVM 의 시작 시간 은 모든 구성 요소 초기 화 완료 후 까지 입 니 다.코드 는 다음 과 같 습 니 다.

public class MyApplicationInitializedListener implements ApplicationInitializedListener {
  @Override
  public void componentsInitialized() {
    RuntimeMXBean bean = ManagementFactory.getRuntimeMXBean();
    long startTime = bean.getStartTime();
    long costTime = System.currentTimeMillis() - startTime;

    Messages.showMessageDialog("  ：" + costTime, "    ", Messages.getInformationIcon());
  }
}

plugin.xml 에 다음 코드 를 추가 합 니 다:

<extensions defaultExtensionNs="com.intellij">
  <applicationInitializedListener id="MyApplicationInitializedListener"
                  implementation="cn.silently9527.MyApplicationInitializedListener"/>
</extensions>

이전의 시작 정보 와 시간 소 모 를 최적화 하 다.

VisualGC 와 IDEA 시작 플러그 인 에 의 해 수 집 된 정보:

IDEA 가동 시간 15s 총 쓰레기 수집 22 회,1.2s 소모,그 중 신생대 GC 17 회,324 ms 소모;

옛날 GC 5 회,953 ms 로 딩 류 27526 개,21s

소모
이 데 이 터 를 보면 정상 이 라 고 할 수 있 습 니 다.15s 도 받 아들 이 는 범위 에서 본 고 는 주로 성능 이 좋 은 것 을 보 여 주 었 기 때문에 빠 른 지 테스트 해 야 합 니 다.
최적화 시도 시작
메모리 를 조정 하여 쓰레기 회수 주파 수 를 제어 하 다
그림 에서 알 수 있 듯 이 시작 매개 변수 가 지정 한 512 m 의 메모리 가 신세대 에 배 치 된 것 은 169 m 밖 에 되 지 않 습 니 다.IDEA 는 우리 가 자주 사용 하 는 도구 이기 때문에 평소에 컴 파일 하 는 과정 도 충분 한 메모리 가 필요 합 니 다.그래서 우 리 는 먼저 전체적인 메모 리 를 확대 해 야 합 니 다.여기 서 저 는 가장 큰 메모리-Xmx1024m를 설정 합 니 다.JVM 이 GC 기간 에 더 이상 시간 을 낭비 하지 않 고 확장 크기 를 동적 으로 계산 할 수 있 도록-Xms1024m도 설정 했다.
시작 하 는 과정 에서 Eden 은 모두 17 번 의 GC 가 발생 했 습 니 다.신세대 gc 횟수 를 줄 이기 위해 저 는 신세대 의 메모리 크기 를-Xmn256m로 설 정 했 습 니 다.
재 시작 후 VisualGC 를 살 펴 보면 신세대 gc 횟수 는 17 회 에서 7 회로 줄 었 고 소요 시간 은 324 ms 에서 152 ms 로 줄 었 다.

메모 리 를 조정 하기 전에 5 번 의 Full GC 가 발생 했 습 니 다.메모 리 를 조정 한 후에 도 4 번 의 Full GC 가 발생 했 습 니 다.그러나 두 장의 그림 을 통 해 알 수 있 듯 이 옛날 에 공간 이 많이 남 았 기 때문에 Full GC 가 발생 해 서 는 안 됩 니 다.코드 에 수 동 호출System.gc()이 Full GC 를 출발 한 곳 이 있 는 지 를 고려 해 인자-XX:+DisableExplicitGC를 추가 하고 IDEA 를 다시 시작 한 결과 실 망 스 러 웠 고 여전히 4 차례 Full GC 가 남아 있 었 다.
최 적 화 된 그림 을 다시 한 번 살 펴 보고 Last Cause:Metadata GC Threshold 를 살 펴 보 세 요.마지막 gc 는 Metaspace 영역 에 메모리 가 부족 해서 발생 하 는 GC 입 니 다.우리 의 추측 을 검증 하기 위해 GC 로 그 를 출력 해 보 세 요.idea.vmoptions에 인쇄 로그 와 관련 된 인 자 를 추가 합 니 다.

-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-Xloggc:../gc.log

JVM 의 GC 로그 의 주요 매개 변 수 는 다음 과 같은 몇 가 지 를 포함한다.

-XX:+PrintGC 출력 GC 로그

-XX:+PrintGCdetails 출력 GC 의 상세 로그

-XX:+PrintGCTIMEStamps 출력 GC 의 시간 스탬프(기준 시간 으로)

-XX:+PrintGCdateStamps 출력 GC 의 시간 스탬프(날짜 형식,예 를 들 어 2013-05-04T 21:53:59.234+0800)

-XX:+PrintHeapAtGC 는 GC 진행 전후 에 쌓 인 정 보 를 출력 합 니 다

-Xloggc:../logs/gc.log 로그 파일 의 출력 경로

아이디어 다시 시작,gc.log 보기

이 중PSYoungGen:은 신세대 가 사용 하 는 ParallelScavenge 쓰레기 수집 기 를 표시 합 니 다.31416K->0K(181248K)gc 전에 사용 한 메모리 크기->gc 이후 메모리 크기(이 지역 의 총 메모리 크기)를 표시 합 니 다.
로그 에서 볼 수 있 듯 이 매번 Full GC 는Metadata GC Threshold때 문 입 니 다.Metaspace 는 gc 가 회수 할 때마다 메모리 가 거의 없고 이 지역 의 용량 만 확 대 했 습 니 다.원인 을 찾 았 으 면 좋 겠 습 니 다.다음 매개 변 수 를 추가 하여 Metaspace 의 크기 를 조정 합 니 다.

-XX:MetaspaceSize=256m

다시 Idea 를 재 개 하 니 Full GC 가 없어 져 서 기분 이 좋 네요.

테스트 를 통 해 큰 프로젝트 를 열 고 컴 파일 코드 를 클릭 하면 자신의 아이디어 카드 가 죽 었 다 는 것 을 알 게 되 었 습 니 다.VisualGC 를 본 후에 메모리 가 남아 있 고 Metaspace 만 가득 차 서 자신 이 준 최대 공간 설정 이 너무 작 아서 바로 지 웠 습 니 다-XX:MaxMetaspaceSize=256m쓰레기 수집 기 선택
방금 gc 로그 에서 우 리 는 기본적으로 ParallelScavenge+Parallel Old 쓰레기 수집 기 를 사용 하 는 것 을 발견 할 수 있 습 니 다.이 조합 은 스루풋 을 중시 합 니 다.여기 서 저 지연 을 중시 하 는 쓰레기 수집 기 를 바 꾸 어 보 겠 습 니 다.
ParNew + CMSidea.vmoptions에 다음 설정 을 추가 합 니 다.

-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC

IDEA 를 다시 시작 한 후 VisualGC 보기

어색 합 니 다.똑 같이 gc 가 6 번 발생 했 습 니 다.ParallelScavenge + Parallel Old의 조합 은 197 ms 가 걸 렸 고ParNew + CMS의 조합 은 379 ms 가 걸 렸 습 니 다.비록 이 결과 이지 만,우 리 는 현재 MinorGC 만 발생 했다 는 것 을 고려 해 야 한다.만약 FullGC 가 발생 하면 결과 가 어떻게 될 지,여러분 스스로 테스트 해 보 세 요.
G1
최신 G1 쓰레기 수 거 기 를 바 꿔 보 겠 습 니 다.idea.vmoptions에 다음 설정 을 추가 합 니 다.

-XX:+UseG1GC

이 결 과 는 좀 느 려 야 할 것 같 습 니 다.스스로 이 두 개의 쓰레기 수 거 기 를 여러 번 테스트 한 적 이 있 습 니 다.매번 결과 가 다 르 고 차이 가 멀 지 않 기 때문에 쓰레기 수 거 기 는 스스로 선택 할 수 있 습 니 다.여기 서 우리 가 선택 한 것 은 G1 입 니 다.
클래스 로드 시간 최적화
이전 분석 에 따 르 면 아이디어 가 로 딩 류 27526 개 를 시작 하 는데 21s 가 걸 렸 습 니 다.이것 은 우리 가 최적화 할 수 있 는 방법 이 있 습 니까?아 이 디 어 는 자주 사용 하 는 개발 도구 이기 때문에 많은 사람들 이 사용 합 니 다.우 리 는 코드 가 안전 하 다 고 생각 할 수 있 습 니 다.현재 가상 컴퓨터 의 요구 에 부합 되 는 지,가상 컴퓨터 의 안전 에 해 를 끼 치지 않 습 니 다.그래서 우 리 는 인자-Xverify:none를 사용 하여 바이트 코드 의 검증 과정 을 사용 하지 않 습 니 다.
IDEA 다시 시작

소모 시간 이 11s 까지 떨 어 졌 는데,효과 가 비교적 뚜렷 하 다.
총결산
모든 최 적 화 를 마 친 후에 여러 번 재 부팅 테스트 를 통 해 평균 가동 시간 이 11s 로 떨 어 졌 습 니 다.이번 조작 이 헛 되 지 않 았 다 는 것 을 위로 하기 위해 11s 이하 의 그림 을 만 들 었 습 니 다.

저 는 이미 0 부터 간단 한 springmvc 를 손 으로 썼 고 상세 한 설명 문 서 를 작 성 했 습 니 다.동료 들 이 springmvc 의 핵심 원 리 를 깊이 이해 하 는 데 도움 이 되 기 를 바 랍 니 다.

소스 코드 가 져 오기 주소:저 는 소스 를 시작 한 프로젝트 코드 를 모두 Git 창고 에 두 었 습 니 다.Github 창고 주소:https://github.com/silently9527,코드 클 라 우 드 창고 주소:https://gitee.com/silently9527,
JVM 성능 개선 실전:당신 의 IntelliJ Idea 가 미 끄 러 운 것 을 즐 길 수 있 도록 하 는 이 글 은 여기까지 소개 되 었 습 니 다.더 많은 JVM 성능 개선 내용 은 우리 의 이전 글 을 검색 하거나 아래 의 관련 글 을 계속 조회 하 시기 바 랍 니 다.앞으로 많은 응원 부 탁 드 리 겠 습 니 다!