樂觀鎖與悲觀鎖

樂觀鎖

---

　　樂觀鎖(Optimistic Lock), 顧名思義，就是很樂觀，每次去拿數據的時候都認爲別人不會修改，因此不會上鎖，可是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可使用版本號等機制。樂觀鎖適用於多讀的應用類型，這樣能夠提升吞吐量，像數據庫若是提供相似於write_condition機制的其實都是提供的樂觀鎖。
　　CAS即是樂觀鎖技術，當多個線程嘗試使用CAS同時更新同一個變量時，只有其中一個線程能更新變量的值，而其它線程都失敗，失敗的線程並不會被掛起，而是被告知此次競爭中失敗，並能夠再次嘗試。
　　CAS有3個操做數，內存值V，舊的預期值A，要修改的新值B。當且僅當預期值A和內存值V相同時，將內存值V修改成B，不然什麼都不作。

　　JVM對CAS的支持

悲觀鎖

---

　　悲觀鎖(Pessimistic Lock), 顧名思義，就是很悲觀，每次去拿數據的時候都認爲別人會修改，因此每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會block直到它拿到鎖。傳統的關係型數據庫裏邊就用到了不少這種鎖機制，好比行鎖，表鎖等，讀鎖，寫鎖等，都是在作操做以前先上鎖。
　　好比說 synchronized 和 ReentrantLock 就是獨佔鎖，他假設最壞的狀況，而且只有在確保其它線程不會形成干擾的狀況下執行，會致使其它全部須要鎖的線程掛起，等待持有鎖的線程釋放鎖。

　　缺點：
　　因爲在進程掛起和恢復執行過程當中存在着很大的開銷。當一個線程正在等待鎖時，它不能作任何事。舉個栗子，若是一個線程須要某個資源，可是這個資源的佔用時間很短，當線程第一次搶佔這個資源時，可能這個資源被佔用，若是此時掛起這個線程，可能馬上就發現資源可用，而後又須要花費很長的時間從新搶佔鎖，時間代價就會很是的高。