为什么在垃圾收集中使长寿命的对象有所作为？
我经常读到，在Sun JVM中，短寿命对象（“相对较新的对象”）比长寿命对象（“相对较旧的对象”）可以更有效地进行垃圾回收。
- 为什么呢？
- 这是特定于Sun JVM还是由一般的垃圾回收原理导致？
问题答案：
大多数Java应用程序都会创建Java对象，然后很快将其丢弃。您可以在方法中创建一些对象，然后一旦退出该方法，所有对象都会死亡。大多数应用程序都是以这种方式运行的，并且大多数人倾向于以这种方式编写其应用程序的代码。Java堆大致分为三部分，永久的，老的（长寿）一代和年轻的（短寿）一代。Young
gen进一步细分为S1，S2和Eden。这些只是堆。
大多数对象都是在年轻一代中创建的。这里的想法是，由于对象的死亡率很高，因此我们快速创建它们，使用它们然后丢弃它们。速度至关重要。创建对象时，年轻的gen会填满，直到出现次要的GC。在次要GC中，将所有活动对象从eden复制并说S2到S1。然后，将“指针”放在eden和S2上。
每个副本都会老化该对象。默认情况下，如果对象存活32个副本，即。32个次要GC，然后GC认为它将存在更长时间。因此，它要做的就是通过将其移交给旧一代来保有它。老一代只是一个大空间。当旧一代填满时，旧一代会发生一个完整的GC或主要GC。由于没有其他空间可复制到，因此GC必须紧凑。这比次要GC慢很多，这就是为什么我们避免更频繁地这样做。
您可以使用
java -XX:MaxTenuringThreshold=16
如果您知道自己有很多寿命长的物体。您可以使用以下命令打印应用程序的各个年龄段
java -XX:-PrintTenuringDistribution
-
有人能给我解释一下原因吗？
-
我试图理解是什么保存了对对象的引用，使得它们在执行Java流终端操作时不符合垃圾收集的条件？ 这是我的测试代码 从未调用LargetObject的finalize方法。 我的想法是一旦. map（largeObject- 为什么这不会发生？也许真的可以做些什么？
-
[GC（分配失败）[defnew:10931K->472K(12288K),0.0053905秒]10931K->10712K(39616K),0.0054285秒][times:user=0.00 sys=0.00,real=0.01秒] [GC（分配失败）[defnew:10712k->472k(12288k),0.0057686秒]20952k->20952k(39616k),0.00580
-
问题内容： 我有两节课 假设我在代码中使用对象B [say ]，并在最终使用它后将其设置为。我知道B的对象现在可用于垃圾回收了。 我知道在将b设置为null之后，它将 立即有资格 进行垃圾回收吗？但是类型A的对象呢？将B设置为以后，是否可以 立即 将其用于垃圾回收？还是 在B被垃圾回收之后 才有资格 进行 垃圾回收 ？ 从理论上讲，在对B进行垃圾收集之前，还有参考吗？因此，SUN JVM编译器将在
-
每个java开发人员都知道，java对象不再使用时将被垃圾收集。我想知道JVM如何识别必须为垃圾收集选择的对象。（例如，如果我有10个对象。如果对10个对象中的2个进行垃圾收集，jvm将如何找到这两个对象）。 JVM使用标记和扫描算法（如果我是对的）。 1）例如我在下面提供字符串对象场景 //现在s1
-
问题内容： 我是Java新手，对Java中的垃圾收集器感到困惑。它实际上是做什么的，什么时候生效。请描述Java中垃圾收集器的一些属性。 问题答案： 该垃圾收集器是运行在一个程序的Java虚拟机，其摆脱其未使用的Java应用程序了对象。它是自动内存管理的一种形式。 当典型的Java应用程序运行时，它正在创建新的对象，例如和，但是在一段时间之后，这些对象将不再使用。例如，看下面的代码： 在上面的代码