毕竟,它是一个守护线程。但是有时候,我们为什么还要显式地调用System.gc( )函数呢?是否值得调用?有哪些优缺点?如果在许多情况下都没有用处,为什么这个方法没有被Java废弃呢?
备注:通过示例进行解释会更有用。
System.gc()
方法视为提示虚拟机运行垃圾收集。话虽如此,就像很多人认为他们在执行的“优化”一样,通常最好让系统自己处理这些事情。系统正在不断发展等等。仍然有一些情况下,开发者可能真的知道得更好,使用它的用例可能非常类似于为什么仍然会编写汇编代码(大多数情况下,编译器更好,但在某些情况下——或对于某些开发者来说——人类实际上可以编写更高效的代码)。问:为什么我们需要显式地调用System.gc()函数?
答:因为有些人写了糟糕的代码。
我认为大多数人都会同意,你不应该显式地调用System.gc()
。
让系统按照它应该的方式管理内存。任何依赖此操作以提高性能的代码很可能是错误的。另外,请记住JVM完全可以忽略您的请求。
如果您想要更多信息,建议阅读以下答案:
在某些情况下调用System.gc()是有用的:
可能还有更多用例,但这不是您很快就需要的。大多数情况下最好让它按照自己的方式工作。
不打算回答这个问题,显式调用垃圾收集器是一种非常糟糕的做法,但是Java中的某些代码确实依赖于finalization...并试图强制执行它。在某些分析场景下调用它也是有用的。没有标准的JVM会忽略System.gc()。当然,它可以被禁用。然而,由于垃圾收集器管理Java引用到外部资源,因此可能需要它。
以下是来自java.nio.Bits的一些代码:
static void reserveMemory(long size) {
synchronized (Bits.class) {
if (!memoryLimitSet && VM.isBooted()) {
maxMemory = VM.maxDirectMemory();
memoryLimitSet = true;
}
if (size <= maxMemory - reservedMemory) {
reservedMemory += size;
return;
}
}
System.gc();
try {
Thread.sleep(100);
} catch (InterruptedException x) {
// Restore interrupt status
Thread.currentThread().interrupt();
}
synchronized (Bits.class) {
if (reservedMemory + size > maxMemory)
throw new OutOfMemoryError("Direct buffer memory");
reservedMemory += size;
}
睡眠对于程序的正常运行是必要的(或尝试运行),清理器通常可以在高优先级的finalizer线程上快速执行。
所以是的,在编程中仍然使用它 - 但绝大多数情况下这并不是一个好的实践。
显式地使用System.gc()
是一种反模式,虽然我们使用它来建议JVM进行垃圾清理,但它取决于JVM是否会进行清理,同时还会强制执行一些标准。只有当标准符合要求时,它才会采取行动;否则就不会。
It is said that we cannot force the garbage collection process in java.
这是一个非常流行的观点,但是完全错误。
有几个应用程序定期执行此操作,甚至有一些闪亮的按钮可以点击,确实会执行垃圾回收。换句话说,它们并不是“暗示”垃圾回收器启动垃圾回收,而是真正地强制进行垃圾回收。
因此,这种信念既流行又错误。更不为人知的是如何实际触发这样的垃圾回收,正如我在这里所提问的+6次赞的问题的唯一(且非常模糊)答案所示:
System.gc()
的误用远比正确使用要多得多,但这并不意味着它没有用处。 - maaartinus