對於我們開發的網站，如果網站的訪問量非常大的話，那麼我們就需要考慮相關的併發訪問問題了。而併發問題是絕大部分的程式設計師頭疼的問題，但話又說回來了，既然逃避不掉，那我們就要想想應對措施，今天我們就一起討論一下常見的併發和同步吧。
首先為了更好的理解併發和同步，我們需要首先明白兩個重要的概念：同步和非同步

同步和非同步的區別和聯絡

對於Java程式設計師來說，Synchronized最為熟悉了，如果它作用於一個類的話，那麼就是一個執行緒訪問類的方法時，其他執行緒就會阻塞，相反，如果沒有這個關鍵字來修飾的話，不同執行緒就可以在同一時間訪問同一個方法，這就是非同步。

髒讀和不可重複讀

不可重複讀
在第一個事務讀取資料後，第二個事務對資料進行了修改，導致第一個事務結束前再訪問這個資料的時候，會發現兩次讀取到的資料是不一樣的，因此稱為不可重複讀。

如何處理併發和同步

悲觀鎖
悲觀鎖，正如其名，它指的是對資料被外界(包括本系統當前的其他事務，以及來自外部系統的事務處理)修改持保守態度。因此，在這個資料處理過程中，將資料處於鎖定狀態。
悲觀鎖的實現，往往依靠資料庫提供的鎖機制(也只有資料庫層提供的鎖機制才能真正保證資料訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系統不會修改資料)。
一個典型的倚賴資料庫的悲觀鎖呼叫：

select * fromaccountwherename=”Erica” forupdate

這條 sql 語句鎖定了 account 表中所有符合檢索條件（ name=”Erica” ）的記錄。
本次事務提交之前（事務提交時會釋放事務過程中的鎖），外界無法修改這些記錄。
Hibernate 的悲觀鎖，也是基於資料庫的鎖機制實現。
下面的程式碼實現了對查詢記錄的加鎖：

1
2
3
4

String hqlStr ="from TUser as user where user.name='Erica'";
Query query = session.createQuery(hqlStr);
query.setLockMode("user",LockMode.UPGRADE); // 加鎖
List userList = query.list();// 執行查詢，獲取資料

觀察執行期 Hibernate 生成的 SQL 語句：

1

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 的加鎖模式有：

1
2
3
4
5
6
7
8
9
10
11
12

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為例，進行相應的講解
開啟兩個測試視窗，其中一個視窗A執行命令：

1
2
3
4
5
6
7
8
9
10
11

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from empinfo for update;
+--------+----------+------+---------+
| Fempno | Fempname | Fage | Fsalary |
+--------+----------+------+---------+
| 1233   | sdfs     | NULL |    NULL |
| 324234 | sdf      |   38 |   12121 |
+--------+----------+------+---------+
2 rows in set (0.00 sec)

這個時候開啟視窗B執行更新或插入操作：

1

mysql> update empinfo set Fage=12 where Fempno=1233;

這個時候視窗B的更新或插入操作不會執行，會一直在等待，直到A視窗的事務提交了：

1
2

mysql> commit;
Query OK, 0 rows affected (0.00 sec)

B視窗的更新才開始執行。
那麼for update到底鎖定表還是行呢？

由於InnoDB預設是Row-Level Lock，所以只有「明確」的指定主鍵，MySQL才會執行Row lock (只鎖住被選取的資料例) ，否則MySQL將會執行Table Lock (將整個資料表單給鎖住)。
例1: (明確指定主鍵，並且有此筆資料，row lock)

1
2
3

SELECT * FROM products WHERE id='3' FOR UPDATE;

SELECT * FROM products WHERE id='3' and type=1 FOR UPDATE;

例2: (明確指定主鍵，若查無此筆資料，無lock)

SELECT * FROM products WHEREid='-1'FORUPDATE;

例3: (無主鍵，table lock)

SELECT * FROM products WHEREname='Mouse'FORUPDATE;

例4: (主鍵不明確，table lock)

SELECT * FROM products WHEREid<>'3'FORUPDATE;

例5: (主鍵不明確，table lock)

SELECT * FROM products WHEREidLIKE'3'FORUPDATE;

