摘要：只用語句，也能完成很多事情，如果不夠，你還可以調(diào)用數(shù)據(jù)庫的特定功能和存儲過程。在中，并沒有針對存儲過程的實(shí)際支持，本地查詢是調(diào)用存儲過程的唯一方式。規(guī)范引入了幾個(gè)新的功能以應(yīng)對這些低效操作，比如實(shí)體圖，條件更新和存儲過程查詢。

經(jīng)常在網(wǎng)上看到開發(fā)者們抱怨 JPA 性能低下的帖子或文章，但如果仔細(xì)查看這些性能問題，常會(huì)發(fā)現(xiàn)導(dǎo)致問題的根本原因大致包括以下幾個(gè)：

使用過多的 SQL 查詢從數(shù)據(jù)庫中獲取所需的實(shí)體信息，即我們常說的n+1查詢問題

逐個(gè)更新實(shí)體，而不是使用單條語句進(jìn)行更新

使用 Java 應(yīng)用程序而非數(shù)據(jù)庫進(jìn)行大量數(shù)據(jù)處理

JPA提供了處理這類問題的方法，并給 JPA2.1 增加了一些額外功能，可以極大地提升性能表現(xiàn)，筆者將在本文中解釋如何利用 JPA2.1 的功能避免上述問題。

順便提一下，如果想了解Java項(xiàng)目中更多的典型性能問題，可以參考筆者最近發(fā)布的基于性能調(diào)查結(jié)果的深度報(bào)告，如果你在尋找 JPA 資源，點(diǎn)擊此鏈接便可獲取JPA2.1特征的備忘清單。接下來我們來看看如何用JPA來解決現(xiàn)有的性能問題。

根據(jù)以往的經(jīng)驗(yàn)，使用過多的 SQL 查詢獲取所要求的實(shí)體是導(dǎo)致性能問題最普遍的原因。

即使是看起來最簡單的查詢，如果操作不當(dāng)，也會(huì)觸發(fā)幾十次甚至上百次的 SQL 查詢。而且，你在本節(jié)中可以看到，這類不當(dāng)操作不一定會(huì)出現(xiàn)在查詢語句中，而可能只是幾個(gè)配置不當(dāng)?shù)淖⒔狻Ｋ?，如果你覺得這個(gè)問題不會(huì)造成影響，請三思。

如果在你的項(xiàng)目中出現(xiàn)以下幾段代碼，你會(huì)怎么想？

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(", ")));
}

上面的代碼段會(huì)打印所有作者的姓名及其書名，看起來非常簡單，但你是否想過它給數(shù)據(jù)庫發(fā)送了多少次查詢？一次？還是兩次？或者 Author、Book、Review 實(shí)體各一次？

實(shí)際上，這取決于數(shù)據(jù)庫中作者的人數(shù)。如果數(shù)據(jù)庫較小，里面只有11名作者和6本書。那么這段代碼會(huì)觸發(fā)12次查詢，其中1次用于獲取所有作者姓名，另外11次給每位作者匹配書名。這一問題被稱作 n+1 查詢問題，無論我們使用的是 MySQL、SqlServer 還是其他數(shù)據(jù)庫，都容易出現(xiàn)此類問題。因此在生產(chǎn)環(huán)境中，隨著數(shù)據(jù)量不斷增大，代碼的性能就越差。

我們可以通過多種方法，用一次查詢獲取所有要求的實(shí)體信息 ，從而避免這一情況。在筆者看來，使用 @NamedEntityGraph 來解決此問題是最新，也最好的方法。

實(shí)體圖通過獨(dú)立于查詢的方法指定應(yīng)該從數(shù)據(jù)庫中獲取的實(shí)體的圖。這意味著，你需要為實(shí)體圖創(chuàng)建一個(gè)獨(dú)立的定義，并在需要時(shí)與查詢合并。下段代碼展示了如何定義根據(jù)作者名提取書名的 @NamedEntityGraph。

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

現(xiàn)在，實(shí)體管理器可以用這個(gè)圖為參考，通過一次查詢獲取所有作者和書名。在圖的定義中可以看到，筆者只提供了包含相關(guān)實(shí)體的屬性名稱。因此，筆者將@NamedEntityGraph作為loadgraph (負(fù)載圖)，這樣便可提取其他所有屬性及其定義的獲取類型，如下所示：

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();

該示例展示了一個(gè)非常簡單的實(shí)體圖，在實(shí)際的應(yīng)用中，很可能會(huì)用到更復(fù)雜的圖，但這也不成問題。你可以定義多個(gè) @NamedAttributeNodes 以定義更復(fù)雜的圖，也可以用 @NamedSubGraph 注解來創(chuàng)建多層次的圖。如果想了解更多關(guān)于 @NamedEntityGraphs 的信息，請點(diǎn)擊實(shí)體圖使用方式詳解。

在某些使用案例中，你可能還需要用更動(dòng)態(tài)的方式來定義實(shí)體圖，比如，根據(jù)一些輸入?yún)?shù)進(jìn)行定義。在此類案例中，通過 Java API 用編程的方式定義實(shí)體圖效果更佳。

逐個(gè)更新實(shí)體是造成 JPA 性能問題的另一個(gè)常見原因。作為 Java 開發(fā)者，我們習(xí)慣處理對象，并用面向?qū)ο蟮姆绞剿伎紗栴}。盡管這是實(shí)現(xiàn)復(fù)雜邏輯和應(yīng)用的好方法，但也是處理數(shù)據(jù)庫時(shí)導(dǎo)致性能退化的一個(gè)常見原因。

