教你如何优化Spring/Hibernate应用性能

admin

对于大多数典型的 spring/hibernate 企业应用而言，其性能表现几乎完全依赖于持久层的性能。此篇文章中将介绍如何确认应用是否受数据库约束，同时介绍七种常用的提高应用性能的速成法。本文系 OneAPM 工程师翻译整理。
, X9 N2 ?2 L3 v+ v
/ m: n) L" }3 r2 m3 C0 L. ?* `
如何确认应用是否受限于数据库
  c2 U& a5 Z8 L; y7 C6 F( g0 ~确认应用是否受限于数据库的第一步，是在开发环境中进行测试，并使用 VisualVM 进行监控。VisualVM 是一款包含在 JDK 中的 java 分析器，在命令行输入 jvisualvm 即可调用。
- e7 J5 ~* {& F; P5 W7 [
" |* x( k1 W, o+ W6 ^3 n" m  K7 q
6 L  ]* X1 R4 g, t$ j8 J( u启用 Visual VM 之后，尝试以下步骤：


2 i; W% f; I/ ]0 a! Y) N8 c: ]1.双击你正在运行的应用
. O* F( A; ~/ P& ^2.选择 Sampler
3 r9 k2 J/ l( V: k) s; ]1 m3.点击 Settings 复选框
, d" V: \( l4 p  [( {4.选择Profile only packages，然后输入下列包：
' Y! A. ~. |: V1 Q. g$ dyour.application.packages.*

2 v% ^/ _* p, W, z' ?
org.hibernate.*
2 C. x4 V8 m, @, J# F+ q

; Z( M2 b; z) n! h: qorg.springframework.*


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

' d* ^! v+ \0 d% P
点击 Sample CPU

3 J" U! _- V" D+ Q% C) I
" y  X9 |/ z, |如果应用性能受限于数据库，其 CPU 分析结果会非常恐怖

0 p% ?8 r0 g' v
Spring/Hibernate 应用性能优化
0 _- C" e2 L5 L# r/ M2 Q

4 b$ D; I4 x  ^# G' X我们看到，客户端 Java 进程花在等待数据库从网络中返回结果的时间占56%。
+ c. p  |+ k, R9 f- A
( N. t( [+ H8 T6 C) m
看到数据库查询是导致应用运行缓慢的原因，其实是好兆头。Hibernate 反射调用占比32.7%是正常情况，无法进一步优化。

+ k+ X* x3 U9 R$ G7 q9 u" k: `7 k
- x6 |0 X1 ~( V8 B7 o# i) N+ f性能调优第一步：定义基准运行
# C7 Z- s, m6 G1 [5 ]% t4 k0 m. {性能调优的第一步是为程序定义基准运行，我们要定义一组能有效执行的输入数据，让程序基准运行与生产环境下的运行差不多。


主要的区别在于基准运行的耗时要小很多。作为参考，5到10分钟的执行时间比较不错。

/ ^2 X7 F# q/ Z0 ^6 L
2 N9 y1 n! ~0 b- E3 h什么是好的基准？
好的基准应该具备以下特征：

• 功能正确
• 输入数据的种类与生产环境下相似
• 在短时间内执行完毕
• 基准运行的优化方案可以外推至完整运行
  / ?* }, K, n2 Q% o

/ ~% A9 m5 a9 ~5 K/ l4 r0 \% e定义好的基准是成功解决问题的一半。
7 _1 w( n$ w; j( ^5 w9 r$ ~- j
# [4 m# r3 K4 `) z: p/ Z
什么是不好的基准
例如，通过批量运行处理通讯系统的电话数据记录，选取10000条记录就是错误的做法。

7 M5 Q1 Q% x# ^6 e1 `( U1 q* _
4 k) C* H1 |- y  U0 m* K原因是：前10000条记录可能多为语音电话，而未知的性能问题可能发生在短信流量的处理过程中。一开始如果基准不够好，就会导致错误的结论。

4 w: D4 O9 |6 x) q4 ?% J- m
收集 SQL 日志与查询时间
! S' @8 c8 n1 A" C3 i- tSQL 查询的执行语句与其执行时间可以通过 log4jdbc等方式收集。详细了解如何使用 log4jdbc 收集 SQL 查询信息，点击文章 使用 log4jdbc 优化 Spring/Hibernate 应用 SQL 日志。


# o: y$ X& x* |" ^( k! |. P查询的执行时间是从 Java 客户端收集的，该时间包含查询数据库的来回网络调用。SQL 查询的日志如下：


: L! Q' D9 r7 C16 avr. 2014 11:13:48 | SQL_QUERY /* insert your.package.YourEntity */ insert into YOUR_TABLE (...) values (...) {executed in 13 msec}
预处理语句也是很重要的信息来源，它们常常会透露出常用的查询类型。了解更多的日志讯息，可以查看文章：Hibernate 为什么/在何处使用该 SQL 查询？

& }$ D1 o+ q* Z+ c
8 F: g3 ]' j" k5 l+ l, X通过 SQL 日志可以了解哪些指标？
SQL 日志可以回答下列问题：

