悲觀鎖介紹（百科）：

悲觀鎖，正如其名，它指的是對數(shù)據(jù)被外界（包括本系統(tǒng)當(dāng)前的其他事務(wù)，以及來自外部系統(tǒng)的事務(wù)處理）修改持保守態(tài)度，因此，在整個(gè)數(shù)據(jù)處理過程中，將數(shù)據(jù)處于鎖定狀態(tài)。悲觀鎖的實(shí)現(xiàn)，往往依靠數(shù)據(jù)庫提供的鎖機(jī)制（也只有數(shù)據(jù)庫層提供的鎖機(jī)制才能真正保證數(shù)據(jù)訪問的排他性，否則，即使在本系統(tǒng)中實(shí)現(xiàn)了加鎖機(jī)制，也無法保證外部系統(tǒng)不會(huì)修改數(shù)據(jù)）。

使用場景舉例：以MySQL InnoDB為例

商品goods表中有一個(gè)字段status，status為1代表商品未被下單，status為2代表商品已經(jīng)被下單，那么我們對某個(gè)商品下單時(shí)必須確保該商品status為1。假設(shè)商品的id為1。

1如果不采用鎖，那么操作方法如下：

//1.查詢出商品信息

select status from t_goods where id=1;

//2.根據(jù)商品信息生成訂單

insert into t_orders (id,goods_id) values (null,1);

//3.修改商品status為2

update t_goods set status=2;

上面這種場景在高并發(fā)訪問的情況下很可能會(huì)出現(xiàn)問題。

前面已經(jīng)提到，只有當(dāng)goods status為1時(shí)才能對該商品下單，上面第一步操作中，查詢出來的商品status為1。但是當(dāng)我們執(zhí)行第三步Update操作的時(shí)候，有可能出現(xiàn)其他人先一步對商品下單把goods status修改為2了，但是我們并不知道數(shù)據(jù)已經(jīng)被修改了，這樣就可能造成同一個(gè)商品被下單2次，使得數(shù)據(jù)不一致。所以說這種方式是不安全的。

2使用悲觀鎖來實(shí)現(xiàn)：

在上面的場景中，商品信息從查詢出來到修改，中間有一個(gè)處理訂單的過程，使用悲觀鎖的原理就是，當(dāng)我們在查詢出goods信息后就把當(dāng)前的數(shù)據(jù)鎖定，直到我們修改完畢后再解鎖。那么在這個(gè)過程中，因?yàn)間oods被鎖定了，就不會(huì)出現(xiàn)有第三者來對其進(jìn)行修改了。

注：要使用悲觀鎖，我們必須關(guān)閉mysql數(shù)據(jù)庫的自動(dòng)提交屬性，因?yàn)镸ySQL默認(rèn)使用autocommit模式，也就是說，當(dāng)你執(zhí)行一個(gè)更新操作后，MySQL會(huì)立刻將結(jié)果進(jìn)行提交。

我們可以使用命令設(shè)置MySQL為非autocommit模式：

set autocommit=0;

設(shè)置完autocommit后，我們就可以執(zhí)行我們的正常業(yè)務(wù)了。具體如下：

//0.開始事務(wù)

begin;/begin work;/start transaction; (三者選一就可以)

//1.查詢出商品信息

select status from t_goods where id=1for update;

//2.根據(jù)商品信息生成訂單

insert into t_orders (id,goods_id) values (null,1);

//3.修改商品status為2

update t_goods set status=2;

//4.提交事務(wù)

commit;/commit work;

注：上面的begin/commit為事務(wù)的開始和結(jié)束，因?yàn)樵谇耙徊轿覀冴P(guān)閉了mysql的autocommit，所以需要手動(dòng)控制事務(wù)的提交，在這里就不細(xì)表了。

上面的第一步我們執(zhí)行了一次查詢操作：select status from t_goods where id=1 for update;

