此外，似乎没有人敢赞成，也不敢反对我的回答。System.gc()``System.gc()
System.gc()``System.gc()
有人告诉我这是不好的做法，但后来我也被告知垃圾收集器运行不会再系统地停止世界，它也可以被 JVM 有效地用作提示，所以我有点不知所措。
我确实理解 JVM 在需要回收内存时通常比您更清楚。我也明白担心几千字节的数据是愚蠢的。我也明白，即使是兆字节的数据也不是几年前的样子。但是，1.5 GB？而且您 知道 内存中大约有 1.5 GB 的数据；这不像是在黑暗中拍摄。是System.gc()系统性的不好，还是在某个时候它变得好起来了？
System.gc()
所以问题实际上是双重的：
每个人总是说要避免的原因System.gc()是它是一个 很好的指标，表明根本上的代码被破坏了 。任何依赖它来保证正确性的代码肯定会被破坏；任何依赖它来获得性能的东西都很可能被破坏。
您不知道您正在运行哪种垃圾收集器。当然，有些 JVM 不会像您断言的那样 “阻止世界” ，但有些 JVM 并不那么聪明或出于各种原因（也许它们在电话上？）不这样做。你不知道它会做什么。
此外，它不能保证做任何事情。JVM 可能会完全忽略您的请求。
“你不知道它会做什么”、“你不知道它是否会有所帮助”和“无论如何你都不应该调用它”的组合是为什么人们通常如此有力地说你不应该打电话给它。我认为这是“如果您需要询问是否应该使用它，则不应该”的情况
编辑 以解决另一个线程的一些问题：
在阅读了您链接的主题后，我还想指出一些事情。首先，有人建议调用gc()可能会将内存返回给系统。这当然不一定是正确的——Java 堆本身的增长独立于 Java 分配。
gc()
例如，JVM 将持有内存（数十兆字节）并根据需要增加堆。即使释放 Java 对象，它也不一定会将内存返回给系统；保留分配的内存以用于未来的 Java 分配是完全自由的。
要表明它可能System.gc()什么都不做，请查看 JDK 错误 6668279 ，特别是有一个-XX:DisableExplicitGCVM 选项：
-XX:DisableExplicitGC
默认情况下System.gc()启用调用 ( -XX:-DisableExplicitGC)。用于-XX:+DisableExplicitGC禁用对 的调用System.gc()。请注意，JVM 在必要时仍会执行垃圾收集。
-XX:-DisableExplicitGC
-XX:+DisableExplicitGC
