JVM内存监视手段和内存溢出解决方案

引言

本文仅关注一些常见的虚拟机内存监视手段,以及JVM运行时数据区各个部分内存溢出的发生和对应的解决方案,总体来说属于概括性总结,涉及相对不是很深入,目的是让自己和其它初学者有一个框架性、概念性的了解,当遇到问题时有迹可循、不至于不知所措。

一、虚拟机内存监视手段

虚拟机常出现的问题包括:内存泄露、内存溢出、频繁GC导致性能下降等,导致这些问题的原因可以通过下面虚拟机内存监视手段来进行分析,具体实施时可能需要灵活选择,同时借助两种甚至更多的手段来共同分析。

比如GC日志可以分析出哪些GC较为频繁导致性能下降、是否发生内存泄露。jstat工具和GC日志类似,同样可以查看GC情况、分析是否发生内存泄露。判断发生内存泄露后,可以通过jmap工具和MAT等分析工具的结合查看虚拟机内存快照,分析发生内存泄露的原因。内存溢出快照可以分析出内存溢出发生的原因等。

GC日志记录

将JVM每次进行GC的情况记录下来,通过观察GC日志可以看出来GC的频度、以及每次GC都回收了哪些区域的内存,根据这些信息为依据来调整JVM相关设置,可以减少Minor GC的频率以及Full GC的次数,还可以判断是否有内存泄露发生。

下面是常见的GC日志输出参数:

u  -verbose.gc:显示GC的操作内容。打开它,可以显示最忙和最空闲收集行为发生的时间、收集前后的内存大小、收集需要的时间等。

u  -XX:+printGCdetails:详细了解GC中的变化。

u  -XX:+PrintGCTimeStamps:了解垃圾收集发生的时间,自JVM启动以后以秒计量。

u  -XX:+PrintHeapAtGC:了解堆的更详细的信息。

u  -Xloggc:[file]:将GC信息输出到单独的文件中

jstat:虚拟机统计信息监控工具

实时监视虚拟机运行时的类装载情况、各部分内存占用情况、GC情况、JIT编译情况等。

例:每隔250ms查询一次进程2211的垃圾收集情况,查询50次

步骤①:jps列出本机所有运行的jvm实例,获取jvm的pid

步骤②:jstat实时监控gc情况,jstat –gc 2211 250 50

其他参数包括:

-class监视类装载、卸载数量、总空间以及类装载所耗费时间

-gccapacity监视内容与-gc相同,输出主要关注堆各个区域用到的最大、最小空间

-gcutil监视内同与-gc相同,输出主要关注堆各个区域已使用空间所占总空间百分比

-gcnew监视新生代GC情况

-gcold监视旧生代GC情况

jmap:虚拟机内存映像工具

jmap工具可以让运行中的JVM生成Dump文件,当JVM内存出现问题时可以通过jmap生成快照,分析整个堆,主要经历两个步骤:

步骤1:jps列出本机所有运行的jvm实例,获取jvm的pid

步骤2:使用jmap命令将指定JVM快照导出为dump文件

jmap -dump:format=b,file=path/heap.bin PID

获得JVM快照的dump文件之后,可以通过MAT工具进行分析。

MAT(MemoryAnalyzer Tool)工具是eclipse的一个插件,使用起来非常方便,尤其是在分析大内存的dump文件时,可以非常直观的看到各个对象在堆空间中所占用的内存大小、类实例数量、对象引用关系、利用OQL对象查询,以及可以很方便的找出对象GC Roots的相关信息,最吸引人的是能够快速为开发人员生成内存泄露报表,方便定位和分析问题。

除此之外,jmap还可以查询finalize执行队列、Java堆和持久代的详细信息,比如空间使用率,当前使用的是哪种收集器等。

内存溢出快照生成

通过设置JVM参数,可以让虚拟机发生OutOfMemoryError(OOM)内存溢出时自动生成dump文件,通过分析dump文件查看内存使用情况可以找到内存溢出发生的原因:

-XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath=/path/to/heap/dump

获得JVM快照的dump文件之后,可以通过MAT工具进行分析。

二、运行时数据区内存溢出

JVM运行时数据区分为以下几个部分:

其中方法区和堆是所有工作线程共享的,而栈、程序计数器和本地方法栈是线程私有的。

注:图片转自网络

1.程序计数器

作用:指向当前线程下一条需要执行的字节码指令的地址

内存溢出:不会发生

2.虚拟机栈

作用:由栈帧组成、每个栈帧代表一次方法调用,其包含存储变量表、操作数栈和方法出口三个部分,方法执行完成后该栈帧将被弹出。

内存溢出:StackOverflowError和OutOfMemoryError。

溢出原因:

StackOverflowError:如果请求的栈的深度大于虚拟机所允许的深度,将会抛出这个异常,如果使用虚拟机默认参数,一般达到1000到2000这样的深度没有问题。

