零. 简介
垃圾收集器长时间停顿,表现在 Web 页面上可能是页面响应码 500 之类的服务器错误问题,如果是个支付过程可能会导致支付失败,将造成公司的直接经济损失,程序员要尽量避免或者说减少此类情况发生。



一. 并发模式失败(concurrent mode failure)

并发模式失败日志:

  1. 2016-02-21T13:53:07.974+0800: 171467.254: [GC [1 CMS-initial-mark: 1436199K(1560576K)] 1512927K(2504320K), 0.0618140 secs] [Times: user=0.06 sys=0.00, real=0.07 secs]
  2. 2016-02-21T13:53:08.036+0800: 171467.316: [CMS-concurrent-mark-start]
  3. 2016-02-21T13:53:08.377+0800: 171467.657: [CMS-concurrent-mark: 0.340/0.340 secs] [Times: user=2.11 sys=0.15, real=0.34 secs]
  4. 2016-02-21T13:53:08.377+0800: 171467.657: [CMS-concurrent-preclean-start]
  5. 2016-02-21T13:53:08.385+0800: 171467.665: [CMS-concurrent-preclean: 0.008/0.008 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
  6. 2016-02-21T13:53:08.385+0800: 171467.665: [CMS-concurrent-abortable-preclean-start]
  7. {Heap before GC invocations=88667 (full 45):
  8. par new generation   total 943744K, used 914399K [0x0000000757000000, 0x0000000797000000, 0x0000000797000000)
  9. eden space 838912K, 100% used [0x0000000757000000, 0x000000078a340000, 0x000000078a340000)
  10. from space 104832K,  72% used [0x000000078a340000, 0x000000078ecf7d98, 0x00000007909a0000)
  11. to   space 104832K,   0% used [0x00000007909a0000, 0x00000007909a0000, 0x0000000797000000)
  12. concurrent mark-sweep generation total 1560576K, used 1436199K [0x0000000797000000, 0x00000007f6400000, 0x00000007f6400000)
  13. concurrent-mark-sweep perm gen total 159744K, used 78413K [0x00000007f6400000, 0x0000000800000000, 0x0000000800000000)
  14. 2016-02-21T13:53:09.535+0800: 171468.815: [GC2016-02-21T13:53:09.535+0800: 171468.815: [ParNew
  15. Desired survivor size 53673984 bytes, new threshold 6 (max 6)
  16. - age   1:    7100568 bytes,    7100568 total
  17. - age   2:    4676456 bytes,   11777024 total
  18. - age   3:    8773736 bytes,   20550760 total
  19. - age   4:    7709744 bytes,   28260504 total
  20. - age   5:   10891960 bytes,   39152464 total
  21. - age   6:   11735032 bytes,   50887496 total
  22. : 914399K->75616K(943744K), 0.0414860 secs] 2350599K->1517225K(2504320K), 0.0417710 secs] [Times: user=0.32 sys=0.05, real=0.05 secs]
  23. Heap after GC invocations=88668 (full 45):
  24. par new generation   total 943744K, used 75616K [0x0000000757000000, 0x0000000797000000, 0x0000000797000000)
  25. eden space 838912K,   0% used [0x0000000757000000, 0x0000000757000000, 0x000000078a340000)
  26. from space 104832K,  72% used [0x00000007909a0000, 0x0000000795378128, 0x0000000797000000)
  27. to   space 104832K,   0% used [0x000000078a340000, 0x000000078a340000, 0x00000007909a0000)
  28. concurrent mark-sweep generation total 1560576K, used 1441609K [0x0000000797000000, 0x00000007f6400000, 0x00000007f6400000)
  29. concurrent-mark-sweep perm gen total 159744K, used 78413K [0x00000007f6400000, 0x0000000800000000, 0x0000000800000000)
  30. }
  31. 2016-02-21T13:53:10.202+0800: 171469.482: [CMS-concurrent-abortable-preclean: 1.772/1.817 secs] [Times: user=4.94 sys=0.06, real=1.81 secs]
  32. 2016-02-21T13:53:10.204+0800: 171469.483: [GC[YG occupancy: 497152 K (943744 K)]2016-02-21T13:53:10.204+0800: 171469.483: [Rescan (parallel) , 1.3691900 secs]2016-02-21T13:53:11.573+0800: 171470.853: [weak refs processing, 0.1009300 secs]2016-02-21T13:53:11.674+0800: 1714
  33. 70.954: [class unloading, 0.0153470 secs]2016-02-21T13:53:11.689+0800: 171470.969: [scrub symbol table, 0.0110770 secs]2016-02-21T13:53:11.700+0800: 171470.980: [scrub string table, 0.0016360 secs] [1 CMS-remark: 1441609K(1560576K)] 1938761K(2504320K), 1.5079530 secs] [Ti
  34. mes: user=13.01 sys=0.08, real=1.51 secs]
  35. 2016-02-21T13:53:11.712+0800: 171470.992: [CMS-concurrent-sweep-start]
  36. {Heap before GC invocations=88668 (full 45):
  37. par new generation   total 943744K, used 914528K [0x0000000757000000, 0x0000000797000000, 0x0000000797000000)
  38. eden space 838912K, 100% used [0x0000000757000000, 0x000000078a340000, 0x000000078a340000)
  39. from space 104832K,  72% used [0x00000007909a0000, 0x0000000795378128, 0x0000000797000000)
  40. to   space 104832K,   0% used [0x000000078a340000, 0x000000078a340000, 0x00000007909a0000)
  41. concurrent mark-sweep generation total 1560576K, used 1441606K [0x0000000797000000, 0x00000007f6400000, 0x00000007f6400000)
  42. concurrent-mark-sweep perm gen total 159744K, used 78413K [0x00000007f6400000, 0x0000000800000000, 0x0000000800000000)
  43. 2016-02-21T13:53:11.775+0800: 171471.055: [GC2016-02-21T13:53:11.775+0800: 171471.055: [ParNew (promotion failed)
  44. Desired survivor size 53673984 bytes, new threshold 6 (max 6)
  45. - age   1:    4030872 bytes,    4030872 total
  46. - age   2:    5959704 bytes,    9990576 total
  47. - age   3:    4628680 bytes,   14619256 total
  48. - age   4:    8773080 bytes,   23392336 total
  49. - age   5:    7707144 bytes,   31099480 total
  50. - age   6:   10890224 bytes,   41989704 total
  51. : 914528K->907344K(943744K), 1.0312010 secs]2016-02-21T13:53:12.807+0800: 171472.086: [CMS2016-02-21T13:53:14.455+0800: 171473.735: [CMS-concurrent-sweep: 1.684/2.743 secs] [Times: user=3.69 sys=0.36, real=2.74 secs]
  52. (concurrent mode failure): 1451903K->475795K(1560576K), 3.9644230 secs] 2356134K->475795K(2504320K), [CMS Perm : 78413K->78413K(159744K)], 4.9959570 secs] [Times: user=5.65 sys=0.34, real=5.00 secs]
  53. Heap after GC invocations=88669 (full 46):
  54. par new generation   total 943744K, used 0K [0x0000000757000000, 0x0000000797000000, 0x0000000797000000)
  55. eden space 838912K,   0% used [0x0000000757000000, 0x0000000757000000, 0x000000078a340000)
  56. from space 104832K,   0% used [0x000000078a340000, 0x000000078a340000, 0x00000007909a0000)
  57. to   space 104832K,   0% used [0x00000007909a0000, 0x00000007909a0000, 0x0000000797000000)
  58. concurrent mark-sweep generation total 1560576K, used 475795K [0x0000000797000000, 0x00000007f6400000, 0x00000007f6400000)
  59. concurrent-mark-sweep perm gen total 159744K, used 78413K [0x00000007f6400000, 0x0000000800000000, 0x0000000800000000)
  60. }
2016-02-21T13:53:07.974+0800: 171467.254: [GC [1 CMS-initial-mark: 1436199K(1560576K)] 1512927K(2504320K), 0.0618140 secs] [Times: user=0.06 sys=0.00, real=0.07 secs]
2016-02-21T13:53:08.036+0800: 171467.316: [CMS-concurrent-mark-start]
2016-02-21T13:53:08.377+0800: 171467.657: [CMS-concurrent-mark: 0.340/0.340 secs] [Times: user=2.11 sys=0.15, real=0.34 secs]
2016-02-21T13:53:08.377+0800: 171467.657: [CMS-concurrent-preclean-start]
2016-02-21T13:53:08.385+0800: 171467.665: [CMS-concurrent-preclean: 0.008/0.008 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
2016-02-21T13:53:08.385+0800: 171467.665: [CMS-concurrent-abortable-preclean-start]
{Heap before GC invocations=88667 (full 45):
par new generation total 943744K, used 914399K [0x0000000757000000, 0x0000000797000000, 0x0000000797000000)
eden space 838912K, 100% used [0x0000000757000000, 0x000000078a340000, 0x000000078a340000)
from space 104832K, 72% used [0x000000078a340000, 0x000000078ecf7d98, 0x00000007909a0000)
to space 104832K, 0% used [0x00000007909a0000, 0x00000007909a0000, 0x0000000797000000)
concurrent mark-sweep generation total 1560576K, used 1436199K [0x0000000797000000, 0x00000007f6400000, 0x00000007f6400000)
concurrent-mark-sweep perm gen total 159744K, used 78413K [0x00000007f6400000, 0x0000000800000000, 0x0000000800000000)
2016-02-21T13:53:09.535+0800: 171468.815: [GC2016-02-21T13:53:09.535+0800: 171468.815: [ParNew
Desired survivor size 53673984 bytes, new threshold 6 (max 6)
- age 1: 7100568 bytes, 7100568 total
- age 2: 4676456 bytes, 11777024 total
- age 3: 8773736 bytes, 20550760 total
- age 4: 7709744 bytes, 28260504 total
- age 5: 10891960 bytes, 39152464 total
- age 6: 11735032 bytes, 50887496 total
: 914399K->75616K(943744K), 0.0414860 secs] 2350599K->1517225K(2504320K), 0.0417710 secs] [Times: user=0.32 sys=0.05, real=0.05 secs]
Heap after GC invocations=88668 (full 45):
par new generation total 943744K, used 75616K [0x0000000757000000, 0x0000000797000000, 0x0000000797000000)
eden space 838912K, 0% used [0x0000000757000000, 0x0000000757000000, 0x000000078a340000)
from space 104832K, 72% used [0x00000007909a0000, 0x0000000795378128, 0x0000000797000000)
to space 104832K, 0% used [0x000000078a340000, 0x000000078a340000, 0x00000007909a0000)
concurrent mark-sweep generation total 1560576K, used 1441609K [0x0000000797000000, 0x00000007f6400000, 0x00000007f6400000)
concurrent-mark-sweep perm gen total 159744K, used 78413K [0x00000007f6400000, 0x0000000800000000, 0x0000000800000000)
}
2016-02-21T13:53:10.202+0800: 171469.482: [CMS-concurrent-abortable-preclean: 1.772/1.817 secs] [Times: user=4.94 sys=0.06, real=1.81 secs]
2016-02-21T13:53:10.204+0800: 171469.483: [GC[YG occupancy: 497152 K (943744 K)]2016-02-21T13:53:10.204+0800: 171469.483: [Rescan (parallel) , 1.3691900 secs]2016-02-21T13:53:11.573+0800: 171470.853: [weak refs processing, 0.1009300 secs]2016-02-21T13:53:11.674+0800: 1714
70.954: [class unloading, 0.0153470 secs]2016-02-21T13:53:11.689+0800: 171470.969: [scrub symbol table, 0.0110770 secs]2016-02-21T13:53:11.700+0800: 171470.980: [scrub string table, 0.0016360 secs] [1 CMS-remark: 1441609K(1560576K)] 1938761K(2504320K), 1.5079530 secs] [Ti
mes: user=13.01 sys=0.08, real=1.51 secs]
2016-02-21T13:53:11.712+0800: 171470.992: [CMS-concurrent-sweep-start]
{Heap before GC invocations=88668 (full 45):
par new generation total 943744K, used 914528K [0x0000000757000000, 0x0000000797000000, 0x0000000797000000)
eden space 838912K, 100% used [0x0000000757000000, 0x000000078a340000, 0x000000078a340000)
from space 104832K, 72% used [0x00000007909a0000, 0x0000000795378128, 0x0000000797000000)
to space 104832K, 0% used [0x000000078a340000, 0x000000078a340000, 0x00000007909a0000)
concurrent mark-sweep generation total 1560576K, used 1441606K [0x0000000797000000, 0x00000007f6400000, 0x00000007f6400000)
concurrent-mark-sweep perm gen total 159744K, used 78413K [0x00000007f6400000, 0x0000000800000000, 0x0000000800000000)
2016-02-21T13:53:11.775+0800: 171471.055: [GC2016-02-21T13:53:11.775+0800: 171471.055: [ParNew (promotion failed)
Desired survivor size 53673984 bytes, new threshold 6 (max 6)
- age 1: 4030872 bytes, 4030872 total
- age 2: 5959704 bytes, 9990576 total
- age 3: 4628680 bytes, 14619256 total
- age 4: 8773080 bytes, 23392336 total
- age 5: 7707144 bytes, 31099480 total
- age 6: 10890224 bytes, 41989704 total
: 914528K->907344K(943744K), 1.0312010 secs]2016-02-21T13:53:12.807+0800: 171472.086: [CMS2016-02-21T13:53:14.455+0800: 171473.735: [CMS-concurrent-sweep: 1.684/2.743 secs] [Times: user=3.69 sys=0.36, real=2.74 secs]
(concurrent mode failure): 1451903K->475795K(1560576K), 3.9644230 secs] 2356134K->475795K(2504320K), [CMS Perm : 78413K->78413K(159744K)], 4.9959570 secs] [Times: user=5.65 sys=0.34, real=5.00 secs]
Heap after GC invocations=88669 (full 46):
par new generation total 943744K, used 0K [0x0000000757000000, 0x0000000797000000, 0x0000000797000000)
eden space 838912K, 0% used [0x0000000757000000, 0x0000000757000000, 0x000000078a340000)
from space 104832K, 0% used [0x000000078a340000, 0x000000078a340000, 0x00000007909a0000)
to space 104832K, 0% used [0x00000007909a0000, 0x00000007909a0000, 0x0000000797000000)
concurrent mark-sweep generation total 1560576K, used 475795K [0x0000000797000000, 0x00000007f6400000, 0x00000007f6400000)
concurrent-mark-sweep perm gen total 159744K, used 78413K [0x00000007f6400000, 0x0000000800000000, 0x0000000800000000)
}
两个原因:
  • 在 CMS 启动过程中,新生代提升速度过快,老年代收集速度赶不上新生代提升速度
  • 在 CMS 启动过程中,老年代碎片化严重,无法容纳新生代提升上来的大对象

发送这种情况,应用线程将会全部停止(相当于网站这段时间无法响应用户请求),进行压缩式垃圾收集(回退到 Serial Old 算法)

解决办法:
  • 新生代提升过快问题:(1)如果频率太快的话,说明空间不足,首先可以尝试调大新生代空间和晋升阈值。(2)如果内存有限,可以设置 CMS 垃圾收集在老年代占比达到多少时启动来减少问题发生频率(越早启动问题发生频率越低,但是会降低吞吐量,具体得多调整几次找到平衡点),参数如下:如果没有第二个参数,会随着 JVM 动态调节 CMS 启动时间
-XX:CMSInitiatingOccupancyFraction=68 (默认是 68)
-XX:+UseCMSInitiatingOccupancyOnly

  • 老年代碎片严重问题:(1)如果频率太快或者 Full GC 后空间释放不多的话,说明空间不足,首先可以尝试调大老年代空间(2)如果内存不足,可以设置进行 n 次 CMS 后进行一次压缩式 Full GC,参数如下:
-XX:+UseCMSCompactAtFullCollection:允许在 Full GC 时,启用压缩式 GC
-XX:CMSFullGCBeforeCompaction=n     在进行 n 次,CMS 后,进行一次压缩的 Full GC,用以减少 CMS 产生的碎片



二. 提升失败(promotion failed)
在 Minor GC 过程中,Survivor Unused 可能不足以容纳 Eden 和另一个 Survivor
中的存活对象, 那么多余的将被移到老年代, 称为过早提升(Premature Promotion)。 这会导致老年代中短期存活对象的增长, 可能会引发严重的性能问题。  再进一步, 如果老年代满了, Minor GC 后会进行 Full GC, 这将导致遍历整个堆, 称为提升失败(Promotion
Failure)。

提升失败日志: 
  1. 2016-01-07T18:54:26.948+0800: 18782.967: [GC2016-04-07T18:54:26.948+0800: 18782.967: [ParNew (promotion failed)
  2. Desired survivor size 117833728 bytes, new threshold 10 (max 10)
  3. - age   1:    6141680 bytes,    6141680 total
  4. - age   2:    6337936 bytes,   12479616 total
  5. - age   3:     549120 bytes,   13028736 total
  6. - age   4:      87768 bytes,   13116504 total
  7. - age   5:     221384 bytes,   13337888 total
  8. - age   6:     934168 bytes,   14272056 total
  9. - age   7:     146072 bytes,   14418128 total
  10. - age   8:     626064 bytes,   15044192 total
  11. - age   9:     398000 bytes,   15442192 total
  12. - age  10:     429616 bytes,   15871808 total
  13. : 1969227K->1929200K(2071808K), 0.7452140 secs]2016-01-07T18:54:27.693+0800: 18783.713: [CMS: 1394703K->632845K(2097152K), 4.0993640 secs] 3301676K->632845K(4168960K), [CMS Perm : 77485K->77473K(159744K)], 4.8450240 secs] [Times: user=5.18 sys=0.56, real=4.84 secs]
  14. Heap after GC invocations=5847 (full 7):
  15. par new generation   total 2071808K, used 0K [0x00000006e9c00000, 0x0000000776400000, 0x0000000776400000)
  16. eden space 1841664K,   0% used [0x00000006e9c00000, 0x00000006e9c00000, 0x000000075a280000)
  17. from space 230144K,   0% used [0x0000000768340000, 0x0000000768340000, 0x0000000776400000)
  18. to   space 230144K,   0% used [0x000000075a280000, 0x000000075a280000, 0x0000000768340000)
  19. concurrent mark-sweep generation total 2097152K, used 632845K [0x0000000776400000, 0x00000007f6400000, 0x00000007f6400000)
  20. concurrent-mark-sweep perm gen total 159744K, used 77473K [0x00000007f6400000, 0x0000000800000000, 0x0000000800000000)
  21. }
2016-01-07T18:54:26.948+0800: 18782.967: [GC2016-04-07T18:54:26.948+0800: 18782.967: [ParNew (promotion failed)
Desired survivor size 117833728 bytes, new threshold 10 (max 10)
- age 1: 6141680 bytes, 6141680 total
- age 2: 6337936 bytes, 12479616 total
- age 3: 549120 bytes, 13028736 total
- age 4: 87768 bytes, 13116504 total
- age 5: 221384 bytes, 13337888 total
- age 6: 934168 bytes, 14272056 total
- age 7: 146072 bytes, 14418128 total
- age 8: 626064 bytes, 15044192 total
- age 9: 398000 bytes, 15442192 total
- age 10: 429616 bytes, 15871808 total
: 1969227K->1929200K(2071808K), 0.7452140 secs]2016-01-07T18:54:27.693+0800: 18783.713: [CMS: 1394703K->632845K(2097152K), 4.0993640 secs] 3301676K->632845K(4168960K), [CMS Perm : 77485K->77473K(159744K)], 4.8450240 secs] [Times: user=5.18 sys=0.56, real=4.84 secs]
Heap after GC invocations=5847 (full 7):
par new generation total 2071808K, used 0K [0x00000006e9c00000, 0x0000000776400000, 0x0000000776400000)
eden space 1841664K, 0% used [0x00000006e9c00000, 0x00000006e9c00000, 0x000000075a280000)
from space 230144K, 0% used [0x0000000768340000, 0x0000000768340000, 0x0000000776400000)
to space 230144K, 0% used [0x000000075a280000, 0x000000075a280000, 0x0000000768340000)
concurrent mark-sweep generation total 2097152K, used 632845K [0x0000000776400000, 0x00000007f6400000, 0x00000007f6400000)
concurrent-mark-sweep perm gen total 159744K, used 77473K [0x00000007f6400000, 0x0000000800000000, 0x0000000800000000)
}

