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为什末要这样作，有他的原因，根据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();
5
、尽量运用对象池技术以提高系统性能；生命周期长的对象拥有生命周期短的对象时容易引发内存泄漏，例如大集合对象拥有大数据量的业务对象的时候，可以考虑分块进行处理，然后解决一块释放一块的策略。
6
、不要在经常调用的方法中创建对象，尤其是忌讳在循环中创建对象。可以适当的使用
hashtable ，
vector
创建一组对象容器，然后从容器中去取那些对象，而不用每次
new 之后又丢弃
7
、一般都是发生在开启大型文件或跟数据库一次拿了太多的数据，造成
Out Of Memory Error
的状况，这时就大概要计算一下数据量的最大值是多少，并且设定所需最小及最大的内存空间值。