Java：线程执行后的内存清理

我们有一个处理大量数据的Java批处理程序

处理完这些数据后，JVM为什么不立即清除垃圾，而不是等待下一次执行

根据我观察到的情况，来自上一次运行的数据保持原样，直到我手动关闭JVM或下一次计划运行开始

我希望JVM立即清除数据，以便在下一次计划运行时，它不必在运行期间并行清除垃圾，希望运行得更快

谢谢你的帮助

编辑： 非常感谢您的快速回复

由于内存中存在这种垃圾，我没有看到对进程的性能有多大影响。 但是，它一直在消耗系统RAM，并影响JVM之外其他程序的内存可用性

---

我的另一个问题是，在开发和调试这个程序的过程中，当程序运行时，我让它运行，但一旦运行完毕，为了分析结果，我必须打开一些其他应用程序，这些应用程序显然需要一些RAM，但JVM不会放弃RAM空间，除非我停止它，影响其他程序的可用性和性能。

您不能强制垃圾收集器运行。您几乎不能建议JVM使用

System.gc（）

运行它。此外，最近的JVM已经针对内存管理进行了相当优化，因此不要期望在自己调用

System.gc（）

之后会有任何大的改进。

JVM的gc非常高效，要使其“更高效”并不容易。除非您有严重的性能问题，否则我不会尝试做任何事情

如果您有严重的性能问题，您应该研究其他可能性，主要是在您的代码上。这几乎从来都不是GC

---

话虽如此，我的实际建议是看看是否有什么东西保留了对数据的引用。如果只通过下一次运行清除了引用，则可以解释症状。是否有线程实际上与GC资格无关。重要的是您是否有对数据的实时引用

JVM使用gc策略运行垃圾收集器。几乎所有GC都发生在分配失败时。您可以调用System.gc（）；但不建议采用这种方式

如果您认为JVM会影响其他应用程序，那么将大内存分配给JVM不是一个好主意。GC选项可以根据jvm版本和使用的GC选项进行调优。 jvm可能正在运行默认的串行收集器，这对于较大的堆大小来说不是一个好的选择。请看并发标记扫描收集器，它同时执行垃圾收集

如果使用1.7，请查看g1垃圾收集器

---

最重要的是确保在代码中释放不需要的对象，并且没有内存泄漏。

通常情况下，过于频繁地运行GC不是一个好主意，因此稍后再运行GC是一个很好的折衷策略。但是你可以遵循一种不同的策略，需要注意的是“活动引用”指的是通过正在运行或尚未运行的线程的强引用可以访问的任何对象。所以有一点联系。