從面向?qū)ο蟮慕嵌葋砜?，對?shí)體進(jìn)行更新和刪除操作是完全可以接受的。但當(dāng)你不得不更新一大組實(shí)體時(shí)，這種操作就會(huì)非常低效。持久性提供者(Persistence Provider)將為每個(gè)更新實(shí)體創(chuàng)建一個(gè)更新語句，并在下一次 flush 操作時(shí)發(fā)送至數(shù)據(jù)庫中。

然而，SQL 提供了一個(gè)更為高效的方式。它允許你創(chuàng)建可一次性更新多個(gè)實(shí)體的更新語句。你還可以對 JPA 2.1 引入的 CriteriaUpdate 和 CriteriaDelete 語句進(jìn)行同樣的操作。

如果你之前用過 criteria 條件查詢，肯定對新的 CriteriaUpdate 以及 CriteriaDelete 語句非常熟悉，更新和刪除操作的創(chuàng)建方式幾乎與 JPA 2.0 中引入的 criteria 條件查詢創(chuàng)建方式一樣。

在下面的代碼段中可以看到，你需要從實(shí)體管理器中獲取 CriteriaBuilder 并用它創(chuàng)建 CriteriaUpdate 對象，對 CriteriaQuery 進(jìn)行的操作與此類似，主要區(qū)別在于用于定義更新操作的 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 操作中，你只需要在實(shí)體管理器中調(diào)用 createCriteriaDelete 方法以獲取 CriteriaDelete 對象，并用它來定義與上例類似的 FROM 和 WHERE 查詢部分。

作為 Java 開發(fā)者，我們傾向于在 Java 中實(shí)現(xiàn)所有的應(yīng)用邏輯，這也是造成性能問題的一大常見原因。別誤會(huì)，在 Java 中實(shí)現(xiàn)邏輯的好處很多，但如果將部分邏輯實(shí)現(xiàn)在數(shù)據(jù)庫中，只把結(jié)果發(fā)送到業(yè)務(wù)邏輯層，也能得到很好的效果。

在數(shù)據(jù)庫中執(zhí)行邏輯的方法很多。只用 SQL 語句，也能完成很多事情，如果不夠，你還可以調(diào)用數(shù)據(jù)庫的特定功能和存儲過程。在本文中，筆者將仔細(xì)探討存儲過程，更確切地說是探討調(diào)用存儲過程的方式。

在 JPA 2.0 中，并沒有針對存儲過程的實(shí)際支持，本地查詢是調(diào)用存儲過程的唯一方式。JPA 2.1.引入了 @NamedStoredProcedureQuery 和更為動(dòng)態(tài)的 StoredProcedureQuery，改變了這一現(xiàn)狀。在本文中，筆者將重點(diǎn)關(guān)注基于注解的、用 @NamedStoredProcedureQuery 進(jìn)行調(diào)用的存儲過程的定義。筆者在自己的博客中詳細(xì)介紹了動(dòng)態(tài)存儲過程查詢 。

在下面代碼段中可以看到， @NamedStoredProcedureQuery 的定義非常簡潔，你需要指定查詢的名稱、數(shù)據(jù)庫中的存儲過程名稱以及輸入和輸出參數(shù)。在本例中，筆者用輸入?yún)?shù) x 和 y 調(diào)用存儲過程 calculate，期望的輸出參數(shù)為 sum，其它支持的參數(shù)類型還有用于輸入和輸出的參數(shù) INPUT 和用于檢索結(jié)果集的 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 相似，你需要向?qū)嶓w管理器的createNamedStoredProcedureQuery 方法提供查詢名稱，以便在本次查詢中獲取 StoredProcedureQuery 對象，然后，用 setParameter 方法設(shè)定輸入?yún)?shù)，之后再用 execute 方法調(diào)用存儲過程。

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 給數(shù)據(jù)庫存儲和檢索帶來諸多便利。通過這一工具，可快速開展項(xiàng)目，解決大部分問題，但也更容易導(dǎo)致實(shí)現(xiàn)非常低效的持久層。由此，普遍存在的問題包括：使用過多查詢獲取所需數(shù)據(jù)、逐個(gè)更新實(shí)體以及在 Java 中執(zhí)行所有邏輯。

JPA 2.1規(guī)范引入了幾個(gè)新的功能以應(yīng)對這些低效操作，比如實(shí)體圖（entity graphs），條件更新（criteria update）和存儲過程查詢（stored procedure queries）。筆者的JPA2.1新功能備忘單囊括了JPA 2.1的這些功能及其他新功能，你可以免費(fèi)下載。

（編譯自：http://zeroturnaround.com/rebellabs/three-jpa-2-1-features-that-will-boost-your-applications-performance/）

OneAPM 為您提供端到端的 Java 應(yīng)用性能解決方案，我們支持所有常見的 Java 框架及應(yīng)用服務(wù)器，助您快速發(fā)現(xiàn)系統(tǒng)瓶頸，定位異常根本原因。分鐘級部署，即刻體驗(yàn)，Java 監(jiān)控從來沒有如此簡單。想閱讀更多技術(shù)文章，請?jiān)L問 OneAPM 官方技術(shù)博客。

本文轉(zhuǎn)自 OneAPM 官方博客