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

admin

对于大多数典型的 spring/hibernate 企业应用而言，其性能表现几乎完全依赖于持久层的性能。此篇文章中将介绍如何确认应用是否受数据库约束，同时介绍七种常用的提高应用性能的速成法。本文系 OneAPM 工程师翻译整理。


如何确认应用是否受限于数据库
确认应用是否受限于数据库的第一步，是在开发环境中进行测试，并使用 VisualVM 进行监控。VisualVM 是一款包含在 JDK 中的 java 分析器，在命令行输入 jvisualvm 即可调用。


启用 Visual VM 之后，尝试以下步骤：

( }" N& z* p! k4 L
1.双击你正在运行的应用
: d& G" b. A3 p: f2.选择 Sampler
" l8 y$ z) a. u% l' L3.点击 Settings 复选框
1 H6 S" E( n0 X5 F7 a4.选择Profile only packages，然后输入下列包：
! [$ Q! t% u0 C- byour.application.packages.*

3 _. F3 U1 X, {# u
org.hibernate.*

" |7 S* X& m) x
org.springframework.*


your.database.driver.package, 比如 oracle.*
( u4 Z( d* z5 G. e& H+ Y- `  i

" U0 _4 w$ D- e/ A9 h5 @6 c9 C" X点击 Sample CPU

8 H- |  z& E& L0 z+ x
- {- v3 w/ A3 B; H# G5 B" i7 C如果应用性能受限于数据库，其 CPU 分析结果会非常恐怖
( M3 x6 ]3 l& d
3 E5 K& \4 H2 d$ w  g0 y2 R2 ?
Spring/Hibernate 应用性能优化
; W* f  H3 n7 q4 \5 C! }

我们看到，客户端 Java 进程花在等待数据库从网络中返回结果的时间占56%。
2 M) i  {" _# D  G, J# K9 y

) d3 t% z0 a, v6 H; G  {4 d% U看到数据库查询是导致应用运行缓慢的原因，其实是好兆头。Hibernate 反射调用占比32.7%是正常情况，无法进一步优化。
+ U8 k) w. y' m  T
; R# Y) ?+ h3 S# g  [7 t
性能调优第一步：定义基准运行
性能调优的第一步是为程序定义基准运行，我们要定义一组能有效执行的输入数据，让程序基准运行与生产环境下的运行差不多。


+ R) X. o/ U" k% Z0 k: G5 T& m9 t主要的区别在于基准运行的耗时要小很多。作为参考，5到10分钟的执行时间比较不错。
" x1 ]& Z% n4 F5 ?' w* B8 T

; S* h" [. @4 L; n5 ?' ^什么是好的基准？
好的基准应该具备以下特征：
$ F" @0 m8 @% Z$ z' n

% S5 `' {# \) i* f

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

  X- U- R+ o+ G7 {/ l$ K定义好的基准是成功解决问题的一半。
( \* e5 {: z7 W- F
  B3 A1 d& ~+ c# q3 N( \' r
什么是不好的基准
例如，通过批量运行处理通讯系统的电话数据记录，选取10000条记录就是错误的做法。
" G, d" I- D" R7 `- y8 _, k
, C! l, `5 G5 X- U: V6 H  i
原因是：前10000条记录可能多为语音电话，而未知的性能问题可能发生在短信流量的处理过程中。一开始如果基准不够好，就会导致错误的结论。


收集 SQL 日志与查询时间
SQL 查询的执行语句与其执行时间可以通过 log4jdbc等方式收集。详细了解如何使用 log4jdbc 收集 SQL 查询信息，点击文章 使用 log4jdbc 优化 Spring/Hibernate 应用 SQL 日志。
- c1 _7 p/ K4 v

查询的执行时间是从 Java 客户端收集的，该时间包含查询数据库的来回网络调用。SQL 查询的日志如下：
$ g, n  Q; w' ?# \' \3 q
) S. V' ?5 B9 e8 H+ B
16 avr. 2014 11:13:48 | SQL_QUERY /* insert your.package.YourEntity */ insert into YOUR_TABLE (...) values (...) {executed in 13 msec}
8 v5 R$ P! p; P" V- \预处理语句也是很重要的信息来源，它们常常会透露出常用的查询类型。了解更多的日志讯息，可以查看文章：Hibernate 为什么/在何处使用该 SQL 查询？
- b$ X( g$ u5 x- u0 x4 r9 w
' T5 q- R8 F# }8 ]7 J, ?5 w
通过 SQL 日志可以了解哪些指标？
" [* b. y) S0 I2 A# q/ w1 h' ]% eSQL 日志可以回答下列问题：
+ u+ T5 M" l# j& m# B

+ w5 K$ y! a% t6 `( P6 d* N2 u

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

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


如何你习惯了 Unix 命令行，bash 或是一个好选择。Bash 也可以在 Windows 工作站使用，Cygwin 或 Git 都包含了 bash 命令行。

. D6 ]* @0 M1 ], N5 {. u
常用的速成法
" v3 Z' n* Y$ b, {下面介绍的速成法能找出 Spring/Hibernate 应用中常见的性能问题，以及对应的解决方案。


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

" L2 i- C. K5 j3 r0 o2 M$ ^3 k
0 y6 v2 z9 O0 [问题在于，如果要插入50条记录，我们希望为了获取这50个 id，可以避免50趟查询数据库的来回网络调用，让 Java 进程不一直等待。

: L2 n% i7 H  Z$ n* m2 P" n) I
Hibernate 通常如何解决此问题？
Hibernate 提供了优化的 ID 生成器以避免此问题。也即，对于序列，会默认使用 HiLo id 生成器。以下是 HiLo 序列生成器的工作方式：
$ E9 b' H8 {! j+ m! Y7 U

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

, r% \" @4 W, S/ i1000 * 50 + 0 = 50000


4 j& f6 G; ~% V8 m1000 * 50 + 1 = 50001
- R' Y$ o) D) E  x+ a; a

...

& T* G7 e3 ?1 W; o, }# |$ N* c
  x3 p: Q) ?- f" I. G# t' R1000 * 50 + 49 = 50049, 达到低值 (50)


5 \1 Y2 j6 R9 P7 |为新的高值1001调用序列，依次类推

: p, }/ \  Z5 T* v
' T6 V  v9 G( d. S8 e6 b9 U因此一次序列调用，可生成50个键，从而减少数次来回网络调用导致的负担。
/ P5 Z6 H. Z: b
( Z, x* N4 x0 N( J5 a
这些优化的键生成器默认在 Hibernate 4中开启。如要禁用，可将 hibernate.id.new_generator_mappings 设置为 false。
. M( n% Z0 ?6 k# k9 q

/ M5 Q1 O6 X* `+ R& s6 i为什么生成主键仍是一个问题？
问题在于，如果你声明键生成策略为 AUTO，且未启用优化的键生成器，那么应用最后会面临大量的序列调用。
2 ]- d4 G( ~$ \7 ^& \  {
5 D7 {5 p9 O3 f& ]
. c6 |/ G, l! _5 s为了确保启用优化的键生成器，请将键生成策略改为 SEQUENCE 而非 AUTO。
) r: e( U' E# ?0 G6 U$ f
, W7 z& _1 o+ I5 r
" o8 o8 X8 n+ j. i- t; w+ O& `@Id
3 C" |: V! D* F+ Q$ s# l/ j@GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "your_key_generator")
6 u1 y! w, @1 N6 I5 ?- {. g$ Iprivate Long id;
' Z" v/ p; Q% }  L3 I1 t改变设定之后，在插入操作频繁的应用中能看到10%到20%的性能提升，而且几乎没有改动代码。


速成法2——使用 JDBC 批处理 inserts/updates
2 A4 S: g9 Z7 ^& e3 v对于批处理程序，JDBC 驱动程序提供了旨在减少网络来回传输的优化方法：”JDBC batch inserts/updates“。使用该方法后，插入或更新会先在驱动层排队，然后再传送到数据库。

% W/ Z9 ]8 Y) V& o
2 T( B% x' l. x: d5 H当达到阈值后，所有排队的语句都会一次性传给数据库。这可以避免驱动程序逐一传送语句，导致网络来回传送的负担。


经过以下配置，就能激活批处理 inserts/updates：

: C/ D; k; c8 v, ^
; W# d/ D' g# d7 {; n4 K<prop key="hibernate.jdbc.batch_size">100</prop>  
<prop key="hibernate.order_inserts">true</prop>  
" X5 H% O& D+ z; Z. W4 K. u1 D<prop key="hibernate.order_updates">true</prop>  
仅设置 JDBC 批处理大小并不够。因为 JDBC 驱动程序只会在收到对同一张表 insert/updates 时批处理这些语句。

- c& T4 K9 S9 R4 }3 }+ z  O2 a* L8 B0 q
如果收到对一张新表的插入语句，JDBC 驱动程序会先清除对前一张表的批处理语句，然后开始分批处理针对新表的 SQL 语句。

, e# q+ j3 a5 d3 E2 }
Spring Batch 内置了相似的功能。该优化能在插入操作频繁的应用中带来30%到40%的性能提升，而不用改动任何代码行。

: w+ U; [1 I+ E7 X$ Z
速成法3——定期清理 Hibernate 会话
: C3 ^$ U) _' I$ G9 }2 S在向数据库添加或修改数据时，Hibernate 会在会话中保留一版已经存在的实体，以防在会话关闭之前这些实体再度被修改。


3 t( i5 q, ^( v6 C$ `% J但是，多数情况下，一旦对应的插入操作已经在数据库中完成，我们就可以安心地丢弃那些实体。这会释放 Java 客户端进程中的内存，避免过久的 Hibernate 会话导致的性能问题。

5 R3 x$ V: v" e* K2 l, j
这种长久的会话应该尽量避免。但如果出于某种原因不得不使用它们，以下是控制内存消耗的方法：

0 I! S2 K6 L9 f( a
* S: K. h+ @8 L7 j9 V) r4 X' qentityManager.flush();
entityManager.clear();
2 u8 J# A+ X0 X4 h# {$ mflush 会触使新实体中的插入语句传送至数据库。clear 则会释放会话中的新实体。
8 X0 i6 H9 _( n. d9 x. ^
# J9 `, Y6 V- K# U# v" w2 ]) x3 u
速成法4——减少 Hibernate dirty-checking(脏数据检查) 的代价
1 x2 U) J* \% cHibernate 内部使用了一种机制用于追踪被修改的实体，名为 dirty-checking。该机制并不基于实体类中的 equals 和 hashcode 方法。
  U! p' |8 c1 m0 i

; P. `8 H0 G* S" I; {Hibernate 尽可能将 dirty-checking 的性能成本保持在最低值，只在需要时使用 dirty-check。但是该机制也有成本，在列数很多的表中该成本尤其可观。


在进行任何优化之前，最重要的是使用 VisualVM 测量 dirty-checking 的成本。

' T5 J( j& d* i; u% l. B; X
/ }( w& C6 {* ^$ {如何避免 dirty-checking ？
$ d" z/ I2 b' o. Q' w: ndirty-checking 可以通过以下方式禁用：
0 \' x: |- N8 ^( N" a
( X$ x8 k. `, _# o( Z
@Transactional(readOnly=true)
. {  o5 G1 p2 D/ W* _public void someBusinessMethod() {
....
2 O' a+ x. k, r9 c. H/ _}
1 F7 J2 s0 H8 v- ]禁用 dirty-checking 的另一种方式是使用 Hibernate 无状态会话，预知详情请查看文档。

* v3 {' h6 y  l1 y* ]4 }7 _3 ]% {& J
+ s: L' @9 x% Z速成法5——搜索”坏“查询计划


检查最慢查询列表，看看有没有好的查询计划。最常见的”坏“查询计划包括：

% |7 Q0 e4 J0 {4 O+ C) h
2 c  P; p; ]9 v+ a. |4 V' p( e; H# X

• 全表搜索：通常缺少一个索引或表统计过期时进行全表搜索。
• 全笛卡尔连接：意思是计算多张表的全笛卡尔乘积。检查一下缺少的连接条件，或拆分为几个步骤以简化查询。
  ) V$ I/ {0 E4 f# s

速成法6——检查错误的提交间隔
如果你使用批处理程序，提交间隔会对性能造成十倍甚至百倍的影响。

1 k/ d9 e( y; }# g2 j$ {
请确保提交间隔是符合预期的（对于 Spring 批任务，通常是100到1000之间）。经常，该参数的配置不正确。
6 C6 I0 U1 U: K4 Y. `/ _
$ T% U/ ^; e2 Y
速成法7—— 使用二级查询缓存
如果一些数据可以缓存，则可以查看本文了解如何设置 Hibernate 缓存：Hibernate 二级/查询缓存的陷阱。


结论
解决应用性能问题的关键，在于通过收集一些指标发现当前的瓶颈。
2 p3 k+ m8 `. \

没有一些测量指标，往往无法在短时间内找到真正的问题根源。
  p5 j) u. |( S, ^

3 N) U/ \/ E0 G4 `3 \2 S此外，很多典型的数据库驱动应用的性能陷阱，如果一开始就使用了 Spring Batch，就能够避免。


" e0 f2 y- h) Q  K8 WOneAPM for Java 能够深入到所有 Java 应用内部完成应用性能管理和监控，包括代码级别性能问题的可见性、性能瓶颈的快速识别与追溯、真实用户体验监控、服务器监控和端到端的应用性能管理。想阅读更多技术文章，请访问OneAPM官网
0 W1 T- V7 F" h2 U