从gc.log(重新格式化)：
10388.186: [GC[YG occupancy: 206547 K (306688 K)]10388.186: [Rescan (parallel),0.1095860 secs]10388.295: [weak refs processing,2.0799570 secs] [1 CMS-remark: 2973838K(3853568K)] 3180386K(4160256K),2.1899230 secs] [Times: user=2.51 sys=0.00,real=2.18 secs] Total time for which application threads were stopped: 2.1906890 seconds
目前我已经有了这些设置.尝试更简单的设置,但没有变化.
-Xms4g -Xmx4g -XX:NewSize=128m -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:MaxGCPauseMillis=50 -XX:CMSInitiatingOccupancyFraction=50 -XX:ParallelGCThreads=16 -XX:+DisableExplicitGC
如果我打开NewSize,我最终会遇到长时间的GC循环.该机器有8个内核,不会为应用程序烧录太多的cpu.试图早期和同时运行旧gen GC.
是的,我不能摆脱弱参考用法,因为这是第三方图书馆的一部分.
解决方法
简而言之,尝试-XX：ParallelRefProcEnabled开关.
UPDATE
我在Jon Masamitsu的Weblog中发现了一个更好的解释：
6) Parallel reference processing in the low pause collector.
For an application that uses 07002 objects extensively,the GC work to process the Reference objects can be noticeable. It’s not necessarily worse in the low pause collector than in the other collects,but it hurts more (because we’re trying to keep the pauses low). Parallel reference processing is available for the low pause collector but is not on by default. Unless there are tons of Reference Objects,doing the reference processing serially is usually faster. Turn it on with the flag
-XX:+ParallelRefProcEnabledif you make extensive use ofReferenceObjects (most applications don’t).
