JVM이 ‘java.lang.OutOfMemoryError : GC 오버 헤드 제한 초과’를 발생시키는 데 사용하는 샘플링 시간은 얼마입니까? GCTimeLimit 및 GCHeapFreeLimit 매개 변수로 98 % 및 2 %를 제어 할 수 있다는 것을 알고 있지만 샘플링 시간은 얼마입니까?
답변
에서 자바 SE 6 핫스팟 [TM] 가상 머신의 가비지 컬렉션 조정
다음과 같은
과도한 GC 시간 및 OutOfMemoryError
가비지 수집에 너무 많은 시간이 소요되면 동시 수집기는 OutOfMemoryError를 발생시킵니다. 총 시간의 98 % 이상이 가비지 수집에 소요되고 힙의 2 % 미만이 복구되면 OutOfMemoryError가 발생합니다. 이 기능은 힙이 너무 작아서 진행이 거의 또는 전혀 진행되지 않는 동안 애플리케이션이 장시간 실행되지 않도록 설계되었습니다. 필요한 경우 -XX : -UseGCOverheadLimit 옵션을 명령 줄에 추가하여이 기능을 비활성화 할 수 있습니다.
정책은 동시 수집을 수행하는 데 소요 된 시간이 98 % 시간 제한에 포함되지 않는다는 점을 제외하면 병렬 수집기의 정책과 동일합니다. 즉, 애플리케이션이 중지 된 동안 수행 된 수집 만 과도한 GC 시간에 포함됩니다. 이러한 컬렉션은 일반적으로 동시 모드 실패 또는 명시 적 컬렉션 요청 (예 : System.gc () 호출) 때문입니다.
더 아래의 통로와 함께
명시 적 가비지 수집의 가장 일반적으로 발생하는 사용 중 하나는 RMI 분산 가비지 수집 (DGC)에서 발생합니다. RMI를 사용하는 애플리케이션은 다른 가상 머신의 개체를 참조합니다. 때때로 로컬 힙을 수집하지 않으면 이러한 분산 응용 프로그램에서 가비지를 수집 할 수 없으므로 RMI는 주기적으로 전체 수집을 강제합니다. 이러한 컬렉션의 빈도는 속성으로 제어 할 수 있습니다. 예를 들면
java -Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000기본 비율 인 분당 한 번 대신 시간당 한 번 명시 적 수집을 지정합니다. 그러나 이로 인해 일부 개체가 회수되는 데 훨씬 더 오래 걸릴 수도 있습니다. DGC 활동의 적시성에 대한 상한이 필요하지 않은 경우 이러한 속성을 Long.MAX_VALUE만큼 높게 설정하여 명시 적 컬렉션 간의 시간을 효과적으로 무한대로 만들 수 있습니다.
98 %를 결정하기위한 평가 기간이 1 분이라는 것을 암시하는 것처럼 보이지만 올바른 정의를 사용하여 Sun의 JVM에서 구성 할 수 있습니다.
물론 다른 해석도 가능합니다.
