你有沒有想過如果你能解決Hibernate問題，那么你的應(yīng)用程序可以更快?

那么請閱讀這篇文章!

我在很多應(yīng)用程序中修復過性能問題，其中大部分都是由同樣的錯誤引起的。修復之后，性能變得更溜，而且其中的大部分問題都很簡單。所以，如果你想改進應(yīng)用程序，那么可能也是小菜一碟。

這里列出了導致Hibernate性能問題的10個最常見的錯誤，以及如何修復它們。

錯誤1：使用Eager Fetching

FetchType.EAGER的啟示已經(jīng)討論了好幾年了，而且有很多文章對它進行了詳細的解釋。我自己也寫了一篇。但不幸的是，它仍然是性能問題最常見的兩個原因之一。

FetchType定義了Hibernate何時初始化關(guān)聯(lián)。你可以使用@OneToMany，@ManyToOne，@ManyToMany和@OneToOneannotation注釋的fetch屬性進行指定。

@Entity 
public class Author{ 
 
    @ManyToMany(mappedBy="authors", fetch=FetchType.LAZY) 
    private List<Book> books = new ArrayList<Book>(); 
 
    ... 
 
} 

當Hibernate加載一個實體的時候，它也會即時加載獲取的關(guān)聯(lián)。例如，當Hibernate加載Author實體時，它也提取相關(guān)的Book實體。這需要對每個Author進行額外的查詢，因此經(jīng)常需要幾十甚至數(shù)百個額外的查詢。

這種方法是非常低效的，因為Hibernate不管你是不是要使用關(guān)聯(lián)都會這樣做。***改用FetchType.LAZY代替。它會延遲關(guān)系的初始化，直到在業(yè)務(wù)代碼中使用它。這可以避免大量不必要的查詢，并提高應(yīng)用程序的性能。

幸運的是，JPA規(guī)范將FetchType.LAZY定義為所有對多關(guān)聯(lián)的默認值。所以，你只需要確保你不改變這個默認值即可。但不幸的是，一對一關(guān)系并非如此。

錯誤2：忽略一對一關(guān)聯(lián)的默認FetchType

接下來，為了防止立即抓取(eager fetching)，你需要做的是對所有的一對一關(guān)聯(lián)更改默認的FetchType。不幸的是，這些關(guān)系在默認情況下會被即時抓取。在一些用例中，那并非一個大問題，因為你只是加載了一個額外的數(shù)據(jù)庫記錄。但是，如果你加載多個實體，并且每個實體都指定了幾個這樣的關(guān)聯(lián)，那么很快就會積少成多，水滴石穿。

所以，***確保所有的一對一關(guān)聯(lián)設(shè)置FetchType為LAZY。

@Entity 
public class Review { 
 
    @ManyToOne(fetch = FetchType.LAZY) 
    @JoinColumn(name = "fk_book") 
    private Book book; 
 
    ... 
 
} 

錯誤3：不要初始化所需的關(guān)聯(lián)

當你對所有關(guān)聯(lián)使用FetchType.LAZY以避免錯誤1和錯誤2時，你會在代碼中發(fā)現(xiàn)若干n+1選擇問題。當Hibernate執(zhí)行1個查詢來選擇n個實體，然后必須為每個實體執(zhí)行一個額外的查詢來初始化一個延遲的獲取關(guān)聯(lián)時，就會發(fā)生這個問題。

Hibernate透明地獲取惰性關(guān)系，因此在代碼中很難找到這種問題。你只要調(diào)用關(guān)聯(lián)的getter方法，我想我們大家都不希望Hibernate執(zhí)行任何額外的查詢吧。

List<Author> authors = em.createQuery("SELECT a FROM Author a", Author.class).getResultList(); 
for (Author a : authors) { 
    log.info(a.getFirstName() + " " + a.getLastName() + " wrote " 
            + a.getBooks().size() + " books."); 
} 

如果你使用開發(fā)配置激活Hibernate的統(tǒng)計組件并監(jiān)視已執(zhí)行的SQL語句的數(shù)量，n+1選擇問題就會更容易被發(fā)現(xiàn)。

15:06:48,362 INFO [org.hibernate.engine.internal.StatisticalLoggingSessionEventListener] - Session Metrics { 
  28925 nanoseconds spent acquiring 1 JDBC connections; 
  24726 nanoseconds spent releasing 1 JDBC connections; 
  1115946 nanoseconds spent preparing 13 JDBC statements; 
  8974211 nanoseconds spent executing 13 JDBC statements; 
  0 nanoseconds spent executing 0 JDBC batches; 
  0 nanoseconds spent performing 0 L2C puts; 
  0 nanoseconds spent performing 0 L2C hits; 
  0 nanoseconds spent performing 0 L2C misses; 
  20715894 nanoseconds spent executing 1 flushes (flushing a total of 13 entities and 13 collections); 
  88175 nanoseconds spent executing 1 partial-flushes (flushing a total of 0 entities and 0 collections) 
} 

