System.gc ()는 언제 작동합니까?

System.gc ()는 언제 작동합니까?

---

가비지 수집이 Java로 자동화되어 있음을 알고 있습니다. 그러나 System.gc()코드를 호출 하면 JVM이 해당 시점에서 가비지 수집을 수행하거나 결정하지 않을 수 있음을 이해 했습니다. 이것이 정확히 어떻게 작동합니까? JVM은 GC를 볼 때 정확히 어떤 기반 / 파라미터를 결정 System.gc()합니까?

어떤 경우에 이것을 코드에 넣는 것이 좋은 아이디어가 있습니까?

---

실제로는 일반적으로 가비지 콜렉션을 수행하기로 결정합니다. 대답은 실행중인 JVM, 사용중인 모드 및 사용중인 가비지 수집 알고리즘과 같은 많은 요소에 따라 다릅니다.

나는 당신의 코드에서 그것에 의존하지 않을 것입니다. JVM이 OutOfMemoryError를 발생시키려는 경우 System.gc ()를 호출하면 중지되지 않습니다. 가비지 콜렉터는 극단적으로 가기 전에 가능한 한 많이 해제하려고 시도하기 때문입니다. 실제로 사용 된 것을 본 유일한 시간은 IDE에서 사용자가 클릭 할 수있는 버튼에 연결되어 있지만 심지어는 유용하지 않습니다.

---

System.gc ()를 호출하는 것이 적절한 곳을 생각할 수있는 유일한 예는 가능한 메모리 누수를 검색하기 위해 응용 프로그램을 프로파일 링하는 경우입니다. 프로파일 러가 메모리 스냅 샷을 찍기 직전 에이 메소드를 호출한다고 생각합니다.

---

Java 언어 사양에서는 호출 할 때 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주기를 트리거하여 모든 측정이 빈 힙으로 시작되도록 할 수 있습니다.

---

Java에서는 GC를 제어 할 수 없습니다 .VM이 결정합니다. 필자 System.gc()가 필요한 경우를 본 적이 없다 . 때문에 System.gc()호출이 단순히 VM은 가비지 수집을 할 것을 제안하고 또한 전체 가비지 컬렉션 (다중 세대 힙에 이전 및 새 세대)를 수행 한 후 실제로 발생할 수 있습니다 더 많은 CPU 사이클이 필요 이상으로 소비 될 수 있습니다.

경우에 따라 무거운 리프팅이 발생하기 전에 다음 몇 분 동안 응용 프로그램이 유휴 상태가 될 것임을 알 수 있으므로 지금 전체 컬렉션을 수행하도록 VM에 제안하는 것이 좋습니다. 예를 들어 응용 프로그램을 시작하는 동안 많은 임시 객체를 초기화 한 직후 (즉, TON의 정보를 캐시했으며 1 분 정도 많은 활동을하지 않을 것임을 알고 있습니다). 일식 시작과 같은 IDE를 생각해보십시오. 초기화하는 것이 많으므로 초기화 직후에 그 시점에서 전체 gc를 수행하는 것이 좋습니다.

---

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

가비지 수집에 대한 자세한 내용은 Java HotSpot Garbage Collection 에서 제공되는 문서를 읽어 보는 것이 좋습니다 .

---

System.gc()VM에 의해 구현되며 구현은 구현에 따라 다릅니다. 예를 들어 구현자는 단순히 반환하고 아무것도 할 수 없습니다.

수동으로 수집을 발행하는 경우에 관해서는,이 작업을 수행 할 수있는 유일한 시간은 당신이 작은 컬렉션의 부하를 포함하는 대규모 컬렉션 포기하는 경우 - Map<String,<LinkedList>>예를 들어 - 당신이 시도하고 반환 한 다음 공격 먹고 싶어하고 그러나 대부분 걱정하지 않아도됩니다. GC는 대부분 슬프게도 당신보다 더 잘 알고 있습니다.

---

직접 메모리 버퍼를 사용하면 직접 메모리가 부족하더라도 JVM이 GC를 실행하지 않습니다.

전화를 걸고 ByteBuffer.allocateDirect()OutOfMemoryError가 발생하면 GC를 수동으로 트리거 한 후이 호출이 정상임을 알 수 있습니다.

---

대부분의 JVM은 -C :: DiableExplicitGC 및 -XX : + ExplicitGCInvokesConcurrent 스위치에 따라 GC를 시작합니다. 그러나 나중에 더 나은 구현을 할 수 있도록 사양이 잘 정의되어 있지 않습니다.

사양은 명확해야합니다. 버그 # 6668279 : (spec) System.gc ()는 사용을 권장하지 않으며 동작을 보증하지 않음을 나타냅니다.

내부적으로 gc 메소드는 RMI 및 NIO에서 사용되며 동기 실행이 필요합니다. 현재 논의 중입니다.

버그 # 5025281 : System.gc ()가 동시 (전 세계가 아닌) 전체 컬렉션을 트리거하도록 허용

---

일반적으로 VM은 OutOfMemoryException을 발생시키기 전에 가비지 수집을 자동으로 수행하므로 명시적인 호출을 추가하면 성능 저하가 더 이른 시점으로 이동한다는 점을 제외하고는 도움이되지 않습니다.

