1.悲觀鎖，正如其名，它指的是對數據被外界（包括本系統當前的其他事務，以及來自外部系統的事務處理）修改持保守態度，因此，在整個數據處理過程中，將數據處於鎖定狀態。悲觀鎖的實現，往往依靠數據庫提供的鎖機制（也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系 統不會修改數據）。
數據庫鎖機制:
1 未提交讀（read uncommitted）
2 提交讀（read committed）
3 重復讀（repeatable read）
4 序列化（serializable）
鎖機制：
共享鎖：其他事務可以讀，但不能修改。
排他鎖：其他事務不能讀取。
鎖粒度：一般分為：行鎖、表鎖、庫鎖
解釋：
1 未提交讀（read uncommitted）
一個更新數據庫的事務A在未commit的情況下，另一個事務B正在讀取事務A更新的記錄，會產生臟讀現象，這是因為A事務在開啟 DB Transaction后，做一些DML操作時，記錄會保存在內存中，這時B事務讀取了A事務提交在內存中的數據，產生了臟讀。
2 提交讀（read committed）
數據的修改只有在commit之后，才回被讀取。和1 相反。
3 重復讀（repeatable read）
當數據庫隔離級別設置成 repeatable read后，事務A中的select 的過程中事務B可以修改A讀取部分的數據，當A第2次執行同樣的sql時，返回和上次相同的數據 ，消除不可重復讀。
注：個人認為只是應為A事務采用這種隔離級別后，讀取的是數據庫在事務開始時間點的映象，在這個時間點后的所有操作都不會對A事務中的查詢產生影響，依據是本文后續的實驗，如果有疑問，請指出。
4 序列化（serializable）
當數據庫隔離級別設置成Serializeable后，事務A中的select 會以共享鎖鎖定相關的數據（在select 返回的數據結果集），這些數據不可以被修改（可以被讀取），若事務B對這些數據做UPDATE操作，會處於等待狀態，消除幻讀。
注：事務B可以UPDATE 事務A中為鎖定的數據，后面的實驗可以證明。
2、樂觀鎖（ Optimistic Locking ） 相對悲觀鎖而言，樂觀鎖機制采取了更加寬松的加鎖機制。悲觀鎖大多數情況下依靠數據庫的鎖機制實現，以保證操作最大程度的獨占性。但隨之而來的就是數據庫性能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。 而樂觀鎖機制在一定程度上解決了這個問題。樂觀鎖，大多是基於數據版本（ Version ）記錄機制實現。何謂數據版本？即為數據增加一個版本標識，在基於數據庫表的版本解決方案中，一般是通過為數據庫表增加一個 “version” 字段來實現。讀取出數據時，將此版本號一同讀出，之后更新時，對此版本號加一。此時，將提交數據的版本數據與數據庫表對應記錄的當前版本信息進行比對，如果提交的數據版本號大於數據庫表當前版本號，則予以更新，否則認為是過期數據。
hibernate 樂觀鎖與悲觀鎖使用
原文地址 ：http://www.blogjava.net/baoyaer/articles/203445.html
Hibernate支持兩種鎖機制：
即通常所說的“悲觀鎖（Pessimistic Locking）”和 “樂觀鎖（OptimisticLocking）”。
悲觀鎖的實現，往往依靠數據庫提供的鎖機制（也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系統不會修改數據）。
Hibernate的加鎖模式有：
Ø LockMode.NONE ： 無鎖機制。
Ø LockMode.WRITE ：Hibernate在Insert和Update記錄的時候會自動
獲取。
Ø LockMode.READ ： Hibernate在讀取記錄的時候會自動獲取。
以上這三種鎖機制一般由Hibernate內部使用，如Hibernate為了保證Update
過程中對象不會被外界修改，會在save方法實現中自動為目標對象加上WRITE鎖。
Ø LockMode.UPGRADE ：利用數據庫的for update子句加鎖。
Ø LockMode. UPGRADE_NOWAIT ：Oracle的特定實現，利用Oracle的for update nowait子句實現加鎖。
Hibernate的悲觀鎖，也是基於數據庫的鎖機制實現。 下面的代碼實現了對查詢記錄的加鎖：
String hqlStr = " from TUser as user where user.name=’Erica’ " ;
2
Query query = session.createQuery(hqlStr);
3
query.setLockMode( " user " ,LockMode.UPGRADE); // 加鎖
4
List userList = query.list(); // 執行查詢，
獲取數據 query.setLockMode 對查詢語句中特定別名所對應的記錄進行加鎖（我們為 TUser類指定了一個別名“user”），這里也就是對返回的所有user記錄進行加鎖。 觀察運行期Hibernate生成的SQL語句：
select tuser0_.id as id, tuser0_.name as name, tuser0_.group_id as group_id, tuser0_.user_type as user_type, tuser0_.sex as sex from t_user tuser0_ where (tuser0_.name = ’Erica’ ) for update
這里Hibernate通過使用數據庫的for update子句實現了悲觀鎖機制。
上面這兩種鎖機制是我們在應用層較為常用的，加鎖一般通過以下方法實現：
Criteria.setLockMode
Query.setLockMode
Session.lock
注意，只有在查詢開始之前（也就是Hiberate 生成SQL 之前）設定加鎖，才會 真正通過數據庫的鎖機制進行加鎖處理，否則，數據已經通過不包含for update 子句的Select SQL加載進來，所謂數據庫加鎖也就無從談起。
樂觀鎖，大多是基於數據版本（Version）記錄機制實現。何謂數據版本？即為數據增加一個版本標識，在基於數據庫表的版本解決方案中，一般是通過為數據庫表增加一個“version”字段來實現。讀取出數據時，將此版本號一同讀出，之后更新時，對此版本號加一。此時，將提交數據的版本數據與數據庫表對應記錄的當前版本信息進行比對，如果提交的數據版本號大於數據庫表當前版本號，則予以更新，否則認為是過期數據。
1． 首先為TUser的class描述符添加optimistic-lock屬性：
< hibernate - mapping >
< class
name = " org.hibernate.sample.TUser "
table = " t_user "
dynamic - update = " true "
dynamic - insert = " true "
optimistic - lock = " version "
>
……
</ class >
</ hibernate - mapping >
添加一個Version屬性描述符
代碼內容
< hibernate - mapping >
2
< class
3
name = " org.hibernate.sample.TUser "
4
table = " t_user "
5
dynamic - update = " true "
6
dynamic - insert = " true "
7
optimistic - lock = " version "
8
>
9
< id
10
name = " id "
11
column = " id "
12
type = " java.lang.Integer "
13
>
14
< generator class = " native " >
15
</ generator >
16
</ id >
17
< version
18
column = " version "
19
name = " version "
20
type = " java.lang.Integer "
21
/>
22
……
23
</ class >
24
</ hibernate - mapping >
25
注意version 節點必須出現在ID 節點之后。
這里我們聲明了一個version屬性，用於存放用戶的版本信息，保存在TUser表的 version字段中。 此時如果我們嘗試編寫一段代碼，更新TUser表中記錄數據，如：
代碼內容
Criteria criteria = session.createCriteria(TUser. class );
2
criteria.add(Expression.eq( " name " , " Erica " ));
3
List userList = criteria.list();
4
TUser user = (TUser)userList.get( 0 );
5
Transaction tx = session.beginTransaction();
6
user.setUserType( 1 ); // 更新UserType字段
7
tx.commit();
8
每次對TUser進行更新的時候，我們可以發現，數據庫中的version都在遞增。 而如果我們嘗試在tx.commit 之前，啟動另外一個Session，對名為Erica 的用 戶進行操作，以模擬並發更新時的情形：
代碼內容
Session session = getSession();
2
Criteria criteria = session.createCriteria(TUser. class );
3
criteria.add(Expression.eq( " name " , " Erica " ));
4
Session session2 = getSession();
5
Criteria criteria2 = session2.createCriteria(TUser. class );
6
criteria2.add(Expression.eq( " name " , " Erica " ));
7
List userList = criteria.list();
8
List userList2 = criteria2.list();TUser user = (TUser)userList.get( 0 );
9
TUser user2 = (TUser)userList2.get( 0 );
10
Transaction tx = session.beginTransaction();
11
Transaction tx2 = session2.beginTransaction();
12
user2.setUserType( 99 );
13
tx2.commit();
14
user.setUserType( 1 );
15
tx.commit();
16
執行以上代碼，代碼將在tx.commit()處拋出StaleObjectStateException異 常，並指出版本檢查失敗，當前事務正在試圖提交一個過期數據。通過捕捉這個異常，我 們就可以在樂觀鎖校驗失敗時進行相應處理。
悲觀鎖與樂觀鎖的比較:
悲觀鎖大多數情況下依靠數據庫的鎖機制實現，以保證操作最大程度的獨占性。但隨之而來的就是數據庫性能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受;
相對悲觀鎖而言，樂觀鎖機制采取了更加寬松的加鎖機制。樂觀鎖機制往往基於系統中的數據存儲邏輯，因此也具備一定的局限性，如在上例中，由於樂觀鎖機制是在我們的系統中實現，來自外部系統的更新操作不受我們系統的控制，因此可能會造成臟數據被更新到數據庫中。在
系統設計階段，我們應該充分考慮到這些情況出現的可能性，並進行相應調整（如將樂觀鎖策略在數據庫存儲過程中實現，對外只開放基於此存儲過程的數據更新途徑，而不是將數據庫表直接對外公開）。
Hibernate 在其數據訪問引擎中內置了樂觀鎖實現。如果不用考慮外部系統對數據庫的更新操作，利用Hibernate提供的透明化樂觀鎖實現，將大大提升我們的生產力。
Hibernate中可以通過class描述符的optimistic-lock屬性結合version描述符指定。
optimistic-lock屬性有如下可選取值：
Ø none
無樂觀鎖
Ø version
通過版本機制實現樂觀鎖
Ø dirty
通過檢查發生變動過的屬性實現樂觀鎖
Ø all
通過檢查所有屬性實現樂觀鎖
其中通過version實現的樂觀鎖機制是Hibernate官方推薦的樂觀鎖實現，同時也是Hibernate中，目前唯一在數據對象脫離Session發生修改的情況下依然有效的鎖機制。因此，一般情況下，我們都選擇version方式作為Hibernate樂觀鎖實現機制。