jvm의 Java 가비지 수집 및 stw 분석

이 기사는 주로 Java 코드 일시 중지, jvm의 스레드 및 기타 관련 내용을 포함하여 jvm의 Java 가비지 수집 및 stw에 대한 빠른 이해를 소개합니다. 여전히 필요한 친구가 참조할 수 있습니다.

STW라고 하는 Java의 Stop-The-World 메커니즘은 가비지 수집 알고리즘을 실행할 때 Java 애플리케이션의 다른 모든 스레드가 일시 중지된다는 것입니다(가비지 수집 도우미 제외). Java의 전역 일시 중지 현상, 전역 일시 중지, 모든 Java 코드 중지, 기본 코드는 실행될 수 있지만 JVM과 상호 작용할 수 없는 현상은 대부분 gc로 인해 발생합니다.

GC 중 STW(Stop the World)는 모두의 가장 큰 적입니다. 하지만 많은 사람들은 GC 외에도 JVM에서도 일시정지가 발생한다는 사실을 모르고 있을 수 있습니다.

JVM에는 특별한 스레드인 VM 스레드가 있습니다. 이는 GC 디스패치, 스레드 덤프 등과 같은 특별한 VM 작업을 수행하는 데 특별히 사용됩니다. 이러한 작업을 수행하려면 전체 힙과 모든 스레드의 상태가 필요합니다. 정적이어야만 일관성을 얻을 수 있습니다. 이에 JVM에서는 Safe Point라는 개념을 도입하고, VM Operation이 필요할 때 모든 Thread에게 Static Safe Point에 진입하도록 알리는 방법을 찾았다.

안전 지점을 트리거하는 기타 VM 작업에는 다음이 포함됩니다.

3. 편향된 잠금을 취소합니다.

4. 다양한 디버그 작업(예: 스레드 덤프 또는 교착 상태 확인)

JVM에 어떤 일이 발생했는지 확인하세요.

가장 간단한 방법은 JVM 시작 매개변수의 GC 매개변수에 문장을 하나 더 추가하는 것입니다.

-XX:+PrintGCApplicationStoppedTime

GC 로그에 모든 JVM 일시 중지 시간(GC뿐만 아니라)이 인쇄됩니다. 내부에.

2016-08-22T00:19:49.559+0800: 219.140: 애플리케이션 스레드가 중지된 총 시간: 0.0053630초

이것은 거의 모든 일시 중지를 유발할 수 있는 매우 유용한 필수 매개 변수입니다...

하지만 JDK 1.7.40 이전 버전에서는 타임스탬프를 인쇄하지 않았기 때문에 JVM이 중지된 시간만 알 수 있고 언제 중지했는지는 알 수 없습니다. 이때 간단한 방법은 "-XX:+PrintGCApplicationConcurrentTime"을 추가하여 두 번의 일시 중지 사이에 JVM의 정상 실행 시간을 인쇄하는 것입니다(또한 타임스탬프 없음). 그러나 최소한 타임스탬프가 있는 GC 로그와 함께 사용하여 역전할 수 있습니다. 그만해요 이제 그럴 시간이 됐어요.

2016-08-22T00:19:50.183+0800: 219.764: 적용 시간: 5.6240430초

무슨 이유로 일시 정지를 인쇄하는 방법은 무엇입니까? 두 개의 매개 변수 : -xx :+printsafepointstatistics -xx : printsafepointStatisticsCount = 1

이번에는 유사한 내용이 stdout

vmop에서 인쇄됩니다 [Threads : Total _running wait_to_block] 1913.425 : gencollectforallocation 55 2 0 ] [time: spin block sync cleanup vmop] page_trap_count[ 0 0 0 0 6 ] 0

이 로그는 두 개의 섹션으로 나누어집니다. 첫 번째 섹션은 타임스탬프, VM 작업 유형 및 스레드입니다. overview

total: 안전 포인트의 전체 스레드 수

initially_running: 안전 포인트 시작 시 실행 중인 상태의 스레드 수

wait_to_block: 일시 중단을 기다려야 하는 스레드 수 VM 작업 시작 전

두 번째 줄은 safepoint에 도달하는 다양한 단계와 작업을 수행하는 데 걸리는 시간이며, 그 중 가장 중요한 것은 vmop입니다.

spin: 스레드가 응답할 때까지 기다리는 시간

safepoint 호출

block: 모든 스레드를 일시 중지하는 시간

sync: spin+block과 동일하며 처음부터 안전 지점에 진입하는 데 걸리는 시간이며 이를 결정하는 데 사용할 수 있습니다. safe point 진입에 걸리는 시간

cleanup : clean up에 걸리는 시간

vmop : 실제로 VM Operation을 실행하는데 걸리는 시간

이렇게 많지만 매우 짧은 safe point를 볼 수 있다 자세한 내용은 편향된 잠금 구현 원칙을 참조하세요. 일반적으로 동시성이 높은 애플리케이션은 시작 매개변수에 "-XX:-UseBiasedLocking"을 추가하여 취소합니다. 또한 일부 유형은 vm 작업이 아니라는 사실도 확인했습니다. 문서에는 긴급하지 않은 일부 작업의 경우 매초마다 안전 지점에 들어가는 것이 보장된다고 나와 있습니다(이 초가 이미 GC된 경우에는 필요하지 않습니다). 예를 들어 일부 샘플링 프로파일러 도구는 -DGuaranteedSafepointInterval을 사용하여 조정할 수 있지만 매초마다 발생하지 않으며 시간이 가변적입니다.

실제 전투에서 안전 포인트 로그를 사용해본 결과 정기적으로 Thread Dump 등을 호출하는 프로그램이 발견되었습니다. 그러나 safepoint 로그는 기본적으로 stdout으로 출력되기 때문에 stdout 로그의 성능과 청결성 때문에 일반적으로 기본적으로 활성화하지 않습니다. 필요할 때만 엽니다.

VM에서 일어나는 일에 대해 자세히 알아보려면 다음 세 가지 매개변수를 추가하세요. 안타깝게도 JVM은 이 세 가지 매개 변수가 설정되어 있다는 이유만으로 보안 포인트 로그를 vm.log로 전송하지 않고 두 번 인쇄할 수 없습니다.

-XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=/dev/shm/vm.log

요약

위 내용은 jvm의 Java 가비지 수집 및 stw 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!