그러나 관련성이있는 경우가 발생했다고 생각합니다. 그래도 효과가 있는지 테스트하지 않았으므로 확실하지 않습니다.

파일을 메모리 매핑 할 때 충분한 메모리 블록을 사용할 수 없으면 map () 호출에서 IOException이 발생한다고 생각합니다. map () 파일 바로 앞에있는 가비지 수집이이를 방지하는 데 도움이 될 수 있습니다. 어떻게 생각해?

---

우리는 절대 가비지 콜렉션을 강요 할 수 없습니다. System.gc는 가비지 수집을 위해 vm 만 제안하지만 실제로 메커니즘이 실행되는 시간은 아무도 모르는 것입니다. 이는 JSR 사양에 명시되어 있습니다.

---

다양한 가비지 콜렉션 설정을 테스트하는 데 시간이 걸리는 LOT이 있지만 위에서 언급했듯이 일반적으로 그렇게하는 것은 유용하지 않습니다.

현재 메모리 제한 환경과 상대적으로 많은 양의 데이터가 포함 된 프로젝트를 진행하고 있습니다. 환경을 한계로 밀어 붙일 수있는 몇 개의 큰 데이터가 있으며 메모리 사용량을 줄일 수 있었지만 이론 상으로는 제대로 작동해야하지만 힙 공간 오류가 계속 발생합니다. 자세한 GC 옵션은 가비지 수집을 시도했지만 아무 소용이 없다는 것을 보여주었습니다. 디버거에서 System.gc ()를 수행 할 수 있으며 충분한 메모리가 충분할 것입니다.

결과적으로 내 응용 프로그램이 System.gc ()를 호출하는 유일한 시간은 데이터 처리에 필요한 큰 버퍼가 할당 될 코드 세그먼트를 입력하려고 할 때이며 사용 가능한 여유 메모리에 대한 테스트는 내가 아닌 것으로 나타냅니다 그것을 보장합니다. 특히, 정적 데이터가 300MB 이상을 차지하는 1GB 환경을보고 있는데, 처리되는 데이터가 100-200MB 이상인 경우를 제외하고 대부분의 비 정적 데이터는 실행 관련입니다. 소스. 그것은 모두 자동 데이터 변환 프로세스의 일부이므로 데이터는 장기적으로 비교적 짧은 기간 동안 존재합니다.

Unfortunately, while information about the various options for tuning the garbage collector is available, it seems largely an experimental process and the lower level specifics needed to understand how to handle these specific situations are not easily obtained.

All of that being said, even though I am using System.gc(), I still continued to tune using command line parameters and managed to improve the overall processing time of my application by a relatively significant amount, despite being unable to get over the stumbling block posed by working with the larger blocks of data. That being said, System.gc() is a tool....a very unreliable tool, and if you are not careful with how you use it, you will wish that it didn't work more often than not.

---

If you want to know if your System.gc() is called, you can with the new Java 7 update 4 get notification when the JVM performs Garbage Collection.

I am not 100% sure that the GarbageCollectorMXBean class was introduces in Java 7 update 4 though, because I couldn't find it in the release notes, but I found the information in the javaperformancetuning.com site

---

Garbage Collection is good in Java, if we are executing Software coded in java in Desktop/laptop/server. You can call System.gc() or Runtime.getRuntime().gc() in Java.

Just note that none of those calls are guaranteed to do anything. They are just a suggestion for the jvm to run the Garbage Collector. It's up the the JVM whether it runs the GC or not. So, short answer: we don't know when it runs. Longer answer: JVM would run gc if it has time for that.

I believe, the same applies for Android. However, this might slow down your system.

---

I can't think of a specific example when it is good to run explicit GC.

In general, running explicit GC can actually cause more harm than good, because an explicit gc will trigger a full collection, which takes significantly longer as it goes through every object. If this explicit gc ends up being called repeatedly it could easily lead to a slow application as a lot of time is spent running full GCs.

Alternatively if going over the heap with a heap analyzer and you suspect a library component to be calling explicit GC's you can turn it off adding: gc=-XX:+DisableExplicitGC to the JVM parameters.

---

Accroding to Thinking in Java by Bruce Eckel, one use case for explicit System.gc() call is when you want to force finalization, i.e. the call to finalize method.

---

you can see System.gc() calls to be made from multiple sources and not just from your application source code. Thus searching your application code ‘System.gc()’ string isn’t enough to tell whether your application is making System.gc() calls. Thus it poses a challenge: How to detect whether System.gc() calls are invoked in your entire application stack?

This is where GC logs comes handy. Enable GC logs in your application. In fact, it’s advisable to keep your GC log enabled all the time in all your production servers, as it helps you to troubleshoot and optimize application performance. Enabling GC logs adds negligible (if at all observable) overhead. Now upload your GC log to the Garbage Collection log analyzer tool like GCeasy, HP JMeter,…. These tools generate rich Garbage collection analysis report.

Read More: Downsides of invoking System.gc()

---

while system.gc works,it will stop the world:all respones are stopped so garbage collector can scan every object to check if it is needed deleted. if the application is a web project, all request are stopped until gc finishes,and this will cause your web project can not work in a monent.

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