提升失败原因:Minor GC 时发现 Survivor 空间放不下,而老年代的空闲也不够
  • 新生代提升太快
  • 老年代碎片太多,放不下大对象提升(表现为老年代还有很多空间但是,出现了 promotion failed)

解决方法:
       两条和上面 concurrent mode failure 一样
       另一条,是因为 Survivor Unused 不足,那么可以尝试调大 Survivor 来尝试下 



三. 在 GC 的时候其他系统活动影响
有些时候系统活动诸如内存换入换出(vmstat)、网络活动(netstat)、I/O (iostat)在 GC 过程中发生会使 GC 时间变长。

前提是你的服务器上是有 SWAP 区域(用 top、 vmstat 等命令可以看出)用于内存的换入换出,那么操作系统可能会将 JVM 中不活跃的内存页换到 SWAP 区域用以释放内存给线程使用(这也透露出内存开始不够用了)。内存换入换出是一个开销巨大的磁盘操作,比内存访问慢好几个数量级。

看一段 GC 日志:耗时 29.47 秒 
  1. {Heap before GC invocations=132 (full 0):
  2. par new generation total 2696384K, used 2696384K [0xfffffffc20010000, 0xfffffffce0010000, 0xfffffffce0010000)
  3. eden space 2247040K, 100% used [0xfffffffc20010000, 0xfffffffca9270000, 0xfffffffca9270000)
  4. from space 449344K, 100% used [0xfffffffca9270000, 0xfffffffcc4940000, 0xfffffffcc4940000)
  5. to space 449344K, 0% used [0xfffffffcc4940000, 0xfffffffcc4940000, 0xfffffffce0010000)
  6. concurrent mark-sweep generation total 9437184K, used 1860619K [0xfffffffce0010000, 0xffffffff20010000, 0xffffffff20010000)
  7. concurrent-mark-sweep perm gen total 1310720K, used 511451K [0xffffffff20010000, 0xffffffff70010000, 0xffffffff70010000)
  8. 2013-07-17T03:58:06.601-0700: 51522.120: [GC Before GC: : 2696384K->449344K(2696384K), 29.4779282 secs] 4557003K->2326821K(12133568K) ,29.4795222 secs] [Times: user=915.56 sys=6.35, real=29.48 secs]
{Heap before GC invocations=132 (full 0):
par new generation total 2696384K, used 2696384K [0xfffffffc20010000, 0xfffffffce0010000, 0xfffffffce0010000)
eden space 2247040K, 100% used [0xfffffffc20010000, 0xfffffffca9270000, 0xfffffffca9270000)
from space 449344K, 100% used [0xfffffffca9270000, 0xfffffffcc4940000, 0xfffffffcc4940000)
to space 449344K, 0% used [0xfffffffcc4940000, 0xfffffffcc4940000, 0xfffffffce0010000)
concurrent mark-sweep generation total 9437184K, used 1860619K [0xfffffffce0010000, 0xffffffff20010000, 0xffffffff20010000)
concurrent-mark-sweep perm gen total 1310720K, used 511451K [0xffffffff20010000, 0xffffffff70010000, 0xffffffff70010000)
2013-07-17T03:58:06.601-0700: 51522.120: [GC Before GC: : 2696384K->449344K(2696384K), 29.4779282 secs] 4557003K->2326821K(12133568K) ,29.4795222 secs] [Times: user=915.56 sys=6.35, real=29.48 secs]
再看看此时的 vmstat 命令中 si、so 列的数值,如果数值大说明换入换出严重,这是内存不足的表现。

