Young GC越来越耗时

• 前提：服务用的是CMS垃圾收集器         
• 现象 ：当每次CMS GC后 YoungGc会变正常，但是后面越来越慢
• 可能的原因  （1）StringTable太大    （2）存在老生代到新生代的引用
• 对于第一种情况定位

  83245.952: [GC (CMS Initial Mark) [1 CMS-initial-mark: 1619782K(2023424K)] 1686491K(2722496K), 0.0077340 secs] [Times: user=0.03 sys=0.00, real=0.01 secs]
  83245.960: Total time for which application threads were stopped: 0.0094512 seconds, Stopping threads took: 0.0000811 seconds
  83245.960: [CMS-concurrent-mark-start]
  83246.101: [CMS-concurrent-mark: 0.140/0.140 secs] [Times: user=0.16 sys=0.00, real=0.14 secs]
  83246.101: [CMS-concurrent-preclean-start]
  83246.106: [CMS-concurrent-preclean: 0.005/0.005 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
  83246.106: [CMS-concurrent-abortable-preclean-start]
  83249.717: [CMS-concurrent-abortable-preclean: 3.609/3.611 secs] [Times: user=3.89 sys=0.04, real=3.61 secs]
  83249.719: [GC (CMS Final Remark) [YG occupancy: 248182 K (699072 K)]83249.719: [Rescan (parallel) , 0.0364698 secs]83249.755: [weak refs processing, 0.0005544 secs]83249.756: [class unloading, 0.0361213 secs]83249.792: [scrub symbol table, 0.0085194 secs]83249.800: [scrub string table, 0.0014245 secs][1 CMS-remark: 1619782K(2023424K)] 1867964K(2722496K), 0.0989427 secs] [Times: user=0.21 sys=0.00, real=0.10 secs]
  83249.818: Total time for which application threads were stopped: 0.1008135 seconds, Stopping threads took: 0.0001093 seconds
  83249.818: [CMS-concurrent-sweep-start]
  83250.378: [CMS-concurrent-sweep: 0.560/0.560 secs] [Times: user=0.61 sys=0.00, real=0.56 secs]
  83250.379: [CMS-concurrent-reset-start]
  83250.383: [CMS-concurrent-reset: 0.004/0.004 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
  
  jvm日志中scrub string table, 0.0014245 secs   如果耗时比较长的话，就代表StringTable太大
  
  
  
  fastjson和jackson来把Stirng对象返序列化成类

   

•  如果老年代引用年轻代太多的话，会降低YoungGc的速度