本質(zhì)： 悲觀鎖和樂觀鎖都是一種概念和認知。數(shù)據(jù)庫有java語言都有對應(yīng)的實現(xiàn)方式。
悲觀鎖
悲觀鎖（Pessimistic Lock），顧名思義，就是很悲觀，每次去拿數(shù)據(jù)的時候都認為別人會修改，所以每次在拿數(shù)據(jù)的時候都會上鎖，這樣別人想拿這個數(shù)據(jù)就會block直到它拿到鎖。
悲觀鎖：假定會發(fā)生并發(fā)沖突，屏蔽一切可能違反數(shù)據(jù)完整性的操作。
SELECT ... LOCK IN SHARE MODE - 共享鎖
SELECT ... FOR UPDATE -排它鎖（悲觀鎖）
SELECT * FROM tb_product_stock WHERE product_id=101 FOR UPDATE -悲觀鎖，每次查詢數(shù)據(jù)時候都認為會有其他人修改，都加鎖。
Java synchronized鎖 就屬于悲觀鎖的一種實現(xiàn)，每次線程要修改數(shù)據(jù)時都先獲得鎖，保證同一時刻只有一個線程能操作數(shù)據(jù)，其他線程則會被block。
樂觀鎖
樂觀鎖（Optimistic Lock），顧名思義，就是很樂觀，每次去拿數(shù)據(jù)的時候都認為別人不會修改，所以不會上鎖，但是在提交更新的時候會判斷一下在此期間別人有沒有去更新這個數(shù)據(jù)。樂觀鎖適用于讀多寫少的應(yīng)用場景，這樣可以提高吞吐量。
樂觀鎖：假設(shè)不會發(fā)生并發(fā)沖突，只在提交操作時檢查是否違反數(shù)據(jù)完整性。
java樂觀鎖實現(xiàn) CAS鎖
數(shù)據(jù)庫樂觀鎖一般來說有以下2種方式：
1.使用數(shù)據(jù)版本（Version）記錄機制實現(xiàn)，這是樂觀鎖最常用的一種實現(xiàn)方式。何謂數(shù)據(jù)版本？即為數(shù)據(jù)增加一個版本標識，一般是通過為數(shù)據(jù)庫表增加一個數(shù)字類型的 “version” 字段來實現(xiàn)。當讀取數(shù)據(jù)時，將version字段的值一同讀出，數(shù)據(jù)每更新一次，對此version值加一。當我們提交更新的時候，判斷數(shù)據(jù)庫表對應(yīng)記錄的當前版本信息與第一次取出來的version值進行比對，如果數(shù)據(jù)庫表當前版本號與第一次取出來的version值相等，則予以更新，否則認為是過期數(shù)據(jù)。
UPDATE tb_product_stock SET number=number-1, version=version+1 WHERE product_id=#{productId} and version=#{version} AND number=#{number}?-樂觀鎖,每次取數(shù)據(jù)時候認為別人不會修改，只在提交更新時候?qū)Ρ葀ersion，版本跟當初取數(shù)據(jù)時候版本一致則更新成功，否則更新失敗。提高吞吐量。缺點: 高并發(fā)情況下由于并發(fā)更新頻繁，導(dǎo)致樂觀鎖頻繁更新失敗，處理效率不高
2.使用時間戳（timestamp）。樂觀鎖定的第二種實現(xiàn)方式和第一種差不多，同樣是在需要樂觀鎖控制的table中增加一個字段，名稱無所謂，字段類型使用時間戳（timestamp）, 和上面的version類似，也是在更新提交的時候檢查當前數(shù)據(jù)庫中數(shù)據(jù)的時間戳和自己更新前取到的時間戳進行對比，如果一致則OK，否則就是版本沖突。
示例： 商品扣庫存
CREATE TABLE `tb_product_stock` (
`id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '自增ID',
`product_id` bigint(32) NOT NULL COMMENT '商品ID',
`number` INT(8) NOT NULL DEFAULT 0 COMMENT '庫存數(shù)量',
`version` INT(8) NOT NULL DEFAULT 0 COMMENT '數(shù)據(jù)版本',
`create_time` DATETIME NOT NULL COMMENT '創(chuàng)建時間',
`modify_time` DATETIME NOT NULL COMMENT '更新時間',
PRIMARY KEY (`id`),
UNIQUE KEY `index_pid` (`product_id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='商品庫存表';
不考慮并發(fā)的情況下，更新庫存代碼如下:
// 更新庫存(不考慮并發(fā))
public boolean updateStockRaw(Long productId){
? ? ProductStock product = query("SELECT * FROM tb_product_stock WHERE product_id=#{productId}", productId);
? ? if (product.getNumber() > 0) {
? ? ? ? int updateCnt = update("UPDATE tb_product_stock SET number=number-1 WHERE product_id=#{productId}", productId);
? ? ? ? if(updateCnt > 0){? ? //更新庫存成功
? ? ? ? ? ? return true;
? ? ? ? ?}
? ? }
? ?return false;
?}
悲觀鎖
// 更新庫存(使用悲觀鎖)
public boolean updateStock(Long productId){
//先鎖定商品庫存記錄
ProductStock product = query("SELECT * FROM tb_product_stock WHERE product_id=#{productId} FOR UPDATE", productId);
if (product.getNumber() > 0) {
? ? int updateCnt = update("UPDATE tb_product_stock SET number=number-1 WHERE product_id=#{productId}", productId);
? ? if(updateCnt > 0){? ? //更新庫存成功?
? ? ? ? return true;
? ? }
?}
return false;
}
樂觀鎖
public boolean updateStock(Long productId){
int updateCnt = 0;
while (updateCnt == 0) {
? ? ProductStock product = query("SELECT * FROM tb_product_stock WHERE product_id=#{productId}", productId);
? ? ? ? // 首先讀取行記錄 version字段，然后通過樂觀鎖 帶著version字段去更新原紀錄，如果沒有并發(fā)更新則會成功更新，如果有并發(fā)更新則會更新失敗，需要重試處理。
? ? ? ? updateCnt = update("UPDATE tb_product_stock SET number=number-1, version=version+1 WHERE product_id=#{productId} and version=#{version} AND number=#{number}", productId, product.getVersion(), product.getNumber());
? ? ? ? if(updateCnt > 0){? ? //更新庫存成功
? ? ? ? ? ? ?return true;
? ? ? ? ?} else {
? ? ? ? ? ? ?return false;
????????}
}
樂觀鎖與悲觀鎖的區(qū)別
樂觀鎖的思路一般是表中增加version版本字段，更新時where語句中增加版本的判斷，算是一種CAS（Compare And Swep）操作，商品庫存場景中起到了版本控制的作用
悲觀鎖之所以是悲觀，在于他認為本次操作會發(fā)生并發(fā)沖突，所以一開始就對商品加上鎖（SELECT ... FOR UPDATE），然后就可以安心的做判斷和更新，因為這時候不會有別人更新這條商品庫存。
數(shù)據(jù)庫樂觀鎖高并發(fā)性能不是很好，更好的解決方案：
分布式鎖： 1.Redis分布式鎖(AP模型) 2.zk分布式鎖 3.etcd分布式鎖（CP模型）
