java GC发生了什么？ PermGen空间正在填补？
我不知道我的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 (a org.apache.lucene.index.DocumentsWriter) at org.apache.lucene.index.DocumentsWriter.flush(DocumentsWriter.java:659) - locked (a org.apache.lucene.index.DocumentsWriter) at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3623) - locked (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 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118) - locked (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 (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 (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 (a java.lang.Thread) at java.lang.Thread.join(Thread.java:1186) - locked (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烫发正在填满。 烫发是否真的需要那么多空间？
如果你的内存碎片化，或者没有什么可以清理，就会发生这种情况。 当您接近最大内存大小时，通常会发生这种情况。
我从来没有听说过每个人都需要2 G的人。 你确定它不是你需要看的年轻和终身空间吗？
BTW：intern（）ed字符串被放置在Java 7的主堆空间中。在Java 7之前，它们曾经被置于perm gen空间中，这使得制作过多的数据成为一个坏主意（）
具有世代垃圾收集的 JVM中的永久生成（perm gen）包含无法收集的“永久”数据。 这个内存段主要由系统类加载器加载的类定义组成，所以如果你的程序加载了很多类（例如有很多大的依赖项），那么这个空间就会填满。 请注意，除非您使用自定义类加载器（即默认的系统类加载器以外），否则不会卸载类（通常）。
有关调整perm gen空间大小的信息，请参阅本指南 。
就我而言，PermGen正在填补并激发完整的GC，因为我使用JAXB动态创建类。 为了调试这个，我看到通过JMX控制台监视PermGen直接对应于完整的GC（使用-verbose：gc）。 此外，使用-verbose：class向我展示了它是我的JAXB用法。
没有详细查看您的应用程序，很难说。 但是，使用permgen空间的常见罪魁祸首是字符串（在代码库中搜索.intern() ）和动态代码生成。