二、悲觀鎖
三、樂觀鎖和悲觀鎖的適用場景
總是認為不會產生併發的問題，每次去取資料的時候總認為不會有其他執行緒對資料進行修改，因此不會上鎖，但是在更新時會判斷其他執行緒在這之前有沒有對資料進行修改，一般使用版本號機制或cas機制來實現！
cas是樂觀鎖的一種實現方式，是一種輕量級的鎖！
原理：執行緒在讀取資料時不進行加鎖，在準備寫回資料時，先去查詢原值，操作的時候比較原值是否被修改，若為被修改則寫回，否則，重回新執行讀取流程。
因為cas操作長時間不成功的話，會導致一直自旋，相當於死迴圈，造成cpu消耗過大！
總是假設最壞情況，每次取資料時都認為其他執行緒會修改資料，所以都會加鎖，當其他執行緒想要訪問資料時，都要掛起等待。
synchronized，代表這個方法加鎖，相當於不管哪乙個執行緒（例如執行緒a），執行到這個方法時,都要檢查有沒有其它執行緒b（或者c、 d等）正在用這個方法(或者該類的其他同步方法)，有的話要等正在使用synchronized方法的執行緒b（或者c 、d）執行完這個方法後再執行此執行緒a，沒有的話，鎖定呼叫者，然後直接執行。
你可以看到在物件頭中儲存了鎖標誌位和指向 monitor 物件的起始位址，如下圖所示，右側就是物件對應的 monitor 物件。
當 monitor 被某個執行緒持有後，就會處於鎖定狀態，如圖中的 owner 部分，會指向持有 monitor 物件的執行緒。
另外 monitor 中還有兩個佇列分別是entrylist和waitlist，主要是用來存放進入及等待獲取鎖的執行緒。
如果執行緒進入，則得到當前物件鎖，那麼別的執行緒在該類所有物件上的任何操作都不能進行。
1.響應速度：如果需要非常高的響應速度，建議採用樂觀鎖方案，成功就執行，不成功就失敗，不需要等待其他併發去釋放鎖
2.衝突頻率：如果衝突頻率非常高，建議採用悲觀鎖，保證成功率，如果衝突頻率大，樂觀鎖會需要多次重試才能成功，代價比較大
3.重試代價：如果重試代價大，建議採用悲觀鎖
資料庫悲觀鎖和樂觀鎖簡述
鎖 locking 業務邏輯的實現過程中，往往需要保證資料訪問的排他性。如在金融系統的日終結算 處理中，我們希望針對某個 cut off 時間點的資料進行處理，而不希望在結算進行過程中 可能是幾秒種，也可能是幾個小時 資料再發生變化。此時，我們就需要通過一些機 制來保證這些資料在某個操作過程中不會被...
資料庫的悲觀鎖和樂觀鎖
資料庫的四種隔離級別 髒讀 不可重複讀 可重複讀 序列化，雖然四種隔離級別能夠處理事務問題，但是不夠靈活，於是有了悲觀鎖和樂觀鎖。悲觀鎖 對於外界的修改持保守態度，在整個資料處理中資料處於鎖定狀態。以mysql為例，select for update和lock in share model能夠實現悲...
資料庫的悲觀鎖和樂觀鎖
悲觀鎖就是對資料的衝突持悲觀態度，也就是假設資料肯定會發生衝突，所以在資料開始讀取的時候就把資料鎖定住。書籍表book，id為商品id 主鍵 isonline是否上線，1代表上線，0代表下線，那麼我們如果要對書籍進行下線，就需要將online置為0，假設id為1 如果不採用鎖 1 select fr...