[英]What is going on with java GC? PermGen space is filling up?
我不知道我的java進程發生了什么。 此過程是索引過程。 它從一組zip文件中讀取文檔,並將它們添加到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正在填滿。 燙發的確需要那么多空間嗎?
如果你的內存碎片,或者沒有什么可以清理,就會發生這種情況。 當您接近最大內存大小時,通常會發生這種情況。
我從來沒有聽說過每個人需要2 G的人。 你確定它不是你需要看的年輕和終身空間嗎?
BTW:intern()ed字符串放在Java 7的主堆空間中。在Java 7之前,它們曾經被置於perm gen空間中,這使得制作過多的數據成為一個壞主意()
就我而言,PermGen正在填補並激發完整的GC,因為我使用JAXB動態創建類。 為了調試這個,我看到通過JMX控制台監視PermGen直接對應於完整的GC(使用-verbose:gc)。 此外,使用-verbose:class向我展示了它是我的JAXB用法。
具有世代垃圾收集的 JVM中的永久生成(perm gen)包含無法收集的“永久”數據。 這個內存段主要由系統類加載器加載的類定義組成,所以如果你的程序加載了很多類(例如有很多大的依賴項),那么這個空間就會填滿。 請注意,除非您使用自定義類加載器(即默認的系統類加載器以外),否則不會卸載類(通常)。
有關調整perm gen空間大小的信息,請參閱本指南 。
沒有詳細查看您的應用程序,很難說。 但是,使用permgen空間的常見罪魁禍首是字符串(在代碼庫中搜索.intern()
)和動態代碼生成。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.