• 哪些是执行过的最慢查询？
• 哪些是最常用的查询？
• 生成主键的耗时是多少？
• 是否有数据适合缓存？
  

8 Y- y8 O* X% u) M; L如何解析 SQL 日志
对于大量的日志文件，最可行的解析方式就是使用命令行工具，该方法的好处是非常灵活，只要写一小段脚本或命令，我们可以抽取出几乎大多数指标。只要你喜欢，任何命令行工具都适用。


如何你习惯了 Unix 命令行，bash 或是一个好选择。Bash 也可以在 Windows 工作站使用，Cygwin 或 Git 都包含了 bash 命令行。
6 K' D& d9 v$ V2 n! W/ e

常用的速成法
& k; T% L# v7 O" X下面介绍的速成法能找出 Spring/Hibernate 应用中常见的性能问题，以及对应的解决方案。

. ~$ `$ Q* a6 H
速成法1——减少生成主键的代价
在插入操作频繁的进程中，主键的生成策略很重要。生成 id 的一种常见方法是使用数据库序列，通常一张表一个 id，从而避免在不同表间进行插入时的冲突。


: C7 U! T0 h# n8 i$ X7 ~  ]7 _( k8 P问题在于，如果要插入50条记录，我们希望为了获取这50个 id，可以避免50趟查询数据库的来回网络调用，让 Java 进程不一直等待。

+ v: B( c: A% K/ C  w/ A( N  n" R
Hibernate 通常如何解决此问题？
Hibernate 提供了优化的 ID 生成器以避免此问题。也即，对于序列，会默认使用 HiLo id 生成器。以下是 HiLo 序列生成器的工作方式：
/ ~  [( O$ X% O$ i$ F' `& w
( A! q" C& K& I6 ?0 {+ S' b

• 调用一次序列，获得 1000 (高值)
• 用以下方式计算50个 id
  

# q1 ?) W  f2 I. m" A6 d1000 * 50 + 0 = 50000


1000 * 50 + 1 = 50001

: k- l0 R, G1 A, U
2 ^8 b. |% G* v9 X! D; t...
4 a& M8 z/ R) g' K- K

- `* s% }7 N( e1000 * 50 + 49 = 50049, 达到低值 (50)


为新的高值1001调用序列，依次类推


6 m" I0 {8 c, o  e因此一次序列调用，可生成50个键，从而减少数次来回网络调用导致的负担。


这些优化的键生成器默认在 Hibernate 4中开启。如要禁用，可将 hibernate.id.new_generator_mappings 设置为 false。
' V0 `5 `' u0 n

: L$ H, e! E+ d+ V: m; M! `为什么生成主键仍是一个问题？
  o1 a5 j# ]( |问题在于，如果你声明键生成策略为 AUTO，且未启用优化的键生成器，那么应用最后会面临大量的序列调用。
! E9 O$ E2 \  c& T
' }( s% \$ G% Z- U- F
为了确保启用优化的键生成器，请将键生成策略改为 SEQUENCE 而非 AUTO。

$ o% a0 [6 o$ o8 E
9 e% ?& u& T) Z4 ^@Id
3 @' T- o, Y8 U/ x@GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "your_key_generator")
private Long id;
改变设定之后，在插入操作频繁的应用中能看到10%到20%的性能提升，而且几乎没有改动代码。


: _6 b7 f- L( B  Q5 B, [+ F( ?速成法2——使用 JDBC 批处理 inserts/updates
! U2 r# e" V7 D对于批处理程序，JDBC 驱动程序提供了旨在减少网络来回传输的优化方法：”JDBC batch inserts/updates“。使用该方法后，插入或更新会先在驱动层排队，然后再传送到数据库。
" x4 N  y. l4 F1 ^$ ~, V+ Y$ l4 ?7 x9 z
. _3 Q; f. n- ]
: V: Z" d- J9 g当达到阈值后，所有排队的语句都会一次性传给数据库。这可以避免驱动程序逐一传送语句，导致网络来回传送的负担。


2 p9 c6 z  e; ~$ O& Y+ a经过以下配置，就能激活批处理 inserts/updates：


<prop key="hibernate.jdbc.batch_size">100</prop>  
! h. k) Y  N- g<prop key="hibernate.order_inserts">true</prop>  
0 M% J6 o2 ~4 o" b<prop key="hibernate.order_updates">true</prop>  
3 g2 G+ Z% z+ Q仅设置 JDBC 批处理大小并不够。因为 JDBC 驱动程序只会在收到对同一张表 insert/updates 时批处理这些语句。

4 Z* w& y) p. g; L7 Y! |* d
: A5 @: z: ?% B2 T1 s. v1 k& V如果收到对一张新表的插入语句，JDBC 驱动程序会先清除对前一张表的批处理语句，然后开始分批处理针对新表的 SQL 语句。
' K9 ]7 z$ t8 c2 _- O

