内存泄漏和内存溢出

1.1 内存泄漏指由于疏忽或错误造成程序未能释放已经不再使用的内存的情况。内存泄漏会因为减少可用内存的数量从而降低计算机的性能。最终，在最糟糕的情况下，过多的可用内存被分配掉导致全部或部分设备停止正常工作，或者应用程序崩溃。

1.2 下面给出了一个简单的内存泄露的例子:我们循环申请Object对象，并将所申请的对象放入一个Vector中，如果我们仅仅释放引用本身，那么Vector仍然引用该对象，所以这个对象对GC来说是不可回收的。因此，如果对象加入到Vector后，还必须从Vector中删除，最简单的方法就是将Vector对象设置为null。

Vectorv=newVector(10);
for(inti=1;i<100;i++)
{ 
		Objecto=newObject();
		v.add(o);
		o=null;
}

2.1 内存溢出是指程序要求的内存，超出了系统所能分配的范围，从而发生溢出。 
内存溢是指在一个域中输入的数据超过它的要求而且没有对此作出处理引发的数据溢出问题，多余的数据就可以作为指令在计算机上运行。
2.2 为了便于理解，我们不妨打个比方:缓冲区溢出好比是将十磅的糖放进一个只能装五磅的容器里。一旦该容器放满了，余下的部分就溢出在柜台和地板上，弄得一团糟。由于计算机程序的编写者写了一些编码，但是这些编码没有对目的区域或缓冲区——五磅的容器——做适当的检查，看它们是否够大，能否完全装入新的内容——十磅的糖，结果可能造成缓冲区溢出的产生。当缓冲区溢出时，过剩的信息覆盖的是计算机内存中以前的内容,除非这些被覆盖的内容被保存或能够恢复，否则就会永远丢失。

-------------------------------------------

显而易见：过多的内存泄漏必定会造成内存溢出

比如：应用服务器内存长期不合理占用，内存经常处于高位占用，很难回收到低位； 应用服务器极为不稳定，几乎每两天重新启动一次，有时甚至每天重新启动一次；  应用服务器经常做Full GC(Garbage Collection)，而且时间很长，大约需要30-40秒，应用服务器在做Full GC的时候是不响应客户的交易请求的，非常影响系统性能

1. 内存溢出类型  
    1.1. java.lang.OutOfMemoryError: PermGen space
    JVM管理两种类型的内存，堆和非堆。堆是给开发人员用的上面说的就是，是在JVM启动时创建；非堆是留给JVM自己用的，用来存放类的信息的。它和堆不同，运行期内GC不会释放空间。如果web app用了大量的第三方jar或者应用有太多的class文件而恰好MaxPermSize设置较小，超出了也会导致这块内存的占用过多造成溢出，或者tomcat热部署时侯不会清理前面加载的环境，只会将context更改为新部署的，非堆存的内容就会越来越多。  PermGen space的全称是Permanent Generation space,是指内存的永久保存区域，这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space中，它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的应用中有很CLASS的话,就很可能出现PermGen space错误，这种错误常见在web服务器对JSP进行pre compile的时候。如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。一个最佳的配置例子：(经过本人验证，自从用此配置之后，再未出现过tomcat死掉的情况)  set JAVA_OPTS=-Xms800m -Xmx800m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m

    1.2. java.lang.OutOfMemoryError: Java heap space  
    第一种情况是个补充，主要存在问题就是出现在这个情况中。其默认空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。如果内存剩余不到40％，JVM就会增大堆到Xmx设置的值，内存剩余超过70％，JVM就会减小堆到Xms设置的值。所以服务器的Xmx和Xms设置一般应该设置相同避免每次GC后都要调整虚拟机堆的大小。假设物理内存无限大，那么JVM内存的最大值跟操作系统有关，一般32位机是1.5g到3g之间，而64位的就不会有限制了。注意：如果Xms超过了Xmx值，或者堆最大值和非堆最大值的总和超过了物理内存或者操作系统的最大限制都会引起服务器启动不起来。

    垃圾回收GC的角色 ：JVM调用GC的频度还是很高的，主要两种情况下进行垃圾回收：  当应用程序线程空闲；另一个是java内存堆不足时，会不断调用GC，若连续回收都解决不了内存堆不足的问题时，就会报out of memory错误。因为这个异常根据系统运行环境决定，所以无法预期它何时出现。根据GC的机制，程序的运行会引起系统运行环境的变化，增加GC的触发机会。 为了避免这些问题，程序的设计和编写就应避免垃圾对象的内存占用和GC的开销。显示调用System.GC()只能建议JVM需要在内存中对垃圾对象进行回收，但不是必须马上回收， 一个是并不能解决内存资源耗空的局面，另外也会增加GC的消耗。