正如你所看到的JPQL查詢和對12個選定的Author實體的每一個調(diào)用getBooks方法，導致了13個查詢。這比大多數(shù)開發(fā)人員所以為的還要多，在他們看到如此簡單的代碼片段的時候。

如果你讓Hibernate初始化所需的關(guān)聯(lián)，那么你可以很容易地避免這種情況。有若干不同的方式可以做到這一點。最簡單的方法是添加JOIN FETCH語句到FROM子句中。

Author a = em.createQuery( 
                "SELECT a FROM Author a JOIN FETCH a.books WHERE a.id = 1", 
                Author.class).getSingleResult(); 

錯誤4：選擇比所需的更多記錄

當我告訴你選擇太多的記錄會減慢應(yīng)用程序的速度時，我敢保證你一定不會感到驚訝。但是我仍然經(jīng)常會發(fā)現(xiàn)這個問題，當我在咨詢電話中分析應(yīng)用程序的時候。

其中一個原因可能是JPQL不支持你在SQL查詢中使用OFFSET和LIMIT關(guān)鍵字。這看起來似乎不能限制查詢中檢索到的記錄數(shù)量。但是，你可以做到這一點。你只需要在Query接口上，而不是在JPQL語句中設(shè)置此信息。

我在下面的代碼片段中做到這一點。我首先通過id排序選定的Author實體，然后告訴Hibernate檢索前5個實體。

List<Author> authors = em.createQuery("SELECT a FROM Author a ORDER BY a.id ASC", Author.class) 
                                    .setMaxResults(5) 
                                    .setFirstResult(0) 
                                    .getResultList(); 

錯誤5：不使用綁定參數(shù)

綁定參數(shù)是查詢中的簡單占位符，并提供了許多與性能無關(guān)的好處：

• 它們非常易于使用。
• Hibernate自動執(zhí)行所需的轉(zhuǎn)換。
• Hibernate會自動轉(zhuǎn)義Strings，防止SQL注入漏洞。

而且也可以幫助你實現(xiàn)一個高性能的應(yīng)用程序。

大多數(shù)應(yīng)用程序執(zhí)行大量相同的查詢，只在WHERE子句中使用了一組不同的參數(shù)值。綁定參數(shù)允許Hibernate和數(shù)據(jù)庫識別與優(yōu)化這些查詢。

你可以在JPQL語句中使用命名的綁定參數(shù)。每個命名參數(shù)都以“:”開頭，后面跟它的名字。在查詢中定義了綁定參數(shù)后，你需要調(diào)用Query接口上的setParameter方法來設(shè)置綁定參數(shù)值。

TypedQuery<Author> q = em.createQuery( 
                "SELECT a FROM Author a WHERE a.id = :id", Author.class); 
q.setParameter("id", 1L); 
Author a = q.getSingleResult(); 

錯誤6：執(zhí)行業(yè)務(wù)代碼中的所有邏輯

對于Java開發(fā)人員來說，在業(yè)務(wù)層實現(xiàn)所有的邏輯是自然而然的。我們可以使用我們最熟悉的語言、庫和工具。

但有時候，在數(shù)據(jù)庫中實現(xiàn)操作大量數(shù)據(jù)的邏輯會更好。你可以通過在JPQL或SQL查詢中調(diào)用函數(shù)或者使用存儲過程來完成。

讓我們快速看看如何在JPQL查詢中調(diào)用函數(shù)。如果你想深入探討這個話題，你可以閱讀我關(guān)于存儲過程的文章。

你可以在JPQL查詢中使用標準函數(shù)，就像在SQL查詢中調(diào)用它們一樣。你只需引用該函數(shù)的名稱，后跟一個左括號，一個可選的參數(shù)列表和一個右括號。

Query q = em.createQuery("SELECT a, size(a.books) FROM Author a GROUP BY a.id"); 
List<Object[]> results = q.getResultList(); 

并且，通過JPA的函數(shù)function，你也可以調(diào)用數(shù)據(jù)庫特定的或自定義的數(shù)據(jù)庫函數(shù)。

TypedQuery<Book> q = em.createQuery( 
             "SELECT b FROM Book b WHERE b.id = function('calculate', 1, 2)", 
             Book.class); 
Book b = q.getSingleResult(); 

錯誤7：無理由地調(diào)用flush方法

這是另一個比較普遍的錯誤。開發(fā)人員在持久化一個新實體或更新現(xiàn)有實體后，調(diào)用EntityManager的flush方法時經(jīng)常會出現(xiàn)這個錯誤。這迫使Hibernate對所有被管理的實體執(zhí)行臟檢查，并為所有未決的插入、更新或刪除操作創(chuàng)建和執(zhí)行SQL語句。這會減慢應(yīng)用程序，因為它阻止了Hibernate使用一些內(nèi)部優(yōu)化。

