摘要：對于大多數典型的企業應用而言，其性能表現幾乎完全依賴于持久層的性能。速成法使用批處理對于批處理程序，驅動程序提供了旨在減少網絡來回傳輸的優化方法。速成法檢查錯誤的提交間隔如果你使用批處理程序，提交間隔會對性能造成十倍甚至百倍的影響。

對于大多數典型的 Spring/Hibernate 企業應用而言，其性能表現幾乎完全依賴于持久層的性能。此篇文章中將介紹如何確認應用是否受數據庫約束，同時介紹七種常用的提高應用性能的速成法。本文系 OneAPM 工程師編譯整理。

確認應用是否受限于數據庫的第一步，是在開發環境中進行測試，并使用 VisualVM 進行監控。VisualVM 是一款包含在 JDK 中的 Java 分析器，在命令行輸入 jvisualvm 即可調用。

啟用 Visual VM 之后，嘗試以下步驟：

雙擊你正在運行的應用

選擇 Sampler

點擊 Settings 復選框

選擇Profile only packages，然后輸入下列包：

your.application.packages.*

org.hibernate.*

org.springframework.*

your.database.driver.package, 比如 oracle.*

點擊 Sample CPU

如果應用性能受限于數據庫，其 CPU 分析結果看起來會像下圖：

我們看到，客戶端 Java 進程花在等待數據庫從網絡中返回結果的時間占56%。

看到數據庫查詢是導致應用運行緩慢的原因，其實是好兆頭。Hibernate 反射調用占比32.7%是正常情況，無法進一步優化。

性能調優的第一步是為程序定義基準運行，我們要定義一組能有效執行的輸入數據，讓程序基準運行與生產環境下的運行差不多。

主要的區別在于基準運行的耗時要小很多。作為參考，5到10分鐘的執行時間比較不錯。

好的基準應該具備以下特征：

功能正確

輸入數據的種類與生產環境下相似

在短時間內執行完畢

基準運行的優化方案可以外推至完整運行

定義好的基準是成功解決問題的一半。

例如，通過批量運行處理通訊系統的電話數據記錄，選取10000條記錄就是錯誤的做法。

原因是：前10000條記錄可能多為語音電話，而未知的性能問題可能發生在短信流量的處理過程中。一開始如果基準不夠好，就會導致錯誤的結論。

SQL 查詢的執行語句與其執行時間可以通過 log4jdbc等方式收集。詳細了解如何使用 log4jdbc 收集 SQL 查詢信息，點擊文章 使用 log4jdbc 優化 Spring/Hibernate 應用 SQL 日志。

查詢的執行時間是從 Java 客戶端收集的，該時間包含查詢數據庫的來回網絡調用。SQL 查詢的日志如下：

16 avr. 2014 11:13:48 | SQL_QUERY /* insert your.package.YourEntity */ insert into YOUR_TABLE (...) values (...) {executed in 13 msec}

預處理語句也是很重要的信息來源，它們常常會透露出常用的查詢類型。了解更多的日志訊息，可以查看文章：Hibernate 為什么/在何處使用該 SQL 查詢？

SQL 日志可以回答下列問題：

哪些是執行過的最慢查詢？

哪些是最常用的查詢？

生成主鍵的耗時是多少？

是否有數據適合緩存？

對于大量的日志文件，最可行的解析方式就是使用命令行工具，該方法的好處是非常靈活，只要寫一小段腳本或命令，我們可以抽取出幾乎大多數指標。只要你喜歡，任何命令行工具都適用。

如何你習慣了 Unix 命令行，bash 或是一個好選擇。Bash 也可以在 Windows 工作站使用，Cygwin 或 Git 都包含了 bash 命令行。

下面介紹的速成法能找出 Spring/Hibernate 應用中常見的性能問題，以及對應的解決方案。

在插入操作頻繁的進程中，主鍵的生成策略很重要。生成 id 的一種常見方法是使用數據庫序列，通常一張表一個 id，從而避免在不同表間進行插入時的沖突。

問題在于，如果要插入50條記錄，我們希望為了獲取這50個 id，可以避免50趟查詢數據庫的來回網絡調用，讓 Java 進程不一直等待。

Hibernate 提供了優化的 ID 生成器以避免此問題。也即，對于序列，會默認使用 HiLo id 生成器。以下是 HiLo 序列生成器的工作方式：

調用一次序列，獲得 1000 (高值)

用以下方式計算50個 id

1000 * 50 + 0 = 50000

1000 * 50 + 1 = 50001

...

