我很难理解以下内容：
“Java语言规范允许使用虚拟gc（）方法。”
为什么标准会这样做？
它有效地构成了java 可选的一个非常重要的特性。
这也意味着我的同一个程序在两个不同的JVM上表现不同实施!!!完全违反Java 可移植性的重要特性。
答案 0 :(得分：13)
它有效地构成了java可选的一个非常重要的特性。
GC中 不是可选的。可选的是显式垃圾收集，由对gc()的调用触发。这是完全可以接受的，因为很少需要显式触发垃圾收集并干扰现代垃圾收集器的功能。
答案 1 :(得分：6)
调用gc方法表明Java虚拟机花费了大量精力来回收未使用的对象，以使其当前占用的内存可用于快速重用。当控制从方法调用返回时，Java虚拟机已尽最大努力从所有丢弃的对象中回收空间。
不保证调用gc()会触发垃圾回收。即你不能强制垃圾收集。这就是为什么这个方法可以是假的。
上面提到的“尽力而为”可能是“等待隐式垃圾收集”。
答案 2 :(得分：4)
这也意味着我的同一个计划 两个人的表现会有所不同 不同的JVM实现！ 完全违反Java的东西 便携性的重要特征。
不同JVM实现之间的这种差异实际上是一件好事。它允许改进不影响程序正确性的底层细节，通常可以提高性能。垃圾收集恰好是JVM规范关注的一个领域，允许实现空间基本上尝试不同的方法来解决问题。 Sun明确声明调用gc（）不会强制进行内存扫描，因此程序员不能声称他们期望每个JVM都有某种行为。
答案 3 :(得分：2)
核心理念 - gc（）是可选的，如果需要，你可以强制收集垃圾。
但是你仍然应该有“自动”垃圾收集。 gc（）只是让程序越来越有效
答案 4 :(得分：2)
通常一个好主意是让JVM在需要进行垃圾收集时解决，而不是明确告诉它这样做。 Java规范允许虚拟方法这一事实并没有改变Java进行垃圾收集的事实，它只是意味着它可以忽略来自您明确执行它的请求。
这是一篇关于Java中垃圾收集的好文章（稍微陈旧），它在System.gc（）上有一个简短的段落：http://www.ibm.com/developerworks/library/j-jtp01274.html
答案 5 :(得分：1)
如果您的程序依赖于System.gc（），您应该重新考虑您的设计或更改为其他编程语言。
垃圾收集可以在每个vm上实现不同，而sun vm单独实现几种不同的实现
知道你的程序以什么方式依赖System.gc（）会很有趣。 如果是终结器，它们会遇到自己的问题，只能用于帮助调试。