注1: FOR UPDATE僅適用於InnoDB，且必須在交易區塊(BEGIN/COMMIT)中才能生效。
注2: 要測試鎖定的狀況，可以利用MySQL的Command Mode ，開二個視窗來做測試。在MySql 5.0中測試確實是這樣的
另外：MyAsim 只支援表級鎖，InnerDB支援行級鎖 添加了(行級鎖/表級鎖)鎖的資料不能被其它事務再鎖定，也不被其它事務修改(修改、刪除） 。是表級鎖時，不管是否查詢到記錄，都會鎖定表。
到這裡，悲觀鎖機制你應該瞭解一些了吧~

樂觀鎖
相對悲觀鎖而言，樂觀鎖機制採取了更加寬鬆的加鎖機制。悲觀鎖大多數情況下依 靠資料庫的鎖機制實現，以保證操作最大程度的獨佔性。但隨之而來的就是資料庫 效能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。如一個金融系統，當某個操作員讀取使用者的資料，並在讀出的使用者資料的基礎上進 行修改時（如更改使用者帳戶餘額），如果採用悲觀鎖機制，也就意味著整個操作過 程中（從操作員讀出資料、開始修改直至提交修改結果的全過程，甚至還包括操作 員中途去煮咖啡的時間），資料庫記錄始終處於加鎖狀態，可以想見，如果面對幾 百上千個併發，這樣的情況將導致怎樣的後果。樂觀鎖機制在一定程度上解決了這個問題。樂觀鎖，大多是基於資料版本 Version ）記錄機制實現。何謂資料版本？即為資料增加一個版本標識，在基於資料庫表的版本解決方案中，一般是通過為資料庫表增加一個 “version” 欄位來 實現。 讀取出資料時，將此版本號一同讀出，之後更新時，對此版本號加一。此時，將提 交資料的版本資料與資料庫表對應記錄的當前版本資訊進行比對，如果提交的資料 版本號大於資料庫表當前版本號，則予以更新，否則認為是過期資料。
假如資料庫中賬戶餘額為100，version為1，操作員A讀出餘額，並修改為50，而在A操作的同時操作員B也讀出了賬戶餘額100，並修改為80，A完成了操作錄入系統，version從1加上1變為2，餘額修改為50，操作員B也提交了記錄，version也變為2，餘額則是80，但是此時資料庫發現，B提交的version為2，當前版本也是2，不滿足 “ 提交版本必須大於記 錄當前版本才能執行更新 “ 的樂觀鎖策略。因此，操作員 B 的提交被駁回。 這樣，就避免了操作員 B 用基於version=1 的舊資料修改的結果覆蓋操作 員 A 的操作結果的可能。 從上面的例子可以看出，樂觀鎖機制避免了長事務中的資料庫加鎖開銷（操作員 A和操作員 B 操作過程中，都沒有對資料庫資料加鎖），大大提升了大併發量下的系 統整體效能表現。 需要注意的是，樂觀鎖機制往往基於系統中的資料儲存邏輯，因此也具備一定的局 限性，如在上例中，由於樂觀鎖機制是在我們的系統中實現，來自外部系統的使用者 餘額更新操作不受我們系統的控制，因此可能會造成髒資料被更新到資料庫中。在 系統設計階段，我們應該充分考慮到這些情況出現的可能性，並進行相應調整（如 將樂觀鎖策略在資料庫儲存過程中實現，對外只開放基於此儲存過程的資料更新途 徑，而不是將資料庫表直接對外公開）。 Hibernate 在其資料訪問引擎中內建了樂觀鎖實現。如果不用考慮外部系統對數 據庫的更新操作，利用 Hibernate 提供的透明化樂觀鎖實現，將大大提升我們的 生產力。

Hibernate使用樂觀鎖我只說一下註解的方式：
在Entity中加入以下程式碼

1
2
3
4
5
6
7
8
9
10

private int version;

@Version
@Column(name = "version",length = 11)
public int getVersion() {
    return version;
}
public void setVersion(int version) {
    this.version = version;
}

這樣就可以輕鬆實現hibernate樂觀鎖方式。

常見併發同步案例分析

案例一:案例二、股票交易系統、銀行系統，大資料量你是如何考慮的
首先，股票交易系統的行情表，每幾秒鐘就有一個行情記錄產生，一天下來就有（假定行情3秒一個） 股票數量×20×60*6 條記錄，一月下來這個表記錄數量多大？ oracle中一張表的記錄數超過100w後 查詢效能就很差了，如何保證系統性能？
再比如，中國移動有上億的使用者量，表如何設計？把所有用於存在於一個表麼？
所以，大數量的系統，必須考慮表拆分-（表名字不一樣，但是結構完全一樣），通用的幾種方式：（視情況而定）
1）按業務分，比如 手機號的表，我們可以考慮 130開頭的作為一個表，131開頭的另外一張表 以此類推
2）利用oracle的表拆分機制做分表
3）如果是交易系統，我們可以考慮按時間軸拆分，當日資料一個表，歷史資料弄到其它表。這裡歷史資料的報表和查詢不會影響當日交易。
此外，我們還得考慮快取
這裡的快取，指的不僅僅是hibernate，hibernate本身提供了一級二級快取。這裡的快取獨立於應用，依然是記憶體的讀取，假如我們能減少資料庫頻繁的訪問，那對系統肯定大大有利的。比如一個電子商務系統的商品搜尋，如果某個關鍵字的商品經常被搜，那就可以考慮這部分商品列表存放到快取（記憶體中去），這樣不用每次訪問資料庫，效能大大增加。簡單的快取大家可以理解為自己做一個hashmap，把常訪問的資料做一個key，value是第一次從資料庫搜尋出來的值，下次訪問就可以從map裡讀取，而不讀資料庫；專業些的目前有獨立的快取框架比如memcached 等，可獨立部署成一個快取伺服器。

常見的提高高併發下訪問的效率的手段

最後複製一些在高併發下面需要常常需要處理的內容:
儘量使用快取，包括使用者快取，資訊快取等，多花點記憶體來做快取，可以大量減少與資料庫的互動，提高效能。
用jprofiler等工具找出效能瓶頸，減少額外的開銷。
優化資料庫查詢語句，減少直接使用hibernate等工具的直接生成語句（僅耗時較長的查詢做優化）。
優化資料庫結構，多做索引，提高查詢效率。
統計的功能儘量做快取，或按每天一統計或定時統計相關報表，避免需要時進行統計的功能。
能使用靜態頁面的地方儘量使用，減少容器的解析（儘量將動態內容生成靜態html來顯示）。
解決以上問題後，使用伺服器叢集來解決單臺的瓶頸問題。