OutOfMemoryError:因为除掉堆内存和方法区容量,剩下的内存由虚拟机栈和本地方法栈瓜分,如果剩下的内存不足以满足更多的工作线程的运行、或者不足以拓展虚拟机栈的时候,就会抛出OutOfMemoryError异常。

解决方法:

针对StackOverflowError:

1.      首先栈溢出会输出异常信息,根据信息查看对应的方法调用是否出现无限调用、或者栈帧过大等代码逻辑上的问题,通过修改代码逻辑解决;

2.      如果确确实实需要更大的栈容量,可以检查并调大栈容量:-Xss16m。

针对OutOfMemoryError:

1.      首先检查是否创建过多的线程,减少线程数

2.      可以通过“减少最大堆容量”或“减少栈容量”来解决。

3.本地方法栈

作用:与虚拟机栈唯一的不同是虚拟机栈执行的是java方法,而本地方法栈执行的是本地的C/C++方法

内存溢出:StackOverflowError和OutOfMemoryError

溢出原因:同虚拟机栈

解决方法:同虚拟机栈

4.堆

作用:所有线程共享,存放对象实例

内存溢出:OutOfMemoryError:Javaheap space

溢出原因:堆中没有足够内存完成实例分配,并且无法继续拓展时

解决方法:

1.内存泄露检查:首先通过“内存溢出快照 + MAT等分析工具”,分析是否存在内存泄露现象,检查时可以怀疑的点比如集合、第三方库如数据库连接的使用、new关键字相关等。

2.如果没有内存泄露,那么就是内存溢出,所有对象却是都还需要存活,这个时候就只能调大堆内存了:-Xms和-Xmx。

5.方法区

作用:所有线程共享,存放已加载的class信息、常量、静态变量和即时编译后的代码

内存溢出:OutOfMemoryError:PermGen space

溢出原因:方法区没有足够内存完成内存分配存放运行时新加载的class信息

解决方法:

1. 内存泄露检查:检查是否加载过多class文件(jar文件),或者重复加载相同的class文件(jar文件)多次

2. 通过-XX:PermSize=64M -XX:MaxPermSize=128M改大方法区大小

6.运行时常量池

作用:方法区的一部分,存放常量

内存溢出:OutOfMemoryError:PermGen space

溢出原因:方法区没有足够的内存完成内存分配,存放运行时新创建的常量,比如String类的intern()方法,其作用是如果常量池已经包含一个相同的字符串,则返回其引用,否则将此String对象包含的字符串添加到常量池中。

解决方法:

1. 内存泄露检查:检查是否创建过多常量

2. 通过-XX:PermSize=64M -XX:MaxPermSize=128M改大方法区大小

7.直接内存

作用:不属于JVM运行时数据区,也不是虚拟机规范中定义的内存区域,JDK1.4引入的NIO中包含通道Channel和缓冲区Buffer,应用程序从通道获取数据是先经过OS的内核缓冲区,再拷贝至Buffer,因为比较耗时,所以Buffer提供了一种直接操作操作系统缓冲区的方式,即ByteBuffer.allocateDirector(size),这个方法返回DirectByteBuffer应用就是指向这个底层存储空间关联的缓冲区,即直接内存(native memory),或者叫堆外内存。

内存溢出:OutOfMemoryError

溢出原因:JVM所需内存 + 直接内存 > 机器物理内存(或操作系统级限制),无法动态拓展

判断方法:内存泄露检查:例如内存占用较高,机器性能骤降,但是通过GC信息或者jstat发现GC很少,通过jmap获得快照分析后也没发现什么异常,而程序中又直接或者间接地用到了NIO,那么和可能就是直接内存泄露了。

解决方法:分析NIO相关的程序逻辑解决。

时间: 2024-12-16 02:33:53

JVM内存监视手段和内存溢出解决方案的相关文章

JVM:内存监视手段及各区域内存溢出解决

转载请务必注明出处: jiq?钦's technical Blog - 季义钦 引言 本文仅关注一些常见的虚拟机内存监视手段,以及JVM运行时数据区各个部分内存溢出的发生和对应的解决方案,总体来说属于概括性总结,涉及相对不是很深入,目的是让自己和其它初学者有一个框架性.概念性的了解,当遇到问题时有迹可循.不至于不知所措. 一.虚拟机内存监视手段 虚拟机常出现的问题包括:内存泄露.内存溢出.频繁GC导致性能下降等,导致这些问题的原因可以通过下面虚拟机内存监视手段来进行分析,具体实施时可能需要灵活选

应用jacob组件造成的内存溢出解决方案(java.lang.OutOfMemoryError: Java heap space)

