本节介绍
- Java堆的OutOfMemoryError测试
- Eclipse Memory Analyzer分析内存溢出
- 虚拟机栈和本地方法栈*Error测试
- 方法区和运行时常量池溢出
- 本机直接内存溢出
(1)首先设置debug configuration。如下图所示:
(2)接下来进行编码操作,如下面的代码所示,不断添加新的对象到List中。由于Java堆设置的大小为20M并且不可扩展(将堆的最小值-Xms参数与最大值-Xmx参数设置为一样即可避免堆自动扩展),通过参数-XX:+HeapDumpOnOutOfMemoryError可以让虚拟机出现内存溢出异常时Dump出当前的内存堆转储快照以便事后进行分析。
Java堆内存溢出测试:如下如所示:
(3)结果分析:Java堆内存的OOM(OutOfMemoryError)异常是实际应用中常见的内存溢出异常情况。当出现Java堆内存溢出时,异常堆栈信息“java.lang.OutOFMemoryError”会跟着进一步提示“Java heap space”
二、Eclipse Memory Analyzer分析内存溢出
(1) Eclipse安装Eclipse Memory Analyzer。
现在已经出1.2.1了,下载地址http://www.eclipse.org/mat/downloads.php
也可以通过eclipse install new software ,地址http://download.eclipse.org/mat/1.2/update-site/
(2)打开进入后,如下所示:
要解决这个区域的异常,一般的手段是先通过内存映像工具(如Eclipse Memory Analyzer)对Dump出来的堆转储快照进行分析,重点是确认内存中的对象是否都是必要的,也就是要先分清楚到底是出现了内存泄露还是内存溢出。
从上图可以看到它的大部分功能。
1. Histogram可以列出内存中的对象,对象的个数以及大小。
2. Dominator Tree可以列出那个线程,以及线程下面的那些对象占用的空间。
3.Top consumers通过图形列出最大的object。
4.Leak Suspects通过MA自动分析泄漏的原因。
(3)这次重点是看Leak Suspects,点开后就能看到:
(4)结果分析:在这张图上,我们可以清楚的看到,这个对象集合中保存了大量YourBeauty对象的引用,就是它导致的内存泄露。
三、虚拟机栈和本地方法栈*Error测试
(1)如果线程请求的栈深度大于虚拟机所允许的最大深度,将抛出*Error异常。
(2)如果虚拟机在扩展栈时无法申请到足够的内存空间,则抛出OutOfMemoryError异常。 (3)使用-Xss参数减小栈内存容量。测试结果:抛出*Error异常。异常出现时输出堆栈深度相应减小。 (4) 实验表明:在单线程情况下,无论是由于栈帧太大还是虚拟机栈容量太小,当内存无法分配的时候,虚拟机抛出的都是*Error异常。
四、方法区和运行时常量池溢出
(1)由于运行时常量池是方法区的一部分,因此这两个区域的溢出测试就放在了一起进行。前面提到JDK 1.7开始逐步“去永久代”的事情,在此就以测试代码观察一下这件事对程序的实际影响。
(2)String.intern()是一个Native方法,它的作用是:如果字符串常量池已经包含一个等于此String对象的字符串,则返回代表池中这个字符串的String对象;否则,将此String对象包含的字符串添加到常量池中,并且返回此String对象的引用。在JDK1.6及之前的版本中,由于常量池分配中永久代内,我们可以通过-XX:PermSize和-XX:MaxPermSize限制方法区大小,从而间接限制其中常量池的容量。
五、本机直接内存溢出
(1) DirectMemory容量可通过-XX:MaxDirectMemorySize指定,如果不知道,则默认与Java堆最大值(-Xmx指定)一样,下述代码越过了DirectByteBuffer类,直接通过反射获取Unsafe实例进行内存分配。因为,虽然使用DirectByteBuffer分配内存也会抛出内存溢出异常,但它抛出异常时并没有真正向操作系统申请分配内存,而是同计算得知内存无法分配,于是手动抛出异常,真正申请分配内存的方法是unsafe.allocateMemory()
(2)使用unsafe分配本机内存。
根据GC的工作原理,我们可以通过一些技巧和方式,让GC运行更加有效率,更加符合应用程序的要求。以下就是一些程序设计的几点建议。
1.最基本的建议就是尽早释放无用对象的引用。大多数程序员在使用临时变量的时候,都是让引用变量在退出活动域(scope)后,自动设置为null.我们在使用这种方式时候,必须特别注意一些复杂的对象图,例如数组,队列,树,图等,这些对象之间有相互引用关系较为复杂。对于这类对象,GC回收它们一般效率较低。如果程序允许,尽早将不用的引用对象赋为null.这样可以加速GC的工作。
2.尽量少用finalize函数。finalize函数是Java提供给程序员一个释放对象或资源的机会。但是,它会加大GC的工作量,因此尽量少采用finalize方式回收资源。
3.如果需要使用经常使用的图片,可以使用soft应用类型。它可以尽可能将图片保存在内存中,供程序调用,而不引起OutOfMemory.
4.注意集合数据类型,包括数组,树,图,链表等数据结构,这些数据结构对GC来说,回收更为复杂。另外,注意一些全局的变量,以及一些静态变量。这些变量往往容易引起悬挂对象(dangling reference),造成内存浪费。
5.当程序有一定的等待时间,程序员可以手动执行System.gc(),通知GC运行,但是Java语言规范并不保证GC一定会执行。使用增量式GC可以缩短Java程序的暂停时间。