为什么PermGen的空间在增长? [英] Why is PermGen space growing?

查看:182
本文介绍了为什么PermGen的空间在增长?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已经阅读了几篇文章,并且理解了以下内容(如果我错了,请纠正我和/或编辑问题):

I've read a few articles, and I understood the following (please correct me and/or edit the question if I'm wrong):

java堆是这样分段的:

The java heap is segmented like this:

  • 年轻一代:创建的对象移至此处,该部分经常且廉价地进行垃圾收集

  • Young Generation: objects that are created go here, this part is frequently and inexpensively garbage collected

上一代:可以幸存下来的年轻一代的对象去了这里,该区域的垃圾收集频率降低,并且使用了对CPU要求更高的过程/算法(我相信这称为标记扫描)

Old Generation: objects that survive the garbage collections of the Young generation go here, this area is garbage collected less frequently and using a more CPU demanding process/algorithm (I believe it's called mark-sweep)

如另一位用户所述,PermGen不属于名为heap

as stated by another user, PermGen is not a part of the region called heap

  • PermGen:此区域填充了您的应用程序类元数据和许多其他不依赖于应用程序使用情况的东西.

因此,知道这一点...当应用程序负载沉重时,为什么我的PermGen空间会增加?对于我之前说的内容,尽管有应用程序负载,但不应增量填充该空间,但是正如我在一开始所说的那样,我可能对某些假设是错误的.

So, knowing this... why does my PermGen space grows when the app is under heavy load? For what I said before this space should not incrementally fill in spite of the app load, but as I said in the beginning probably I'm wrong about some assumptions.

实际上,如果PermGen空间正在增长,是否有一种垃圾收集或重置方法?

In fact if the PermGen space is growing, is there a way of garbage collect or reset it?

推荐答案

实际上,在Sun的JVM中,Permanent Generation(PermGen)与堆完全分开.您确定您没有在找终身代吗?如果您的永久一代持续增长,的确会令人怀疑.

Actually, in Sun's JVM Permanent Generation (PermGen) is completely separate from the heap. Are you sure you aren't looking at the Tenured Generation? It would be suspicious indeed if your Permanent Generation kept growing.

如果您的烫发持续增长,那么这是一个很难挖掘的领域.通常,它应该在首次加载新类时增长(并且可能对反射的某些特定用途也可能导致这种情况).实习生的字符串也存储在perm gen中.

If your perm gen IS growing constantly, it is a difficult area to dig into. Generally it should grow when new classes are loaded for the first time (and potentially certain uses of reflection could also cause this). Interned strings are also stored in perm gen.

如果您碰巧是在Solaris上,则可以使用 jmap -permstat 转储perm gen统计信息,但是该选项似乎在Windows(以及其他平台)上不可用.这是有关Java 6的jmap文档

If you happen to be on Solaris, you could use jmap -permstat to dump out perm gen statistics, but that option does not appear to be available on Windows (and potentially other platforms). Here is the documentation on jmap for Java 6

摘自Sun的 JConsole指南(这样您就可以查看这些池的大小):

From Sun's guide on JConsole (which will let you view the size of these pools):

对于HotSpot Java VM,内存 串行垃圾收集池 以下是

For the HotSpot Java VM, the memory pools for serial garbage collection are the following.

  • Eden Space(堆):最初从中分配内存的池 对于大多数对象.
  • 幸存者空间(堆):包含已幸存对象的池 伊甸园的垃圾收集 空间.
  • 持久生成(堆):包含已存在对象的池 在幸存者空间中待了一段时间.
  • 永久生成(非堆):包含所有反射的池 虚拟机本身的数据, 例如类和方法对象.和 使用类数据共享的Java VM, 这一代分为 只读和读写区域.
  • 代码缓存(非堆):HotSpot Java VM还包括代码缓存, 包含用于 本地的编译和存储 代码.
  • Eden Space (heap): The pool from which memory is initially allocated for most objects.
  • Survivor Space (heap): The pool containing objects that have survived the garbage collection of the Eden space.
  • Tenured Generation (heap): The pool containing objects that have existed for some time in the survivor space.
  • Permanent Generation (non-heap): The pool containing all the reflective data of the virtual machine itself, such as class and method objects. With Java VMs that use class data sharing, this generation is divided into read-only and read-write areas.
  • Code Cache (non-heap): The HotSpot Java VM also includes a code cache, containing memory that is used for compilation and storage of native code.

这篇关于为什么PermGen的空间在增长?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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