以上是我服务器tomcat中的gc信息，前8次gc都是正常的，从第9次开始就不行了，这是参数配置：
-Xmx1200M
-Xms1200M
-Xmn400M
-XX:PermSize=200M
-XX:MaxPermSize=200M
-Xss256K
-XX:+DisableExplicitGC
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction=1
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=50
系统环境是：jdk1.6，tomcat是6.0，server是2003.下面附我的GC日志。怀疑是内存泄露，还有没有别的原因呢？如果是内存泄露的话小弟搞不定呀，这个程序是别人开发的，又没办法避免呢？
问题补充：113576.731: [GC [1 CMS-initial-mark: 818759K(819200K)] 1007675K(1187840K), 0.0284085 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
113576.760: [CMS-concurrent-mark-start]
{Heap before GC invocations=9130 (full 22):
par new generation total 368640K, used 368001K [0x03030000, 0x1c030000, 0x1c030000)
eden space 327680K, 100% used [0x03030000, 0x17030000, 0x17030000)
from space 40960K, 98% used [0x17030000, 0x197907d0, 0x19830000)
to space 40960K, 0% used [0x19830000, 0x19830000, 0x1c030000)
concurrent mark-sweep generation total 819200K, used 818759K [0x1c030000, 0x4e030000, 0x4e030000)
concurrent-mark-sweep perm gen total 204800K, used 33888K [0x4e030000, 0x5a830000, 0x5a830000)
113577.453: [Full GC 113577.454: [CMS113577.526: [CMS-concurrent-mark: 0.761/0.766 secs] [Times: user=2.74 sys=0.11, real=0.77 secs]
(concurrent mode failure): 818759K->818879K(819200K), 2.0137570 secs] 1186761K->851814K(1187840K), [CMS Perm : 33888K->33887K(204800K)], 2.0140581 secs] [Times: user=2.00 sys=0.01, real=2.02 secs]
Heap after GC invocations=9131 (full 23):
par new generation total 368640K, used 32935K [0x03030000, 0x1c030000, 0x1c030000)
eden space 327680K, 10% used [0x03030000, 0x05059c10, 0x17030000)
from space 40960K, 0% used [0x17030000, 0x17030000, 0x19830000)
to space 40960K, 0% used [0x19830000, 0x19830000, 0x1c030000)
concurrent mark-sweep generation total 819200K, used 818879K [0x1c030000, 0x4e030000, 0x4e030000)
concurrent-mark-sweep perm gen total 204800K, used 33887K [0x4e030000, 0x5a830000, 0x5a830000)
}
{Heap before GC invocations=9131 (full 23):
par new generation total 368640K, used 215915K [0x03030000, 0x1c030000, 0x1c030000)
eden space 327680K, 65% used [0x03030000, 0x1030afe8, 0x17030000)
from space 40960K, 0% used [0x17030000, 0x17030000, 0x19830000)
to space 40960K, 0% used [0x19830000, 0x19830000, 0x1c030000)
concurrent mark-sweep generation total 819200K, used 818879K [0x1c030000, 0x4e030000, 0x4e030000)
concurrent-mark-sweep perm gen total 204800K, used 33887K [0x4e030000, 0x5a830000, 0x5a830000)
113579.505: [Full GC 113579.505: [CMS: 818879K->818799K(819200K), 1.8753771 secs] 1034795K->883632K(1187840K), [CMS Perm : 33887K->33887K(204800K)], 1.8756784 secs] [Times: user=1.86 sys=0.02, real=1.88 secs]
Heap after GC invocations=9132 (full 24):
par new generation total 368640K, used 64832K [0x03030000, 0x1c030000, 0x1c030000)
eden space 327680K, 19% used [0x03030000, 0x06f80310, 0x17030000)
from space 40960K, 0% used [0x17030000, 0x17030000, 0x19830000)
to space 40960K, 0% used [0x19830000, 0x19830000, 0x1c030000)
concurrent mark-sweep generation total 819200K, used 818799K [0x1c030000, 0x4e030000, 0x4e030000)
concurrent-mark-sweep perm gen total 204800K, used 33887K [0x4e030000, 0x5a830000, 0x5a830000)
}
{Heap before GC invocations=9132 (full 24):
par new generation total 368640K, used 365462K [0x03030000, 0x1c030000, 0x1c030000)
eden space 327680K, 100% used [0x03030000, 0x17030000, 0x17030000)
from space 40960K, 92% used [0x17030000, 0x19515918, 0x19830000)
to space 40960K, 0% used [0x19830000, 0x19830000, 0x1c030000)
concurrent mark-sweep generation total 819200K, used 818799K [0x1c030000, 0x4e030000, 0x4e030000)
concurrent-mark-sweep perm gen total 204800K, used 33887K [0x4e030000, 0x5a830000, 0x5a830000)
113581.692: [Full GC 113581.692: [CMS: 818799K->818794K(819200K), 1.9379831 secs] 1184261K->864338K(1187840K), [CMS Perm : 33887K->33887K(204800K)], 1.9382735 secs] [Times: user=1.91 sys=0.03, real=1.94 secs]
Heap after GC invocations=9133 (full 25):
par new generation total 368640K, used 45543K [0x03030000, 0x1c030000, 0x1c030000)
eden space 327680K, 13% used [0x03030000, 0x05ca9e78, 0x17030000)
from space 40960K, 0% used [0x17030000, 0x17030000, 0x19830000)
to space 40960K, 0% used [0x19830000, 0x19830000, 0x1c030000)
concurrent mark-sweep generation total 819200K, used 818794K [0x1c030000, 0x4e030000, 0x4e030000)
concurrent-mark-sweep perm gen total 204800K, used 33887K [0x4e030000, 0x5a830000, 0x5a830000)
}
{Heap before GC invocations=9133 (full 25):
par new generation total 368640K, used 368640K [0x03030000, 0x1c030000, 0x1c030000)
eden space 327680K, 100% used [0x03030000, 0x17030000, 0x17030000)
from space 40960K, 100% used [0x17030000, 0x19830000, 0x19830000)
to space 40960K, 0% used [0x19830000, 0x19830000, 0x1c030000)
concurrent mark-sweep generation total 819200K, used 819041K [0x1c030000, 0x4e030000, 0x4e030000)
concurrent-mark-sweep perm gen total 204800K, used 33888K [0x4e030000, 0x5a830000, 0x5a830000)
113584.104: [Full GC 113584.104: [CMS: 819041K->818501K(819200K), 1.9492036 secs] 1187681K->885891K(1187840K), [CMS Perm : 33888K->33887K(204800K)], 1.9495094 secs] [Times: user=1.95 sys=0.00, real=1.95 secs]
Heap after GC invocations=9134 (full 26):
par new generation total 368640K, used 67390K [0x03030000, 0x1c030000, 0x1c030000)
eden space 327680K, 20% used [0x03030000, 0x071ffa30, 0x17030000)
from space 40960K, 0% used [0x17030000, 0x17030000, 0x19830000)
to space 40960K, 0% used [0x19830000, 0x19830000, 0x1c030000)
concurrent mark-sweep generation total 819200K, used 818501K [0x1c030000, 0x4e030000, 0x4e030000)
concurrent-mark-sweep perm gen total 204800K, used 33887K [0x4e030000, 0x5a830000, 0x5a830000)
}
113586.479: [GC [1 CMS-initial-mark: 818518K(819200K)] 1187158K(1187840K), 0.2061670 secs] [Times: user=0.22 sys=0.00, real=0.22 secs]
113586.685: [CMS-concurrent-mark-start]
{Heap before GC invocations=9134 (full 27):
par new generation total 368640K, used 368640K [0x03030000, 0x1c030000, 0x1c030000)
eden space 327680K, 100% used [0x03030000, 0x17030000, 0x17030000)
from space 40960K, 100% used [0x17030000, 0x19830000, 0x19830000)
to space 40960K, 0% used [0x19830000, 0x19830000, 0x1c030000)
concurrent mark-sweep generation total 819200K, used 818539K [0x1c030000, 0x4e030000, 0x4e030000)
concurrent-mark-sweep perm gen total 204800K, used 33888K [0x4e030000, 0x5a830000, 0x5a830000)
113586.687: [Full GC 113586.687: [CMS113587.462: [CMS-concurrent-mark: 0.770/0.776 secs] [Times: user=0.77 sys=0.00, real=0.77 secs]
(concurrent mode failure): 818539K->818462K(819200K), 2.7243913 secs] 1187179K->906000K(1187840K), [CMS Perm : 33888K->33887K(204800K)], 2.7246902 secs] [Times: user=2.70 sys=0.02, real=2.72 secs]
Heap after GC invocations=9135 (full 28):
par new generation total 368640K, used 87537K [0x03030000, 0x1c030000, 0x1c030000)
eden space 327680K, 26% used [0x03030000, 0x085ac4c0, 0x17030000)
from space 40960K, 0% used [0x17030000, 0x17030000, 0x19830000)
to space 40960K, 0% used [0x19830000, 0x19830000, 0x1c030000)
concurrent mark-sweep generation total 819200K, used 818462K [0x1c030000, 0x4e030000, 0x4e030000)
concurrent-mark-sweep perm gen total 204800K, used 33887K [0x4e030000, 0x5a830000, 0x5a830000)
添加评论
关注(0)
相关推荐
Java垃圾收集（Garbage Collection，简称GC）是Java编程中一个重要的特性，它负责自动管理内存，自动回收不再使用的对象，以避免程序员手动进行内存管理，防止内存泄漏。GC回收机制是Java虚拟机（JVM）的核心组成...
Java虚拟机（JVM）的垃圾回收（GC）机制是Java程序高效运行的关键部分，它自动管理内存，释放不再使用的对象以避免内存泄漏。本文主要探讨JVM堆内存的结构和GC的工作原理，以及如何进行性能调优。 JVM堆是Java应用...
例如，吞吐量优先的场景下可以选择并行垃圾回收器（Parallel GC），而响应时间优先的情况下则更适合使用并发标记清扫垃圾回收器（CMS）或G1垃圾回收器。 3. **监控和分析**：使用JVisualVM、Visual GC等工具监控...
Minor GC针对新生代，Major GC针对老年代，而Full GC则是对整个堆和方法区进行垃圾回收，是性能影响最大的一种。 3. **触发Full GC的原因**：当老年代空间不足、持久代空间不足、System.gc()被显式调用、上一次GC后...
GChisto及CMS GC相应补丁文件，补丁文件未亲测。 This patch adds the following features and improvements when using CMS GC in incremental mode: detecting Full GCs corrected parsing errors when using -XX:...
GC是JVM自动进行内存管理的过程，其目标是回收不再使用的对象，以释放内存空间。GC分为Minor GC、Major GC和Full GC三种类型。Minor GC针对新生代，Major GC针对老年代，而Full GC则是对整个堆和方法区的清理，执行...
《JVM性能调优——JVM内存整理及GC回收》是针对Java开发人员的重要主题，尤其是在大型企业级应用中，确保JVM（Java虚拟机）的高效运行是至关重要的。本资料深入探讨了如何通过调整JVM内存设置和优化垃圾回收机制来...
- **CMS（Concurrent Mark Sweep）GC**：并发标记清除，减少STW时间，但可能出现浮动垃圾和内存碎片问题。 - **G1（Garbage-First）GC**：基于region的收集器，目标是预测和控制停顿时间，适用于大型应用。 - **...
Java垃圾回收（GC）是Java语言的一大特性，它自动化地管理程序内存，使得开发者无需手动进行内存分配和释放，从而避免了C/C++等语言中常见的内存泄漏问题。GC通过智能地识别并回收不再使用的对象，确保内存的有效...
GC的主要目标是在不干扰程序正常运行的前提下，有效地回收内存资源。 ### **垃圾回收算法** #### 1. 引用计数法 此算法简单，但无法处理对象之间相互引用的情况，因此在现代JVM中很少使用。 #### 2. 根搜索算法...
在Java编程语言中，垃圾回收（Garbage Collection, GC）是一项至关重要的机制，它自动管理内存，释放不再使用的对象，防止内存泄漏。本篇将深入探讨如何监控Java的垃圾回收，帮助开发者提升应用性能和稳定性。 Java...
Java虚拟机（JVM）的垃圾收集（Garbage Collection, GC）是其内存管理的关键部分，用于自动回收不再使用的对象占用的内存空间。本篇主要介绍了10种不同的垃圾回收器，包括它们的工作原理、优缺点以及适用场景。 1. ...
CMS提供了一些参数来优化其行为，比如`UseCMSCompactAtFullCollection`用于在Full GC时进行内存碎片整理，以及`CMSFullGCsBeforeCompaction`来控制每隔多少次不压缩的Full GC后执行一次带压缩的Full GC。 然而，CMS...
Java虚拟机（JVM）是Java程序运行的基础，它的核心组成部分之一就是垃圾回收器（Garbage Collector, GC），以及内存分配策略。理解这些概念对于优化Java应用性能至关重要。本篇文章将深入探讨JVM的垃圾回收机制以及...
Java垃圾收集（Garbage Collection, 简称GC）是Java编程中的一项重要特性，它自动管理内存，释放不再使用的对象，避免了程序员手动管理内存可能导致的内存泄露问题。本篇将深入探讨Java中的GC过程。 一、Java内存...
Java虚拟机（JVM）是Java程序运行的基础，它的历史发展和内存回收机制是Java开发者必须深入了解的关键领域。本文将详细探讨JVM的发展历程以及内存管理中的垃圾回收机制。 一、JVM的历史发展 1. **早期阶段**：1995...
Full GC会清理整个堆内存，包括年轻代和老年代，同时也会清理方法区。 3. **垃圾收集算法**：JVM支持多种垃圾收集算法，如： - 标记-清除（Mark-Sweep） - 复制算法（Copying） - 标记-整理（Mark-Compact） - ...
面试中常见的问题包括GC收集器的对比，如CMS收集器在内存不足时可能导致Full GC，而G1能预测停顿时间。Minor GC在新生代空间不足时触发，Full GC则在全局内存不足或系统需求时发生。常用的内存调试工具有jmap、...
用于分析 java gc日志文件。根据日志中的CMS GC统计信息可得到Full GC（也可以理解为Major GC）以及Minor GC相关数据