2. JVM内存区域组成
    2.1. 栈(栈内存):在函数中定义的基本类型变量和对象的引用变量都在函数的栈内存中分配；在函数（代码块）中定义一个变量时，java就在栈中为这个变量分配内存空间，当超过变量的作用域后，java会自动释放掉为该变量所分配的内存空间。
栈调整：参数有+UseDefaultStackSize -Xss256K，表示每个线程可申请256k的栈空间，每个线程都有他自己的Stack。
优势是存取速度比堆要快；
缺点是存在栈中的数据大小与生存期必须是确定的无灵活性。
    2.2. 堆(堆内存):堆内存用来存放由new创建的对象和数组；在堆中分配的内存由java虚拟机的自动垃圾回收器来管理。java堆分为三个区：New、Old和Permanent。
GC有两个线程：新创建的对象被分配到New区，当该区被填满时会被GC辅助线程移到Old区，当Old区也填满了会触发GC主线程遍历堆内存里的所有对象。Old区的大小等于Xmx减去-Xmn。
优势是可以动态分配内存大小，生存期也不必事先告诉编译器，因为它是在运行时动态分配内存的；
缺点就是要在运行时动态分配内存，存取速度较慢。

3. JVM如何设置虚拟内存
    提示：在JVM中如果98％的时间是用于GC且可用的Heap size 不足2％的时候将抛出此异常信息。
    提示：Heap Size 最大不要超过可用物理内存的80％，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。 
    提示：JVM初始分配的内存由-Xms指定，默认是物理内存的1/64；JVM最大分配的内存由-Xmx指定，默认是物理内存的1/4。
    默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制；空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制。因此服务器一般设置-Xms、-Xmx相等以避免在每次GC 后调整堆的大小。 
    提示：假设物理内存无限大的话，JVM内存的最大值跟操作系统有很大的关系。
    简单的说就32位处理器虽然可控内存空间有4GB,但是具体的操作系统会给一个限制，
    这个限制一般是2GB-3GB（一般来说Windows系统下为1.5G-2G，Linux系统下为2G-3G），而64bit以上的处理器就不会有限制了
    提示：注意：如果Xms超过了Xmx值，或者堆最大值和非堆最大值的总和超过了物理内存或者操作系统的最大限制都会引起服务器启动不起来。
    提示：设置NewSize、MaxNewSize相等，"new"的大小最好不要大于"old"的一半，原因是old区如果不够大会频繁的触发"主" GC ，大大降低了性能
    JVM使用-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64；
    由XX:MaxPermSize设置最大非堆内存的大小，默认是物理内存的1/4。
    解决方法：手动设置Heap size
    修改TOMCAT_HOME/bin/catalina.bat
    在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：
    JAVA_OPTS="-server -Xms800m -Xmx800m -XX:MaxNewSize=256m"

4. 内存溢出检测，如何查找引起内存泄漏的原因一般有两个步骤:
   第一是安排有经验的编程人员对代码进行走查和分析，找出内存泄漏发生的位置，可以安排对系统业务和开发语言工具比较熟悉的开发人员对应用的代码进行了交叉走查，尽量找出代码中存在的数据库连接声明和结果集未关闭、代码冗余等故障代码。 
   第二是使用专门的内存泄漏测试工具进行测试，检测Java的内存泄漏。在这里我们通常使用一些工具来检查Java程序的内存泄漏问题。市场上已有几种专业检查Java内存泄漏的工具，它们的基本工作原理大同小异，都是通过监测Java程序运行时，所有对象的申请、释放等动作，将内存管理的所有信息进行统计、分析、可视化。开发人员将根据这些信息判断程序是否有内存泄漏问题。这些工具包括Optimizeit Profiler，JProbe Profiler，JinSight , Rational 公司的Purify等。

