我需要帮助理解从jmap
和jstat
获得的与GC相关的数字如何与传递给Java的设置相关。我在内存为16GB的服务器上使用以下设置启动应用程序(solr):
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -Xms12144m -Xmx12144m -XX:NewRatio=4 -XX:SurvivorRatio=8 -XX:+UseCompressedOops
jmap
的输出开始:
Concurrent Mark-Sweep GC Heap Configuration: MinHeapFreeRatio = 40 MaxHeapFreeRatio = 70 MaxHeapSize = 12733906944 (12144.0MB) NewSize = 2686976 (2.5625MB) MaxNewSize = 130809856 (124.75MB) OldSize = 5439488 (5.1875MB) NewRatio = 4 SurvivorRatio = 8 PermSize = 21757952 (20.75MB) MaxPermSize = 176160768 (168.0MB)
为什么newsize
、maxnewsize
、oldsize
和permsize
都这么小,而maxheapsize
却很大?newsize+OldSize=heap size
不应该吗?并且总的堆大小不应该接近maxheapsize
吗?当newRatio
设置为4时,为什么newSize
正好是oldSize
的一半?
下面是jmap
输出的其余部分。它与上面的内容相匹配,并且包括一个并发标记扫描生成
部分,我也不知道如何解释。
此外,GC日志表明“期望的幸存者大小”是6.2MB,这也很奇怪,因为我理解-xx:survivorratio=8
应该使幸存者空间为newsize
的1/8。
最后,我在GC日志中只看到parnew
消息,我认为这是GC for Eden。
Heap Usage: New Generation (Eden + 1 Survivor Space): capacity = 117768192 (112.3125MB) used = 20402232 (19.45708465576172MB) free = 97365960 (92.85541534423828MB) 17.324059793666528% used Eden Space: capacity = 104726528 (99.875MB) used = 16408336 (15.648208618164062MB) free = 88318192 (84.22679138183594MB) 15.667793359863893% used From Space: capacity = 13041664 (12.4375MB) used = 3993896 (3.8088760375976562MB) free = 9047768 (8.628623962402344MB) 30.624128945508794% used To Space: capacity = 13041664 (12.4375MB) used = 0 (0.0MB) free = 13041664 (12.4375MB) 0.0% used concurrent mark-sweep generation: capacity = 12603097088 (12019.25MB) used = 7903352408 (7537.22420501709MB) free = 4699744680 (4482.02579498291MB) 62.70960505037411% used Perm Generation: capacity = 45903872 (43.77734375MB) used = 27759192 (26.473228454589844MB) free = 18144680 (17.304115295410156MB) 60.472441191889% used
MaxHeapSize很大,为什么NewSize、MaxNewSize、OldSize和PermSize都这么小?
尺寸只需要它们需要多大就多大。如果生成更多短期垃圾,则NewSize会更大(我不知道MaxNewSize是如何设置的,但它通常比我设置的要小)
并发标记扫描生成
正如你所注意到的,新的空间很小,所以它经常清理,而旧的空间很大,所以它很少清理,如果有的话。
问题内容: 是否有可能使Go中的垃圾收集器处理并释放通过C代码分配的内存?抱歉,我之前没有使用过C和cgo,因此我的示例可能需要澄清。 假设您有一些要使用的C库,并且该库分配了一些需要手动释放的内存。我想做的是这样的: 当Go运行时中没有对* Stuff的引用时,垃圾收集器是否可以调用Stuff.Free()? 我在这里有意义吗? 也许更直接的问题是:是否有可能通过编写一个在该对象的引用为零时运行
Kubernetes 垃圾收集器的角色是删除指定的对象,这些对象曾经有但以后不再拥有 Owner 了。 注意:垃圾收集是 beta 特性,在 Kubernetes 1.4 及以上版本默认启用。 Owner 和 Dependent 一些 Kubernetes 对象是其它一些的 Owner。例如,一个 ReplicaSet 是一组 Pod 的 Owner。具有 Owner 的对象被称为是 Owner
问题内容: 我有一段代码可以在内存中加载很大的图像。所以打电话似乎是合理的事情 在加载图像之前。据我所知,它毫无问题。 昨天,我决定使用一个名为FindBugs的非常有用的软件来扫描您的代码并报告可能导致错误或通常不建议使用的策略的问题。问题是我提到的这段代码得到了报告。描述是这样的: …强迫垃圾收集;除了基准测试代码外,都非常可疑 并继续阐述: 代码显式调用垃圾回收。除了基准测试中的特定用途外,
一、垃圾收集算法 1.标记-清除算法 最基础的收集算法是“标记-清除”(Mark-Sweep)算法,如同它的名字一样,算法分为“标记”和“清除”两个阶段。 ①首先标记出所有需要回收的对象 ②在标记完成后统一回收所有被标记的对象。 不足: 效率问题:标记和清除两个过程的效率都不高 空间问题:标记清除之后产生大量不连续的内存碎片,空间碎片太多可能会导致以后程序运行过程中需要分配较大对象时,无法找到足够
问题内容: 有人可以解释一下G1垃圾收集器的工作原理吗?我还无法在任何地方找到任何全面,易于理解的描述。 谢谢 问题答案: 收集器将堆分成固定大小的区域,并跟踪这些区域中的实时数据。它将一组指针(“记住的集”)保留在区域内和区域外。当认为有必要使用GC时,它将首先收集实时数据较少的区域(因此,“垃圾优先”)。通常,这意味着一步就可以收集整个区域:如果进入一个区域的指针数量为零,则无需对该区域进行标
[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