System.gc()는 언제 어떤 처리를 합니까?

System.gc()는 언제 어떤 처리를 합니까?

자바에서는 가비지 수집이 자동화되어 있는 것을 알고 있습니다.하지만 당신이 전화하면 이해했어요.System.gc()JVM이 해당 시점에서 가비지 수집을 수행할지 여부를 결정할 수 있습니다.이게 정확히 어떻게 작동하나요?JVM은 정확히 어떤 기준으로 GC를 실행(또는 실행하지 않음)할지를 결정합니다.System.gc()?

이것을 코드에 넣는 것이 좋은 예가 있습니까?

실제로, 그것은 보통 가비지 수집을 하기로 결정한다.답은 실행 중인 JVM, 실행 중인 모드, 사용 중인 가비지 수집 알고리즘 등 여러 요소에 따라 달라집니다.

난 네 암호에 의존하지 않을 거야.JVM이 Out Of Memory Error를 발생시키려 해도 System.gc()를 호출해도 중지되지 않습니다.이는 가비지 컬렉터가 가능한 한 많은 양의 메모리를 해방하려고 하기 때문입니다.실제로 사용하는 것은 IDE에서 사용자가 클릭할 수 있는 버튼에 접속되어 있는 것 뿐이지만, 실제로도 그다지 유용하지 않습니다.

System.gc()를 호출하는 것이 의미가 있는 유일한 예는 응용 프로그램을 프로파일링하여 메모리 누전 가능성을 검색하는 경우입니다.프로파일러들은 메모리 스냅숏을 찍기 직전에 이 방법을 불렀다고 생각합니다.

Java에서는 GC를 제어할 수 없습니다.VM이 결정합니다.전 우연히 이런 경우를 본 적이 없어요System.gc()필요합니다.그 이후로는System.gc()호출은 단순히 VM이 가비지 수집을 수행하고 전체 가비지 수집(다세대 힙의 이전 세대 및 새 세대)도 수행하도록 제안합니다. 그러면 실제로 필요한 것보다 더 많은 CPU 사이클이 소비될 수 있습니다.

경우에 따라서는 애플리케이션이 무거운 리프팅이 발생하기 전에 몇 분 동안 유휴 상태로 있을 수 있으므로 VM에 지금 전체 수집을 수행하도록 제안하는 것이 타당할 수 있습니다.예를 들어, 애플리케이션 부팅 중에 많은 임시 개체를 초기화한 직후(즉, 엄청난 양의 정보를 캐시했을 뿐이며, 1분 정도 동안 많은 작업이 수행되지는 않을 것입니다).예를 들어 일식 시작과 같은 IDE는 초기화가 매우 중요하기 때문에 초기화 직후에 그 시점에서 완전한 GC를 실행하는 것이 타당하다고 생각합니다.

Java Language Specification은 사용자가 호출할 때 JVM이 GC를 시작하는 것을 보증하지 않습니다.System.gc()이것이 "그 시점에서 GC를 실행하기로 결정하거나 실행하지 않을 수 있다"는 이유입니다.

Oracle JVM의 백본인 OpenJDK 소스 코드를 보면System.gc()는 GC 사이클을 시작합니다.J9과 같은 다른 JVM을 사용하는 경우 해당 설명서를 확인하여 답을 찾아야 합니다.예를 들어, Azul의 JVM에는 연속적으로 실행되는 가비지 컬렉터가 있기 때문에 콜은System.gc()아무것도 하지 않다

JConsole 또는 VisualVM에서 GC를 시작하는 다른 답변도 있습니다.기본적으로 이러한 툴은 리모트콜을 발신합니다.System.gc().

일반적으로 가비지 수집 주기는 코드에서 시작하지 않습니다. 가비지 수집 주기가비지 수집 사이클은 어플리케이션의 의미와 혼동됩니다.애플리케이션이 비즈니스 작업을 수행하고 JVM이 메모리 관리를 담당합니다.이러한 우려는 분리해야 합니다(어플리케이션에 메모리 관리를 시키지 말고 비즈니스에 집중합니다).

다만, 에의 문의가 있는 경우는 거의 없습니다.System.gc()이해할 수 있을 것 같아요.예를 들어 마이크로벤치마크를 생각해 봅시다.아무도 GC 사이클이 마이크로벤치마크의 중간에서 발생하는 것을 원하지 않습니다.따라서 각 측정 사이에 GC 사이클을 트리거하여 모든 측정이 빈 힙으로 시작되도록 할 수 있습니다.

