紧急问题求助：在压测时，Jvm在GC时把所有线程挂起，没有GC成功造成整个进程假死

[qq_28869939]

项目在做压测时，但服务器5000或者1W人的时候都会出现如下情况：
1. 整个运行一段时间后进程假死。（时间大概40分钟到1个半小时）
2. 多有日志都已经停止打印

情况：
线程数量在1000多个。 tomcat进程。
1. 能运行jstat 查看GC的一些情况， 后面会贴出来
2. 运行jstack -l 进程号， 不成功， 提示需要-F
3. 运行jstack -l -F 第一次不成， 第二次成功。 （有时候一次也成功）。 但所有线程就恢复了。 从假死状态变活了。 所有线程恢复正常。

目前进展：
1. 怀疑过java版本和tomcat版本的问题， 都升级了。也会出现。
2. 换过GC收集器， 从CMS到UseParallelOldGC 都使用也会出现假死状态。
3. 无OOM的错误日志
4. 打开了gc.log的日志， 在假死时， 也停止了打印。
5. 打开了vm里面的日志，发现一个问题， 后面会详细说明。
6.我们通过jstat来每一秒来打印一下当时的GC情况。 发现当时的eden区满了 两个S区也很正常！！！！ 但年老代还有很大很大的空间。
日志如下：
Timestamp S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT
20193.3 177152.0 172544.0 69827.0 0.0 2796032.0 2796032.0 5242880.0 2012227.5 101336.0 96395.8 10968.0 9880.1 382 13.786 4 1.234 15.020
20194.3 177152.0 172544.0 69827.0 0.0 2796032.0 2796032.0 5242880.0 2012227.5 101336.0 96395.8 10968.0 9880.1 382 13.786 4 1.234 15.020
7.还分析出了， 假死的时候是在GC的时候假死的。 （分析过程： 用jstack后， 所有线程恢复正常了，这时候看vm.log数据分析得知）
日志如下：
vmop [threads: total initially_running wait_to_block] [time: spin block sync cleanup vmop] page_trap_count
88255.844: ParallelGCFailedAllocation [ 1082 1 2 ] [ 0 2399273 2399274 3 90 ] 0
这个有一个很大的数据： 2399273 这个是在GC时，暂停所有线程所用到的时间。
这个时间是进程假死后，到运行jstack后，线程恢复时 中间的时间是吻合的。
所以说是在GC时，在等待所有线程暂定，进程GC时，一直暂停不掉？？？？ 进入不了安全点或者安全区域？？

所以这个问题非常难找， 用jstack看， 一用，线程就恢复了。 所以不是当时现场。 而且看也很正常。看日志吧，日志也暂停打印了，最后的日志也很正常， 用jdb挂起当时的线程来看，也很正常。

大家是否碰到过这种情况。 非常感谢。

具体参数和数据如下， 请大家帮助分析。
1. JVM参数(换成了Parallel并行收集器)：
java -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-server
-Xmx8192m
-Xms8192m
-Xss512k
-Xmn3072m
-XX:MaxTenuringThreshold=7
-XX:+UseParallelOldGC
-XX:MaxDirectMemorySize=1024m
-XX:+UnlockDiagnosticVMOptions
-XX:+PrintGCApplicationConcurrentTime -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 -XX:+LogVMOutput -XX:LogFile=vm.log -XX:+PrintFlagsFinal -XX:+PrintGCApplicationStoppedTime -XX:+PrintReferenceGC
-Djava.util.Arrays.useLegacyMergeSort=true
-DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector
-verbose:gc -XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:./gc.log
-XX:-HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./java_heap_dump.hprof -XX:ErrorFile=./hs_err_jvm.log
-Djdk.tls.ephemeralDHKeySize=2048
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources -
classpath ..... -Dcatalina.base=..... -Dcatalina.home=... -Djava.io.tmpdir=... org.apache.catalina.startup.Bootstrap start

如果需要其他信息， 也可以联系。

[小强哥w]

这个是RHEL6.6以及衍生版的一个bug，RHEL6.6.z以后已经修复。 可参考：https://groups.google.com/forum/#!topic/mechanical-sympathy/QbmpZxp6C64 拿分，不谢

[O了ge去]

这个是RHEL6.6以及衍生版的一个bug，RHEL6.6.z以后已经修复。 换6.8去即可。

[傲哥哥]

“用jstack看， 一用，线程就恢复了” 这是什么问题 Eden 区满了 就越频繁执行 Minor GC啊，看看是分配不空间不足还是，代码有问题