http://www.educity.cn/wenda/351088.html 使用jacob组件造成的内存溢出解决方案(java.lang.OutOfMemoryError: Java heap space) 都说内存泄漏是C++的通病,内存溢出是Java的硬伤,这个头疼的问题算是让我给碰到了.我在做的这个功能涉及到修改word文档,因为微软没有公开word源代码,所以直接用java流来读取word的后果是读出来的会是乱码,经过查资料得知可以使用poi和jacob来操作word,jacob使用

内存溢出解决方案

内存溢出解决方案 1.内存溢出(OOM)是指应用系统中存在无法回收的内存或使用的内存过多,最终使得程序运行要用到的内存大于虚拟机能提供的最大内存.为了解决Java中内存溢出问题, 我们首先必须了解Java是如何管理内存的.Java的内存管理就 是对象的分配和释放问题.在Java中,内存的分配是由程序完成的,而内存的释放是由垃圾收集器(GarbageCollection,GC)完成的, 程 序员不需要通过调用GC函数来释放内存,因为不同的JVM实现者可能使用不同的算法管理GC,有的是内存使用到达一

Android 内存溢出解决方案(OOM)

众所周知,每个Android应用程序在运行时都有一定的内存限制,限制大小一般为16MB或24MB(视平台而定).因此在开发应用时需要特别关注自身的内存使用量,而一般最耗内存量的资源,一般是图片.音频文件.视频文件等多媒体资源:由于Android系统对音频.视频等资源做了边解析便播放的处理,使用时并不会把整个文件加载到内存中,一般不会出现内存溢出(以下简称OOM)的错误,因此它们的内存消耗问题暂不在本文的讨论范围.本文重点讨论的是图片的内存消耗问题,如果你要开发的是一款图片浏览器应用,例如像And

JVM学习—内存方区域与内存溢出异常

Java与C++中存在的一堵高墙就是又内存动态分配和垃圾回收技术所围成的,墙外面的人想进去,墙里面的人想出去. Java将内存控制权交给了JVM,所以程序员无需为每个对象手动释放空间,所以不容易出现内存泄露与溢出.但是一旦出现内存泄露或溢出,如果不了解虚拟机怎样分配内存的,那么排查将非常困难.Java虚拟机将执行java程序过程中管理的内存划分成若干个区域,每个区域有各自的用途以及创建和销毁的时间.这些区域有的是随着JVM进程启动而存在,有的则是通过用户线程的启动和结束而建立和销毁. 程序计数器

PHP内存溢出解决方案

一.内存溢出解决方案 在做数据统计分析时,经常会遇到大数组,可能会发生内存溢出,这里分享一下我的解决方案.还是用例子来说明这个问题,如下: 假定日志中存放的记录数为500000条,那么解决方案如下: ini_set(‘memory_limit’,’64M’); //重置php可以使用的内存大小为64M,一般在远程主机上是不能修改php.ini文件的,只能通过程序设置.注:在safe_mode(安全模式)下,ini_set失效 set_time_limit(600);//设置超时限制为6分钟 $f

Android内存溢出解决方案(OOM)

众所周知,每个Android应用程序在运行时都有一定的内存限制,限制大小一般为16MB或24MB(视平台而定).因此在开发应用时需要特别关注自身的内存使用量,而一般最耗内存量的资源,一般是图片.音频文件.视频文件等多媒体资源:由于Android系统对音频.视频等资源做了边解析便播放的处理,使用时并不会把整个文件加载到内存中,一般不会出现内存溢出(以下简称OOM)的错误,因此它们的内存消耗问题暂不在本文的讨论范围.本文重点讨论的是图片的内存消耗问题,如果你要开发的是一款图片浏览器应用,例如像And

JVM自动内存管理机制——Java内存区域

一.JVM运行时数据区域概述 Java相比较于C/C++的一个特点就是,在虚拟机自动内存管理机制的帮助下,我们不需要为每一个操作都写像C/C++一样的delete/free代码,所以也不容易出现内存泄漏和内存溢出的问题.显然,这里的不容易只是相对而言的,如果我们想要降低这种代码隐患的发生,就需要对Java虚拟机怎样使用内存有了解,这样的话就算产生错误,排查起来也会相对容易.下面我们来说一说JVM运行时数据区域 1.程序计数器(PC寄存器): 被看作是当前线程所执行的字节码的行号指示器,字节码解析

drools规则引擎因为内存泄露导致的内存溢出

进入这个问题之前,先了解一下drools: 在很多行业应用中比如银行.保险领域,业务规则往往非常复杂,并且规则处于不断更新变化中,而现有很多系统做法基本上都是将业务规则绑定在程序代码中. 主要存在的问题有以下几个方面: 1) 当业务规则变更时,对应的代码也得跟着更改,每次即使是小的变更都需要经历开发.测试验证上线等过程,变更成本比较大. 2) 长时间系统变得越来越难以维护. 3) 开发团队一般是由一个熟悉业务的BA(业务分析人员)和若干个熟悉技术的开发人员组成,开发人员对业务规则的把握能力远不及