與普通查詢不一樣的是，我們使用了select…for update的方式，這樣就通過數(shù)據(jù)庫實(shí)現(xiàn)了悲觀鎖。此時(shí)在t_goods表中，id為1的 那條數(shù)據(jù)就被我們鎖定了，其它的事務(wù)必須等本次事務(wù)提交之后才能執(zhí)行。這樣我們可以保證當(dāng)前的數(shù)據(jù)不會(huì)被其它事務(wù)修改。

注：需要注意的是，在事務(wù)中，只有SELECT ... FOR UPDATE 或LOCK IN SHARE MODE 同一筆數(shù)據(jù)時(shí)會(huì)等待其它事務(wù)結(jié)束后才執(zhí)行，一般SELECT ... 則不受此影響。拿上面的實(shí)例來說，當(dāng)我執(zhí)行select status from t_goods where id=1 for update;后。我在另外的事務(wù)中如果再次執(zhí)行select status from t_goods where id=1 for update;則第二個(gè)事務(wù)會(huì)一直等待第一個(gè)事務(wù)的提交，此時(shí)第二個(gè)查詢處于阻塞的狀態(tài)，但是如果我是在第二個(gè)事務(wù)中執(zhí)行select status from t_goods where id=1;則能正常查詢出數(shù)據(jù)，不會(huì)受第一個(gè)事務(wù)的影響。

補(bǔ)充：MySQL select…for update的Row Lock與Table Lock

上面我們提到，使用select…for update會(huì)把數(shù)據(jù)給鎖住，不過我們需要注意一些鎖的級別，MySQL InnoDB默認(rèn)Row-Level Lock，所以只有「明確」地指定主鍵，MySQL 才會(huì)執(zhí)行Row lock (只鎖住被選取的數(shù)據(jù)) ，否則MySQL 將會(huì)執(zhí)行Table Lock (將整個(gè)數(shù)據(jù)表單給鎖住)。

但是悲觀鎖并不是適用于任何場景，它也有它存在的一些不足，因?yàn)楸^鎖大多數(shù)情況下依靠數(shù)據(jù)庫的鎖機(jī)制實(shí)現(xiàn)，以保證操作最大程度的獨(dú)占性。如果加鎖的時(shí)間過長，其他用戶長時(shí)間無法訪問，影響了程序的并發(fā)訪問性，同時(shí)這樣對數(shù)據(jù)庫性能開銷影響也很大，特別是對長事務(wù)而言，這樣的開銷往往無法承受。所以與悲觀鎖相對的，我們有了樂觀鎖，具體參見下面介紹：

樂觀鎖介紹：

樂觀鎖（ Optimistic Locking ） 相對悲觀鎖而言，樂觀鎖假設(shè)認(rèn)為數(shù)據(jù)一般情況下不會(huì)造成沖突，所以在數(shù)據(jù)進(jìn)行提交更新的時(shí)候，才會(huì)正式對數(shù)據(jù)的沖突與否進(jìn)行檢測，如果發(fā)現(xiàn)沖突了，則讓返回用戶錯(cuò)誤的信息，讓用戶決定如何去做。那么我們?nèi)绾螌?shí)現(xiàn)樂觀鎖呢，一般來說有以下2種方式：

1.使用數(shù)據(jù)版本（Version）記錄機(jī)制實(shí)現(xiàn)，這是樂觀鎖最常用的一種實(shí)現(xiàn)方式。何謂數(shù)據(jù)版本？即為數(shù)據(jù)增加一個(gè)版本標(biāo)識，一般是通過為數(shù)據(jù)庫表增加一個(gè)數(shù)字類型的 “version” 字段來實(shí)現(xiàn)。當(dāng)讀取數(shù)據(jù)時(shí)，將version字段的值一同讀出，數(shù)據(jù)每更新一次，對此version值加一。當(dāng)我們提交更新的時(shí)候，判斷數(shù)據(jù)庫表對應(yīng)記錄的當(dāng)前版本信息與第一次取出來的version值進(jìn)行比對，如果數(shù)據(jù)庫表當(dāng)前版本號與第一次取出來的version值相等，則予以更新，否則認(rèn)為是過期數(shù)據(jù)。用下面的一張圖來說明：