為什麼需要鎖（併發控制）？
在多使用者環境中，在同一時間可能會有多個使用者更新相同的記錄，這會產生衝突。這就是著名的併發性問題。
典型的衝突有：
丟失更新：乙個事務的更新覆蓋了其它事務的更新結果，就是所謂的更新丟失。例如：使用者a把值從6改為2，使用者b把值從2改為6，則使用者a丟失了他的更新。
髒讀：當乙個事務讀取其它完成一半事務的記錄時，就會發生髒讀取。例如：使用者a,b看到的值都是6，使用者b把值改為2，使用者a讀到的值仍為6。
為了解決這些併發帶來的問題。 我們需要引入併發控制機制。
悲觀鎖：假定會發生併發衝突，遮蔽一切可能違反資料完整性的操作。
樂觀鎖：假設不會發生併發衝突，只在提交操作時檢查是否違反資料完整性。樂觀鎖不能解決髒讀的問題。
樂觀鎖介紹：
樂觀鎖（ optimistic locking ） 相對悲觀鎖而言，樂觀鎖假設認為資料一般情況下不會造成衝突，所以在資料進行提交更新的時候，
才會正式對資料的衝突與否進行檢測，如果發現衝突了，則讓返回使用者錯誤的資訊，讓使用者決定如何去做。那麼我們如何實現樂觀鎖呢，一般來說有以下2種方式：
1.使用資料版本（version）記錄機制實現，這是樂觀鎖最常用的一種實現方式。何謂資料版本？即為資料增加乙個版本標識，
一般是通過為資料庫表增加乙個數字型別的 「version」 欄位來實現。當讀取資料時，將version欄位的值一同讀出，資料每更新一次，
對此version值加一。當我們提交更新的時候，判斷資料庫表對應記錄的當前版本資訊與第一次取出來的version值進行比對，
如果資料庫表當前版本號與第一次取出來的version值相等，則予以更新，否則認為是過期資料。用下面的一張圖來說明：
2,樂觀鎖定的第二種實現方式和第一種差不多，同樣是在需要樂觀鎖控制的table中增加乙個字段，名稱無所謂，字段型別使用時間戳（timestamp）, 和上面的version類似，也是在更新提交的時候檢查當前資料庫中資料的時間戳和自己更新前取到的時間戳進行對比，如果一致則ok，否則就是版本衝突。
悲觀鎖應用
需要使用資料庫的鎖機制，比如sql server 的tablockx（排它表鎖） 此選項被選中時，sql server 將在整個表上置排它鎖直至該命令或事務結束。這將防止其他程序讀取或修改表中的資料。
結論在實際生產環境裡邊,如果併發量不大且不允許髒讀，可以使用悲觀鎖解決併發問題；但如果系統的併發非常大的話,悲觀鎖定會帶來非常大的效能問題,所以我們就要選擇樂觀鎖定的方法。
悲觀鎖與樂觀鎖
悲觀鎖與樂觀鎖 悲觀鎖 pessimistic locking 顧名思義就是採用一種悲觀的態度來對待事務併發問題，我們認為系統中的併發更新會非常頻繁，並且事務失敗 了以後重來的開銷很大，這樣以來，我們就需要採用真正意義上的鎖來進行實現。悲觀鎖的基本思想就是每次一 個事務讀取某一條記錄後，就會把這條記...
樂觀鎖與悲觀鎖
悲觀鎖 pessimistic locking 顧名思義就是採用一種悲觀的態度來對待事務併發問題，我們認為系統中的併發更新會非常頻繁，並且事務失敗了以後重來的開銷很大，這樣以來，我們就需要採用真正意義上的鎖來進行實現。悲觀鎖的基本思想就是每次乙個事務讀取某一條記錄後，就會把這條記錄鎖住，這樣 其它的...
樂觀鎖與悲觀鎖
鎖 locking 這個概念在我們學習多執行緒的時候曾經接觸過，其實這裡的鎖和多執行緒裡面處理併發的鎖是乙個道理，都是暴力的把資源歸為自己所有。這裡我們用到鎖的目的就是通過一些機制來保證一些資料在某個操作過程中不會被外界修改，這樣的機制，在這裡，也就是所謂的 鎖 即給我們選定的目標資料上鎖，使其無法...