摘要：對于大多數(shù)典型的企業(yè)應(yīng)用而言，其性能表現(xiàn)幾乎完全依賴于持久層的性能。速成法使用批處理對于批處理程序，驅(qū)動程序提供了旨在減少網(wǎng)絡(luò)來回傳輸?shù)膬?yōu)化方法。速成法檢查錯誤的提交間隔如果你使用批處理程序，提交間隔會對性能造成十倍甚至百倍的影響。

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

確認(rèn)應(yīng)用是否受限于數(shù)據(jù)庫的第一步，是在開發(fā)環(huán)境中進(jìn)行測試，并使用 VisualVM 進(jìn)行監(jiān)控。VisualVM 是一款包含在 JDK 中的 Java 分析器，在命令行輸入 jvisualvm 即可調(diào)用。

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

雙擊你正在運(yùn)行的應(yīng)用

選擇 Sampler

點(diǎn)擊 Settings 復(fù)選框

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

your.application.packages.*

org.hibernate.*

org.springframework.*

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

點(diǎn)擊 Sample CPU

如果應(yīng)用性能受限于數(shù)據(jù)庫，其 CPU 分析結(jié)果看起來會像下圖：

我們看到，客戶端 Java 進(jìn)程花在等待數(shù)據(jù)庫從網(wǎng)絡(luò)中返回結(jié)果的時(shí)間占56%。

看到數(shù)據(jù)庫查詢是導(dǎo)致應(yīng)用運(yùn)行緩慢的原因，其實(shí)是好兆頭。Hibernate 反射調(diào)用占比32.7%是正常情況，無法進(jìn)一步優(yōu)化。

性能調(diào)優(yōu)的第一步是為程序定義基準(zhǔn)運(yùn)行，我們要定義一組能有效執(zhí)行的輸入數(shù)據(jù)，讓程序基準(zhǔn)運(yùn)行與生產(chǎn)環(huán)境下的運(yùn)行差不多。

主要的區(qū)別在于基準(zhǔn)運(yùn)行的耗時(shí)要小很多。作為參考，5到10分鐘的執(zhí)行時(shí)間比較不錯。

好的基準(zhǔn)應(yīng)該具備以下特征：

功能正確

輸入數(shù)據(jù)的種類與生產(chǎn)環(huán)境下相似

在短時(shí)間內(nèi)執(zhí)行完畢

基準(zhǔn)運(yùn)行的優(yōu)化方案可以外推至完整運(yùn)行

定義好的基準(zhǔn)是成功解決問題的一半。

例如，通過批量運(yùn)行處理通訊系統(tǒng)的電話數(shù)據(jù)記錄，選取10000條記錄就是錯誤的做法。

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

SQL 查詢的執(zhí)行語句與其執(zhí)行時(shí)間可以通過 log4jdbc等方式收集。詳細(xì)了解如何使用 log4jdbc 收集 SQL 查詢信息，點(diǎn)擊文章 使用 log4jdbc 優(yōu)化 Spring/Hibernate 應(yīng)用 SQL 日志。

查詢的執(zhí)行時(shí)間是從 Java 客戶端收集的，該時(shí)間包含查詢數(shù)據(jù)庫的來回網(wǎng)絡(luò)調(diào)用。SQL 查詢的日志如下：

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

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

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

哪些是執(zhí)行過的最慢查詢？

哪些是最常用的查詢？

生成主鍵的耗時(shí)是多少？

是否有數(shù)據(jù)適合緩存？

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

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

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

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

問題在于，如果要插入50條記錄，我們希望為了獲取這50個(gè) id，可以避免50趟查詢數(shù)據(jù)庫的來回網(wǎng)絡(luò)調(diào)用，讓 Java 進(jìn)程不一直等待。

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

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

用以下方式計(jì)算50個(gè) id

1000 * 50 + 0 = 50000

1000 * 50 + 1 = 50001

...

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

為新的高值1001調(diào)用序列，依次類推

因此一次序列調(diào)用，可生成50個(gè)鍵，從而減少數(shù)次來回網(wǎng)絡(luò)調(diào)用導(dǎo)致的負(fù)擔(dān)。

這些優(yōu)化的鍵生成器默認(rèn)在 Hibernate 4中開啟。如要禁用，可將 hibernate.id.new_generator_mappings 設(shè)置為 false。

問題在于，如果你聲明鍵生成策略為 AUTO，且未啟用優(yōu)化的鍵生成器，那么應(yīng)用最后會面臨大量的序列調(diào)用。

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

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

改變設(shè)定之后，在插入操作頻繁的應(yīng)用中能看到10%到20%的性能提升，而且?guī)缀鯖]有改動代碼。

對于批處理程序，JDBC 驅(qū)動程序提供了旨在減少網(wǎng)絡(luò)來回傳輸?shù)膬?yōu)化方法：”JDBC batch inserts/updates“。使用該方法后，插入或更新會先在驅(qū)動層排隊(duì)，然后再傳送到數(shù)據(jù)庫。

當(dāng)達(dá)到閾值后，所有排隊(duì)的語句都會一次性傳給數(shù)據(jù)庫。這可以避免驅(qū)動程序逐一傳送語句，導(dǎo)致網(wǎng)絡(luò)來回傳送的負(fù)擔(dān)。

經(jīng)過以下配置，就能激活批處理 inserts/updates：

100  
true  
true  

僅設(shè)置 JDBC 批處理大小并不夠。因?yàn)?JDBC 驅(qū)動程序只會在收到對同一張表 insert/updates 時(shí)批處理這些語句。

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

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

在向數(shù)據(jù)庫添加或修改數(shù)據(jù)時(shí)，Hibernate 會在會話中保留一版已經(jīng)存在的實(shí)體，以防在會話關(guān)閉之前這些實(shí)體再度被修改。

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

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

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

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

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

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

在進(jìn)行任何優(yōu)化之前，最重要的是使用 VisualVM 測量 dirty-checking 的成本。

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

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

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

速成法5——搜索”壞“查詢計(jì)劃

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

全表搜索：通常缺少一個(gè)索引或表統(tǒng)計(jì)過期時(shí)進(jìn)行全表搜索。

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

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

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

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

解決應(yīng)用性能問題的關(guān)鍵，在于通過收集一些指標(biāo)發(fā)現(xiàn)當(dāng)前的瓶頸。

沒有一些測量指標(biāo)，往往無法在短時(shí)間內(nèi)找到真正的問題根源。

此外，很多典型的數(shù)據(jù)庫驅(qū)動應(yīng)用的性能陷阱，如果一開始就使用了 Spring Batch，就能夠避免。

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

OneAPM for Java 能夠深入到所有 Java 應(yīng)用內(nèi)部完成應(yīng)用性能管理和監(jiān)控，包括代碼級別性能問題的可見性、性能瓶頸的快速識別與追溯、真實(shí)用戶體驗(yàn)監(jiān)控、服務(wù)器監(jiān)控和端到端的應(yīng)用性能管理。想閱讀更多技術(shù)文章，請?jiān)L問 OneAPM 官方博客