Spring/Hibernate 應用性能優化的7種方法

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

如何確認應用是否受限于數據庫

確認應用是否受限于數據庫的第一步，是在開發環境中進行測試，并使用 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 日志與查詢時間

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 日志可以了解哪些指標？

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

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

• 哪些是最常用的查詢？

• 生成主鍵的耗時是多少？

• 是否有數據適合緩存？

如何解析 SQL 日志

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

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

常用的速成法

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

速成法1——減少生成主鍵的代價

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

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

Hibernate 通常如何解決此問題？

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%的性能提升，而且幾乎沒有改動代碼。

速成法2——使用 JDBC 批處理 inserts/updates

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

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

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

<prop key="hibernate.jdbc.batch_size">100</prop>

<prop key="hibernate.order_inserts">true</prop>

<prop key="hibernate.order_updates">true</prop>

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

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

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

速成法3——定期清理 Hibernate 會話

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

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

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

entityManager.flush();

entityManager.clear();

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

速成法4——減少 Hibernate dirty-checking(臟數據檢查) 的代價

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

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

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

如何避免 dirty-checking ？

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

@Transactional(readOnly=true)

public void someBusinessMethod() {

....

}

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

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

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

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

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

速成法6——檢查錯誤的提交間隔

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

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

速成法7—— 使用二級查詢緩存

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

結論

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

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

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

 

 

來自：https://mp.weixin.qq.com/s?__biz=MzAwNjA3NDMyOA==&mid=2659763070&idx=5&sn=3d2698a02ece4e3c8f647f7935aadaa4&chksm=806e99c9b71910df582ec729f4a74f641edc761fb3040b09a1c0c7e47dc9e7c683e303ca608e&scene=0&key=&ascene=7&uin=&devicetype=android-23&version=26031b31&nettype=WIFI