Hibernate 填坑记录

1.操作大量数据（数据同步）尽量不使用 Hibernate ，jdbc效率更高。

2.Hibernate 存在一级缓存，一个事务内大量操作数据会导致缓存存储大量数据(hibernate的一级缓存是session级别的，所以如果session关闭后，缓存就没了），最终内存溢出。
解决方法：
Session.flush();
Session.clear();

3.同步数据的时候，jvm内存设置不够大的话会报oom：java heap space。因为一个事务内需要大量操作数据库，所以觉得是数据量太大，事务未结束没提交数据进数据库导致的。取消事务后发现仍然有这个问题。再仔细看报错信息是获取连接的时候，报的内存溢出。
上网查资料后发现：
Hibernate 有四种链接释放机制：
default : 默认方式
on_close : session关闭时释放连接
after_transcation : 事务处理结束后，以事务为单位进行连接的释放
after_statement : 每次执行后释放当前连接。
四种释放连接的颗粒度，从粗到细：
1、采用第一种default配置，在spring中配置事务管理，由于事务颗粒度比较小，事务执行结束，也不会触发释放的操作，直至达连接设置回收的最大超时时间才能回收连接，连接会迟迟不释放，导致连接池被占满。
2、采用第二种on_close, 同样在spring中配置事务，连接一直等到session 关闭时才会，释放较慢，同样会导致连接池被沾满
3、采用after_transcation 的策略释放链接，每次事务都会释放链接。采用xml配置进行全局事务管理的配置，则不会出现连接池沾满的现象。但是如果采用注解，而某个持久层的
Dao类未标注Transactional注解，或者xml配置中遗漏了某个dao的事务管理配置，则该Dao操作执行结束，并不是一个事务的结束，不会释放链接，导致链接迟迟不能被释放，久而久之会导致连接池被占满。
4、after_statement 的策略释放连接及时。但也有一个弊端,由于每一次执行都会释放连接，如果一个事务需要几个执行操作，但第一次执行时连接就被释放，连接已归还给连接池了，第二次执行时获取新的连接，这样就无法保证事务性了。
因为设置的是auto模式，所以导致连接一直未释放，不停获取连接结果把内存撑爆了。所以将连接释放设置成after_transcation 模式，在合适的地方手动开启关闭事务，问题解决。