肤浅理解hibernate缓存

hibernate 二级缓存的如何配置在这里就不概述了,包括使用第三插件ehCache,osCache..
在这里我要讲的是关于应用缓存的时候遇到的一些问题。
get方法是不会走缓存的，会直接命中数据库，所以每次都会发sql

session.get(User.class, 1L);

load方法会先去缓存里面找，如果没找到就会发sql去命中数据库，也就是说load会查缓存

session.load(User.class, 1L);

以上两种情况都是比较基本的东西，相信大家都应该知道。
下面讲一下手写hql和hibernate二级缓存的应用
默认情况下 hql,jpa ql,sql,criteria是不会查询缓存的，他们会绕开缓存，直接生成sql去数据库命中。所以你在给实体加缓存但是为什么总产生sql原因之一。但是也可以通过配置让他们先去缓存中查找。
首先要在hibernate配置文件中配置,这是启用查询缓存

hibernate.cache.use_query_cache = true 

但是紧紧这样还不够，你还需要在你手写hql的地方加上激活查询缓存的设置

query.setCacheable(true);

这样你再调用该查询语句的时候就不会发sql。
但是请记住，启用查询缓存后，一定要给相对应的实体加上二级缓存，如果hql中的实体没有启用二级缓，只是设置了query.setCacheable(true);那么你这个查询可以将一更多命中数据库而告终。
大多数查询都没有从结果高速缓存中受益，这可能有点出乎意料。毕竟，避免数据库命中听起来似乎总是件好事。比起对象导航或者按标示符获取而言，它之所以并非永远对任意的查询有用主要有以下两个原因：
首先，必须问问，你会每隔多久重复执行同一个查询？毫无疑问，在你的应用程序可有很多已反复执行的查询。当你确定某个查询会在一定时间内被重复执行，它就很适合做结果告诉缓存。
其次，对于执行许多查询和少数插入，删除或者更新的应用程序来说，高速缓存查询可以提升性能。另一方面，如果应用程序执行许多写入操作，查询告诉缓存就没有得到有效的利用。当出现在被告诉缓存的查询结果中的表有任何插入，更新或者删除操作时，hibernate就会废弃掉被高速缓存的查询结果集。这样就意味着呗告诉缓存的结果寿命可能很短，即使重复执行查询，由于相同的数据的并发修改，也没有可以使用高速缓存的结果。
当然如果你想优化你的程序或者让你程序的性能大幅度提高，首先还是要考虑你的抓取策略，其次再考虑缓存。
第一次写文章，写的不是很好，希望大家多提意见。