JAVA内存泄露专题.docx

内存泄露与内存溢出1 定义1、内存泄漏：一般可以理解为系统资源（各方面的资源，堆、栈、线程等）在错误使用的情况下，导致使用完毕的资源无法回收（或没有回收）,从而造成那部分内存不可用的情况。2、内存溢出：指内存不够使用而抛出异常，内存泄露是其形成的原因之一。2 危害会导致新的资源分配请求无法完成，引起系统错误，最后导致系统崩溃。3 内存泄漏分类类型描述常发性内存泄漏发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏偶发性内存泄漏发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的一次性内存泄漏发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次隐式内存泄漏程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏4 内存泄露/溢出发生的区域内存区域发生情况备注程序计数器不可能虚拟机栈Y本地方法栈Y非堆内存Y即方法区、持久代运行时常量池Y本机直接内存Y堆内存Y5 内存溢出异常内存区域异常虚拟机栈java.lang.StackOverflowError本地方法栈java.lang.OutOfMemoryError: unable to create new native thread非堆内存java.lang.OutOfMemoryError:PermGen space运行时常量池java.lang.OutOfMemoryError:PermGenspace本机直接内存java.lang.OutOfMemoryError堆内存java.lang.OutOfMemoryError: Java heap space6 内存溢出常见原因异常常见原因解决办法java.lang.StackOverflowError线程栈的溢出，要么是方法调用层次过多（比如存在无限递归调用），要么是线程栈太小1、 增大线程栈2、 优化程序设计，减少方法调用层次java.lang.OutOfMemoryError: unable to create new native threadStack空间不足以创建额外的线程，要么是创建的线程过多，要么是Stack空间确实小1.通过-Xss启动参数减少单个线程栈大小，这样便能开更多线程（当然不能太小，太小会出现StackOverflowError）2.通过-Xms -Xmx 两参数减少Heap大小，将内存让给Stack（前提是保证Heap空间够用）java.lang.OutOfMemoryError:PermGen spacePermanent Generation空间不足，不能加载额外的类，可能为运行时常量池溢出或持久代溢出。大量动态反射生成的类不断被加载可导致此错误调整PermGen内存java.lang.OutOfMemoryError有可能本机直接内存不够用java.lang.OutOfMemoryError: Java heap space1、内存泄露2、堆内存分配不合理引起溢出3、创建一个占用内存过大的对象1、调整堆内存2、根据垃圾回收前后情况对比，同时根据对象引用情况（常见的集合对象引用）分析，基本都可以找到泄漏点，然后修改程序错误7 发生内存泄露的情形Java内存泄露根本原因是什么呢？答：长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄露，尽管短生命周期对象已经不再需要，但是因为长生命周期对象持有它的引用而导致不能被回收，这就是java中内存泄露的发生场景。具体主要有如下几大类：7.1 静态集合类引起内存泄露像HashMap、Vector等的使用最容易出现内存泄露，这些静态变量的生命周期和应用程序一致，他们所引用的所有的对象Object也不能被释放，因为他们也将一直被Vector等引用着。例:import java.util.Vector;/* * author leijp*/public class VectorMemoryOOM public static void main(String args) Vector vobj = new Vector(10);for (int i = 0; i 100; i+) Object obj = new Object();/注意此处Java如何清除内存 vobj.add(obj); obj = null; /GC会清除这一块内存吗？ System.out.print(end);解析：在这个例子中，循环申请Object 对象，并将所申请的对象放入一个Vector 中，如果仅仅释放引用本身（o=null），那么Vector 仍然引用该对象，所以这个对象对GC 来说是不可回收的。因此，如果对象加入到Vector 后，还必须从Vector 中删除，最简单的方法就是将Vector对象设置为null。7.2 创建过大对象public class VectorMemoryOOM /* * param args */public static void main(String args) Vector vobj = new Vector(999999999);运行结果：Exception in thread main java.lang.OutOfMemoryError: Java heap spaceat java.util.Vector.(Vector.java:131)at java.util.Vector.(Vector.java:144)at test.VectorMemoryOOM.main(VectorMemoryOOM.java:19)以上代码运行时瞬间报错。7.3 监听器在java 编程中，我们都需要和监听器打交道，通常一个应用当中会用到很多监听器，我们会调用一个控件的诸如addXXXListener()等方法来增加监听器，但往往在释放对象的时候却没有记住去删除这些监听器，从而增加了内存泄漏的机会。7.4 各种连接比如数据库连接（dataSourse.getConnection()），网络连接(socket)和io连接，除非其显式的调用了其close（）方法将其连接关闭，否则是不会自动被GC 回收的。对于Resultset 和Statement 对象可以不进行显式回收，但Connection 一定要显式回收，因为Connection 在任何时候都无法自动回收，而Connection一旦回收，Resultset 和Statement 对象就会立即为NULL。但是如果使用连接池，情况就不一样了，除了要显式地关闭连接，还必须显式地关闭Resultset Statement 对象（关闭其中一个，另外一个也会关闭），否则就会造成大量的Statement 对象无法释放，从而引起内存泄漏。这种情况下一般都会在try里面去的连接，在finally里面释放连接。7.5 内部类和外部模块等的引用内部类的引用是比较容易遗忘的一种，而且一旦没释放可能导致一系列的后继类对象没有释放。此外程序员还要小心外部模块不经意的引用，例如程序员A 负责A 模块，调用了B 模块的一个方法如：public void registerMsg(Object b);这种调用就要非常小心了，传入了一个对象，很可能模块B就保持了对该对象的引用，这时候就需要注意模块B 是否提供相应的操作去除引用。7.6 单例模式不正确使用单例模式是引起内存泄露的一个常见问题，单例对象在被初始化后将在JVM的整个生命周期中存在（以静态变量的方式），如果单例对象持有外部对象的引用，那么这个外部对象将不能被jvm正常回收，导致内存泄露8 JVM监控分析8.1 查看系统资源的基本使用情况8.2 查看内存使用情况8.3 典型内存泄露堆内存情况9 内存溢出/泄露实战9.1 模拟Java堆溢出说明：Java堆用于存储对象实例，只要不断地创建对象，并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象，那么在对象数量到达最大堆的容量限制后就会产生内存溢出异常。通过设置参数-XX:+HeapDumpOnOutOfMemoryError可以让虚拟机在出现内存溢出异常时Dump出当前的内存堆转储快照以便事后进行分析。代码清单1Java堆内存溢出异常测试/* * VM Args：-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError * author leijp */public class TestOutOfMemoryError static class OOMObject public static void main(String args) List list = new ArrayList();while (true) list.add(new OOMObject();运行结果：Exception in thread main java.lang.OutOfMemoryError: Java heap spaceat java.util.Arrays.copyOf(Arrays.java:2245)at java.util.Arrays.copyOf(Arrays.java:2219)at java.util.ArrayList.grow(ArrayList.java:242)at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:216)at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:208)at java.util.ArrayList.add(ArrayList.java:440)at test.TestOutOfMemoryError.main(TestOutOfMemoryError.java:22)* java.lang.instrument ASSERTION FAILED *: error = JVMTI_ERROR_NONE at ./././src/share/instrument/Reentrancy.c line: 161Java堆内存的OOM异常是实际应用中常见的内存溢出异常情况。当出现Java堆内存溢出时，异常堆栈信息“java.lang.OutOfMemoryError”会跟着进一步提示“Java heap space”。重点是确认内存中的对象是否是必要的，也就是要先分清楚到底是出现了内存泄漏（Memory Leak）还是内存溢出（Memory Overflow）。图2-5显示了使用Eclipse Memory Analyzer打开的堆转储快照文件。如果是内存泄露，可进一步通过工具查看泄露对象到GC Roots的引用链。于是就能找到泄露对象是通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收它们的。掌握了泄露对象的类型信息及GC Roots引用链的信息，就可以比较准确地定位出泄露代码的位置。如果不存在泄露，换句话说，就是内存中的对象确实都还必须存活着，那就应当检查虚拟机的堆参数（-Xmx与-Xms），与机器物理内存对比看是否还可以调大，从代码上检查是否存在某些对象生命周期过长、持有状态时间过长的情况，尝试减少程序运行期的内存消耗。以上是处理Java堆内存问题的简单思路，处理这些问题所需要的知识、工具与经验是后面3章的主题。9.2 虚拟机栈和本地方法栈溢出JMV并不区分虚拟机栈和本地方法栈，栈部分通常会出现两种异常：1、如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError异常。2、如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常。代码清单2虚拟机栈和本地方法栈OOM测试/* VM Args：-Xss128k* author zzm*/public class JavaVMStackSOF private int stackLength = 1; public void stackLeak() stackLength+; stackLeak(); public static void main(String args) throws Throwable JavaVMStackSOF oom = new JavaVMStackSOF(); try oom.stackLeak(); catch (Throwable e) System.out.println(stack length: + oom.stackLength); throw e; 运行结果：stack length:2402Exception in thread main java.lang.StackOverflowError at org.fenixsoft.oom.VMStackSOF.leak(VMStackSOF.java:20) at org.fenixsoft.oom.VMStackSOF.leak(VMStackSOF.java:21) at org.fenixsoft.oom.VMStackSOF.leak(VMStackSOF.java:21)后续异常堆栈信息省略实验结果表明：在单个线程下，无论是由于栈帧太大还是虚拟机栈容量太小，当内存无法分配的时候，虚拟机抛出的都是StackOverflowError异常。如果测试时不限于单线程，通过不断地建立线程的方式倒是可以产生内存溢出异常，如代码清单2所示。但是这样产生的内存溢出异常与栈空间是否足够大并不存在任何联系，或者准确地说，在这种情况下，为每个线程的栈分配的内存越大，反而越容易产生内存溢出异常。其实原因不难理解，操作系统分配给每个进程的内存是有限制的，譬如32位的Windows限制为2GB。虚拟机提供了参数来控制Java堆和方法区的这两部分内存的最大值。剩余的内存为2GB（操作系统限制）减去Xmx（最大堆容量），再减去MaxPermSize（最大方法区容量），程序计数器消耗内存很小，可以忽略掉。如果虚拟机进程本身耗费的内存不计算在内，剩下的内存就由虚拟机栈和本地方法栈“瓜分”了。每个线程分配到的栈容量越大，可以建立的线程数量自然就越少，建立线程时就越容易把剩下的内存耗尽。这一点读者需要在开发多线程的应用时特别注意，出现StackOverflowError异常时有错误堆栈可以阅读，相对来说，比较容易找到问题的所在。而且，如果使用虚拟机默认参数，栈深度在大多数情况下（因为每个方法压入栈的帧大小并不是一样的，所以只能说在大多数情况下）达到10002000完全没有问题，对于正常的方法调用（包括递归），这个深度应该完全够用了。但是，如果是建立过多线程导致的内存溢出，在不能减少线程数或者更换64位虚拟机的情况下，就只能通过减少最大堆和减少栈容量来换取更多的线程。如果没有这方面的处理经验，这种通过“减少内存”的手段来解决内存溢出的方式会比较难以想到。代码清单2-5创建线程导致内存溢出异常/* VM Args：-Xss2M （这时候不妨设置大些）* author zzm*/public classJavaVMStackOOM private void dontStop() while (true) public void stackLeakByThread() while (true) Thread thread = new Thread(new Runnable() Override public void run() dontStop(); ); thread.start(); public static void main(String args) throws Throwable JavaVMStackOOM oom = new JavaVMStackOOM(); oom.stackLeakByThread(); 注意特别提示一下，如果读者要尝试运行上面这段代码，记得要先保存当前的工作。由于在Windows平台的虚拟机中，Java的线程是映射到操作系统的内核线程上的，因此上述代码执行时有较大的风险，可能会导致操作系统假死。运行结果：Exception in thread main java.lang.OutOfMemoryError: unable to create new native thread9.3 运行时常量池溢出如果要向运行时常量池中添加内容，最简单的做法就是使用Sern()这个Native方法。该方法的作用是：如果池中已经包含一个等于此String对象的字符串，则返回代表池中这个字符串的String对象；否则，将此String对象包含的字符串添加到常量池中，并且返回此String对象的引用。由于常量池分配在方法区内，我们可以通过-XX:PermSize和-XX:MaxPermSize限制方法区的大小，从而间接限制其中常量池的容量，如代码清单2-4所示。代码清单2-4运行时常量池导致的内存溢出异常/* *VMArgs：-XX:PermSize=10M-XX:MaxPermSize=10M*authorzzm */ publicclassRuntimeConstantPoolOOM publicstaticvoidmain(Stringargs) /使用List保持着常量池引用，避免FullGC回收常量池行为 Listlist=newArrayList(); /10MB的PermSize在integer范围内足够产生OOM了 inti=0; while(true) list.add(String.valueOf(i+).intern(); 运行结果：Exceptioninthreadmainjava.lang.OutOfMemoryError:PermGenspaceatjava.lang.Sern(NativeMethod) atorg.fenixsoft.oom.RuntimeConstantPoolOOM.main(RuntimeConstantPoolOOM.java:18)从运行结果中可以看到，运行时常量池溢出，在OutOfMemoryError后面跟随的提示信息是“PermGen space”，说明运行时常量池属于方法区（HotSpot虚拟机中的永久代）的一部分9.4 方法区溢出方法区用于存放Class的相关信息，如类名、访问修饰符、常量池、字段描述、方法描述等。对于这些区域的测试，基本的思路是运行时产生大量的类去填满方法区，直到溢出。虽然直接使用JavaSE API也可以动态产生类（如反射时的GeneratedConstructorAccessor和动态代理等），但在本次实验中操作起来比较麻烦。在代码清单2-8中，笔者借助CGLib直接操作字节码运行时生成了大量的动态类。值得特别注意的是，我们在这个例子中模拟的场景并非纯粹是一个实验，这样的应用经常会出现在实际应用中：当前的很多主流框架，如Spring、Hibernate，在对类进行增强时，都会使用到CGLib这类字节码技术，增强的类越多，就需要越大的方法区来保证动态生成的Class可以加载入内存。另外，JVM上的动态语言（例如Groovy等）通常都会持续创建类来实现语言的动态性，随着这类语言的流行，也越来越容易遇到与代码清单2-8相似的溢出场景。代码清单2-8借助CGLib使方法区出现内存溢出异常/* VM Args： -XX:PermSize=10M -XX:MaxPermSize=10M* author zzm*/public classJavaMethodAreaOOM public static void main(String args) while (true) Enhancer enhancer = new Enhancer(); enhancer.setSuperclass(OOMObject.class); enhancer.setUseCache(false); enhancer.setCallback(new MethodInterceptor() public Object intercept(Object obj, Method method, Object args, MethodProxy proxy) throws Throwable return proxy.invokeSuper(obj, args); ); enhancer.create(); static class OOMObject 运行结果：Caused by: java.lang.OutOfMemoryError: PermGen spaceat java.lang.ClassLoader.defineClass1(Native Method)at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)at java.lang.ClassLoader.defineClass(ClassLoader.java:616). 8 more方法区溢出也是一种常见的内存溢出异常，一个类要被垃圾收集器回收掉，判定条件是比较苛刻的。在经常动态生成大量Class的应用中，需要特别注意类的回收状况。这类场景除了上面提到的程序使用了CGLib字节码增强和动态语言之外，常见的还有：大量JSP或动态产生JSP文件的应用（JSP第一次运行时需要编译为Java类）、基于OSGi的应用（即使是同一个类文件，被不同的加载器加载也会视为不同的类）等。9.5 本机直接内存溢出DirectMemory容量可通过-XX：MaxDirectMemorySize指定，如果不指定，则默认与Java堆最大值（-Xmx指定）一样，代码清单2-9越过了DirectByteBuffer类，直接通过反射获取Unsafe实例进行内存分配（Unsafe类的getUnsafe()方法限制了只有引导类加载器才会返回实例，也就是设计者希望只有rt.jar中的类才能使用Unsafe的功能）。因为，虽然使用DirectByteBuffer分配内存也会抛出内存溢出异常，但它抛出异常时并没有真正向操作系统申请分配内存，而是通过计算得知内存无法分配，于是手动抛出异常，真正申请分配内存的方法是unsafe.allocateMemory()。代码清单2-9使用unsafe分配本机内存/* VM Args：-Xmx20M -XX:MaxDirectMemorySize=10M* author zzm*/public class DirectMemoryOOM private static final int _1MB = 1024 * 1024; public static void main(String args) throws Exception Field unsafeField = Unsafe.class.getDeclaredFields()0; unsafeField.setAccessible(true); Unsafe unsafe = (Unsafe) unsafeField.get(null); while (true) unsafe.allocateMemory(_1MB); 运行结果：Exception in thread main java.lang.OutOfMe