最近公司的应用经常报OOM，一开始我以为是公司业务数据太多，导致内存不够，所以只是简单的把容器的内存加大。撑了几天后这个错仍然被报出来。后来我仔 细分析过项目代码后，没有发现有任何引起内存泄漏的地方。百思不得其解，于是我决定在OOM异常发生的那刻将JVM内存堆导出来仔细分析，我在生产环境的某一台机器上加上了JVM启动参数：“-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/app/vas_platform/temp/” 然后等了一天，终于又报错了，拿出堆文件用“Eclipse Memory Analyzer”打开分析，发现占用内存的地方居然有75%来自org.hibernate.engine.StatefulPersistenceContext（靠，这不科学啊！）
后来查看各个StatefulPersistenceContext里面的内容发现里面保存存着多达几十万个实体对象，其中大部分都是比较大的对象（本身字段特别多而且还级联了许多其它的实体一级接着一级的级联），
心想为什么会这样呢？一个请求过来->打开Session->处理完业务->关闭Session，没问题啊而且所有页面均没有卡死的现
像，难道代码里面有占用Session没关的地方。于是仔细分析代码终于被我发现问题了。我们的应用会定时启动几个quartz任务来处理复杂且影响页面
响应时间的业务，这部分业务的业务数据是从数据库查的，只有业务数据全都被处理完后这个quartz才会结束。
因为Hibernate的Session是带有一级缓存的，每个经由Session查出来的对象会填充至一级缓存，以避免多次的数据库仿问。当这几个
quartz任务的业务数据较多的时候，就会有很多对象被填入一级缓存这样一来持久化上下文中保存的对象越来越多。最终导致OOM.