探查内存不足(内存泄露)问题 - zhaonjtu - JavaEye技术网站
来源:百度文库 编辑:神马文学网 时间:2024/06/03 04:45:25
探查内存不足(内存泄露)问题
关键字: 探查内存不足(内存泄露)问题Java 堆、本地内存和进程大小 Java 堆 - 这是 JVM 用来分配 java 对象的内存。java 堆内存的最大值用 java 命令行中的 .Xmx 标志来指定。如果未指定最大的堆大小,那么该极限值由 JVM 根据诸如计算机中的物理内存量和该时刻的可用空闲内存量这类因素来决定。始终建议您指定最大的 java 堆值。本地内存 - 这是 JVM 用于其内部操作的内存。JVM 将使用的本地内存堆数量取决于生成的代码量、创建的线程、GC 期间用于保存 java 对象信息的内存,以及在代码生成、优化等过程中使用的临时空间。 进程大小 - 进程大小将是 java 堆、本地内存与加载的可执行文件和库所占用内存的总和。在 32 位操作系统上,进程的虚拟地址空间最大可达到 4 GB。从这 4 GB 内存中,操作系统内核为自己保留一部分内存(通常为 1 - 2 GB)。剩余内存可用于应用程序。 Windows缺省情况下,2 GB 可用于应用程序,剩余 2 GB 保留供内核使用。但是,在 Windows 的一些变化版本中,有一个 /3GB 开关可用于改变该分配比率,使应用程序能够获得 3 GB。有关 /3GB 开关的详细信息,可以在以下网址中找到:http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ddtools/hh/ddtools/bootini_1fcj.asp RH Linux AS 2.1 - 3 GB 可用于应用程序。 对于其它操作系统,请参考操作系统文档了解有关配置。 进程地址空间和物理内存之间的差异 每个进程都获得其自有的地址空间。在 32 位操作系统中,此地址空间范围为 0 到 4 GB。此范围与计算机的可用随机存取内存 (RAM) 或交换空间无关。计算机中的可用物理内存总量是该计算机上的可用 RAM 和交换空间之和。所有运行的进程共享这些物理内存。 进程内的存储地址是虚拟地址。内核将此虚拟地址映射到物理地址上。物理地址指向物理内存中的某个位置。在任一给定时间,计算机中运行进程所使用的全部虚拟内存的总和不能超过该计算机上可用物理内存的总量。 为什么会发生 OOM 问题,JVM 在这种情况下如何处理? java 堆中的内存不足 在这种情况下,JVM 让应用程序决定在抛出 java.lang.OutOfMemoryError 后该执行什么操作。例如,应用程序可以处理此错误,并决定以安全方式自行关闭或决定忽略此错误。如果应用程序不处理此错误,那么抛出此错误的线程将退出(如果您进行 java Thread Dump,那么将看不到该线程)。 在使用 Weblogic Server 的情况下,如果此错误是由某个执行线程抛出的,则会处理此错误并将其记录在日志中。如果连续抛出此错误,那么核心运行状况监视器线程将关闭 Weblogic Server。 本地堆中的内存不足 当发生这种情况时,JVM 处理本地 OOM 状态,记录说明它已用完本地内存或无法获得内存的消息,然后退出。如果 JVM 或加载的任何其它模块(如 libc 或第三方模块)不处理这个本地 OOM 状态,那么操作系统将给 JVM 发送命令 JVM 退出的 sigabort 信号。通常情况下,JVM 收到 sigabort 信号时将会生成一个核心文件。 排除故障的步骤确定是 Java OOM 还是本地 OOM: 请注意,上述消息仅发送到 stdout 或 stderr 中,而不发送到应用程序特定的日志文件(如 weblogic.log) 完整 GC 运行: 您可以检查是否在发出 OOM 消息之前执行了完整 GC 运行。当完成一次完整 GC 运行时,将会打印类似如下消息(格式取决于 JVM - 请查看 JVM 帮助信息以了解有关格式) [memory ] 7.160: GC 131072K->130052K (131072K) in 1057.359 ms 以上输出的格式如下(备注:在此模式下将全部使用相同的格式): [memory ] 但是,没有办法断定是否使用 verbose 消息删除了软/弱/虚可及的对象。如果您怀疑在抛出 OOM 时这些对象仍然存在,请与 JVM 供应商联系。 如果垃圾回收算法是一种按代回收算法(对于 Jrockit 为 gencopy 或 gencon,对于其它 JDK 则是缺省算法),您也将看到类似如下的 verbose 输出: 以上是 nursery GC(即 young GC)周期,它将把活动对象从 nursery(或 young 空间)提升到 old 空间。这个周期对我们的分析不重要。有关按代回收算法的详细信息,可以在 JVM 文档中找到。 如果在 java OOM 之前未发生 GC 周期,那么这是一个 JVM 错误。 完全压缩: Java 对象要求内存是连续的。如果可用空闲内存是一些碎片,那么 JVM 将无法分配大对象,因为它可能无法放入任何可用空闲内存块中。在这种情况下,JVM 将执行一次完全压缩,以便形成更多连续的空闲内存来容纳大对象。 压缩工作包括在 java 堆内存中将对象从一个位置移动到另一个位置,以及更新对这些对象的引用以指向新位置。除非确有必要,否则 JVM 不会压缩所有对象。这是为了减少 GC 周期的暂停时间。 我们可以通过分析 verbose gc 消息来检查 java OOM 是否由碎片引起。如果您看到类似如下的输出(在此无论是否有可用的空闲 java 堆都会抛出 OOM),那么这就是由碎片引起的。 [memory ] 8.162: GC 73043K->72989K (131072K) in 12.938 ms 在上述情况中您可以看到,所指定的最大堆内存是 128MB,并且当实际内存使用量仅为 72580K 时,JVM 抛出 OOM。堆使用量仅为 55%。因此在这种情况下,碎片影响是:即使还有 45% 的空闲堆,内存也会抛出 OOM。这是一个 JVM 错误或缺陷。您应当与 JVM 供应商联系。 Java 软引用也可用于数据缓存,当 JVM 用完 java 堆时,可以保证删除软可及对象。 对于本地 OOM 问题: 在 Unix 或 Linux 环境下,对于一个给定 PID,可以使用以下命令来查找虚拟内存大小 - ps -p 在 Linux 环境下,单个 JVM 实例内的每个 java 线程都显示为一个独立的进程。如果我们获得根 java 进程的 PID,那么这就足够了。可以使用 ps 命令的 .forest 选项来找到根 java 进程。例如,ps lU 调整 java 堆 为了缩小问题的范围,可尝试禁用运行时优化,并检查这是否会产生任何效果。 如果在整个运行过程中,本地内存使用量继续不断增加,那么这可能是本地代码中的内存泄漏。 检查应用程序是否使用一些 JNI 代码。这也可能造成本地内存泄漏,如果可能的话,您可以尝试在没有 JNI 代码的情况下运行应用程序。
如果有一个第三方本地模块,那么它也可能使用本地内存。例如,本地 JDBC 驱动程序将分配本地内存。
最大本地内存量受到任何特定操作系统上的虚拟进程大小限制的约束,也受到用 .Xmx 标志指定用于 java 堆的内存量的限制。例如,如果应用程序能分配总计为 3 GB 的内存量,并且最大 java 堆的大小为 1 GB,那么本地内存量的最大值可能在 2 GB 左右。
如果 JVM 不能在 java 堆中获得更多内存来分配更多 java 对象,将会抛出 java 内存不足 (java OOM) 错误。如果 java 堆充满了活动对象,并且 JVM 无法再扩展 java 堆,那么它将不能分配更多 java 对象。
如果 JVM 无法获得更多本地内存,它将抛出本地内存不足(本地 OOM)错误。当进程到达操作系统的进程大小限值,或者当计算机用完 RAM 和交换空间时,通常会发生这种情况。
对于 Java OOM:
执行一次完整 GC 运行,并且删除了所有不可及对象以及虚可及、弱可及、软可及对象,并回收了那些空间。有关不同级别的对象可及性的详细信息,可以在以下网址中可找到:http://java.sun.com/developer/technicalArticles/ALT/RefObj
[memory ]
[memory ]
[memory ]
[memory ]
[memory ]
[memory ] 2.414: Nursery GC 31000K->20760K (75776K), 0.469 ms
确保 JVM 执行了适当的压缩工作,并且内存并未成碎片(否则会阻止分配大对象并触发 java OOM 错误)。
[memory ] 8.172: GC 72989K->72905K (131072K) in 12.000 ms
[memory ] 8.182: GC 72905K->72580K (131072K) in 13.509 ms
java.lang.OutOfMemoryError
应当注意,指定的最大堆内存量(在 java 命令行中使用 Xmx 标志)与应用程序的实际 java 堆使用量无关,其在 JVM 启动时被保留,并且此保留内存不能用于其它任何用途。
在使用 Jrockit 时,使用 -verbose 来代替 -verbosegc,因为这可以提供 codegen 信息以及 GC 信息。
在 Windows 环境下,使用下列步骤来监视虚拟进程大小:
如果计算机没有足够的 RAM 和交换空间,则操作系统将不能为此进程提供更多内存,这样也会导致内存不足。请确保 RAM 与磁盘中的交换空间之和足以满足该计算机中正在运行的所有进程的需要。
如果 java 堆使用量完全在最大堆范围内,则减小 java 最大堆将为 JVM 提供更多的本地内存。这不是一个解决办法,而是一个可尝试的变通方法。由于操作系统限制进程大小,我们需要在 java 堆和本地堆之间寻求一个平衡。
在加载了所有类并调用了方法(代码生成结束)后,JVM 的本地内存用量预计将会几乎达到稳定。对于大多数应用程序而言,这通常发生在最初几小时内。此后,JVM 可能会因加载运行时类型、生成优化代码等处理而仅使用少量本地内存。
检查您是否在使用类似数据库驱动程序的任何第三方本地模块。这些本地模块也可以分配本地内存,泄漏可能从这些模块中发生。为了缩小问题的范围,应尝试在没有这些第三方模块的情况下重现问题。例如,可以使用纯 java 驱动程序来代替本地数据库驱动程序。