JPA2.1中三个提升应用性能的新功能

经常在网上看到开发者们抱怨JPA性能低下的帖子或文章，但如果仔细查看这些性能问题，常会发现导致问题的根本原因大致包括以下几个：

• 使用过多的SQL查询从数据库中获取所需的实体信息，即我们常说的n+1查询问题
• 逐个更新实体，而不是使用单条语句进行更新
• 使用Java应用程序而非数据库进行大量数据处理

JPA提供了处理这类问题的方法，并给JPA2.1 增加了一些额外功能，可以极大地提升性能表现，笔者将在本文中解释如何利用JPA2.1的功能避免上述问题。

顺便提一下，如果想了解Java项目中更多的典型性能问题，可以参考笔者最近发布的基于性能调查结果的深度报告，如果你在寻找JPA资源，点击此链接便可获取JPA2.1特征的备忘清单。接下来我们来看看如何用JPA来解决现有的性能问题。

解决“SQL查询过多”的问题

根据以往的经验，使用过多的SQL查询获取所要求的实体是导致性能问题最普遍的原因。

即使是看起来最简单的查询，如果操作不当，也会触发几十次甚至上百次的SQL查询。而且，你在本节中可以看到，这类不当操作不一定会出现在查询语句中，而可能只是几个配置不当的注解。所以，如果你觉得这个问题不会造成影响，请三思。

如果在你的项目中出现以下几段代码，你会怎么想？

List authors = this.em.createQuery("SELECT a FROM Author a",
		Author.class).getResultList();

for (Author a : authors) {
	System.out.println("作者 "
			+ a.getFirstName()
			+ " "
			+ a.getLastName()
			+ " 书籍信息 "
			+ a.getBooks()
					.stream()
					.map(b -> b.getTitle() + "("
							+ b.getReviews().size() + " 评论)")
					.collect(Collectors.joining(", ")));
}

上面的代码段会打印所有作者的姓名及其书名，看起来非常简单，但你是否想过它给数据库发送了多少次查询？一次？还是两次？或者Author、Book、Review实体各一次？

实际上，这取决于数据库中作者的人数。如果数据库较小，里面只有11名作者和6本书。那么这段代码会触发12次查询，其中1次用于获取所有作者姓名，另外11次给每位作者匹配书名。这一问题被称作n+1查询问题，无论我们使用的是MySQL、SqlServer还是其他数据库，都容易出现此类问题。因此在生产环境中，随着数据量不断增大，代码的性能就越差。

我们可以通过多种方法，用一次查询获取所有要求的实体信息 ，从而避免这一情况。在笔者看来，使用@NamedEntityGraph来解决此问题是最新，也最好的方法。

实体图通过独立于查询的方法指定应该从数据库中获取的实体的图。这意味着，你需要为实体图创建一个独立的定义，并在需要时与查询合并。下段代码展示了如何定义根据作者名提取书名的@NamedEntityGraph。

@Entity
@NamedEntityGraph(name = "graph.AuthorBooks", attributeNodes = @NamedAttributeNode("books"))
public class Author implements Serializable {
…
}

现在，实体管理器可以用这个图为参考，通过一次查询获取所有作者和书名。在图的定义中可以看到，笔者只提供了包含相关实体的属性名称。因此，笔者将@NamedEntityGraph作为loadgraph (负载图)，这样便可提取其他所有属性及其定义的获取类型，如下所示：

EntityGraph graph = this.em.getEntityGraph("graph.AuthorBooks");

List authors = this.em
.createQuery("SELECT DISTINCT a FROM Author a", Author.class)
.setHint("javax.persistence.loadgraph", graph).getResultList();

该示例展示了一个非常简单的实体图，在实际的应用中，很可能会用到更复杂的图，但这也不成问题。你可以定义多个@NamedAttributeNodes以定义更复杂的图，也可以用@NamedSubGraph注解来创建多层次的图。如果想了解更多关于@NamedEntityGraphs的信息，请点击实体图使用方式详解。

在某些使用案例中，你可能还需要用更动态的方式来定义实体图，比如，根据一些输入参数进行定义。在此类案例中，通过Java API用编程的方式定义实体图效果更佳。

解决“逐个更新实体”的问题

逐个更新实体是造成JPA性能问题的另一个常见原因。作为Java开发者，我们习惯处理对象，并用面向对象的方式思考问题。尽管这是实现复杂逻辑和应用的好方法，但也是处理数据库时导致性能退化的一个常见原因。

