悲觀鎖
悲觀鎖（Pessimistic Lock），顧名思義，就是很悲觀，每次去拿數據的時候都認為別人會修改，所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會block直到它拿到鎖。
悲觀鎖：假定會發生并發沖突，屏蔽一切可能違反數據完整性的操作。
Java synchronized 就屬于悲觀鎖的一種實現，每次線程要修改數據時都先獲得鎖，保證同一時刻只有一個線程能操作數據，其他線程則會被block。
樂觀鎖
樂觀鎖（Optimistic Lock），顧名思義，就是很樂觀，每次去拿數據的時候都認為別人不會修改，所以不會上鎖，但是在提交更新的時候會判斷一下在此期間別人有沒有去更新這個數據。樂觀鎖適用于讀多寫少的應用場景，這樣可以提高吞吐量。
樂觀鎖：假設不會發生并發沖突，只在提交操作時檢查是否違反數據完整性。
樂觀鎖一般來說有以下2種方式：
- 使用數據版本（Version）記錄機制實現，這是樂觀鎖最常用的一種實現方式。何謂數據版本？即為數據增加一個版本標識，一般是通過為數據庫表增加一個數字類型的 “version” 字段來實現。當讀取數據時，將version字段的值一同讀出，數據每更新一次，對此version值加一。當我們提交更新的時候，判斷數據庫表對應記錄的當前版本信息與第一次取出來的version值進行比對，如果數據庫表當前版本號與第一次取出來的version值相等，則予以更新，否則認為是過期數據。
- 使用時間戳（timestamp）。樂觀鎖定的第二種實現方式和第一種差不多，同樣是在需要樂觀鎖控制的table中增加一個字段，名稱無所謂，字段類型使用時間戳（timestamp）, 和上面的version類似，也是在更新提交的時候檢查當前數據庫中數據的時間戳和自己更新前取到的時間戳進行對比，如果一致則OK，否則就是版本沖突。
Java JUC中的atomic包就是樂觀鎖的一種實現，AtomicInteger 通過CAS（Compare And Set）操作實現線程安全的自增。
MySQL隱式和顯示鎖定
MySQL InnoDB采用的是兩階段鎖定協議（two-phase locking protocol）。在事務執行過程中，隨時都可以執行鎖定，鎖只有在執行 COMMIT或者ROLLBACK的時候才會釋放，并且所有的鎖是在同一時刻被釋放。前面描述的鎖定都是隱式鎖定，InnoDB會根據事務隔離級別在需要的時候自動加鎖。
另外，InnoDB也支持通過特定的語句進行顯示鎖定，這些語句不屬于SQL規范：
- SELECT ... LOCK IN SHARE MODE
- SELECT ... FOR UPDATE
實戰
接下來，我們通過一個具體案例來進行分析：考慮電商系統中的下單流程，商品的庫存量是固定的，如何保證商品數量不超賣？ 其實需要保證數據一致性：某個人點擊秒殺后系統中查出來的庫存量和實際扣減庫存時庫存量的一致性就可以。
假設，MySQL數據庫中商品庫存表tb_product_stock 結構定義如下：
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 '庫存數量',
`create_time` DATETIME NOT NULL COMMENT '創建時間',
`modify_time` DATETIME NOT NULL COMMENT '更新時間',
PRIMARY KEY (`id`),
UNIQUE KEY `index_pid` (`product_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='商品庫存表';
對應的POJO類：
class ProductStock {
private Long productId; //商品id
private Integer number; //庫存量
public Long getProductId() {
return productId;
}
public void setProductId(Long productId) {
this.productId = productId;
}
public Integer getNumber() {
return number;
}
public void setNumber(Integer number) {
this.number = number;
}
}
不考慮并發的情況下，更新庫存代碼如下：
/**
* 更新庫存(不考慮并發)
* @param productId
* @return
*/
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;
}
多線程并發情況下，會存在超賣的可能。
悲觀鎖
/**
* 更新庫存(使用悲觀鎖)
* @param productId
* @return
*/
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;
}
樂觀鎖
/**
* 下單減庫存
* @param productId
* @return
*/
public boolean updateStock(Long productId){
int updateCnt = 0;
while (updateCnt == 0) {
ProductStock product = query("SELECT * FROM tb_product_stock WHERE product_id=#{productId}", productId);
if (product.getNumber() > 0) {
updateCnt = update("UPDATE tb_product_stock SET number=number-1 WHERE product_id=#{productId} AND number=#{number}", productId, product.getNumber());
if(updateCnt > 0){ //更新庫存成功
return true;
}
} else { //賣完啦
return false;
}
}
return false;
}
使用樂觀鎖更新庫存的時候不加鎖，當提交更新時需要判斷數據是否已經被修改（AND number=#{number}），只有在 number等于上一次查詢到的number時 才提交更新。
** 注意** ：UPDATE 語句的WHERE 條件字句上需要建索引
樂觀鎖與悲觀鎖的區別
樂觀鎖的思路一般是表中增加版本字段，更新時where語句中增加版本的判斷，算是一種CAS（Compare And Swep）操作，商品庫存場景中number起到了版本控制（相當于version）的作用（ AND number=#{number}）。
悲觀鎖之所以是悲觀，在于他認為本次操作會發生并發沖突，所以一開始就對商品加上鎖（SELECT ... FOR UPDATE），然后就可以安心的做判斷和更新，因為這時候不會有別人更新這條商品庫存。
小結
這里我們通過 MySQL 樂觀鎖與悲觀鎖 解決并發更新庫存的問題，當然還有其它解決方案，例如使用 分布式鎖。目前常見分布式鎖實現有兩種：基于Redis和基于Zookeeper，基于這兩種 業界也有開源的解決方案，例如 Redisson Distributed locks 、 Apache Curator Shared Lock ，這里就不細說，網上Google 一下就有很多資料。
