logo标签列表

Java垃圾回收出现了什么问题？PermGen空间正在填满吗？

javagarbage-collectionjvm
5

我不知道我的Java进程出了什么问题。这个进程是一个索引进程。它从一组压缩文件中读取文档，并将它们添加到Lucene索引中。GC日志显示它一直在运行Full GC。

4959.569: [Full GC 19960K->19960K(10617856K), 0.1648590 secs]
4959.764: [Full GC 19960K->19960K(10617856K), 0.1650240 secs]
4959.959: [Full GC 19960K->19960K(10617856K), 0.1649380 secs]
4960.154: [Full GC 19960K->19960K(10617856K), 0.1650000 secs]
4960.350: [Full GC 19960K->19960K(10617856K), 0.1648900 secs]

就我所理解的，这些行中提到的对象在之前和之后的大小约为19M，但为什么它总是在运行呢？

线程转储看起来像这样：

........[Unloading class sun.reflect.GeneratedConstructorAccessor1]
[Unloading class sun.reflect.GeneratedConstructorAccessor2]
[Unloading class sun.reflect.GeneratedConstructorAccessor3]
2012-01-13 12:55:24
Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.4-b02 mixed mode):

"org.cxv.CXVIndexer.main()" prio=10 tid=0x00007f4540474000 nid=0x4b15 waiting on condition [0x00007f453f5ed000]
   java.lang.Thread.State: RUNNABLE
        at org.apache.lucene.index.DocFieldProcessorPerThread.abort(DocFieldProcessorPerThread.java:72)
        at org.apache.lucene.index.DocumentsWriter.abort(DocumentsWriter.java:424)
        - locked <0x000000034ab44fb8> (a org.apache.lucene.index.DocumentsWriter)
        at org.apache.lucene.index.DocumentsWriter.flush(DocumentsWriter.java:659)
        - locked <0x000000034ab44fb8> (a org.apache.lucene.index.DocumentsWriter)
        at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3623)
        - locked <0x000000034aacf660> (a org.apache.lucene.index.IndexWriter)
        at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3588)
        at org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1858)
        at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1822)
        at org.cxv.IndexCreator.close(IndexCreator.java:25)
        at org.cxv.CXVIndexer.doIndexing(CXVIndexer.java:41)
        at org.cxv.CXVIndexer.main(CXVIndexer.java:75)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
        at java.lang.Thread.run(Thread.java:662)

"Low Memory Detector" daemon prio=10 tid=0x00007f4540003800 nid=0x4b0a runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" daemon prio=10 tid=0x00007f4540001000 nid=0x4b09 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" daemon prio=10 tid=0x000000004032d800 nid=0x4b08 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x000000004032b800 nid=0x4b07 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Surrogate Locker Thread (Concurrent GC)" daemon prio=10 tid=0x0000000040329800 nid=0x4b06 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=10 tid=0x000000004030c800 nid=0x4b05 in Object.wait() [0x00007f453fdfc000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x000000034a6613a8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
        - locked <0x000000034a6613a8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

"Reference Handler" daemon prio=10 tid=0x0000000040305000 nid=0x4b04 in Object.wait() [0x00007f453fefd000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x000000034a6627c0> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:485)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
        - locked <0x000000034a6627c0> (a java.lang.ref.Reference$Lock)

"main" prio=10 tid=0x0000000040111000 nid=0x4af7 in Object.wait() [0x00007f4563c79000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x000000034aadf6f8> (a java.lang.Thread)
        at java.lang.Thread.join(Thread.java:1186)
        - locked <0x000000034aadf6f8> (a java.lang.Thread)
        at org.codehaus.mojo.exec.ExecJavaMojo.joinThread(ExecJavaMojo.java:415)
        at org.codehaus.mojo.exec.ExecJavaMojo.joinNonDaemonThreads(ExecJavaMojo.java:405)
        at org.codehaus.mojo.exec.ExecJavaMojo.execute(ExecJavaMojo.java:317)
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
        at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
        at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
        at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)

"VM Thread" prio=10 tid=0x00000000402fe000 nid=0x4b03 runnable 

"Gang worker#0 (Parallel GC Threads)" prio=10 tid=0x0000000040120000 nid=0x4af8 runnable 

"Gang worker#1 (Parallel GC Threads)" prio=10 tid=0x0000000040122000 nid=0x4af9 runnable 

"Gang worker#2 (Parallel GC Threads)" prio=10 tid=0x0000000040123800 nid=0x4afa runnable 

