java.lang.OutOfMemoryError:压缩类空间 [英] java.lang.OutOfMemoryError: Compressed class space

查看:1805
本文介绍了java.lang.OutOfMemoryError:压缩类空间的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们正在运行java-8-oracle。



我们在六个月前转移到了java8。

在过去的几天里,我们不时发现OOME,我们无法识别或重现问题。



当我们执行呼叫时到服务器(tomcat),我们在stacktrace上得到这个错误:

  java.lang.OutOfMemoryError:压缩类空间

重新启动服务器可解决问题。与其他服务器的调用相同,另一个类型调用到同一服务器。



在gc.log中查看时,我们看到:

  2015-05-27T16:05:42.991 + 0000:98774.440:[Full GC(Last ditch collection)98774.440:[CMS:575745K-> ; 575330K(3495936K),0.8687777秒] 575745K-> 575330K(4107008K),[Metaspace:97940K-> 97940K(1396736K)],0.8696093秒] [时间:用户= 0.95 sys = 0.00,实际= 0.88秒] b $ b 2015-05-27T16:05:55.486 + 0000:98786.935:[Full GC(元数据GC阈值)98786.935:[CMS:573414K-> 578735K(3495936K),0.9372859秒] 925046K-> 578735K(4107008K) ,[Metaspace:99428K-> 99428K(1396736K)],0.9386626秒] [Times:user = 1.01 sys = 0.00,real = 0.94 secs] 



$ p $ jstat -gc 返回:

  S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT 
87296.0 87296.0 0.0 3151.4 523776.0 14828 4.4 3495936.0 574868.5 1395640.0 98066.3 1048576.0 11339.1 12165 636.851 223 116.957

753.808

I在jstat日志或gc日志中没有看到任何内存问题。



尝试运行 jmap -clstats 挂起:

 附加到进程ID 5110,请等待... 
调试器成功连接。
检测到服务器编译器。
JVM版本是25.25-b02
查找类加载器实例..


解决方案

我们面临类似的问题。不幸的是,堆转储不会帮助你,因为这些类不在堆中,而是在本地内存中。在您的JVM设置中启用这些功能来排除加载的类的故障:

-XX:+ PrintGCDetails -XX:+ TraceClassUnloading -XX:+ TraceClassLoading

在我们的例子中,问题是JAXBContext.newInstance不是单例。



祝您好运,
Albert


We are running on java-8-oracle.

We moved to java8 six month ago.

In the past few days we have been getting an OOME from time to time and we haven't been able to identify or reproduce the problem.

When we execute a call to the server (tomcat) we get this error on the stacktrace:

java.lang.OutOfMemoryError: Compressed class space

Restarting the server solves the problem. The same call to other server works, and so does another call of another type to the same server.

When looking on the gc.log we see:

2015-05-27T16:05:42.991+0000: 98774.440: [Full GC (Last ditch collection) 98774.440: [CMS: 575745K->575330K(3495936K), 0.8687777 secs] 575745K->575330K(4107008K), [Metaspace: 97940K->97940K(1396736K)], 0.8696093 secs] [Times: user=0.95 sys=0.00, real=0.88 secs]
2015-05-27T16:05:55.486+0000: 98786.935: [Full GC (Metadata GC Threshold) 98786.935: [CMS: 573414K->578735K(3495936K), 0.9372859 secs] 925046K->578735K(4107008K), [Metaspace: 99428K->99428K(1396736K)], 0.9386626 secs] [Times: user=1.01 sys=0.00, real=0.94 secs]

jstat -gc returns:

 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT
87296.0 87296.0  0.0   3151.4 523776.0 148284.4 3495936.0   574868.5  1395640.0 98066.3 1048576.0 11339.1  12165  636.851  223   116.957  

753.808

I don't see any memory problems either in the jstat log or in the gc log.

Trying to run jmap -clstats hangs:

Attaching to process ID 5110, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.25-b02
finding class loader instances ..

解决方案

We faced a similar issue. Unfortunately heapdumps won't help you since the classes are not in the heap but in native memory. Enable these in your JVM settings to troubleshoot the classes loaded:

-XX:+PrintGCDetails -XX:+TraceClassUnloading -XX:+TraceClassLoading

In our case the issue was JAXBContext.newInstance not being singleton.

Good luck, Albert

这篇关于java.lang.OutOfMemoryError:压缩类空间的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