解决方法:减少线程,这样可以降低内存换入换出;增加内存;如果是 JVM 内存设置过大导致线程所用内存不足,则适当调低 -Xmx 和 -Xms。



四. JVM 的 bug
这种原因就根据自己使用的 JDK 版本去查一下,如果是 JVM 的 bug,升级到解决的版本一般就能解决。



五. 总结
       长时间停顿问题的排查及解决首先需要一定的信息和方法论:
  • 详细的 GC 日志
  • 借助 Linux 平台下的 iostat、vmstat、netstat、mpstat 等命令监控系统情况
  • 使用 GCHisto 这个 GC 图形用户界面工具,可以统计出 Minor GC 及 Full GC 频率及时长分布,可参考:http://blog.csdn.net/wenniuwuren/article/details/50760259
  • 查看 GC 日志中是否出现了上述的典型内存异常问题(promotion failed, concurrent mode failure),整体来说把上述两个典型内存异常情况控制在可接受的发生频率即可,对 CMS 碎片问题来说杜绝以上问题似乎不太可能,只能靠 G1 来解决了
  • 是不是 JVM 本身的 bug 导致的
  • 如果程序没问题,参数调了几次还是不能解决,可能说明流量太大,需要加机器把压力分散到更多 JVM 上

     

六. 参考资料
         《Java 性能优化权威指南》

