對於我們開發的網站，如果網站的訪問量非常大的話，那麼我們就需要考慮相關的併發訪問問題了。而併發問題是絕大部分的程序員頭疼的問題，
但話又說回來了，既然逃避不掉，那我們就坦然面對吧~今天就讓我們一起來研究一下常見的併發和同步吧。
爲了更好的理解併發和同步，我們需要先明白兩個重要的概念:同步和異步
1、同步和異步的區別和聯繫
所謂同步，可以理解爲在執行完一個函數或方法之後，一直等待系統返回值或消息，這時程序是出於阻塞的，只有接收到
返回的值或消息後才往下執行其它的命令。
異步，執行完函數或方法後，不必阻塞性地等待返回值或消息，只需要向系統委託一個異步過程，那麼當系統接收到返回
值或消息時，系統會自動觸發委託的異步過程，從而完成一個完整的流程。
同步在一定程度上可以看做是單線程，這個線程請求一個方法後就待這個方法給他回覆，否則他不往下執行(死心眼)。
異步在一定程度上可以看做是多線程的(廢話，一個線程怎麼叫異步)，請求一個方法後，就不管了，繼續執行其他的方法。
同步就是一件事，一件事情一件事的做。
異步就是，做一件事情，不引響做其他事情。
例如：吃飯和說話，只能一件事一件事的來，因爲只有一張嘴。
但吃飯和聽音樂是異步的，因爲，聽音樂並不引響我們吃飯。
對於Java程序員而言，我們會經常聽到同步關鍵字synchronized，假如這個同步的監視對象是類的話，那麼如果當一個對象
訪問類裏面的同步方法的話，那麼其它的對象如果想要繼續訪問類裏面的這個同步方法的話，就會進入阻塞，只有等前一個對象
執行完該同步方法後當前對象才能夠繼續執行該方法。這就是同步。相反，如果方法前沒有同步關鍵字修飾的話，那麼不同的對象
可以在同一時間訪問同一個方法，這就是異步。
在補充一下(髒數據和不可重複讀的相關概念):
髒數據
不可重複讀
2、如何處理併發和同步
今天講的如何處理併發和同同步問題主要是通過鎖機制。
我們需要明白，鎖機制有兩個層面。
一種是代碼層次上的，如java中的同步鎖，典型的就是同步關鍵字synchronized，這裏我不在做過多的講解，
感興趣的可以參考:http://www.cnblogs.com/xiohao/p/4151408.html
另外一種是數據庫層次上的，比較典型的就是悲觀鎖和樂觀鎖。這裏我們重點講解的就是悲觀鎖（傳統的物理鎖）和樂觀鎖。
悲觀鎖(Pessimistic Locking):
悲觀鎖，正如其名，它指的是對數據被外界（包括本系統當前的其他事務，以及來自 外部系統的事務處理）修改持保守態度，因此，
在整個數據處理過程中，將數據處於鎖定狀態。
悲觀鎖的實現，往往依靠數據庫提供的鎖機制（也只有數據庫層提供的鎖機制才能 真正保證數據訪問的排他性，否則，即使在本系統
中實現了加鎖機制，也無法保證外部系 統不會修改數據）。
一個典型的倚賴數據庫的悲觀鎖調用：
select * from account where name=」Erica」 for update
這條 sql 語句鎖定了 account 表中所有符合檢索條件（ name=」Erica」 ）的記錄。
本次事務提交之前（事務提交時會釋放事務過程中的鎖），外界無法修改這些記錄。
Hibernate 的悲觀鎖，也是基於數據庫的鎖機制實現。
下面的代碼實現了對查詢記錄的加鎖：
String hqlStr ="from TUser as user where user.name='Erica'";
Query query = session.createQuery(hqlStr);
query.setLockMode("user",LockMode.UPGRADE); // 加鎖
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 子句實現了悲觀鎖機制。
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 子句實現加鎖。
上面這兩種鎖機制是我們在應用層較爲常用的，加鎖一般通過以下方法實現：
Criteria.setLockMode
Query.setLockMode
Session.lock
注意，只有在查詢開始之前（也就是 Hiberate 生成 SQL 之前）設定加鎖，纔會
真正通過數據庫的鎖機制進行加鎖處理，否則，數據已經通過不包含 for update
子句的 Select SQL 加載進來，所謂數據庫加鎖也就無從談起。
爲了更好的理解select... for update的鎖表的過程，本人將要以mysql爲例，進行相應的講解
1、要測試鎖定的狀況，可以利用MySQL的Command Mode ，開二個視窗來做測試。
表的基本結構如下:
表中內容如下:
開啓兩個測試窗口，在其中一個窗口執行select * from ta for update0
然後在另外一個窗口執行update操作如下圖:
等到一個窗口commit後的圖片如下:
到這裏，悲觀鎖機制你應該瞭解一些了吧~
需要注意的是for update要放到mysql的事務中，即begin和commit中，否者不起作用。
至於是鎖住整個表還是鎖住選中的行，請參考:
http://www.cnblogs.com/xiohao/p/4385768.html
至於hibernate中的悲觀鎖使用起來比較簡單，這裏就不寫demo了~感興趣的自己查一下就ok了~
樂觀鎖(Optimistic Locking):
相對悲觀鎖而言，樂觀鎖機制採取了更加寬鬆的加鎖機制。悲觀鎖大多數情況下依 靠數據庫的鎖機制實現，以保證操作最大程度的獨佔性。但隨之
而來的就是數據庫 性能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。 如一個金融系統，當某個操作員讀取用戶的數據，並在讀出的用戶數
據的基礎上進 行修改時（如更改用戶帳戶餘額），如果採用悲觀鎖機制，也就意味着整個操作過 程中（從操作員讀出數據、開始修改直至提交修改結果的全
過程，甚至還包括操作 員中途去煮咖啡的時間），數據庫記錄始終處於加鎖狀態，可以想見，如果面對幾 百上千個併發，這樣的情況將導致怎樣的後果。 樂
觀鎖機制在一定程度上解決了這個問題。
樂觀鎖，大多是基於數據版本 Version ）記錄機制實現。何謂數據版本？即爲數據增加一個版本標識，在基於數據庫表的版本解決方案中，一般是通
過爲數據庫表增加一個 「version」 字段來 實現。 讀取出數據時，將此版本號一同讀出，之後更新時，對此版本號加一。此時，將提 交數據的版本數據與數據
庫表對應記錄的當前版本信息進行比對，如果提交的數據 版本號大於數據庫表當前版本號，則予以更新，否則認爲是過期數據。對於上面修改用戶帳戶信息
的例子而言，假設數據庫中帳戶信息表中有一個 version 字段，當前值爲 1 ；而當前帳戶餘額字段（ balance ）爲 $100 。操作員 A 此時將其讀出
（ version=1 ），並從其帳戶餘額中扣除 $50（ $100-$50 ）。 2 在操作員 A 操作的過程中，操作員 B 也讀入此用戶信息（ version=1 ），並 從其帳
戶餘額中扣除 $20 （ $100-$20 ）。 3 操作員 A 完成了修改工作，將數據版本號加一（ version=2 ），連同帳戶扣 除後餘額（ balance=$50 ），提交
至數據庫更新，此時由於提交數據版本大 於數據庫記錄當前版本，數據被更新，數據庫記錄 version 更新爲 2 。 4 操作員 B 完成了操作，也將版本號加一
（ version=2 ）試圖向數據庫提交數 據（ balance=$80 ），但此時比對數據庫記錄版本時發現，操作員 B 提交的 數據版本號爲 2 ，數據庫記錄當前版
本也爲 2 ，不滿足 「 提交版本必須大於記 錄當前版本才能執行更新 「 的樂觀鎖策略，因此，操作員 B 的提交被駁回。 這樣，就避免了操作員 B 用基於
version=1 的舊數據修改的結果覆蓋操作 員 A 的操作結果的可能。 從上面的例子可以看出，樂觀鎖機制避免了長事務中的數據庫加鎖開銷（操作員 A
和操作員 B 操作過程中，都沒有對數據庫數據加鎖），大大提升了大併發量下的系 統整體性能表現。 需要注意的是，樂觀鎖機制往往基於系統中的數據存儲
邏輯，因此也具備一定的局 限性，如在上例中，由於樂觀鎖機制是在我們的系統中實現，來自外部系統的用戶 餘額更新操作不受我們系統的控制，因此可能
會造成髒數據被更新到數據庫中。在 系統設計階段，我們應該充分考慮到這些情況出現的可能性，並進行相應調整（如 將樂觀鎖策略在數據庫存儲過程中實
現，對外只開放基於此存儲過程的數據更新途 徑，而不是將數據庫表直接對外公開）。 Hibernate 在其數據訪問引擎中內置了樂觀鎖實現。如果不用考慮外
部系統對數 據庫的更新操作，利用 Hibernate 提供的透明化樂觀鎖實現，將大大提升我們的 生產力。
Hibernate 中可以通過 class 描述符的 optimistic-lock 屬性結合 version描述符指定。
現在，我們爲之前示例中的 User 加上樂觀鎖機制。
1 ． 首先爲 User 的POJO class
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
|
package
com.xiaohao.test;
public
class
User {
private
Integer id;
private
String userName;
private
String password;
private
int
version;
public
int
getVersion() {
return
version;
}
public
void
setVersion(
int
version) {
this
.version = version;
}
public
Integer getId() {
return
id;
}
public
void
setId(Integer id) {
this
.id = id;
}
public
String getUserName() {
return
userName;
}
public
void
setUserName(String userName) {
this
.userName = userName;
}
public
String getPassword() {
return
password;
}
public
void
setPassword(String password) {
this
.password = password;
}
public
User() {}
public
User(String userName, String password) {
super
();
this
.userName = userName;
this
.password = password;
}
}
|
然後是User.hbm.xml
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
<?xml version=
"1.0"
?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
<hibernate-mapping
package
=
"com.xiaohao.test"
>
<
class
name=
"User"
table=
"user"
optimistic-lock=
"version"
>
<id name=
"id"
>
<generator
class
=
"native"
/>
</id>
<!--version標籤必須跟在id標籤後面-->
<version column=
"version"
name=
"version"
/>
<property name=
"userName"
/>
<property name=
"password"
/>
</
class
>
</hibernate-mapping>
|
注意 version 節點必須出現在 ID 節點之後。
這裏我們聲明瞭一個 version 屬性，用於存放用戶的版本信息，保存在 User 表的version中
optimistic-lock 屬性有如下可選取值：
Ø none
無樂觀鎖
Ø version
通過版本機制實現樂觀鎖
Ø dirty
通過檢查發生變動過的屬性實現樂觀鎖
Ø all
通過檢查所有屬性實現樂觀鎖
其中通過 version 實現的樂觀鎖機制是 Hibernate 官方推薦的樂觀鎖實現，同時也
是 Hibernate 中，目前唯一在數據對象脫離 Session 發生修改的情況下依然有效的鎖機
制。因此，一般情況下，我們都選擇 version 方式作爲 Hibernate 樂觀鎖實現機制。
2 ． 配置文件hibernate.cfg.xml和UserTest測試類
hibernate.cfg.xml
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
<!DOCTYPE hibernate-configuration PUBLIC
"-//Hibernate/Hibernate Configuration DTD 3.0//EN"
<hibernate-configuration>
<session-factory>
<!-- 指定數據庫方言 如果使用jbpm的話，數據庫方言只能是InnoDB-->
<property name=
"dialect"
>org.hibernate.dialect.MySQL5InnoDBDialect</property>
<!-- 根據需要自動創建數據表 -->
<property name=
"hbm2ddl.auto"
>update</property>
<!-- 顯示Hibernate持久化操作所生成的SQL -->
<property name=
"show_sql"
>
true
</property>
<!-- 將SQL腳本進行格式化後再輸出 -->
<property name=
"format_sql"
>
false
</property>
<property name=
"current_session_context_class"
>thread</property>
<!-- 導入映射配置 -->
<property name=
"connection.url"
>jdbc:mysql:
///user</property>
<property name=
"connection.username"
>root</property>
<property name=
"connection.password"
>
123456
</property>
<property name=
"connection.driver_class"
>com.mysql.jdbc.Driver</property>
<mapping resource=
"com/xiaohao/test/User.hbm.xml"
/>
</session-factory>
</hibernate-configuration>
|
UserTest.java
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
package
com.xiaohao.test;
import
org.hibernate.Session;
import
org.hibernate.SessionFactory;
import
org.hibernate.Transaction;
import
org.hibernate.cfg.Configuration;
public
class
UserTest {
public
static
void
main(String[] args) {
Configuration conf=
new
Configuration().configure();
SessionFactory sf=conf.buildSessionFactory();
Session session=sf.getCurrentSession();
Transaction tx=session.beginTransaction();
// User user=new User("小浩","英雄");
// session.save(user);
// session.createSQLQuery("insert into user(userName,password) value('張英雄16','123')")
// .executeUpdate();
User user=(User) session.get(User.
class
,
1
);
user.setUserName(
"221"
);
// session.save(user);
System.out.println(
"恭喜您，用戶的數據插入成功了哦~~"
);
tx.commit();
}
}
|
每次對 TUser 進行更新的時候，我們可以發現，數據庫中的 version 都在遞增。
下面我們將要通過樂觀鎖來實現一下併發和同步的測試用例:
這裏需要使用兩個測試類，分別運行在不同的虛擬機上面，以此來模擬多個用戶同時操作一張表,同時其中一個測試類需要模擬長事務
UserTest.java
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
package
com.xiaohao.test;
import
org.hibernate.Session;
import
org.hibernate.SessionFactory;
import
org.hibernate.Transaction;
import
org.hibernate.cfg.Configuration;
public
class
UserTest {
public
static
void
main(String[] args) {
Configuration conf=
new
Configuration().configure();
SessionFactory sf=conf.buildSessionFactory();
Session session=sf.openSession();
// Session session2=sf.openSession();
User user=(User) session.createQuery(
" from User user where user=5"
).uniqueResult();
// User user2=(User) session.createQuery(" from User user where user=5").uniqueResult();
System.out.println(user.getVersion());
// System.out.println(user2.getVersion());
Transaction tx=session.beginTransaction();
user.setUserName(
"101"
);
tx.commit();
System.out.println(user.getVersion());
// System.out.println(user2.getVersion());
// System.out.println(user.getVersion()==user2.getVersion());
// Transaction tx2=session2.beginTransaction();
// user2.setUserName("4468");
// tx2.commit();
}
}
|
UserTest2.java
|
1
2
3
Transaction tx=session.beginTransaction();
user.setUserName(
"101"
);
tx.commit();
System.out.println(user.getVersion());
// System.out.println(user2.getVersion());
// System.out.println(user.getVersion()==user2.getVersion());
// Transaction tx2=session2.beginTransaction();
// user2.setUserName("4468");
// tx2.commit();
}
}
|
UserTest2.java
|
1
2
3
4
5
6
|