樂觀鎖與悲觀鎖
樂觀鎖：
假設總是最好的情況
當其它線程去讀寫數據的時候，總認為不會發生問題，因此沒有上鎖，
直到數據修改完，准備提交的時候，才會上鎖，完成后釋放。
悲觀鎖：
假設總是最壞的情況
當其它線程去讀寫數據的時候，總認為別的線程會對數據進行修改，因此都會上鎖，
每次只允許一個線程對數據進行修改，其它線程會被阻塞掛起，
從數據開始修改就將數據鎖住，直到更改完才釋放鎖，
排它鎖與共享鎖
排它鎖：
寫鎖（X鎖）
在某一個時刻只能被某一個線程占有，其它線程必須等待鎖釋放之后才能獲取鎖
共享鎖：
讀鎖（S鎖）
允許多個線程同時獲取一個鎖
活鎖與死鎖
活鎖：
事務T1封鎖了數據R，事務T2又請求封鎖R，於是T2等待。
T3也請求封鎖R，當T1釋放了R上的封鎖之后系統首先批准了T3的請求，T2仍然等待。
T4又請求封鎖R，當T3釋放了R上的封鎖之后系統又批准了T4的請求……
T2有可能永遠等待，這就是活鎖的情形
線程A和B都需要過橋(都需要使用進程),而都禮讓不走(那到的系統優先級相同,都認為不是自己優先級高),就這么僵持下去.（很紳士，互相謙讓）
解決辦法：采用先來先服務
死鎖：
互相等待（拿不到資源互相占用資源）
a1已經封鎖了數據R1，正請求對數據R2封鎖，
a2已經封鎖了數據R2，正請求對數據R1封鎖，
解決辦法：一次封鎖法，每個事務必須一次將所有要使用的數據全部加鎖
餓鎖：
這是個獨木橋(單進程),橋上只能走一個人,B來到時A在橋上,B等待;
而此時比B年齡小的C來了,B讓C現行(A走完后系統把進程分給了C),
C上橋后,D又來了,B又讓D現行(C走完后系統把進程分個了D)
以此類推B一直是等待狀態.
mongodb鎖的機制
Mongodb使用讀寫鎖來允許很多用戶同時去讀一個資源，比如數據庫或者集合。讀采用的是共享鎖，寫采用的是排它鎖。
樂觀鎖的實現機制
（1）版本號機制