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

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，因为是一对多的关联方式，后者的载入类型是懒载入。执行

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

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

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

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

缓存和马上载入

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

此时，不管是否选择遍历关联对象。都会发生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")

当使用了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 ...
        }
    }
}

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

首次运行会产生66816次SQL调用。当中33408次是调用find方法时产生的。另外33408次时调用getOptions方法时产生的。在此之后。全部的对象都会被保存到二级缓存中，因此兴许运行时，没有SQL被运行。

所以，当使用无查询的策略是。首次运行的时间一般会比較长，这个过程能够被看成是一个“热身”的过程。在“热身”结束之后。程序的性能会提高一个档次。

另外须要注意的一个问题是，即使使用getOptions方法得到的是一个集合对象，这个集合对象的全部元素也会被存储到二级缓存中，不要将它和查询混淆。所以，当希望缓存一个实体对象关联的一组实体对象时，仅仅须要调用对应的getter方法就可以。甚至不须要对该集合进行遍历。

设置JPA缓存的空间

当JPA缓存占用的内存过多时，它会给GC加入不小的压力。

所以JPA缓存的空间须要被细致设置。可是，JPA规范并没有规定怎样设置JPA缓存。所以须要查看相应JPA实现的相关文档。

TODO：和堆相关

总结

1. JPA的二级缓存会自己主动地为应用缓存对象。

2. 二级缓存不会保存查询(JPQL)的返回对象。所以当须要缓存对象时，不要使用查询。

   (或者开启查询缓存)

3. 慎重使用结合了JOIN FETCH的查询。除非使用的JPA实现支持查询缓存。由于默认情况下。查询会跳过二级缓存。

JPA仅仅读实体(JPA Read-Only Entities)

虽然JPA规范并没有介绍仅仅读实体。可是在非常多JPA实现中，都会这样的实体作出对应的优化。

对仅仅读实体的操作在性能上一般都会优于读写实体(Read-Write Entities)。由于对于仅仅读实体，不须要保存它的状态，不须要将它放在事务中。也不须要对它进行加锁。

在Java EE容器中。不管使用的什么JPA实现，仅仅读实体一般都会被支持。应用server会保证对这些实体的获取是通过一个特殊的非事务性的JDBC连接来完毕。

这样做通常都有更好的性能。