JVM 调优 —— GC 长时间停顿问题及解决方法的更多相关文章

  1. JVM调优-GC参数

    一.Throughput收集器(吞吐量)-XX:+UseParallelGC-XX:+UseParallelOldGC *参数调整:通过调整堆大小,减少GC停顿时间,增大吞吐量增强堆大小可以减少Ful ...

  2. Nagios状态长时间处于Pending的解决方法

    1 nagios 守护进程引起的一系列问题 1 影响nagios web页面收集监控信息 致使页面出现时而收集不到服务信息 2 影响pnp查看图形化,出图缓慢 3 影响查看服务状态信息,致使有时候查看 ...

  3. 一次jvm调优过程

    jvm调优实战 前端时间把公司的一个分布式定时调度的系统弄上了容器云,部署在kubernetes,在容器运行的动不动就出现问题,特别容易jvm溢出,导致程序不可用,终端无法进入,日志一直在刷错误,ku ...

  4. 深入理解JAVA虚拟机(内存模型+GC算法+JVM调优)

    目录 1.Java虚拟机内存模型 1.1 程序计数器 1.2 Java虚拟机栈 局部变量 1.3 本地方法栈 1.4 Java堆 1.5 方法区(永久区.元空间) 附图 2.JVM内存分配参数 2.1 ...

  5. JVM调优之---一次GC调优实战

    某系统反馈『性能抖动,响应时间会突然飙高,TP999 MAX会到3000+』,初步怀疑是JVM FULL GC导致的 STW,观察FULL GC日志默认的JVM参数: -Xms4096m -Xmx40 ...

  6. JVM调优:GC 参数

    2019独角兽企业重金招聘Python工程师标准>>> JVM调优:GC 参数 博客分类: java jvm 参考: <Memory Management in the Jav ...

  7. JVM调优——JVM监控工具jvisualvm的使用及GC插件安装

    一.前言 在高并发的场景下,我们网站的的访问性能会降低,我们怎么优化,这是个问题!天天听JVM调优,实际上还是不知道怎么调优,调优也是看着网上说的修改一下JVM的堆的空间等等进行的.实际上我们应该在压 ...

  8. jvm系列(四):jvm调优-命令大全(jps jstat jmap jhat jstack jinfo)

    文章同步发布于github博客地址,阅读效果更佳,欢迎品尝 运用jvm自带的命令可以方便的在生产监控和打印堆栈的日志信息帮忙我们来定位问题!虽然jvm调优成熟的工具已经有很多:jconsole.大名鼎 ...

  9. JVM调优的几种策略(转)

    JVM参数调优是一个很头痛的问题,可能和应用有关系,别人说可以的对自己不一定管用.下面是本人一些JVM调优的实践经验,希望对读者能有帮助,环境LinuxAS4,resin2.1.17,JDK6.0,2 ...

