内存泄露收集整理（转）
1、性能测试总结之内存泄露和内存溢出
2、java垃圾回收和内存泄露的讲解
3、Java 内存泄露浅析
4、java 内存溢出源码实例
堆OOM（Heap OutOfMemory）
栈溢出（Stack StackOverFlow）
栈溢出（Stack OutOfMemory）
常量池OOM（Constant Pool OOM）
方法区OOM（Method Area OOM）
直接内存区OOM（Direct Memory OOM）
1、性能测试总结之内存泄露和内存溢出
http://lya041.blog.51cto.com/337966/668766
刚刚做完了一个项目的性能测试，“有幸”也遇到了内存泄露的案例，所以在此和大家分享一下。 主要从以下几部分来说明，关于内存和内存泄露、溢出的概念，区分内存泄露和内存溢出；内存的区域划分，了解GC回收机制；重点关注如何去监控和发现内存问题；此外分析出问题还要如何解决内存问题。 下面就开始本篇的内容： 第一部分 概念 众所周知，java中的内存java虚拟机自己去管理的，他不想C++需要自己去释放。笼统地去讲，java的内存分配分为两个部分，一个是数据堆，一个是栈。程序在运行的时候一般分配数据堆，把局部的临时的变量都放进去，生命周期和进程有关系。但是如果程序员声明了static的变量，就直接在栈中运行的，进程销毁了，不一定会销毁static变量。 另外为了保证java内存不会溢出，java中有垃圾回收机制。 System.gc()即垃圾收集机制是指jvm用于释放那些不再使用的对象所占用的内存。java语言并不要求jvm有gc，也没有规定gc如何工作。垃圾收集的目的在于清除不再使用的对象。gc通过确定对象是否被活动对象引用来确定是否收集该对象。 而其中，内存溢出就是你要求分配的java虚拟机内存超出了系统能给你的，系统不能满足需求，于是产生溢出。 内存泄漏是指你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问,该块已分配出来的内存也无法再使用，随着服务器内存的不断消耗，而无法使用的内存越来越多，系统也不能再次将它分配给需要的程序，产生泄露。一直下去，程序也逐渐无内存使用，就会溢出。 第二部分 原理 JAVA垃圾回收及对内存区划分 在Java虚拟机规范中，提及了如下几种类型的内存空间： ◇ 栈内存（Stack）：每个线程私有的。 ◇ 堆内存（Heap）：所有线程公用的。 ◇ 方法区（Method Area）：有点像以前常说的“进程代码段”，这里面存放了每个加载类的反射信息、类函数的代码、编译时常量等信息。 ◇ 原生方法栈（Native Method Stack）：主要用于JNI中的原生代码，平时很少涉及。 而Java的使用的是堆内存，java堆是一个运行时数据区，类的实例(对象)从中分配空间。Java虚拟机(JVM)的堆中储存着正在运行的应用程序所建立的所有对象，“垃圾回收”也是主要是和堆内存（Heap）有关。 垃圾回收的概念就是JAVA虚拟机（JVM）回收那些不再被引用的对象内存的过程。一般我们认为正在被引用的对象状态为“alive”,而没有被应用或者取不到引用属性的对象状态为“dead”。垃圾回收是一个释放处于”dead”状态的对象的内存的过程。而垃圾回收的规则和算法被动态的作用于应用运行当中，自动回收。 JVM的垃圾回收器采用的是一种分代（generational ）回收策略，用较高的频率对年轻的对象(young generation)进行扫描和回收，这种叫做minor collection，而对老对象(old generation)的检查回收频率要低很多，称为major collection。这样就不需要每次GC都将内存中所有对象都检查一遍，这种策略有利于实时观察和回收。 （Sun JVM 1.3 有两种最基本的内存收集方式：一种称为copying或scavenge，将所有仍然生存的对象搬到另外一块内存后，整块内存就可回收。这种方法有效率，但需要有一定的空闲内存，拷贝也有开销。这种方法用于minor collection。另外一种称为mark-compact，将活着的对象标记出来，然后搬迁到一起连成大块的内存，其他内存就可以回收了。这种方法不需要占用额外的空间，但速度相对慢一些。这种方法用于major collection. ） 一些对象被创建出来只是拥有短暂的生命周期，比如 iterators 和本地变量。 另外一些对象被创建是拥有很长的生命周期，比如 高持久化对象等。 垃圾回收器的分代策略是把内存区划分为几个代，然后为每个代分配一到多个内存区块。当其中一个代用完了分配给他的内存后，JVM会在分配的内存区内执行一个局部的GC（也可以叫minor collection）操作，为了回收处于“dead”状态的对象所占用的内存。局部GC通常要不Full GC要快很多。 JVM定义了两个代，年轻代（yong generation）（有时称为“nursery”托儿所）和老年代(old generation)。年轻代包括 “Eden space（伊甸园）”和两个“survivor spaces”。虚拟内存初始化的时候会把所有对象都分配到 Eden space，并且大部分对象也会在该区域被释放。 当进行 minor GC的时候，VM会把剩下的没有释放的对象从Eden space移动到其中一个survivor spaces当中。此外，VM也会把那些长期存活在survivor spaces 里的对象移动到 老生代的“tenured” space中。当 tenured generation 被填满后，就会产生Full GC，Full GC会相对比较慢因为回收的内容包括了所有的 live状态的对象。pemanet generation这个代包括了所有java虚拟机自身使用的相对比较稳定的数据对象，比如类和对象方法等。 关于代的划分，可以从下图中获得一个概况： 如果垃圾回收器影响了系统的性能，或者成为系统的瓶颈，你可以通过自定义各个代的大小来优化它的性能。使用JConsole，可以方便的查看到当前应用所配置的垃圾回收器的各个参数。想要获得更详细的参数，可以参考以下调优介绍： Tuning Garbage collection with the 5.0 HotSpot VM http://java.sun.com/docs/hotspot/gc/index.html 最后，总结一下各区内存： Eden Space (heap)： 内存最初从这个线程池分配给大部分对象。 Survivor Space (heap)：用于保存在eden space内存池中经过垃圾回收后没有被回收的对象。 Tenured Generation (heap)：用于保持已经在 survivor space内存池中存在了一段时间的对象。 Permanent Generation (non-heap): 保存虚拟机自己的静态(refective)数据，例如类（class）和方法（method）对象。Java虚拟机共享这些类数据。这个区域被分割为只读的和只写的， Code Cache (non-heap):HotSpot Java虚拟机包括一个用于编译和保存本地代码（native code）的内存，叫做“代码缓存区”（code cache） 第三部分 监控（工具发现问题） 谈到内存监控工具，JConsole是必须要介绍的，它是一个用JAVA写的GUI程序，用来监控VM，并可监控远程的VM，易用且功能强大。具体可监控JAVA内存、JAVA CPU使用率、线程执行情况、加载类概况等，Jconsole需要在JVM参数中配置端口才能使用。 由于是GUI程序，界面可视化，这里就不做详细介绍， 具体帮助支持文档请参阅性能测试JConsole使用方法总结： http://www.taobao.ali.com/chanpin/km/test/DocLib/性能测试辅助工具－JConsole的使用方法.aspx 或者参考SUN官网的技术文档： http://Java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html http://Java.sun.com/javase/6/docs/technotes/tools/share/jconsole.html 在实际测试某一个项目时，内存出现泄露现象。起初在性能测试的1个小时中，并不明显，而在稳定性测试的时候才发现，应用的HSF调用在经过几个小时运行后，就出现性能明显下降的情况。在服务日志中报大量HSF超时，但所调用系统没有任何超时日志，并且压力应用的load都很低。经过查看日志后，认为应用可能存在内存泄漏。通过jconsole 以及 jmap 工具进行分析发现，确实存在内存泄漏问题，其中PS Old Gen最终达到占用 100%的占用。 从上图可以看到，虽然每次Full GC，JVM内存会有部分回收，但回收并不彻底，不可回收的内存对象会越来越多，这样便会出现以上的一个趋势。在Full GC无法回收的对象越来越多时，最终已使用内存达到系统分配的内存最大值，系统最后无内存可分配，最终down机。 第四部分 分析 经过开发和架构师对应用的分析，查看此时内存队列，看哪个对象占用数据最多，再利用jmap命令，对线程数据分析，如下所示： num #instances #bytes class name ———————————————- 1: 9248056 665860032 com.taobao.matrix.mc.domain.** 2: 9248031 295936992 com.taobao.matrix.** 3: 9248068 147969088 java.util.** 4: 1542111 37010664 java.util.Date 前三个instances不断增加，指代的是同一个代码逻辑，异步分发的问题，堵塞消息，回收多次都无法回收成功。导致内存溢出。 此外，对应用的性能单独做了压测，他的性能只能支撑到一半左右，故发送消息的TPS，应用肯定无法处理过来，导致消息堆积，而JAVA垃圾回收期认为这些都是有用的对象，导致内存堆积，直至系统崩溃。 调优方法 由于具体调优方法涉及到应用的配置信息，故在此暂不列出，可以参考性能测试小组发布的《性能测试调优宝典》 第四部分 总结 内存溢出主要是由于代码编写时对某些方法、类应用不合理，或者没有预估到临时对象会占用很大内存量，或者把过多的数据放入JVM缓存，或者性能压力大导致消息堆积而占用内存，以至于在性能测试时，生成庞大数量的临时对象，GC时没有做出有效回收甚至根本就不能回收，造成内存空间不足，内存溢出。 如果编码之前，对内存使用量进行预估，对放在内存中的数据进行评估，保证有用的信息尽快释放，无用的信息能够被GC回收，这样在一定程度上是可以避免内存溢出问题的。
2、java垃圾回收和内存泄露的讲解
http://lya041.blog.51cto.com/337966/665325
1．垃圾收集算法的核心思想 Java语言建立了垃圾收集机制，用以跟踪正在使用的对象和发现并回收不再使用（引用）的对象。该机制可以有效防范动态内存分配中可能发生的两个危险：因内存垃圾过多而引发的内存耗尽，以及不恰当的内存释放所造成的内存非法引用。 垃圾收集算法的核心思想是：对虚拟机可用内存空间，即堆空间中的对象进行识别，如果对象正在被引用，那么称其为存活 对象，反之，如果对象不再被引用，则为垃圾对象，可以回收其占据的空间，用于再分配。垃圾收集算法的选择和垃圾收集系统参数的合理调节直接影响着系统性 能，因此需要开发人员做比较深入的了解。 2．触发主GC（Garbage Collector）的条件 JVM进行次GC的频率很高,但因为这种GC占用时间极短,所以对系统产生的影响不大。更值得关注的是主GC的触发条件,因为它对系统影响很明显。总的来说,有两个条件会触发主GC: ①当应用程序空闲时,即没有应用线程在运行时,GC会被调用。因为GC在优先级最低的线程中进行,所以当应用忙时,GC线程就不会被调用,但以下条件除外。 ②Java堆内存不足时,GC会被调用。当应用线程在运行,并在运行过程中创建新对象,若这时内存空间不足,JVM 就会强制地调用GC线程,以便回收内存用于新的分配。若GC一次之后仍不能满足内存分配的要求,JVM会再进行两次GC作进一步的尝试,若仍无法满足要 求,则 JVM将报“out of memory”的错误,Java应用将停止。 由于是否进行主GC由JVM根据系统环境决定,而系统环境在不断的变化当中,所以主GC的运行具有不确定性,无法预计它何时必然出现,但可以确定的是对一个长期运行的应用来说,其主GC是反复进行的。 3．减少GC开销的措施 根据上述GC的机制,程序的运行会直接影响系统环境的变化,从而影响GC的触发。若不针对GC的特点进行设计和编码,就会出现内存驻留等一系列负面影响。为了避免这些影响,基本的原则就是尽可能地减少垃圾和减少GC过程中的开销。具体措施包括以下几个方面: (1)不要显式调用System.gc() 此函数建议JVM进行主GC,虽然只是建议而非一定,但很多情况下它会触发主GC,从而增加主GC的频率,也即增加了间歇性停顿的次数。 (2)尽量减少临时对象的使用 临时对象在跳出函数调用后,会成为垃圾,少用临时变量就相当于减少了垃圾的产生,从而延长了出现上述第二个触发条件出现的时间,减少了主GC的机会。 (3)对象不用时最好显式置为Null 一般而言,为Null的对象都会被作为垃圾处理,所以将不用的对象显式地设为Null,有利于GC收集器判定垃圾,从而提高了GC的效率。 (4)尽量使用StringBuffer,而不用String来累加字符串（详见blog另一篇文章JAVA中String与StringBuffer） 由于String是固定长的字符串对象,累加String对象时,并非在一个String对象中扩增,而是重新创建 新的String对象,如Str5=Str1+Str2+Str3+Str4,这条语句执行过程中会产生多个垃圾对象,因为对次作“+”操作时都必须创建 新的String对象,但这些过渡对象对系统来说是没有实际意义的,只会增加更多的垃圾。避免这种情况可以改用StringBuffer来累加字符串,因 StringBuffer是可变长的,它在原有基础上进行扩增,不会产生中间对象。 (5)能用基本类型如Int,Long,就不用Integer,Long对象 基本类型变量占用的内存资源比相应对象占用的少得多,如果没有必要,最好使用基本变量。 (6)尽量少用静态对象变量 静态变量属于全局变量,不会被GC回收,它们会一直占用内存。 (7)分散对象创建或删除的时间 集中在短时间内大量创建新对象,特别是大对象,会导致突然需要大量内存,JVM在面临这种情况时,只能进行主GC, 以回收内存或整合内存碎片,从而增加主GC的频率。集中删除对象,道理也是一样的。它使得突然出现了大量的垃圾对象,空闲空间必然减少,从而大大增加了下 一次创建新对象时强制主GC的机会。 4．gc与finalize方法 ⑴gc方法请求垃圾回收 使用System.gc()可以不管JVM使用的是哪一种垃圾回收的算法，都可以请求Java的垃圾回收。需要注意 的是，调用System.gc()也仅仅是一个请求。JVM接受这个消息后，并不是立即做垃圾回收，而只是对几个垃圾回收算法做了加权，使垃圾回收操作容 易发生，或提早发生，或回收较多而已。 ⑵finalize方法透视垃圾收集器的运行 在JVM垃圾收集器收集一个对象之前 ，一般要求程序调用适当的方法释放资源，但在没有明确释放资源的情况下，Java提供了缺省机制来终止化该对象释放资源，这个方法就是finalize（）。它的原型为： protected void finalize() throws Throwable 在finalize()方法返回之后，对象消失，垃圾收集开始执行。原型中的throws Throwable表示它可以抛出任何类型的异常。 因此，当对象即将被销毁时，有时需要做一些善后工作。可以把这些操作写在finalize()方法里。 protected void finalize() { // finalization code here } ⑶代码示例 class Garbage { int index; static int count; Garbage() { count++; System.out.println("object "+count+" construct"); setID(count); } void setID(int id) { index=id; } protected void finalize() //重写finalize方法 { System.out.println("object "+index+" is reclaimed"); } public static void main(String[] args) { new Garbage(); new Garbage(); new Garbage(); new Garbage(); System.gc(); //请求运行垃圾收集器 } } 5．Java 内存泄漏 由于采用了垃圾回收机制，任何不可达对象（对象不再被引用）都可以由垃圾收集线程回收。因此通常说的Java 内存泄漏其实是指无意识的、非故意的对象引用，或者无意识的对象保持。无意识的对象引用是指代码的开发人员本来已经对对象使用完毕，却因为编码的错误而意 外地保存了对该对象的引用（这个引用的存在并不是编码人员的主观意愿），从而使得该对象一直无法被垃圾回收器回收掉，这种本来以为可以释放掉的却最终未能 被释放的空间可以认为是被“泄漏了”。 考虑下面的程序,在ObjStack类中,使用push和pop方法来管理堆栈中的对象。两个方法中的索引 (index)用于指示堆栈中下一个可用位置。push方法存储对新对象的引用并增加索引值,而pop方法减小索引值并返回堆栈最上面的元素。在main 方法中,创建了容量为64的栈,并64次调用push方法向它添加对象,此时index的值为64,随后又32次调用pop方法,则index的值变为 32,出栈意味着在堆栈中的空间应该被收集。但事实上,pop方法只是减小了索引值,堆栈仍然保持着对那些对象的引用。故32个无用对象不会被GC回收, 造成了内存渗漏。 public class ObjStack { private Object[] stack; private int index; ObjStack(int indexcount) { stack = new Object[indexcount]; index = 0; } public void push(Object obj) { stack[index] = obj; index++; } public Object pop() { index--; return stack[index]; } } public class Pushpop { public static void main(String[] args) { int i = 0; Object tempobj; ObjStack stack1 = new ObjStack(64);//new一个ObjStack对象，并调用有参构造函数。分配stack Obj数组的空间大小为64，可以存64个对象，从0开始存储。 while (i < 64) { tempobj = new Object();//循环new Obj对象，把每次循环的对象一一存放在stack Obj数组中。 stack1.push(tempobj); i++; System.out.println("第" + i + "次进栈" + "/t"); } while (i > 32) { tempobj = stack1.pop();//这里造成了空间的浪费。 //正确的pop方法可改成如下所指示,当引用被返回后,堆栈删除对他们的引用,因此垃圾收集器在以后可以回收他们。 /* * public Object pop() {index - -;Object temp = stack [index];stack [index]=null;return temp;} */ i--; System.out.println("第" + (64 - i) + "次出栈" + "/t"); } } } 如何消除内存泄漏 虽然Java虚拟机(JVM)及其垃圾收集器(garbage collector，GC)负责管理大多数的内存任务，Java软件程序中还是有可能出现内存泄漏。实际上，这在大型项目中是一个常见的问题。避免内存泄 漏的第一步是要弄清楚它是如何发生的。本文介绍了编写Java代码的一些常见的内存泄漏陷阱，以及编写不泄漏代码的一些最佳实践。一旦发生了内存泄漏，要 指出造成泄漏的代码是非常困难的。因此本文还介绍了一种新工具，用来诊断泄漏并指出根本原因。该工具的开销非常小，因此可以使用它来寻找处于生产中的系统 的内存泄漏。 垃圾收集器的作用 虽然垃圾收集器处理了大多数内存管理问题，从而使编程人员的生活变得更轻松了，但是编程人员还是可能犯错而导致 出现内存问题。简单地说，GC循环地跟踪所有来自“根”对象（堆栈对象、静态对象、JNI句柄指向的对象，诸如此类）的引用，并将所有它所能到达的对象标 记为活动的。程序只可以操纵这些对象；其他的对象都被删除了。因为GC使程序不可能到达已被删除的对象，这么做就是安全的。 虽然内存管理可以说是自动化的，但是这并不能使编程人员免受思考内存管理问题之苦。例如，分配（以及释放）内存 总会有开销，虽然这种开销对编程人员来说是不可见的。创建了太多对象的程序将会比完成同样的功能而创建的对象却比较少的程序更慢一些（在其他条件相同的情 况下）。 而且，与本文更为密切相关的是，如果忘记“释放”先前分配的内存，就可能造成内存泄漏。如果程序保留对永远不再 使用的对象的引用，这些对象将会占用并耗尽内存，这是因为自动化的垃圾收集器无法证明这些对象将不再使用。正如我们先前所说的，如果存在一个对对象的引 用，对象就被定义为活动的，因此不能删除。为了确保能回收对象占用的内存，编程人员必须确保该对象不能到达。这通常是通过将对象字段设置为null或者从 集合(collection)中移除对象而完成的。但是，注意，当局部变量不再使用时，没有必要将其显式地设置为null。对这些变量的引用将随着方法的 退出而自动清除。 概括地说，这就是内存托管语言中的内存泄漏产生的主要原因：保留下来却永远不再使用的对象引用。 典型泄漏 既然我们知道了在Java中确实有可能发生内存泄漏，就让我们来看一些典型的内存泄漏及其原因。 全局集合 在大的应用程序中有某种全局的数据储存库是很常见的，例如一个JNDI树或一个会话表。在这些情况下，必须注意管理储存库的大小。必须有某种机制从储存库中移除不再需要的数据。 这可能有多种方法，但是最常见的一种是周期性运行的某种清除任务。该任务将验证储存库中的数据，并移除任何不再需要的数据。 另一种管理储存库的方法是使用反向链接(referrer)计数。然后集合负责统计集合中每个入口的反向链接的数目。这要求反向链接告诉集合何时会退出入口。当反向链接数目为零时，该元素就可以从集合中移除了。 缓存 缓存是一种数据结构，用于快速查找已经执行的操作的结果。因此，如果一个操作执行起来很慢，对于常用的输入数据，就可以将操作的结果缓存，并在下次调用该操作时使用缓存的数据。 缓存通常都是以动态方式实现的，其中新的结果是在执行时添加到缓存中的。典型的算法是： 检查结果是否在缓存中，如果在，就返回结果。 如果结果不在缓存中，就进行计算。 将计算出来的结果添加到缓存中，以便以后对该操作的调用可以使用。 该算法的问题（或者说是潜在的内存泄漏）出在最后一步。如果调用该操作时有相当多的不同输入，就将有相当多的结果存储在缓存中。很明显这不是正确的方法。 为了预防这种具有潜在破坏性的设计，程序必须确保对于缓存所使用的内存容量有一个上限。因此，更好的算法是： 检查结果是否在缓存中，如果在，就返回结果。 如果结果不在缓存中，就进行计算。 如果缓存所占的空间过大，就移除缓存最久的结果。 将计算出来的结果添加到缓存中，以便以后对该操作的调用可以使用。 通过始终移除缓存最久的结果，我们实际上进行了这样的假设：在将来，比起缓存最久的数据，最近输入的数据更有可能用到。这通常是一个不错的假设。 新算法将确保缓存的容量处于预定义的内存范围之内。确切的范围可能很难计算，因为缓存中的对象在不断变化，而且它们的引用包罗万象。为缓存设置正确的大小是一项非常复杂的任务，需要将所使用的内存容量与检索数据的速度加以平衡。 解决这个问题的另一种方法是使用java.lang.ref.SoftReference类跟踪缓存中的对象。这种方法保证这些引用能够被移除，如果虚拟机的内存用尽而需要更多堆的话。 ClassLoader Java ClassLoader结构的使用为内存泄漏提供了许多可乘之机。正是该结构本身的复杂性使ClassLoader在内存泄漏方面存在如此多的问题。 ClassLoader的特别之处在于它不仅涉及“常规”的对象引用，还涉及元对象引用，比如：字段、方法和类。这意味着只要有对字段、方法、类或 ClassLoader的对象的引用，ClassLoader就会驻留在JVM中。因为ClassLoader本身可以关联许多类及其静态字段，所以就有 许多内存被泄漏了。 确定泄漏的位置 通常发生内存泄漏的第一个迹象是：在应用程序中出现了OutOfMemoryError。这通常发生在您最不愿 意它发生的生产环境中，此时几乎不能进行调试。有可能是因为测试环境运行应用程序的方式与生产系统不完全相同，因而导致泄漏只出现在生产中。在这种情况 下，需要使用一些开销较低的工具来监控和查找内存泄漏。还需要能够无需重启系统或修改代码就可以将这些工具连接到正在运行的系统上。可能最重要的是，当进 行分析时，需要能够断开工具而保持系统不受干扰。 虽然OutOfMemoryError通常都是内存泄漏的信号，但是也有可能应用程序确实正在使用这么多的内 存；对于后者，或者必须增加JVM可用的堆的数量，或者对应用程序进行某种更改，使它使用较少的内存。但是，在许多情况 下，OutOfMemoryError都是内存泄漏的信号。一种查明方法是不间断地监控GC的活动，确定内存使用量是否随着时间增加。如果确实如此，就可 能发生了内存泄漏。
3、Java 内存泄露浅析
Java使用有向图的方式进行内存管理， 优点：可以消除引用循环的问题，管理内存精度高 缺点：效率低下（相比引用计数）。 什么是Java中内存泄漏： 在Java中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点： <一>：这些对象是可达的 <二>：这些对象是无用的 这些对象不会被GC所回收，然而它却占用内存。
Java内存泄漏的方面： 静态集合变量：HashMap, Hashtable,等，由于这些集合不断调用add()方法增加一些临时对象，而没有及时调用remove()方法移除临时对象的引用, 导致一些无用的临时对象不能被JVM回收，造成内存泄漏 单例对象：如果该对象持有另外一个对象A的引用，那么对象A不会被回收，当对象A是一个比较大的对象时，会造成严重的内存泄漏。 Web容器中的request, session, application对象：对于request,session，如果并发量较大，而每个request, session都持有较多临时对象的引用， 会导致服务器内存溢出。对于application对象和Web容器中一些具有很长生命周期的对象，长期持有一些临时对象，也会造成内存泄漏。 JDBC操作出现异常，没有及时关闭连接(Connection)对象，会导致内存泄漏。 文件流操作出现异常，没有及时关闭文件流(InputStream)对象，导致内存泄漏。 Http请求超时设置：如果超时设置的时间是无限长，那么当一个Http请求的线程被卡住时，这个线程所占有的资源会永远不会释放，导致内存泄漏。
4、java 内存溢出源码实例
http://yikebocai.com/2013/03/java-oom/
Java内存模型中主要包括
堆(Heap)、栈(VM Stack)、方法区(Method Area)这几部分,当需>要分配的对象、方法、常量等等超出所有区域的限定时就可能产生我们最常见的内存溢出错>误(OutOfMemoryError)或者堆栈溢出(StackOverFlowError)，具体包括如下几种常见情况。
堆OOM（Heap OutOfMemory）
我们在日常编写程序时，最常见的就是堆OOM，这个内存是用来存储对象的，包括我们所知的新生代、老生代，一但创建的对象过多而没有及时释放无法被GC回收，就会产生堆OOM。可以通过-Xms、-Xmx参数来控制堆的大小。阿里国际站的服务器一般为5G的虚拟机，配置堆大小为固定2G。
package org.bocai.jvm.gc; /** * VM Args:-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError * @author yikebocai@gmail.com * @since 2013-3-24 * */ public class HeapOOM { public static void main(String[] args) { int SIZE=1024*1024; byte[][] objs=new byte[100][]; for(int i=0;i<objs.length;i++){ System.out.print("try to create obj "+i+" ..."); objs[i]=new byte[SIZE]; System.out.println("OK"); } } }
栈溢出（Stack StackOverFlow）
虚拟机栈内存不足时会产生两种溢出，一种是StackOverflow，一种是OutOfMemory，虚拟机规范中对此有详细说明。虚拟机在进行方法调用时，每次调用都会产生一个栈桢（Stack Frame），用以记录局部变量表（Local Variables）、操作数栈（Operand Stacks）、动态链接（Dynamic Linking）等信息，当Stack的空间不足以分配更多栈桢时，会产生溢出。比如在递归调用时，每次调用都会产生一个新的栈桢，递归调用的次数是受-Xss这个参数的限制的，我之前在使用递归来实现快速排序时遇到这样的问题，当需要快排的列表很大时，递归次数也会很多，会产生这样的溢出异常。
package org.bocai.jvm.gc; /** * VM Args:-Xss128k * * @author yikebocai@gmail.com * @since 2013-3-24 * */ public class StackSOF { private int stackLength = 1; public void stackLeak() { stackLength++; stackLeak(); } /** * stackLength is about 2403,average 54 bytes per stack frame */ public static void main(String[] args) { StackSOF sof = new StackSOF(); try { sof.stackLeak(); } catch (Throwable e) { System.out.println("stack length:" + sof.stackLength); e.printStackTrace(); } } }
栈溢出（Stack OutOfMemory）
虚拟机为每个线程分配固定的大小，通过参数-Xss可以来调整，虚拟机栈的最大内存不超过整个物理内存减去堆内存的值，如果运行期产生过多线程，并且为而每个线程分配了比较多的内存，就会很快产生OOM异常。
package org.bocai.jvm.gc; /** * VM Args:-Xss2M * * @author yikebocai@gmail.com * @since 2013-3-24 * */ public class StackOOM { /** * VM Stack size is about equals RAM size reduce Heap size * @param args */ public static void main(String[] args) { int counter=0; while (true) { System.out.println("create thread "+(counter++)+" ..."); Thread thread = new Thread(new Runnable() { public void run() { while (true){ try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } } } }); thread.start(); } } }
常量池OOM（Constant Pool OOM）
常量池保存字段(Field)的名称和描述符、方法的名称和描述符、类和接口的全限定名等，它是属于方法区（Method Area）的一部分，因此可以通过设置Perm区的大小来进行调整。最直接的测试方法是用String对象的intern()方法来实现，当常量池中有相等(equals)的值时返回该值，否则创建一个新值放在常量池中并返回该值的引用，详见JDK中String/intern()方法的说明。
package org.bocai.jvm.gc; import java.util.ArrayList; import java.util.List; /** * VM Args: -XX:PermSize=10M -XX:MaxPermSize=10M * * @author yikebocai@gmail.com * @since 2013-3-24 * */ public class ConstantPoolOOM { /** * constant pool included in Method Area,so can set parms PermSize and MaxPermSize */ public static void main(String[] args) { List<String> list = new ArrayList<String>(); int i = 0; while (true) { System.out.println("add string object into constant pool " + i); list.add(String.valueOf(i++).intern()); } } }
上面的测试代码运行的结果是：
...
add string object into constant pool 35925
Exception in thread "main" java.lang.OutOfMemoryError: PermGen space
at java.lang.String.intern(Native Method)
at org.bocai.jvm.gc.ConstantPoolOOM.main(ConstantPoolOOM.java:24)
如果没有使用intern()方法，测试代码运行的结果是：
...
add string object into constant pool 192210
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOfRange(Unknown Source)
at java.lang.String.<init>(Unknown Source)
at java.lang.StringBuilder.toString(Unknown Source)
at org.bocai.jvm.gc.ConstantPoolOOM.main(ConstantPoolOOM.java:23)
或者使用javassist动态增加字段或方法的方式，来产生常量池OOM
package org.bocai.jvm.gc; import java.lang.reflect.Field; import java.lang.reflect.Method; import javassist.ClassPool; import javassist.CtClass; import javassist.CtField; import javassist.CtMethod; /** * @author yikebocai@gmail.com * @since 2013-3-24 * */ public class ConstantPoolOOM2 { @SuppressWarnings("unchecked") public static void main(String[] args) throws Exception { ClassPool pool = ClassPool.getDefault(); CtClass ctClazz = pool.get("org.bocai.jvm.gc.TestBean"); // ctClazz.defrost(); // add field sample CtField field = new CtField(pool.get("java.lang.String"), "test", ctClazz); ctClazz.addField(field); for (int i = 1; i < 10000; i++) { CtField field2 = new CtField(pool.get("java.lang.String"), "test1" + i, ctClazz); ctClazz.addField(field2); } // add method sample CtClass[] paramTypes = { pool.get("java.lang.String") }; CtMethod ctMethod = new CtMethod(pool.get("java.lang.String"), "getTest", paramTypes, ctClazz); ctMethod.setBody("{ return $1 ;}"); ctClazz.addMethod(ctMethod); Class<TestBean> clazz = ctClazz.toClass(); // list fields Field[] fields = clazz.getDeclaredFields(); for (Field f : fields) { System.out.println("Field: " + f.getName()); } // list methods Method[] methods = clazz.getMethods(); for (Method m : methods) { System.out.println("Method: " + m.getName()); } // invoke method Method method = clazz.getMethod("getTest" , new Class[] { String.class }); TestBean bean = clazz.newInstance(); String invoke = (String) method.invoke(bean, new Object[] { "parameter1" }); System.out.println(invoke); } } class TestBean { }
方法区OOM（Method Area OOM）
方法区除了常量池之外，主要存储虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等，和持久区的概念基本一致，可以使用参数-XX:MaxPermSize=10M来设定大小。下面通过CGLIB来动态产生大量的类，来测试方法区OOM。
package org.bocai.jvm.gc; import java.lang.reflect.Method; import net.sf.cglib.proxy.Enhancer; import net.sf.cglib.proxy.MethodInterceptor; import net.sf.cglib.proxy.MethodProxy; /** * VM Args: -XX:PermSize=10M -XX:MaxPermSize=10M * * @author yikebocai@gmail.com * @since 2013-3-24 * */ public class MethodAreaOOM { 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 { System.out.println("insert before"); return proxy.invokeSuper(obj, args); } }); OOMObject obj=(OOMObject)enhancer.create(); obj.test(); } } static class OOMObject { public void test(){ System.out.println("This is super class method"); } } }
直接内存区OOM（Direct Memory OOM）
直接内存区不属于虚拟机运行时内存的一部分，它访问的是操作系统内存，比如NIO中实现的方案就是用的直接内存，可以通过-XX:MaxDirectMemorySize来设定。
package org.bocai.jvm.gc; import java.lang.reflect.Field; import sun.misc.Unsafe; /** * VM Args: -Xmx20M -XX:MaxDirectMemorySize=10M * @author yikebocai@gmail.com * @since 2013-3-24 * */ public class DirectMemoryOOM { public static void main(String[] args) throws IllegalArgumentException, IllegalAccessException { Field unsafeField=Unsafe.class.getDeclaredFields()[0]; unsafeField.setAccessible(true); Unsafe unsafe=(Unsafe)unsafeField.get(null); int counter=0; while(true){ System.out.println("allocate direct memory "+(counter++)); unsafe.allocateMemory(10*1024*1024); } } }
上述例子都是参考自《深入理解Java虚拟机-JVM高级特性和最佳实践》