전화할 때는 매우 조심해야 합니다.System.gc(). 호출하면 불필요한 성능 문제가 애플리케이션에 추가될 수 있으며 실제로 수집을 수행할 수 있다는 보장은 없습니다.실제로 명시적 디세블로 할 수 있습니다.System.gc()java 인수를 통해-XX:+DisableExplicitGC.

가비지 컬렉션에 대한 자세한 내용은 Java HotSpot Garbage Collection에서 제공되는 문서를 읽어보실 것을 강력히 권장합니다.

System.gc()는 VM에 의해 구현되며, 그 기능은 구현에 따라 다릅니다.예를 들어, 구현자는 단순히 되돌아와서 아무것도 하지 않을 수 있습니다.

수동 컬렉션을 발행하는 타이밍에 대해서는 작은 컬렉션을 대량으로 포함한 컬렉션을 폐기하는 경우에만 발행할 수 있습니다.Map<String,<LinkedList>>예를 들어, 그때그때의 퍼포먼스를 시험해 보고 싶지만, 대부분의 경우, 그것에 대해 걱정할 필요는 없습니다.대부분의 경우 GC가 당신보다 더 잘 알고 있습니다.

직접 메모리 버퍼를 사용하는 경우 직접 메모리가 부족해도 JVM은 GC를 실행하지 않습니다.

전화하시면ByteBuffer.allocateDirect()Out Of Memory Error 라고 하는 메세지가 표시됩니다.GC 를 수동으로 기동하면, 이 콜은 정상인 것을 알 수 있습니다.

대부분의 JVM은 GC를 시작합니다(-XX:DiableExplicit에 따라 다름).GC 및 -XX:+명시GCInvokes Concurrent 스위치).그러나 나중에 더 나은 구현을 위해 사양이 제대로 정의되지 않았습니다.

사양에 대한 설명이 필요합니다.버그 #6668279: (spec) System.gc()는 사용을 권장하지 않으며 동작을 보증하지 않음을 나타냅니다.

내부적으로 GC 방식은 RMI와 NIO에 의해 사용되며 동기 실행이 필요합니다.이것은 현재 논의 중입니다.

버그 #5025281: System.gc()가 (stop-the-world가 아닌) 동시 전체 수집을 트리거할 수 있도록 허용함

Garbage Collection에 능하다Java(데스크탑/노트북/서버에서 Java로 코딩된 소프트웨어를 실행하는 경우).전화하시면 됩니다.System.gc()또는Runtime.getRuntime().gc()에Java.

다만, 이러한 콜 중 어느 것도 동작할 수 있는 것은 아닙니다.jvm이 가비지 컬렉터를 실행하기 위한 제안일 뿐입니다.GC를 실행할지는 JVM에 달려 있습니다.짧은 답변입니다.언제 가동되는지 알 수 없습니다.긴 답변: JVM은 시간이 있으면 gc를 실행합니다.

Android도 마찬가지라고 생각합니다.그러나 이로 인해 시스템이 느려질 수 있습니다.

일반적으로 VM은 Out Of Memory를 던지기 전에 가비지 수집을 자동으로 수행합니다.예외적으로 명시적 콜을 추가하는 것은 퍼포먼스 히트를 이전 시점으로 이동시킬 수 있다는 점을 제외하고는 도움이 되지 않습니다.

하지만, 저는 그것이 관련이 있을 수 있는 사례를 접했다고 생각합니다.효과가 있는지 아직 테스트하지 않았기 때문에 잘 모르겠습니다.

파일을 메모리 맵할 때 충분한 메모리 블록을 사용할 수 없을 때 map() 호출이 IOException을 발생시킨다고 생각합니다.map() 파일 바로 앞에 가비지 컬렉션이 있으면 이를 방지하는 데 도움이 될 수 있습니다.당신은 어떻게 생각하나요?

우리는 절대 쓰레기 수집을 강요할 수 없다.System.gc는 가비지 수집용으로 VM만 제안하고 있지만 메커니즘이 실제로 실행되는 시간은 아무도 알 수 없습니다.이것은 JSR 사양에 기재되어 있습니다.