Spring Batch 内置了相似的功能。该优化能在插入操作频繁的应用中带来30%到40%的性能提升，而不用改动任何代码行。
* S# k( _. i% |* M" d
  U+ i" c3 A$ f  m
& w) v* \& M" R+ s9 b; o. e速成法3——定期清理 Hibernate 会话
在向数据库添加或修改数据时，Hibernate 会在会话中保留一版已经存在的实体，以防在会话关闭之前这些实体再度被修改。
! ~- Y! U0 e& l, G* u9 N9 u
' ^) c5 K, w$ T8 L' L- N5 R. E
3 ]& D5 E; M7 Q但是，多数情况下，一旦对应的插入操作已经在数据库中完成，我们就可以安心地丢弃那些实体。这会释放 Java 客户端进程中的内存，避免过久的 Hibernate 会话导致的性能问题。

# i+ O9 R  u; Q8 g: u& K
这种长久的会话应该尽量避免。但如果出于某种原因不得不使用它们，以下是控制内存消耗的方法：
1 [! i4 G3 T9 p( X/ H
/ F/ J: Z6 D* |5 p
entityManager.flush();
# p; n- M* _. Z% u0 ]4 NentityManager.clear();
flush 会触使新实体中的插入语句传送至数据库。clear 则会释放会话中的新实体。
9 Z: q  C5 g0 q6 A

, i/ \, y+ w  H. }速成法4——减少 Hibernate dirty-checking(脏数据检查) 的代价
" f! n; l4 V/ G, T; v+ [2 hHibernate 内部使用了一种机制用于追踪被修改的实体，名为 dirty-checking。该机制并不基于实体类中的 equals 和 hashcode 方法。


7 ?1 _( T$ ~7 N+ P1 P  v8 W! XHibernate 尽可能将 dirty-checking 的性能成本保持在最低值，只在需要时使用 dirty-check。但是该机制也有成本，在列数很多的表中该成本尤其可观。


+ i/ @8 W3 J! l% M在进行任何优化之前，最重要的是使用 VisualVM 测量 dirty-checking 的成本。
: p5 d; I- J! L" B0 z7 v

如何避免 dirty-checking ？
dirty-checking 可以通过以下方式禁用：
. w6 q! x$ C- y) i5 V

! D+ z% x. x" z) a7 B@Transactional(readOnly=true)
0 b+ X3 Z* a3 p; t: |0 npublic void someBusinessMethod() {
' r% W6 u2 g9 X. t" @4 N  p, L* r....
6 s/ A$ W) |, ?3 ?. o  R}
禁用 dirty-checking 的另一种方式是使用 Hibernate 无状态会话，预知详情请查看文档。


) D& w; p& g; J速成法5——搜索”坏“查询计划

- \, u9 D  V  ?, Z( ~$ K  v1 ^
: i  @: J0 X8 I; S检查最慢查询列表，看看有没有好的查询计划。最常见的”坏“查询计划包括：
3 b1 S8 [' f( f" Y; B3 w

4 O1 ]/ N. D4 r) ?

• 全表搜索：通常缺少一个索引或表统计过期时进行全表搜索。
• 全笛卡尔连接：意思是计算多张表的全笛卡尔乘积。检查一下缺少的连接条件，或拆分为几个步骤以简化查询。
  - {$ g/ a9 M: Z* A  A

& U: s( e/ P% T" z$ L1 d9 t" T
速成法6——检查错误的提交间隔
如果你使用批处理程序，提交间隔会对性能造成十倍甚至百倍的影响。
" a- S* ]% S0 {: q. f+ M
0 d( Q) X, j2 O- b+ |! X0 k
+ X* [" K9 n" [/ r4 Z& q请确保提交间隔是符合预期的（对于 Spring 批任务，通常是100到1000之间）。经常，该参数的配置不正确。
8 H6 s$ t9 t' O7 X; q
9 ]: g; h; i2 w7 C' d4 I- {
速成法7—— 使用二级查询缓存
6 s; j( Z( k# _8 v2 H/ f如果一些数据可以缓存，则可以查看本文了解如何设置 Hibernate 缓存：Hibernate 二级/查询缓存的陷阱。
8 ?, T- w! t3 x- l

结论
2 _& q! Z1 A6 L" D. r2 d( j; [' z解决应用性能问题的关键，在于通过收集一些指标发现当前的瓶颈。

# g& q3 y1 z2 x: B: s
+ ~; Y, F+ r+ o# ?& Q& E没有一些测量指标，往往无法在短时间内找到真正的问题根源。
9 I# X) I9 _' {2 f( p; A" c8 P

此外，很多典型的数据库驱动应用的性能陷阱，如果一开始就使用了 Spring Batch，就能够避免。

! l* D7 |) ]( w) w0 k
6 s1 c  p: |- n* U' K! \OneAPM for Java 能够深入到所有 Java 应用内部完成应用性能管理和监控，包括代码级别性能问题的可见性、性能瓶颈的快速识别与追溯、真实用户体验监控、服务器监控和端到端的应用性能管理。想阅读更多技术文章，请访问OneAPM官网