预防内存溢出的几个注意点

1 、尽早释放无用对象的引用。好的办法是使用临时变量的时候,让引用变量在退出活动域后,自动设置为 null ,暗示垃圾收集器来收集该对象,防止发生内存泄露。

对于仍然有指针指向的实例, jvm 就不会回收该资源 , 因为垃圾回收会将值为 null 的对象作为垃圾,提高 GC 回收机制效率;

2
、我们的程序里不可避免大量使用字符串处理,避免使用 String ,应大量使用 StringBuilder ,每一个 String 对象都得独立占用内存一块区域;

String str = “aaa”;    
  
String str2 = “bbb”;    
  
String str3 = str + str2;//
假如执行此次之后 str ,str2 以后再不被调用 , 那它就会被放在内存中等待 Java gc 去回收 , 程序内过多的出现这样的情况就会报上面的那个错误 , 建议在使用字符串时能使用 StringBuilder 就不要用 String, 这样可以省不少开销;    

3
、尽量少用静态变量,因为静态变量是全局的, GC 不会回收的;

4
、避免集中创建对象尤其是大对象, JVM 会突然需要大量内存,这时必然会触发 GC 优化系统内存环境;显示的声明数组空间,而且申请数量还极大。

这是一个案例想定供大家警戒:

使用jspsmartUpload作文件上传,现在运行过程中经常出现java.outofMemoryError的错误,用top命令看看进程使用情况,发现内存不足2M,花了很长时间,发现是jspsmartupload的问题。把jspsmartupload组件的源码文件(class文件)反编译成Java文件,如梦方醒:

m_totalBytes = m_request.getContentLength();        
m_binArray = new byte[m_totalBytes];      

变量m_totalBytes表示用户上传的文件的总长度,这是一个很大的数。如果用这样大的数去声明一个byte数组,并给数组的每个元素分配内存空间,而且m_binArray数组不能马上被释放,JVM的垃圾回收确实有问题,导致的结果就是内存溢出。

jspsmartUpload
为什末要这样作,有他的原因,根据RFC1867http上传标准,得到一个文件流,并不知道文件流的长度。设计者如果想文件的长度,只有操作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();  

5
、尽量运用对象池技术以提高系统性能;生命周期长的对象拥有生命周期短的对象时容易引发内存泄漏,例如大集合对象拥有大数据量的业务对象的时候,可以考虑分块进行处理,然后解决一块释放一块的策略。

6
、不要在经常调用的方法中创建对象,尤其是忌讳在循环中创建对象。可以适当的使用 hashtable vector 创建一组对象容器,然后从容器中去取那些对象,而不用每次 new 之后又丢弃

7
、一般都是发生在开启大型文件或跟数据库一次拿了太多的数据,造成 Out Of Memory Error 的状况,这时就大概要计算一下数据量的最大值是多少,并且设定所需最小及最大的内存空间值。

posted @ 2013-02-21 16:27  风*依旧  阅读(742)  评论(0编辑  收藏  举报