故事
我的服务器使用 24x2 处理器运行，Java 堆大约有 70 GB。 在安装新版本(版本 B)后的某个时候，我看到 Full GC 大约需要 30 秒(停止所有线程)。启用 XX:+ParallelRefProcEnabled 后，弱引用处理时间下降到大约 3-6 秒。但这只是“助弯剂”，并不是治愈方法。
2011-03-22T20:38:24.276+0000: 29540.794: [GC[YG occupancy: 5477281 K (7549760 K)]29540.794: [Rescan (parallel) , 0.4083780 secs]29541.203: [weak refs processing, 3.2855240 secs]29544.488: [class unloading, 0.0187270 secs]29544.507: [scrub symbol & string tables, 0.0095530 secs] [1 CMS-remark: 102801236K(114294784K)] 108278518K(121844544K), 3.7319690 secs] [Times: user=65.53 sys=0.14, real=3.73 secs]
在版本 B 之前(并且没有 ParallelRefProcEnabled 标志)弱引用处理通常需要大约 1.5 秒。 (对于大致相同的负载)
目的:
我想知道的是，引入版本 B 的更改是什么导致处理时间从 1.5 秒跳到 30 秒。 版本 B 有一些变化，没有真正怀疑涉及弱引用。
我想更改我的代码，这样它就不会依赖于繁重的弱引用处理。
问题:
我想了解在“弱引用处理”阶段到底发生了什么，这样我就可以寻找可疑之处，或者证明代码重写是合理的。有没有关于该阶段究竟发生了什么的好资源？
长时间“弱引用处理”的可能原因是什么？ (弱引用实例的数量，持有弱引用的对象的数量，弱引用的引用树的深度，...)
更多信息:
- CPU 使用率不是很高，似乎不是问题
- GC(包括弱引用处理)大约每 8 分钟发生一次。
- 运行 Java Sun，1.6.0_20
如果有任何回复，我将不胜感激， 谢谢， 埃雷兹。
最佳答案
AFAIK，引用处理时间是确定是否可以收集引用所需的时间。这应该与您拥有的 WeakReferences 的数量成正比。
数据结构的改变可能会显着减少弱引用的数量。例如假设您有一个使用 Map of WeakReferences 的缓存。如果可以将其替换为对 Map 的 WeakReference，您可能会得到相同的结果，但引用会大大减少。
您可能会看到 Java 6 update 24 的性能改进，它具有更新得多的 JVM(大约更新一年)
关于java - 我做了什么使 "weak refs processing"需要 30 秒而不是 1.5 秒？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5422204/