5. 几种典型的Java内存泄漏
5.1 全局集合:
   在大型应用程序中存在各种各样的全局数据仓库是很普遍的，比如一个JNDI-tree或者一个session table。在这些情况下，必须注意管理储存库的大小。必须有某种机制从储存库中移除不再需要的数据。 
   通常有很多不同的解决形式，其中最常用的是一种周期运行的清除作业。这个作业会验证仓库中的数据然后清除一切不需要的数据。 
   另一种管理储存库的方法是使用反向链接(referrer)计数。然后集合负责统计集合中每个入口的反向链接的数目。这要求反向链接告诉集合何时会退出入口。当反向链接数目为零时，该元素就可以从集合中移除了。 
5.2 缓存 
   缓存一种用来快速查找已经执行过的操作结果的数据结构。因此，如果一个操作执行需要比较多的资源并会多次被使用，通常做法是把常用的输入数据的操作结果进行缓存，以便在下次调用该操作时使用缓存的数据。缓存通常都是以动态方式实现的,如果缓存设置不正确而大量使用缓存的话则会出现内存溢出的后果，因此需要将所使用的内存容量与检索数据的速度加以平衡。 
   常用的解决途径是使用java.lang.ref.SoftReference类坚持将对象放入缓存。这个方法可以保证当虚拟机用完内存或者需要更多堆的时候，可以释放这些对象的引用。 
5.3 类装载器 
   Java类装载器的使用为内存泄漏提供了许多可乘之机。一般来说类装载器都具有复杂结构，因为类装载器不仅仅是只与"常规"对象引用有关，同时也和对象内部的引用有关。比如数据变量，方法和各种类。这意味着只要存在对数据变量，方法，各种类和对象的类装载器，那么类装载器将驻留在JVM中。既然类装载器可以同很多的类关联，同时也可以和静态数据变量关联，那么相当多的内存就可能发生泄漏。

6. 不健壮代码的特征及解决办法
   1、尽早释放无用对象的引用。好的办法是使用临时变量的时候，让引用变量在退出活动域后，自动设置为null，暗示垃圾收集器来收集该对象，防止发生内存泄露。
对于仍然有指针指向的实例，jvm就不会回收该资源,因为垃圾回收会将值为null的对象作为垃圾，提高GC回收机制效率；
   2、我们的程序里不可避免大量使用字符串处理，避免使用String，应大量使用StringBuffer，每一个String对象都得独立占用内存一块区域；
String str = "aaa"; String str2 = "bbb"; String str3 = str + str2;//假如执行此次之后str ,str2以后再不被调用,那它就会被放在内存中等待Java的gc去回收,程序内过多的出现这样的情况就会报上面的那个错误,建议在使用字符串时能使用StringBuffer就不要用String,这样可以省不少开销； 
   3、尽量少用静态变量，因为静态变量是全局的，GC不会回收的；
   4、避免集中创建对象尤其是大对象，JVM会突然需要大量内存，这时必然会触发GC优化系统内存环境；显示的声明数组空间，而且申请数量还极大。
   5、尽量运用对象池技术以提高系统性能；生命周期长的对象拥有生命周期短的对象时容易引发内存泄漏，例如大集合对象拥有大数据量的业务对象的时候，可以考虑分块进行处理，然后解决一块释放一块的策略。
   6、不要在经常调用的方法中创建对象，尤其是忌讳在循环中创建对象。可以适当的使用hashtable，vector 创建一组对象容器，然后从容器中去取那些对象，而不用每次new之后又丢弃
   7、一般都是发生在开启大型文件或跟数据库一次拿了太多的数据，造成 Out Of Memory Error 的状况，这时就大概要计算一下数据量的最大值是多少，并且设定所需最小及最大的内存空间值。