Hibernate將所有被管理的實體存儲在持久性上下文中，并試圖盡可能延遲寫操作的執(zhí)行。這允許Hibernate將同一實體上的多個更新操作合并為一個SQL UPDATE語句，通過JDBC批處理綁定多個相同的SQL語句，并避免執(zhí)行重復的SQL語句，這些SQL語句返回你已在當前Session中使用的實體。

作為一個經(jīng)驗法則，你應(yīng)該避免任何對flush方法的調(diào)用。JPQL批量操作是罕見的例外之一，對此我將在錯誤9中解釋。

錯誤8：使用Hibernate應(yīng)付一切

Hibernate的對象關(guān)系映射和各種性能優(yōu)化使大多數(shù)CRUD用例的實現(xiàn)非常簡單和高效。這使得Hibernate成為許多項目的一個很好的選擇。但這并不意味著Hibernate對于所有的項目都是一個很好的解決方案。

我在我之前的一個帖子和視頻中詳細討論過這個問題。JPA和Hibernate為大多數(shù)創(chuàng)建、讀取或更新一些數(shù)據(jù)庫記錄的標準CRUD用例提供了很好的支持。對于這些用例，對象關(guān)系映射可以大大提升生產(chǎn)力，Hibernate的內(nèi)部優(yōu)化提供了一個很優(yōu)越的性能。

但是，當你需要執(zhí)行非常復雜的查詢、實施分析或報告用例或?qū)Υ罅坑涗泩?zhí)行寫操作時，結(jié)果就不同了。所有這些情況都不適合JPA和Hibernate的查詢能力以及基于實體管理的生命周期。

如果這些用例只占應(yīng)用程序的一小部分，那么你仍然可以使用Hibernate。但總的來說，你應(yīng)該看看其他的框架，比如jOOQ或者Querydsl，它們更接近于SQL，并且可以避免任何對象關(guān)系映射。

錯誤9：逐個更新或刪除巨大的實體列表

在你看著你的Java代碼時，感覺逐個地更新或刪除實體也可以接受。這就是我們對待對象的方式，對吧?

這可能是處理Java對象的標準方法，但如果你需要更新大量的數(shù)據(jù)庫記錄，那么，這就不是一個好方法了。在SQL中，你只需一次定義一個影響多個記錄的UPDATE或DELETE語句。數(shù)據(jù)庫將會非常高效地處理這些操作。

不幸的是，用JPA和Hibernate操作起來則沒有那么容易。每個實體都有自己的生命周期，而你如果要更新或刪除多個實體的話，則首先需要從數(shù)據(jù)庫加載它們。然后在每個實體上執(zhí)行操作，Hibernate將為每個實體生成所需的SQL UPDATE或DELETE語句。因此，Hibernate不會只用1條語句來更新1000條數(shù)據(jù)庫記錄，而是至少會執(zhí)行1001條語句。

很顯然，執(zhí)行1001條語句比僅僅執(zhí)行1條語句需要花費更多的時間。幸運的是，你可以使用JPQL、原生SQL或Criteria查詢對JPA和Hibernate執(zhí)行相同的操作。

但是它有一些你應(yīng)該知道的副作用。在數(shù)據(jù)庫中執(zhí)行更新或刪除操作時，將不使用實體。這提供了更佳的性能，但它同時忽略了實體生命周期，并且Hibernate不能更新任何緩存。

在《How to use native queries to perform bulk updates》一文中對此我有一個詳細的解釋。

簡而言之，在執(zhí)行批量更新之前，你不應(yīng)使用任何生命周期偵聽器以及在EntityManager上調(diào)用flush和clear方法。flush方法將強制Hibernate在clear方法從當前持久化上下文中分離所有實體之前，將所有待處理的更改寫入數(shù)據(jù)庫。

em.flush(); 
em.clear(); 
Query query = em.createQuery("UPDATE Book b SET b.price = b.price*1.1"); 
query.executeUpdate(); 

錯誤10：使用實體進行只讀操作

JPA和Hibernate支持一些不同的projections。如果你想優(yōu)化你的應(yīng)用程序的性能，那么你應(yīng)該使用projections。最明顯的原因是你應(yīng)該只選擇用例中需要的數(shù)據(jù)。

但這不是唯一的原因。正如我在最近的測試中顯示的那樣，即使你讀取了相同的數(shù)據(jù)庫列，DTO projections也比實體快得多。

在SELECT子句中使用構(gòu)造函數(shù)表達式而不是實體只是一個小小的改變。但在我的測試中，DTO projections比實體快40%。當然，兩者比較的數(shù)值取決于你的用例，而且你也不應(yīng)該通過這樣一個簡單而有效的方式來提高性能。

了解如何查找和修復Hibernate性能問題

正如你所看到的，一些小小的問題都可能會減慢你的應(yīng)用程序。但幸運的是，我們可以輕松避免這些問題并構(gòu)建高性能持久層。