在Hibernate文档确实在他们定义了很好的工作：

19.2.2。策略：只读

如果您的应用程序需要读取而不是修改持久类的实例，则可以使用只读缓存。这是最简单和最佳的执行策略。在群集中使用它甚至是安全的。

19.2.3。策略：读/写

如果应用程序需要更新数据，则可以使用读写缓存。如果需要可序列化的事务隔离级别，则永远不要使用此缓存策略。如果在JTA环境中使用了高速缓存，则必须指定属性
hibernate.transaction.manager_lookup_class
并命名用于获取JTA的策略TransactionManager。在其他环境中，应确保在调用Session.close()或 时完成事务
Session.disconnect()。如果要在群集中使用此策略，则应确保基础缓存实现支持锁定。内置缓存提供程序不支持锁定。

19.2.4。策略：非严格读/写

如果应用程序仅偶尔需要更新数据（即，如果两个事务很难同时尝试更新同一项目），并且不需要严格的事务隔离，则非严格读写缓存可能是合适的。如果在JTA环境中使用了缓存，则必须指定
hibernate.transaction.manager_lookup_class。在其他环境中，应确保在调用Session.close()或
时完成事务Session.disconnect()。

19.2.5。策略：事务性

事务缓存策略为完全事务缓存提供程序（例如JBoss TreeCache）提供支持。这样的缓存只能在JTA环境中使用，必须指定
hibernate.transaction.manager_lookup_class。

换一种说法：

• 只读： 对 经常读取但从未更新的 数据很有用（例如，参考数据，如“国家”）。很简单。它拥有所有最佳性能（显然）。

• 读/写： 如果您的数据需要 更新，则是 理想的。但是它不提供SERIALIZABLE隔离级别，可能会发生幻像读取（您可能会在事务结束时看到开始时不存在的某些内容）。它具有比只读更多的开销。

• 非严格读/写： 或者，如果不太可能两个独立的事务线程可以更新同一对象，则可以使用非严格读/写策略。它比读写具有更少的开销。这对于 很少更新的 数据很有用。

• 事务性： 如果您需要 完全事务性 缓存。仅适用于JTA环境。

因此，选择正确的策略取决于是否要更新数据，更新的频率和所需的隔离级别。如果您不知道如何回答要放入高速缓存中的数据的问题，请向DBA寻求支持。