根据网上的各种资料以及个人的经验
出现内存泄露有好多情况的，主要jvm耗费了太多的内存，部署大系统时，如果内存设置不合理也会报错，还有程序方面的问题等等。
分两种情况：
1 内存不够用。 比如parse一个大的xml，读一个大的文件。比如GC的速度赶不上系统运行期间开辟内存的速度，内存使用峰值超过了JVM参数设置范围。
2 内存泄漏。在内存中某个类的实例在不断增加，可能是有某个全局变量引用了它，所以垃圾回收机制无法回收这些实例。
具体的可能有以下这些原因：
1. java设置内存的参数是否合适
2. 频繁的大数据量并发处理，比如查询数据库，遇到比较大的数据集，或者sql写的效率比较低。我遇到过数据集太大，生成报表或者到导入大批量数据，造成内存外溢；
3. java处理文件的时候，文件比较大
4. i/o ，数据库连接，结果集没有正确close
5. 频繁创建大对象
6. 集合类的不正确使用
7. JNI（Java Native Interface）内存泄漏
8. 系统启动某些功能时，瞬间需要大量内存(只是瞬间，意会还会释放的)
9. 加载生成类太多,如 spring
10. 用tools.jar直接编译超大的java文件
11. fixedthreadpool 线程执行速度太慢，插入速度太快
12. IBM的jvm里频繁生成大对象后会形成不少碎片。IBM的jvm没有碎片整理归并，导致后期的大对象分配内存时出现dump的情况
13. JVM创建的thread过多
14. 调用了第三方库，内存没有得到释放
15. 我用webwork+spring应用的时候，重启应用经常发生内存溢出，我一直怀疑是spring的ioc与xwork的ioc兼容上有问题。
16. 在finalize() 终结方法的使用不当，导致outofmemory.所以我们要慎重使用此方法哦。
原因：GC释放声明有finalize()方法的对象前，都要先调用finalize()方法。如果finalize()方法中又调用了收集堆中的对象，此收集堆中的对象就会复活，或者会复活自身。这样GC需要下一次运行时再次扫描此对象，并且要标志此finalize()方法是否已经运行过了；这样极有可能造成反复的gc扫描，内存的消耗从而加剧。
17. 无限循环的线程，死锁，问题也会导致JVM OUT OF MEMORY
18. 由于内存泄漏导致内存在系统运行期间不断增大，超出JVM参数设置范围
解决方案：
第一种情况，增加虚拟机的内存，在java启动的时候可以指定 -xmx参数。
第二种情况，可以借用一些工具去监视虚拟机内存，并拍一些快照，通过比较快照，去发现到底那个java对象在不断增加而无法释放。
解决这个问题最主要的是，先从你自己的程序代码出发，引起这个异常的原因太多。一旦出现这个异常，先逐步的调试程序，确认代码没有任何问题。在这个前提下，再从面所说的方面寻找解决方法。当然，这只是我个人的理解。
Out Memory问题是一个引子，需要从jvm、应用、服务器性能等多方面优化调整，但是个人认为最核心问题在于应用方面，大多数OM问题是由big Object、大数据集处理、小对象大量创建占用、sql语句不合理、Hibernate配置不当等引起。jvm和服务器性能调整相对还是比较容易的。