溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
你有沒有想過如果你能解決Hibernate問題，那么你的應用程序可以更快？
那么請閱讀這篇文章！
我在很多應用程序中修復過性能問題，其中大部分都是由同樣的錯誤引起的。修復之后，性能變得更溜，而且其中的大部分問題都很簡單。所以，如果你想改進應用程序，那么可能也是小菜一碟。
這里列出了導致Hibernate性能問題的10個最常見的錯誤，以及如何修復它們。
FetchType.EAGER的啟示已經討論了好幾年了，而且有很多文章對它進行了詳細的解釋。我自己也寫了一篇。但不幸的是，它仍然是性能問題最常見的兩個原因之一。
FetchType定義了Hibernate何時初始化關聯。你可以使用@OneToMany，@ManyToOne，@ManyToMany和@OneToOneannotation注釋的fetch屬性進行指定。
@Entity
public class Author{
@ManyToMany(mappedBy="authors", fetch=FetchType.LAZY)
private List<Book> books = new ArrayList<Book>();
...
}當Hibernate加載一個實體的時候，它也會即時加載獲取的關聯。例如，當Hibernate加載Author實體時，它也提取相關的Book實體。這需要對每個Author進行額外的查詢，因此經常需要幾十甚至數百個額外的查詢。
這種方法是非常低效的，因為Hibernate不管你是不是要使用關聯都會這樣做。最好改用FetchType.LAZY代替。它會延遲關系的初始化，直到在業務代碼中使用它。這可以避免大量不必要的查詢，并提高應用程序的性能。
幸運的是，JPA規范將FetchType.LAZY定義為所有對多關聯的默認值。所以，你只需要確保你不改變這個默認值即可。但不幸的是，一對一關系并非如此。
接下來，為了防止立即抓取（eager fetching），你需要做的是對所有的一對一關聯更改默認的FetchType。不幸的是，這些關系在默認情況下會被即時抓取。在一些用例中，那并非一個大問題，因為你只是加載了一個額外的數據庫記錄。但是，如果你加載多個實體，并且每個實體都指定了幾個這樣的關聯，那么很快就會積少成多，水滴石穿。
所以，最好確保所有的一對一關聯設置FetchType為LAZY。
@Entity
public class Review {
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "fk_book")
private Book book;
...
}當你對所有關聯使用FetchType.LAZY以避免錯誤1和錯誤2時，你會在代碼中發現若干n+1選擇問題。當Hibernate執行1個查詢來選擇n個實體，然后必須為每個實體執行一個額外的查詢來初始化一個延遲的獲取關聯時，就會發生這個問題。
Hibernate透明地獲取惰性關系，因此在代碼中很難找到這種問題。你只要調用關聯的getter方法，我想我們大家都不希望Hibernate執行任何額外的查詢吧。
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.");
}如果你使用開發配置激活Hibernate的統計組件并監視已執行的SQL語句的數量，n+1選擇問題就會更容易被發現。
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實體的每一個調用getBooks方法，導致了13個查詢。這比大多數開發人員所以為的還要多，在他們看到如此簡單的代碼片段的時候。
如果你讓Hibernate初始化所需的關聯，那么你可以很容易地避免這種情況。有若干不同的方式可以做到這一點。最簡單的方法是添加JOIN FETCH語句到FROM子句中。
Author a = em.createQuery(
"SELECT a FROM Author a JOIN FETCH a.books WHERE a.id = 1",
Author.class).getSingleResult();當我告訴你選擇太多的記錄會減慢應用程序的速度時，我敢保證你一定不會感到驚訝。但是我仍然經常會發現這個問題，當我在咨詢電話中分析應用程序的時候。
其中一個原因可能是JPQL不支持你在SQL查詢中使用OFFSET和LIMIT關鍵字。這看起來似乎不能限制查詢中檢索到的記錄數量。但是，你可以做到這一點。你只需要在Query接口上，而不是在JPQL語句中設置此信息。
我在下面的代碼片段中做到這一點。我首先通過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();綁定參數是查詢中的簡單占位符，并提供了許多與性能無關的好處：
而且也可以幫助你實現一個高性能的應用程序。
大多數應用程序執行大量相同的查詢，只在WHERE子句中使用了一組不同的參數值。綁定參數允許Hibernate和數據庫識別與優化這些查詢。
你可以在JPQL語句中使用命名的綁定參數。每個命名參數都以“:”開頭，后面跟它的名字。在查詢中定義了綁定參數后，你需要調用Query接口上的setParameter方法來設置綁定參數值。
TypedQuery<Author> q = em.createQuery(
"SELECT a FROM Author a WHERE a.id = :id", Author.class);
q.setParameter("id", 1L);
Author a = q.getSingleResult();對于Java開發人員來說，在業務層實現所有的邏輯是自然而然的。我們可以使用我們最熟悉的語言、庫和工具。
但有時候，在數據庫中實現操作大量數據的邏輯會更好。你可以通過在JPQL或SQL查詢中調用函數或者使用存儲過程來完成。
讓我們快速看看如何在JPQL查詢中調用函數。如果你想深入探討這個話題，你可以閱讀我關于存儲過程的文章。
你可以在JPQL查詢中使用標準函數，就像在SQL查詢中調用它們一樣。你只需引用該函數的名稱，后跟一個左括號，一個可選的參數列表和一個右括號。
Query q = em.createQuery("SELECT a, size(a.books) FROM Author a GROUP BY a.id");
List<Object[]> results = q.getResultList();并且，通過JPA的函數function，你也可以調用數據庫特定的或自定義的數據庫函數。
TypedQuery<Book> q = em.createQuery(
"SELECT b FROM Book b WHERE b.id = function('calculate', 1, 2)",
Book.class);
Book b = q.getSingleResult();這是另一個比較普遍的錯誤。開發人員在持久化一個新實體或更新現有實體后，調用EntityManager的flush方法時經常會出現這個錯誤。這迫使Hibernate對所有被管理的實體執行臟檢查，并為所有未決的插入、更新或刪除操作創建和執行SQL語句。這會減慢應用程序，因為它阻止了Hibernate使用一些內部優化。
Hibernate將所有被管理的實體存儲在持久性上下文中，并試圖盡可能延遲寫操作的執行。這允許Hibernate將同一實體上的多個更新操作合并為一個SQL UPDATE語句，通過JDBC批處理綁定多個相同的SQL語句，并避免執行重復的SQL語句，這些SQL語句返回你已在當前Session中使用的實體。
作為一個經驗法則，你應該避免任何對flush方法的調用。JPQL批量操作是罕見的例外之一，對此我將在錯誤9中解釋。
Hibernate的對象關系映射和各種性能優化使大多數CRUD用例的實現非常簡單和高效。這使得Hibernate成為許多項目的一個很好的選擇。但這并不意味著Hibernate對于所有的項目都是一個很好的解決方案。
我在我之前的一個帖子和視頻中詳細討論過這個問題。JPA和Hibernate為大多數創建、讀取或更新一些數據庫記錄的標準CRUD用例提供了很好的支持。對于這些用例，對象關系映射可以大大提升生產力，Hibernate的內部優化提供了一個很優越的性能。
但是，當你需要執行非常復雜的查詢、實施分析或報告用例或對大量記錄執行寫操作時，結果就不同了。所有這些情況都不適合JPA和Hibernate的查詢能力以及基于實體管理的生命周期。
如果這些用例只占應用程序的一小部分，那么你仍然可以使用Hibernate。但總的來說，你應該看看其他的框架，比如jOOQ或者Querydsl，它們更接近于SQL，并且可以避免任何對象關系映射。
在你看著你的Java代碼時，感覺逐個地更新或刪除實體也可以接受。這就是我們對待對象的方式，對吧？
這可能是處理Java對象的標準方法，但如果你需要更新大量的數據庫記錄，那么，這就不是一個好方法了。在SQL中，你只需一次定義一個影響多個記錄的UPDATE或DELETE語句。數據庫將會非常高效地處理這些操作。
不幸的是，用JPA和Hibernate操作起來則沒有那么容易。每個實體都有自己的生命周期，而你如果要更新或刪除多個實體的話，則首先需要從數據庫加載它們。然后在每個實體上執行操作，Hibernate將為每個實體生成所需的SQL UPDATE或DELETE語句。因此，Hibernate不會只用1條語句來更新1000條數據庫記錄，而是至少會執行1001條語句。
很顯然，執行1001條語句比僅僅執行1條語句需要花費更多的時間。幸運的是，你可以使用JPQL、原生SQL或Criteria查詢對JPA和Hibernate執行相同的操作。
但是它有一些你應該知道的副作用。在數據庫中執行更新或刪除操作時，將不使用實體。這提供了更佳的性能，但它同時忽略了實體生命周期，并且Hibernate不能更新任何緩存。
簡而言之，在執行批量更新之前，你不應使用任何生命周期偵聽器以及在EntityManager上調用flush和clear方法。flush方法將強制Hibernate在clear方法從當前持久化上下文中分離所有實體之前，將所有待處理的更改寫入數據庫。
em.flush();
em.clear();
Query query = em.createQuery("UPDATE Book b SET b.price = b.price*1.1");
query.executeUpdate();JPA和Hibernate支持一些不同的projections。如果你想優化你的應用程序的性能，那么你應該使用projections。最明顯的原因是你應該只選擇用例中需要的數據。
但這不是唯一的原因。正如我在最近的測試中顯示的那樣，即使你讀取了相同的數據庫列，DTO projections也比實體快得多。
在SELECT子句中使用構造函數表達式而不是實體只是一個小小的改變。但在我的測試中，DTO projections比實體快40％。當然，兩者比較的數值取決于你的用例，而且你也不應該通過這樣一個簡單而有效的方式來提高性能。
正如你所看到的，一些小小的問題都可能會減慢你的應用程序。但幸運的是，我們可以輕松避免這些問題并構建高性能持久層。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