随机推荐

  1. Linq 之 Where操作

    适用场景:实现过滤,查询等功能. 说明:与SQL命令中的Where作用相似,都是起到范围限定也就是过滤作用的,而判断条件就是它后面所接的子句. Where操作包括3种形式,分别为简单形式.关系条件形式 ...

  2. img标签下多余空白BUG解决方法

    在进行页面的DIV CSS排版时,遇到IE6(当然有时Firefox下也会偶遇)浏览器中的图片元素img下出现多余空白的问题绝对是常见的 对于该问题的解决方法也是“见机行事”. 1.将图片转换为块级对 ...

  3. IO流8 --- 使用FileReader和FileWriter实现文本文件的复制 --- 技术搬运工(尚硅谷)

    @Test public void test4(){ FileReader fr = null; FileWriter fw = null; try { fr = new FileReader(&qu ...

  4. drf模块及源码

    drf中的APIView请求生命周期 APIView的as_view(局部禁用csrf) => 调用父类view中的as_view返回view()方法 => 自己的类调用自己的dispat ...

  5. Docker 私有仓库下载镜像

    1.添加私有仓库路径 vim /etc/sysconfig/docker --insecure-registry 192.168.105.30:5000 注:版本差异 2.下载镜像 docker pu ...

  6. python基础--闭包and装饰器

    闭包函数:函数内部定义的函数:引用了外部变量但非全局变量 装饰器:有了闭包的概念再去理解装饰器就会相对容易一些.python装饰器本质上就是一个函数,它可以让其他函数在不需要做任何代码变动的前提下增加 ...

  7. 2019.8.9 NOIP模拟测试15 反思总结

    日常爆炸,考得一次比一次差XD 可能还是被身体拖慢了学习的进度吧,虽然按理来说没有影响.大家听的我也听过,大家学的我也没有缺勤多少次. 那么果然还是能力问题吗……? 虽然不愿意承认,但显然就是这样.对 ...

  8. vuex的简单教程

    首先安装vuex npm install vuex --save 然后创建store.js文件里写 import Vue from 'vue' import Vuex from 'vuex' Vue. ...

  9. 开始使用Apache弗林克和Mapr Streams

    Introduction MapR Ecosystem Package 2.0 (MEP) is coming with some new features related to MapR Strea ...

  10. Adding basic files · lcobucci/jwt@aad22ed · GitHub

    Skip to content   Features Business Explore Marketplace Pricing   This repository Sign in or Sign up ...