다양한 가비지 수집 설정을 테스트하는 데 많은 시간을 할애할 필요가 있지만, 위에서 설명한 바와 같이 그렇게 하는 것은 보통 유용하지 않습니다.

현재 메모리 제한이 있는 환경과 비교적 대량의 데이터를 포함하는 프로젝트를 진행하고 있습니다.몇 가지 큰 데이터가 환경을 한계로 몰아넣고 메모리 사용량을 줄일 수 있었지만 이론적으로는 정상적으로 동작할 수 있었습니다만, 여전히 히프 스페이스 에러가 발생합니다(상세 GC 옵션).쓰레기 수집을 시도하고 있다는 걸 보여줬죠디버거에서 System.gc()를 실행하면 충분한 메모리가 확보됩니다.많지는 않지만 충분해

따라서 어플리케이션이 System.gc()를 호출하는 것은 데이터 처리에 필요한 큰 버퍼가 할당되는 코드의 세그먼트를 입력하려고 할 때뿐이며, 사용 가능한 빈 메모리에 대한 테스트에서는 데이터를 보유할 수 없음을 나타냅니다.특히 처리 중인 데이터가 소스에서 최소 100~200MB 이상일 때를 제외하고, 비정적 데이터의 대부분이 실행과 관련된 300MB 이상의 1GB 환경을 검토하고 있습니다.이 모든 것은 자동 데이터 변환 프로세스의 일부이기 때문에 장기적으로 데이터는 모두 비교적 짧은 시간 동안 존재합니다.

유감스럽게도 가비지 컬렉터를 조정하기 위한 다양한 옵션에 대한 정보를 이용할 수 있지만 이는 대부분 실험적인 프로세스로 보이며 이러한 특정 상황을 처리하는 방법을 이해하는 데 필요한 하위 수준의 세부 정보는 쉽게 얻을 수 없습니다.

이 모든 것은 System.gc()를 사용하고 있는데도 명령줄 파라미터를 사용하여 계속 튜닝하여 대규모 데이터 블록으로 인해 발생하는 장애물을 극복하지 못했지만 애플리케이션 전체 처리 시간을 비교적 큰 폭으로 단축할 수 있었습니다.즉, System.gc()는 툴입니다만, 매우 신뢰할 수 없는 툴입니다.사용 방법에 주의를 기울이지 않으면, 자주 동작하지 않았던 것을 후회하게 됩니다.

만약 당신이 알고 싶다면System.gc()호출됩니다.새로운 Java 7 업데이트4에서는 JVM이 가비지 컬렉션을 실행할 때 알림을 받을 수 있습니다.

Garbage Collector MXBean 클래스가 Java 7 업데이트4에 도입되었는지 100% 확신할 수 없습니다.릴리스 노트에서는 찾을 수 없었지만, javaperformancetuning.com 사이트에서 정보를 찾았습니다.

명시적 GC를 실행하는 것이 좋을 때 구체적인 예를 생각할 수 없습니다.

일반적으로 명시적 GC를 실행하면 실제로는 득보다 실이 많을 수 있습니다.명시적 GC는 완전한 수집을 트리거하기 때문에 모든 오브젝트를 통과할 때 시간이 크게 소요되기 때문입니다.이 명시적인 gc가 반복 호출될 경우 풀 GC를 실행하는 데 많은 시간이 소요되기 때문에 애플리케이션 속도가 느려질 수 있습니다.

또는 힙 분석기를 사용하여 힙을 검토하고 라이브러리 구성 요소가 명시적 GC를 호출하고 있는 것으로 의심되는 경우 gc=-XX:를 추가할 수 없습니다.+DisableExplicit(비활성화)GC에서 JVM 파라미터로 이동합니다.

Bruce Eckel이 Java에서 생각하는 방법에 따라 명시적인 System.gc() 호출의 사용 사례 중 하나는 최종화를 강제하고 싶을 때(즉, 메서드를 최종화하는 호출)입니다.

system.display가 동작하는 동안 월드: 가비지 컬렉터가 모든 오브젝트를 스캔하여 삭제할 필요가 있는지 확인할 수 있도록 모든 응답이 정지됩니다.응용 프로그램이 웹 프로젝트인 경우, 모든 요청은 gc가 끝날 때까지 중지되며, 이로 인해 웹 프로젝트가 영구적으로 작동하지 않게 됩니다.

언급URL : https://stackoverflow.com/questions/66540/when-does-system-gc-do-something