7. 案例
   7.1 jspsmartUpload文件上传：
   使用jspsmartUpload作文件上传,现在运行过程中经常出现java.outofMemoryError的错误，用top命令看看进程使用情况，发现内存不足2M，花了很长时间，发现是jspsmartupload的问题。把jspsmartupload组件的源码文件（class文件）反编译成Java文件，如梦方醒： 
   1. m_totalBytes = m_request.getContentLength();         
   2. m_binArray = new byte[m_totalBytes];       
   问题原因是totalBytes这个变量得到的数极大，导致该数组分配了很多内存空间，而且该数组不能及时释放。解决办法只能换一种更合适的办法，至少是不会引发outofMemoryError的方式解决。
   变量m_totalBytes表示用户上传的文件的总长度，这是一个很大的数。如果用这样大的数去声明一个byte数组，并给数组的每个元素分配内存空间，而且m_binArray数组不能马上被释放，JVM的垃圾回收确实有问题，导致的结果就是内存溢出。
   jspsmartUpload为什么要这样做，有他的原因，根据RFC1867的http上传标准，得到一个文件流，并不知道文件流的长度。设计者如果想文件的长度，只有操作servletinputstream一次才知道，因为任何流都不知道大小。只有知道文件长度了，才可以限制用户上传文件的长度。为了省去这个麻烦，jspsmartUpload设计者直接在内存中打开文件，判断长度是否符合标准，符合就写到服务器的硬盘。这样产生内存溢出，这只是我的一个猜测而已。
   所以编程的时候，不要在内存中申请大的空间，因为web服务器的内存有限，并且尽可能的使用流操作，例如：

	byte[] mFileBody = new byte[512];    
	        Blob vField= rs.getBlob("FileBody");     
	     InputStream instream=vField.getBinaryStream();    
	     FileOutputStream fos=new FileOutputStream(saveFilePath+CFILENAME);    
	         int b;    
	                      while( (b =instream.read(mFileBody)) != -1){    
	                       fos.write(mFileBody,0,b);    
	                        }    
	       fos.close();    
	     instream.close();

   

   7.2 Swing子窗体
  曾经在刚入行的时候做过一个小的swing程序，用到了java SE，swing，Thread等东东，当初经验少也没有做过严格的性能测试，布到生产环境用了一段时间后发现那个小程序有时候会抛java.lang.OutofMemoryError异常，就是java的内存溢出。当时也上网查了不少资料，试过一些办法，代码也稍微做了些优化，但是有一个问题我始终是找不到解决的方案 - 不知为什么子窗体关闭后java的垃圾回收机制无法回收其资源，因为这个Java程序可能要经常开关一些子窗体，那么这些子窗体关闭后无法释放资源就造成了Java程序OutOfMemoryError的潜在的隐患！ 