"Gang worker#3 (Parallel GC Threads)" prio=10 tid=0x0000000040125800 nid=0x4afb runnable 

"Gang worker#4 (Parallel GC Threads)" prio=10 tid=0x0000000040127800 nid=0x4afc runnable 

"Gang worker#5 (Parallel GC Threads)" prio=10 tid=0x0000000040129000 nid=0x4afd runnable 

"Gang worker#6 (Parallel GC Threads)" prio=10 tid=0x000000004012b000 nid=0x4afe runnable 

"Gang worker#7 (Parallel GC Threads)" prio=10 tid=0x000000004012d000 nid=0x4aff runnable 

"Concurrent Mark-Sweep GC Thread" prio=10 tid=0x0000000040220800 nid=0x4b02 runnable 
"Gang worker#0 (Parallel CMS Threads)" prio=10 tid=0x000000004021c800 nid=0x4b00 runnable 

"Gang worker#1 (Parallel CMS Threads)" prio=10 tid=0x000000004021e800 nid=0x4b01 runnable 

"VM Periodic Task Thread" prio=10 tid=0x000000004033a000 nid=0x4b0b waiting on condition 

JNI global references: 1154

Heap
 par new generation   total 153344K, used 0K [0x0000000340000000, 0x000000034a660000, 0x000000034a660000)
  eden space 136320K,   0% used [0x0000000340000000, 0x0000000340000000, 0x0000000348520000)
  from space 17024K,   0% used [0x00000003495c0000, 0x00000003495c0000, 0x000000034a660000)
  to   space 17024K,   0% used [0x0000000348520000, 0x0000000348520000, 0x00000003495c0000)
 concurrent mark-sweep generation total 10464512K, used 19960K [0x000000034a660000, 0x00000005c91a0000, 0x0000000780000000)
 concurrent-mark-sweep perm gen total 2097152K, used 2097151K [0x0000000780000000, 0x0000000800000000, 0x0000000800000000)

从线程转储来看，似乎2G perm gen正在填满。它真的需要这么多的空间来存储perm gen吗？

2
你的PermGen已经完全满了。这意味着由于空间不足，它无法处理类对象的创建。首先尝试使用-XX:MaxPermSize=3G来提高你的PermGen级别，并使用VisualVM观察其上升情况。观察加载的类数量，并查看是否达到了某个水平。 - Grooveek
你能否给我们一些线索，关于你所说的“Java进程”到底是什么？它是一个服务器，还是一个桌面应用程序？ - Matthew Farwell
@MatthewFarwell 是的，它是一个服务器。它是一个索引过程。它从一组zip文件中读取文档，并将它们添加到lucene索引中。 - user3111525
4个回答
7
如果你的内存碎片化或者没有需要清理的内容，这种情况就会发生。当你接近最大内存大小时，这种情况经常发生。
我从未听说过有人需要2G每个进程的大小。你确定不是需要查看年轻代和老年代空间吗？
顺便说一句，在Java 7中，intern()ed字符串被放置在主堆空间中。在Java 7之前，它们被放置在永久代空间中，因此过多地使用intern()可能会导致问题。
尝试使用一个收集器来压缩旧代（例如ParallelOldGC），看看是否会遇到与永久空间相同的问题。 - Paul Medcraft
1
在我的情况下，PermGen被填满并引发了完整的GC，因为我使用JAXB动态创建类。为了调试这个问题，我通过JMX控制台监视PermGen，发现它直接对应于完整的GC（使用-verbose:gc）。此外，使用-verbose:class向我展示了这是我的JAXB使用造成的。
1

JVM中的持久代（Perm Gen）和分代垃圾回收一起包含“永久”数据，这些数据不会被回收。该内存段主要由系统类加载器加载的类定义组成，因此，如果您的程序加载了大量的类（例如具有许多大型依赖项），则该空间将填满。请注意，除非使用自定义类加载器（即非默认的系统类加载器），否则类通常不会被卸载。

有关调整持久代空间大小的信息，请参见本指南。

那么，您也认为Perm Gen存在问题吗？ - user3111525
@frankmoss：不一定是问题；可能只是因为您正在加载“大量”依赖类（或其他存储在永久代中的数据），因此必须相应地增加永久代堆空间。 - maerics
0

没有详细查看你的应用程序，很难说。然而，使用permgen空间的常见原因是字符串的内部化（在代码库中搜索.intern()）和动态代码生成。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接