[Java Performance] 数据库性能最佳实践 – JPA缓存

全栈程序员站长

发布于 2022-07-07 20:54:12

1.9K0

发布于 2022-07-07 20:54:12

文章被收录于专栏：全栈程序员必看

大家好，又见面了，我是全栈君。

JPA缓存(JPA Caching)

JPA有两种类型的缓存：

EntityManager自身就是一种缓存。事务中从数据库获取的和写入到数据库的数据会被缓存(什么样的数据会被缓存。在后面有介绍)。在一个程序中或许会有非常多个不同的EntityManager实例。每个实例执行着不同的事务，拥有着它们自己的缓存。
当EntityManager提交一个事务后，它缓存的全部数据就会被合并到一个全局的缓存中。全部的EntityManager都可以訪问这个全局的缓存。

全局缓存被称为二级缓存(Level 2 Cache)。而EntityManager拥有的本地缓存被称为一级缓存(Level 1 Cache)。全部的JPA实现都拥有一级缓存，而且对它没有什么能够调优的。

而二级缓存就不同了：大多数JPA实现都提供了二级缓存，可是有些并没有把启用它作为默认选项，比方Hibernate。一旦启用了二级缓存。它的设置会对性能产生较大的影响。

仅仅有当使用实体的主键进行訪问时，JPA的缓存才会工作。这意味着。以下的两种获取方式会将获取的结果放入到JPA的缓存中：

调用find()方法，由于它须要接受实体类的主键作为參数
调用实体类型的getter方法来得到关联的实体类型。本质上。获取关联的实体对象也是通过关联对象的主键得到，由于在数据库的表结构中。存放的是该关联对象的外键信息。

那么当EntityManager须要通过主键或者关联关系获取一个实体对象时。它首先会去二级缓存中寻找。

假设找到了，那么它就不须要对数据库进行訪问了。

通过查询(JPQL)方式得到的实体对象是不会被放到二级缓存中的。

然而在一些JPA实现中也会将查询得到的结果放入到缓存中。可是仅仅有当同样的查询再次被运行时，这些缓存才会起作用。所以即使JPA的实现支持查询缓存，查询返回的实体也不会被存储在二级缓存中。因此也就不能被诸如find()等方法利用了。

通过以下的一段代码对二级缓存和查询进行性能測试：

EntityManager em = emf.createEntityManager();
Query q = em.createNamedQuery(queryName);
List<StockPrice> l = q.getResultList(); // SQL Call 1
for (StockPrice sp : l) {
    // ... process sp ...
    if (processOptions) {
        Collection<? extends StockOptionPrice> options = sp.getOptions(); // SQL Call 2
        for (StockOptionPrice sop : options) {
            // ... process sop ...
        }
    }
}
em.close();

以上代码通过一个命名查询来得到StockPrice实体对象。布尔变量processOptions用来控制是否遍历关联的StockOptionPrice实体对象。

缓存和懒载入

@NamedQuery(name="findAll", query="SELECT s FROM StockPriceImpl s ORDER BY s.id.symbol")

@OneToMany(mappedBy="stock")
private Collection<StockOptionPrice> optionsPrices;

在默认情况下，对于StockPrice关联的StockOptionPrice，因为是一对多的关联方式，后者的载入类型是懒载入。执行

測试用例	首次运行	兴许运行
默认缓存策略 + 懒载入	61.9s (33,409 SQL调用)	3.2s (1 SQL 调用)
默认缓存策略 + 懒载入 + 不遍历关联对象	5.6s (1 SQL 调用)	2.8s (1 SQL 调用)

当须要遍历关联对象时。在首次运行时产生了大量SQL调用。这是由于对于每一个StockPrice实例。都须要遍历其StockOptionPrice集合，因此产生了：128 * 261 = 33408次SQL调用。

再加上获取StockPrice的一次命名查询，所以一共是33409次。可是在兴许运行时，仅仅会发生一次命名查询导致的SQL调用，这是由于StockOptionPrice此时所有都已经被存储到二级缓存中(由关联关系和find方法得到的实体对象会被保存到二级缓存中，而查询结果则不会被保存)，不须要再对数据库进行訪问。

当不须要遍历关联对象时，每次运行都仅仅会产生一次SQL调用。

同一时候注意到对于此測试用例，首次运行仍然比兴许运行要慢整整一倍，这是由于编译器的“热身”也会在首次运行期间进行(关于JIT编译器的性质。请查看相关章节)。

缓存和马上载入

当StockOptionPrice的载入方式切换成马上载入后，得到的測试数据例如以下：

測试用例	首次运行	兴许运行
默认缓存策略 + 马上载入	60.2s (33,409 SQL调用)	3.1s (1 SQL 调用)
默认缓存策略 + 马上载入 + 不遍历关联对象	60.2s (33,409 SQL 调用)	2.8s (1 SQL 调用)

此时，不管是否选择遍历关联对象。都会发生33409次SQL调用。

由于在运行命名查询得到每一个StockPrice对象后，就会顺便调用StockOptionPrice的getter方法来得到关联对象。此时得到的StockOptionPrice对象会被存储到二级缓存中。因此在兴许运行中不会再触发SQL调用。

JOIN FETCH和缓存

假设在命名查询中使用JOIN FETCH：

@NamedQuery(name="findAll", query="SELECT s FROM StockPriceEagerLazyImpl s " + "JOIN FETCH s.optionsPrices ORDER BY s.id.symbol")

測试用例	首次运行	兴许运行
默认配置	61.9s (33,409 SQL调用)	3.2s (1 SQL 调用)
JOIN FETCH	17.9s (1 SQL 调用)	11.4s (1 SQL 调用)
JOIN FETCH + 查询缓存	17.9s (1 SQL 调用)	1.1s (0 SQL 调用)

当使用了JOIN FETCH后，性能得到了很大的提升。尽管查询的数据量是相同的。可是发生的SQL调用剧减到了1，这也是性能得以大幅提升的首要原因。可是。由于缺少查询缓存。在兴许调用的时候仍然须要较长的时间(相同地，运行时间从17.9s -> 11.4s是由于首次运行期间JIT编译器须要“热身”)。

所以在最后一个測试用例，当开启了查询缓存后，兴许运行的时间大幅缩短到1.1s。同一时候没有发生SQL调用。这是一个使用查询缓存的典型样例。可是须要注意仅仅有当查询使用的參数全然同样时，查询缓存才会起作用。

避免查询

依据二级缓存的特点，假设不使用查询，那么得到的全部对象都会被保存到二级缓存中。那么当程序执行一段时间后。随着对象都被缓存，须要执行的SQL语句就越来越少。程序的执行速度也就越来越快了：

EntityManager em = emf.createEntityManager();
ArrayList<String> allSymbols = ... all valid symbols ...;
ArrayList<Date> allDates = ... all valid dates...;
for (String symbol : allSymbols) {
    for (Date date = allDates) {
        StockPrice sp = em.find(StockPriceImpl.class, new StockPricePK(symbol, date);
        // ... process sp ...
        if (processOptions) {
            Collection<? extends StockOptionPrice> options = sp.getOptions();
            // ... process options ...
        }
    }
}

測试结果例如以下所看到的：