从面向对象的角度来看，对实体进行更新和删除操作是完全可以接受的。但当你不得不更新一大组实体时，这种操作就会非常低效。持久性提供者(Persistence Provider)将为每个更新实体创建一个更新语句，并在下一次flush操作时发送至数据库中。

然而，SQL提供了一个更为高效的方式。它允许你创建可一次性更新多个实体的更新语句。你还可以对JPA 2.1引入的CriteriaUpdate 和CriteriaDelete语句进行同样的操作。

如果你之前用过criteria条件查询，肯定对新的CriteriaUpdate以及CriteriaDelete语句非常熟悉，更新和删除操作的创建方式几乎与JPA 2.0中引入的criteria条件查询创建方式一样。

在下面的代码段中可以看到，你需要从实体管理器中获取CriteriaBuilder并用它创建CriteriaUpdate对象，对CriteriaQuery进行的操作与此类似，主要区别在于用于定义更新操作的set方法。

CriteriaBuilder cb = this.em.getCriteriaBuilder();
// create update
CriteriaUpdate update = cb.createCriteriaUpdate(Author.class);
// set the root class
Root a = update.from(Author.class);
// set update and where clause
update.set(Author_.firstName, cb.concat(a.get(Author_.firstName), " - updated"));
update.where(cb.greaterThanOrEqualTo(a.get(Author_.id), 3L));

// perform update
Query q = this.em.createQuery(update);
q.executeUpdate();

在CriteriaDelete操作中，你只需要在实体管理器中调用createCriteriaDelete 方法以获取CriteriaDelete对象，并用它来定义与上例类似的FROM和WHERE查询部分。

在数据库中处理数据

作为Java开发者，我们倾向于在Java中实现所有的应用逻辑，这也是造成性能问题的一大常见原因。别误会，在Java 中实现逻辑的好处很多，但如果将部分逻辑实现在数据库中，只把结果发送到业务逻辑层，也能得到很好的效果。

在数据库中执行逻辑的方法很多。只用SQL语句，也能完成很多事情，如果不够，你还可以调用数据库的特定功能和存储过程。在本文中，笔者将仔细探讨存储过程，更确切地说是探讨调用存储过程的方式。

在JPA 2.0中，并没有针对存储过程的实际支持，本地查询是调用存储过程的唯一方式。JPA 2.1.引入了@NamedStoredProcedureQuery 和更为动态的StoredProcedureQuery，改变了这一现状。在本文中，笔者将重点关注基于注解的、用@NamedStoredProcedureQuery进行调用的存储过程的定义。笔者在博客中详细介绍了动态存储过程查询 。

在下面代码段中可以看到，@NamedStoredProcedureQuery 的定义非常简洁，你需要指定查询的名称、数据库中的存储过程名称以及输入和输出参数。在本例中，笔者用输入参数x和y调用存储过程calculate，期望的输出参数为sum，其它支持的参数类型还有用于输入和输出的参数INPUT和用于检索结果集的REF_COURSOR。

@NamedStoredProcedureQuery(
name = "calculate",
procedureName = "calculate",
parameters = {
@StoredProcedureParameter(mode = ParameterMode.IN, type = Double.class, name = "x"),
@StoredProcedureParameter(mode = ParameterMode.IN, type = Double.class, name = "y"),
@StoredProcedureParameter(mode = ParameterMode.OUT, type = Double.class, name = "sum") })

@NamedStoredProcedureQuery 的使用方法与 @NamedQuery相似，你需要向实体管理器的createNamedStoredProcedureQuery方法提供查询名称，以便在本次查询中获取StoredProcedureQuery对象，然后，用setParameter方法设定输入参数，之后再用execute方法调用存储过程。

StoredProcedureQuery query = this.em.createNamedStoredProcedureQuery("calculate");
query.setParameter("x", 1.23d);
query.setParameter("y", 4.56d);
query.execute();
Double sum = (Double) query.getOutputParameterValue("sum");

总结

JPA给数据库存储和检索带来诸多便利。通过这一工具，可快速开展项目，解决大部分问题，但也更容易导致实现非常低效的持久层。由此，普遍存在的问题包括：使用过多查询获取所需数据、逐个更新实体以及在Java中执行所有逻辑。

JPA 2.1规范引入了几个新的功能以应对这些低效操作，比如实体图（entity graphs），条件更新（criteria update）和存储过程查询（stored procedure queries）。笔者的JPA2.1新功能备忘单囊括了JPA 2.1的这些功能及其他新功能，你可以免费下载。

若有提升JPA性能的任何建议或更好方法，请在下方评论区中留下你的建议。