1000 * 50 + 49 = 50049, 達到低值 (50)

為新的高值1001調用序列，依次類推

因此一次序列調用，可生成50個鍵，從而減少數次來回網絡調用導致的負擔。

這些優化的鍵生成器默認在 Hibernate 4中開啟。如要禁用，可將 hibernate.id.new_generator_mappings 設置為 false。

問題在于，如果你聲明鍵生成策略為 AUTO，且未啟用優化的鍵生成器，那么應用最后會面臨大量的序列調用。

為了確保啟用優化的鍵生成器，請將鍵生成策略改為 SEQUENCE 而非 AUTO。

@Id
@GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "your_key_generator")
private Long id;

改變設定之后，在插入操作頻繁的應用中能看到10%到20%的性能提升，而且幾乎沒有改動代碼。

對于批處理程序，JDBC 驅動程序提供了旨在減少網絡來回傳輸的優化方法：”JDBC batch inserts/updates“。使用該方法后，插入或更新會先在驅動層排隊，然后再傳送到數據庫。

當達到閾值后，所有排隊的語句都會一次性傳給數據庫。這可以避免驅動程序逐一傳送語句，導致網絡來回傳送的負擔。

經過以下配置，就能激活批處理 inserts/updates：

100  
true  
true  

僅設置 JDBC 批處理大小并不夠。因為 JDBC 驅動程序只會在收到對同一張表 insert/updates 時批處理這些語句。

如果收到對一張新表的插入語句，JDBC 驅動程序會先清除對前一張表的批處理語句，然后開始分批處理針對新表的 SQL 語句。

Spring Batch 內置了相似的功能。該優化能在插入操作頻繁的應用中帶來30%到40%的性能提升，而不用改動任何代碼行。

在向數據庫添加或修改數據時，Hibernate 會在會話中保留一版已經存在的實體，以防在會話關閉之前這些實體再度被修改。

但是，多數情況下，一旦對應的插入操作已經在數據庫中完成，我們就可以安心地丟棄那些實體。這會釋放 Java 客戶端進程中的內存，避免過久的 Hibernate 會話導致的性能問題。

這種長久的會話應該盡量避免。但如果出于某種原因不得不使用它們，以下是控制內存消耗的方法：

entityManager.flush();
entityManager.clear();

flush 會觸使新實體中的插入語句傳送至數據庫。clear 則會釋放會話中的新實體。

Hibernate 內部使用了一種機制用于追蹤被修改的實體，名為 dirty-checking。該機制并不基于實體類中的 equals 和 hashcode 方法。

Hibernate 盡可能將 dirty-checking 的性能成本保持在最低值，只在需要時使用 dirty-check。但是該機制也有成本，在列數很多的表中該成本尤其可觀。

在進行任何優化之前，最重要的是使用 VisualVM 測量 dirty-checking 的成本。

dirty-checking 可以通過以下方式禁用：

@Transactional(readOnly=true)
public void someBusinessMethod() {
....
}

禁用 dirty-checking 的另一種方式是使用 Hibernate 無狀態會話，預知詳情請查看文檔。

速成法5——搜索”壞“查詢計劃

檢查最慢查詢列表，看看有沒有好的查詢計劃。最常見的”壞“查詢計劃包括：

全表搜索：通常缺少一個索引或表統計過期時進行全表搜索。

全笛卡爾連接：意思是計算多張表的全笛卡爾乘積。檢查一下缺少的連接條件，或拆分為幾個步驟以簡化查詢。

如果你使用批處理程序，提交間隔會對性能造成十倍甚至百倍的影響。

請確保提交間隔是符合預期的（對于 Spring 批任務，通常是100到1000之間）。經常，該參數的配置不正確。

如果一些數據可以緩存，則可以查看本文了解如何設置 Hibernate 緩存：Hibernate 二級/查詢緩存的陷阱。

解決應用性能問題的關鍵，在于通過收集一些指標發現當前的瓶頸。

沒有一些測量指標，往往無法在短時間內找到真正的問題根源。

此外，很多典型的數據庫驅動應用的性能陷阱，如果一開始就使用了 Spring Batch，就能夠避免。

原文地址：http://blog.jhades.org/performance-tuning-of-spring-hibernate-applications/

OneAPM for Java 能夠深入到所有 Java 應用內部完成應用性能管理和監控，包括代碼級別性能問題的可見性、性能瓶頸的快速識別與追溯、真實用戶體驗監控、服務器監控和端到端的應用性能管理。想閱讀更多技術文章，請訪問 OneAPM 官方博客