最近无意间在网上看到了一个监控java程序内存使用的工具 - JProbe，马上回想起那个有关内存溢出的难题，于是我就下载了JProbe8.0.0希望从分析内存入手找到我要的答案。软件下载安装后，在安装目录里详尽的用户指南（懂点软件和英语的人很快就能上手），主要是两个步骤： 
   1.用JProbe Config工具根据提示生成J2SE或者J2EE程序的控制脚本（一个.jpl文件和一个.bat文件），在命令行里进入.bat文件所在的目录，然后执行该批处理让要监控的java程序跑起来 
   2.运行JProbe Console工具，点击“Attach to Session...”按钮，弹出java程序的内存实时监控图表“Runtime Summary”，我们主要是看“Data”卡片里的内容（注意：第一次使用该软件可能会遇到一些小问题：比如发布为jar包的程序如果运行时会去读配置文件，从控制脚本启动的话，可能会发生配置文件找不到的异常，解决办法是：不要打jar包，直接就用文件夹发布；还有可能因为一些杀毒软件的网络防火墙导致JProbe无法连接到控制脚本的session，造成监控图表打不开，解决办法是：取消防火墙对于JProbe访问网络的限制） 
   实时监控图表“Runtime Summary”如下图所示：

   可以设置要监视的包或者类，然后点击“Refresh Runtime Data”按钮刷新这些对象占用内存的情况，当你觉得某个类比较可疑的话，你可以在不断的使用程序的过程中监视它的生命周期，看看它是否像预期的那样在结束了生命周期后占用的内存就被释放。
   众所周知：java的内存回收是自动进行的，无需程序员干预，我们称其为垃圾回收，这个垃圾回收可能是不定期的，就是当程序占用内存资源比较少的情况下可能jvm的垃圾回收频率就比较低；反之，java程序消耗内存资源比较多的情况下，垃圾回收的频率和力度就比较高，这种垃圾回收的不确定性很可能会影响我们的判断，但我们可以点击JProbe监控界面右上方的“Request a Garbage Collection”（像一个垃圾桶的图标）按钮来向jvm发出垃圾回收的请求，等几秒后再去点击“Refresh Runtime Data”，这个时候如果那个预期应该已经销毁的对象的类名还是没有从监控界面下方的class列中消失或者其对象数量没有减少的话（请多试几次，中间可以夹杂些其他增加程序内存使用的操作以确保jvm确实执行了垃圾回收），那恭喜你！90%的可能性你已经找到了程序的某个缺陷 
   这个查找元凶的过程可能是相当耗时的，是对程序员的耐心的挑战。我熬了一下午一晚上，功夫不负有心人，基本上把我那个小程序的所有内存溢出的漏洞都找到并补上了。事实告诉我之前那个子窗体关闭后资源无法释放的根本原因是：子窗体虽然调用了dispose()方法，但是子窗体对象的引用一直都在：或者是被静态HashMap引用、或者是它的内部子线程类没有释放、或者是它的某个事件监听类没有释放（借用JProbe的火眼金睛一检验，发现问题真是一大堆啊！），so.我们要彻底释放某个对象占用资源的关键在于找到并释放所有对它的引用！ 
   下面是我解决具体问题的一些经验： 
   程序中造成内存溢出可能性最大的是HashMap，Hashtable等等集合类，尤其是静态的，更是要慎之又慎！！！它们引用的对象可能你感觉已经销毁了，其实很可能你忘记remove键值，而如果这些集合对象还是静态的挂在其他类里面，那么这个引用可能一直都在，借用JProbe测试一下，结果往往出人意料，解决办法：彻底删除键，remove、clear，如果允许最好把集合对象设为null 
   对于不再使用的线程对象，如果要彻底杀了它，很多书上都推荐用join方法，我之前也是这样做的，但后来借助JProbe工具我吃惊的发现这样做很可能要杀的线程仍旧好好的活在你日益增大的内存里，很可能调用了线程的sleep方法后用join方法就会有点问题，解决办法：在join方法前再加一句执行interrupt方法，不过这个时候可能会有新的问题：执行interrupt方法后你的线程类会抛InterruptedException，上有政策下有对策，加一个开关变量做判断就能完美解决，可参考下面的代码： 

/**    
 * <p>Description: 创建线程的内部类</p>    
 * @author cuishen    
 * @version 1.1    
 */    
class NewThread implements Runnable {     
    Thread t;     
    NewThread() {     
        t = new Thread(this, path);     
	        t.start();     
	    }     
	    public void run() {     
	        try {     
	            while(isThreadAlive) {     
	                startMonitor();     
	                Thread.sleep(Long.parseLong(controlList.get(controlList.size() - 1).toString()));     
	            }     
	        } catch (InterruptedException e) {     
	            if(!ifForceInterruptThread) {//开关变量     
	                stopThread(logThread);     
	                String error = "InterruptedException！！！" + path + ": Interrupted，线程异常终止！程序已试图重启该线程！！";     
	                System.err.println(error);     
	                LogService.writeLog(error);     
	                createLogThread();     
	            }     
	        }     
	    }     
	}     
	    
	public void createLogThread() {     
	    ifForceInterruptThread = false;//开关变量     
	    logThread = new NewThread();     
	}     
	    
	private void stopThread(NewThread thread) {     
	    try {     
	        thread.t.join(100);     
	    } catch (InterruptedException ex) {     
	        System.out.println("线程终止异常！！！");     
	    } finally {     
	        thread = null;     
	    }     
	}     
	    
	/**    
	 * 关闭并彻底释放该线程资源的方法    
	 */    
	public void stopThread() {     
	    try {     
	        ifForceInterruptThread = true;//开关变量     
	        isThreadAlive = false;     
	        logThread.t.interrupt();     
	        logThread.t.join(50);     
	    } catch (InterruptedException ex) {     
	        System.out.println("线程终止异常！！！");     
	    } finally {     
	        this.controlList = null;     
	        this.keyList = null;     
	        logThread = null;     
	    }     
	}   

   对于继承JFrame的窗体类，我们要注意在初始化方法中加入：this.setDefaultCloseOperation(DISPOSE_ON_CLOSE); ，并且注意和其关联的事件监听类一律写成窗体类的内部类，这样窗体dispose()的时候，这些内部类也一并销毁，就不会再有什么莫名其妙的引用了。

----------------------------------------------------