如题，一个jvm进程跑了cpu占到100%了，jstack连不上，jstat说没有这个进程（实际上是有的）。
然后jmap看了一下内存信息，

Heap Usage:
PS Young Generation
Eden Space:
   capacity = 89063424 (84.9375MB)
   used     = 0 (0.0MB)
   free     = 89063424 (84.9375MB)
   0.0% used
From Space:
   capacity = 196608 (0.1875MB)
   used     = 0 (0.0MB)
   free     = 196608 (0.1875MB)
   0.0% used
To Space:
   capacity = 196608 (0.1875MB)
   used     = 0 (0.0MB)
   free     = 196608 (0.1875MB)
   0.0% used
PS Old Generation
   capacity = 178978816 (170.6875MB)
   used     = 16274376 (15.520454406738281MB)
   free     = 162704440 (155.16704559326172MB)
   9.092906280037074% used
PS Perm Generation
   capacity = 85983232 (82.0MB)
   used     = 85983224 (81.99999237060547MB)
   free     = 8 (7.62939453125E-6MB)
   99.99999069586033% used

持久带居然到99.99%了，但是伊甸区，from，to却是空的？
最后强制dump了一下内存信息，不知道是不是跟动态字节码生成有关，MAT分析结果给出的是字节码增强占用内存比较多。这个应用的持久带设置的比较小，是82M。

另外为何jstack都连不上？ -F 只能显示出一些死掉的线程

因为PermGen跟Young/Old的空满程度没任何关系。

一般，普通Java对象从eden分配出来之后，如果存活时间够长最终会晋升到OldGen。但这些对象无论如何都不会晋升到PermGen去。

另外full GC后的理想状况就是整个YoungGen都是空的。你看到的情况完全符合理想情况。

CPU占用率很高的话你可以试试用pstack <pid>连上去看看能不能连，可以的话你会看到这个进程的native stack状况。如果好几个线程都在做GC的话那卡住的原因多半就是连续的GC的。这也符合你这里遇到的现象。

看不懂，悲剧啊

不知道你的jvm参数是啥？
PermGen满的时候，也引发full gc。所以eden可能出现 0% used的情况。
同意RednaxelaFX，CPU% 很有可能是在不停的full gc。

Eden 区和 Perm 区是2个地方. 所以0%情况不出奇.

如果是因为jvm在不停的full gc，那么连续的full gc（比如相当于一个死循环，不停的gc），那么这样的情况会导致外部连接无法触发？也就是full gc的那一瞬间是相当于JVM无法接受外部响应的？

gc配置的是UseParallelGC 和  UseParNewGC 。
堆内存配置最大是256，其余都是默认值。

连续full GC的时候JVM会表现得像是死了一样，不要说应用对外提供的连接无法正常工作，连jmap、jstack之类的工具的普通模式也无法连接。


UseParallelGC 与 UseParNewGC 是互斥的。你用的是前者。Full GC是否会使VM失去响应这个问题，对HotSpot VM里无论哪个GC算法都一样。

jstat查看了一下jvm进程，

jstat -gcutil 20977 5000 20
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   
 50.00   0.00  60.30  49.23  60.58 502784  189.958  4605  146.890  336.848
 75.00   0.00  84.77  55.31  60.58 502792  189.961  4605  146.890  336.851
  0.00  75.00  18.48  61.91  60.58 502801  189.965  4605  146.890  336.855
  0.00  33.33  61.70  67.09  60.58 502809  189.968  4605  146.890  336.858
  0.00  58.33  86.37  72.09  60.58 502817  189.971  4605  146.890  336.861
 58.33   0.00  14.69  79.23  60.58 502826  189.975  4605  146.890  336.865
 58.33   0.00  38.46  85.13  60.58 502834  189.978  4605  146.890  336.868
 28.57   0.00  16.93  90.66  60.58 502842  189.981  4605  146.890  336.871
 58.33   0.00  58.58  95.66  60.58 502850  189.984  4605  146.890  336.874
  0.00  75.00   1.51  43.76  60.58 502859  189.988  4606  146.920  336.908
  0.00  83.33  25.93  48.59  60.58 502867  189.990  4606  146.920  336.911
  0.00  91.67  52.64  54.30  60.58 502875  189.993  4606  146.920  336.914
  0.00  58.33  76.60  59.66  60.58 502883  189.996  4606  146.920  336.917
 75.00   0.00   3.75  65.19  60.58 502892  190.000  4606  146.920  336.920
 58.33   0.00  38.98  71.26  60.58 502900  190.003  4606  146.920  336.923
  0.00  58.33  91.53  76.26  60.58 502907  190.006  4606  146.920  336.926
 75.00   0.00  19.60  82.34  60.58 502916  190.009  4606  146.920  336.930
 50.00   0.00  44.50  87.87  60.58 502924  190.013  4606  146.920  336.933
 64.29   0.00  72.00  93.05  60.58 502932  190.016  4606  146.920  336.936
 50.00   0.00  97.48  98.05  60.58 502940  190.020  4606  146.920  336.940

full gc次数非常多，不过jstack连这个进程依然是连不上。
gc可能是不到1分钟就会出现一次，不过jstat可以连上，说明在那个瞬间是没有full gc的，但是我不停的用jstack尝试连接都连不上。

不是，jstat是通过共享文件的方式获取数据的，所以就算目标的Java进程卡死了它也能工作，就算获取的数据不是最新的。其它一些工具依赖着JVM内部执行一些代码，如果JVM卡住就啥也做不了了。

我觉得楼主给的信息过少了，某个java进程跑了100；是什么操作系统？如果是linux，可以敲一下如下命令：ps -eLo user,pid,lwp,nlwp,%cpu,%mem,comm | grep PID > 保存路径。

这样查看一下哪个进程占用cpu资源较多，或者通过其他方式看看系统哪些不正常？