S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT  
  0.00 100.00 100.00 100.00  50.86    244   46.568   149 8659.363 8705.930

jvm直接就不动了。

jmap -dump:format=b,file=test.bin 568

856: Unable to open socket file: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding

无法导出，加了-F的参数也不行。有没有什么好办法，可以把堆内存的对象导出来吗?

CPU吃满了所以无法响应了。但-F也不行这个比较糟糕⋯这样的话就算gdb也应该连不上（jmap -F是基于Serviceability Agent的，底下用的是ptrace跟gdb一样。）

-F多试几次⋯呗。另外试试看pstack能不能连上。

JVM版本和启动参数发一下

java version "1.6.0_32"
Java(TM) SE Runtime Environment (build 1.6.0_32-b05)
Java HotSpot(TM) 64-Bit Server VM (build 20.7-b02, mixed mode)

-server -Djava.awt.headless=true  -Xmx8g -Xms8g -Xmn3g -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+UseParNewGC -XX:ParallelGCThreads=23 -XX:MaxTenuringThreshold=4 -XX:SurvivorRatio=1 -XX:TargetSurvivorRatio=70 -XX:+UseConcMarkSweepGC -XX:ConcGCThreads=6  -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly  -XX:+CMSParallelRemarkEnabled -XX:+CMSScavengeBeforeRemark -XX:CMSMaxAbortablePrecleanTime=1000  -XX:CMSFullGCsBeforeCompaction=0 -XX:+UseCMSCompactAtFullCollection  -XX:+UseCompressedOops    -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -XX:+PrintHeapAtGC  -Xloggc:/java_log/tomcat_gc.log -XX:+HeapDumpOnOutOfMemoryError  -XX:+DisableExplicitGC  -XX:HeapDumpPath=/heap_dump -XX:ErrorFile=/java_log/tomcat_java_error.log

运行了一晚上总于生成了一个3.3G的hprof文件，用MAT看了一下基本知道问题的原因了，是通过ThreadWithAttributes(tomcat的线程对象)看到的问题原因，可能是使用了-F的参数原因，在MAT中没有直观的看见大量的相同对象。

生产环节JDK6U32，中jstat看到结果：
S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT  
  0.00 100.00 100.00 100.00  50.86    244   46.568   149 8659.363 8705.930

在JDK6U45中（测试环境）也做了相同的操作：
heap的各个区域增长的也非常的快，但到最后还是会恢复到正常了，难道是我的测试压力不够，还是jdk6u32的版本有什么bug.

JDK6u45针对HotSpot VM的bugfix只有安全相关的，应该没啥新的GC相关bugfix才对⋯

为什么老年代和永久带满了呢？回收了那么多次

这段时间比较忙，现在有点空，问题解决如下：

-F 在负载均衡的一台机器上，执行成功了，但执行了4个多小时。
用MAT看后发现如下，造成100%

1.有一个同事，写的程序不靠谱，一个List持有20万行对象。
2.另一个同事，设置了fetchSize=20000（使用Oracle11g的驱动），造成了oracle11g分配为connection分配的defineBytes和defineChars属性合起来有128M多。这段代码刚上线，使用的人比较多，连接池中的连接对象都是128m。大家一定要小心oracle驱动的fetchSize设置。

这些问题比较隐秘，要不是写了个Connection和PreparedStatement的监控程序，还真的不能被发现呀。