學(xué)過(guò)Java多線程的應(yīng)該都知道什么是鎖，沒(méi)學(xué)過(guò)的也不用擔(dān)心，Java中的鎖可以簡(jiǎn)單的理解為多線程情況下訪問(wèn)臨界資源的一種線程同步機(jī)制。
在學(xué)習(xí)或者使用Java的過(guò)程中進(jìn)程會(huì)遇到各種各樣的鎖的概念：公平鎖、非公平鎖、自旋鎖、可重入鎖、偏向鎖、輕量級(jí)鎖、重量級(jí)鎖、讀寫鎖、互斥鎖等。
蒙了嗎？不要緊！即使你這些都不會(huì)也不要緊，因?yàn)檫@個(gè)和今天要探討的關(guān)系不大，不過(guò)如果你作為一個(gè)愛(ài)學(xué)習(xí)的小伙伴，這里也給你準(zhǔn)備了一份秘籍：《Java多線程核心技術(shù)》，一共19篇祝你一臂之力！免費(fèi)版的不過(guò)癮，當(dāng)然也有收費(fèi)版的！
一、為什么要使用分布式鎖
我們?cè)陂_(kāi)發(fā)應(yīng)用的時(shí)候，如果需要對(duì)某一個(gè)共享變量進(jìn)行多線程同步訪問(wèn)的時(shí)候，可以使用我們學(xué)到的Java多線程的18般武藝進(jìn)行處理，并且可以完美的運(yùn)行，毫無(wú)Bug！
注意這是單機(jī)應(yīng)用，也就是所有的請(qǐng)求都會(huì)分配到當(dāng)前服務(wù)器的JVM內(nèi)部，然后映射為操作系統(tǒng)的線程進(jìn)行處理！而這個(gè)共享變量只是在這個(gè)JVM內(nèi)部的一塊內(nèi)存空間！
后來(lái)業(yè)務(wù)發(fā)展，需要做集群，一個(gè)應(yīng)用需要部署到幾臺(tái)機(jī)器上然后做負(fù)載均衡，大致如下圖：
上圖可以看到，變量A存在JVM1、JVM2、JVM3三個(gè)JVM內(nèi)存中（這個(gè)變量A主要體現(xiàn)是在一個(gè)類中的一個(gè)成員變量，是一個(gè)有狀態(tài)的對(duì)象，例如：UserController控制器中的一個(gè)整形類型的成員變量），如果不加任何控制的話，變量A同時(shí)都會(huì)在JVM分配一塊內(nèi)存，三個(gè)請(qǐng)求發(fā)過(guò)來(lái)同時(shí)對(duì)這個(gè)變量操作，顯然結(jié)果是不對(duì)的！即使不是同時(shí)發(fā)過(guò)來(lái)，三個(gè)請(qǐng)求分別操作三個(gè)不同JVM內(nèi)存區(qū)域的數(shù)據(jù)，變量A之間不存在共享，也不具有可見(jiàn)性，處理的結(jié)果也是不對(duì)的！
如果我們業(yè)務(wù)中確實(shí)存在這個(gè)場(chǎng)景的話，我們就需要一種方法解決這個(gè)問(wèn)題！
為了保證一個(gè)方法或?qū)傩栽诟卟l(fā)情況下的同一時(shí)間只能被同一個(gè)線程執(zhí)行，在傳統(tǒng)單體應(yīng)用單機(jī)部署的情況下，可以使用Java并發(fā)處理相關(guān)的API(如ReentrantLock或Synchronized)進(jìn)行互斥控制。在單機(jī)環(huán)境中，Java中提供了很多并發(fā)處理相關(guān)的API。但是，隨著業(yè)務(wù)發(fā)展的需要，原單體單機(jī)部署的系統(tǒng)被演化成分布式集群系統(tǒng)后，由于分布式系統(tǒng)多線程、多進(jìn)程并且分布在不同機(jī)器上，這將使原單機(jī)部署情況下的并發(fā)控制鎖策略失效，單純的Java API并不能提供分布式鎖的能力。為了解決這個(gè)問(wèn)題就需要一種跨JVM的互斥機(jī)制來(lái)控制共享資源的訪問(wèn)，這就是分布式鎖要解決的問(wèn)題！
二、分布式鎖應(yīng)該具備哪些條件
在分析分布式鎖的三種實(shí)現(xiàn)方式之前，先了解一下分布式鎖應(yīng)該具備哪些條件：
1、在分布式系統(tǒng)環(huán)境下，一個(gè)方法在同一時(shí)間只能被一個(gè)機(jī)器的一個(gè)線程執(zhí)行；
2、高可用的獲取鎖與釋放鎖；
3、高性能的獲取鎖與釋放鎖；
4、具備可重入特性；
5、具備鎖失效機(jī)制，防止死鎖；
6、具備非阻塞鎖特性，即沒(méi)有獲取到鎖將直接返回獲取鎖失敗。
三、分布式鎖的三種實(shí)現(xiàn)方式
目前幾乎很多大型網(wǎng)站及應(yīng)用都是分布式部署的，分布式場(chǎng)景中的數(shù)據(jù)一致性問(wèn)題一直是一個(gè)比較重要的話題。分布式的CAP理論告訴我們“任何一個(gè)分布式系統(tǒng)都無(wú)法同時(shí)滿足一致性（Consistency）、可用性（Availability）和分區(qū)容錯(cuò)性（Partition tolerance），最多只能同時(shí)滿足兩項(xiàng)?！彼?，很多系統(tǒng)在設(shè)計(jì)之初就要對(duì)這三者做出取舍。在互聯(lián)網(wǎng)領(lǐng)域的絕大多數(shù)的場(chǎng)景中，都需要犧牲強(qiáng)一致性來(lái)?yè)Q取系統(tǒng)的高可用性，系統(tǒng)往往只需要保證“最終一致性”，只要這個(gè)最終時(shí)間是在用戶可以接受的范圍內(nèi)即可。
在很多場(chǎng)景中，我們?yōu)榱吮ＷC數(shù)據(jù)的最終一致性，需要很多的技術(shù)方案來(lái)支持，比如分布式事務(wù)、分布式鎖等。有的時(shí)候，我們需要保證一個(gè)方法在同一時(shí)間內(nèi)只能被同一個(gè)線程執(zhí)行。
基于數(shù)據(jù)庫(kù)實(shí)現(xiàn)分布式鎖；
基于緩存（Redis等）實(shí)現(xiàn)分布式鎖；
基于Zookeeper實(shí)現(xiàn)分布式鎖；
盡管有這三種方案，但是不同的業(yè)務(wù)也要根據(jù)自己的情況進(jìn)行選型，他們之間沒(méi)有最好只有更適合！
四、基于數(shù)據(jù)庫(kù)的實(shí)現(xiàn)方式
基于數(shù)據(jù)庫(kù)的實(shí)現(xiàn)方式的核心思想是：在數(shù)據(jù)庫(kù)中創(chuàng)建一個(gè)表，表中包含方法名等字段，并在方法名字段上創(chuàng)建唯一索引，想要執(zhí)行某個(gè)方法，就使用這個(gè)方法名向表中插入數(shù)據(jù)，成功插入則獲取鎖，執(zhí)行完成后刪除對(duì)應(yīng)的行數(shù)據(jù)釋放鎖。
（1）創(chuàng)建一個(gè)表：
DROP TABLE IF EXISTS `method_lock`;
CREATE TABLE `method_lock` (
? `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '主鍵',
? `method_name` varchar(64) NOT NULL COMMENT '鎖定的方法名',
? `desc` varchar(255) NOT NULL COMMENT '備注信息',
? `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
? PRIMARY KEY (`id`),
? UNIQUE KEY `uidx_method_name` (`method_name`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COMMENT='鎖定中的方法';
1
2
3
4
5
6
7
8
9
（2）想要執(zhí)行某個(gè)方法，就使用這個(gè)方法名向表中插入數(shù)據(jù)：
INSERT INTO method_lock (method_name, desc) VALUES ('methodName', '測(cè)試的methodName');
1
因?yàn)槲覀儗?duì)method_name做了唯一性約束，這里如果有多個(gè)請(qǐng)求同時(shí)提交到數(shù)據(jù)庫(kù)的話，數(shù)據(jù)庫(kù)會(huì)保證只有一個(gè)操作可以成功，那么我們就可以認(rèn)為操作成功的那個(gè)線程獲得了該方法的鎖，可以執(zhí)行方法體內(nèi)容。
（3）成功插入則獲取鎖，執(zhí)行完成后刪除對(duì)應(yīng)的行數(shù)據(jù)釋放鎖：
delete from method_lock where method_name ='methodName';
1
注意：這只是使用基于數(shù)據(jù)庫(kù)的一種方法，使用數(shù)據(jù)庫(kù)實(shí)現(xiàn)分布式鎖還有很多其他的玩法！
使用基于數(shù)據(jù)庫(kù)的這種實(shí)現(xiàn)方式很簡(jiǎn)單，但是對(duì)于分布式鎖應(yīng)該具備的條件來(lái)說(shuō)，它有一些問(wèn)題需要解決及優(yōu)化：
1、因?yàn)槭腔跀?shù)據(jù)庫(kù)實(shí)現(xiàn)的，數(shù)據(jù)庫(kù)的可用性和性能將直接影響分布式鎖的可用性及性能，所以，數(shù)據(jù)庫(kù)需要雙機(jī)部署、數(shù)據(jù)同步、主備切換；
2、不具備可重入的特性，因?yàn)橥粋€(gè)線程在釋放鎖之前，行數(shù)據(jù)一直存在，無(wú)法再次成功插入數(shù)據(jù)，所以，需要在表中新增一列，用于記錄當(dāng)前獲取到鎖的機(jī)器和線程信息，在再次獲取鎖的時(shí)候，先查詢表中機(jī)器和線程信息是否和當(dāng)前機(jī)器和線程相同，若相同則直接獲取鎖；
3、沒(méi)有鎖失效機(jī)制，因?yàn)橛锌赡艹霈F(xiàn)成功插入數(shù)據(jù)后，服務(wù)器宕機(jī)了，對(duì)應(yīng)的數(shù)據(jù)沒(méi)有被刪除，當(dāng)服務(wù)恢復(fù)后一直獲取不到鎖，所以，需要在表中新增一列，用于記錄失效時(shí)間，并且需要有定時(shí)任務(wù)清除這些失效的數(shù)據(jù)；
4、不具備阻塞鎖特性，獲取不到鎖直接返回失敗，所以需要優(yōu)化獲取邏輯，循環(huán)多次去獲取。
5、在實(shí)施的過(guò)程中會(huì)遇到各種不同的問(wèn)題，為了解決這些問(wèn)題，實(shí)現(xiàn)方式將會(huì)越來(lái)越復(fù)雜；依賴數(shù)據(jù)庫(kù)需要一定的資源開(kāi)銷，性能問(wèn)題需要考慮。
五、基于Redis的實(shí)現(xiàn)方式
1、選用Redis實(shí)現(xiàn)分布式鎖原因：
（1）Redis有很高的性能；
（2）Redis命令對(duì)此支持較好，實(shí)現(xiàn)起來(lái)比較方便
2、使用命令介紹：
（1）SETNX
SETNX key val：當(dāng)且僅當(dāng)key不存在時(shí)，set一個(gè)key為val的字符串，返回1；若key存在，則什么都不做，返回0。
1
（2）expire
expire key timeout：為key設(shè)置一個(gè)超時(shí)時(shí)間，單位為second，超過(guò)這個(gè)時(shí)間鎖會(huì)自動(dòng)釋放，避免死鎖。
1
（3）delete
delete key：刪除key
1
在使用Redis實(shí)現(xiàn)分布式鎖的時(shí)候，主要就會(huì)使用到這三個(gè)命令。
3、實(shí)現(xiàn)思想：
（1）獲取鎖的時(shí)候，使用setnx加鎖，并使用expire命令為鎖添加一個(gè)超時(shí)時(shí)間，超過(guò)該時(shí)間則自動(dòng)釋放鎖，鎖的value值為一個(gè)隨機(jī)生成的UUID，通過(guò)此在釋放鎖的時(shí)候進(jìn)行判斷。
（2）獲取鎖的時(shí)候還設(shè)置一個(gè)獲取的超時(shí)時(shí)間，若超過(guò)這個(gè)時(shí)間則放棄獲取鎖。
（3）釋放鎖的時(shí)候，通過(guò)UUID判斷是不是該鎖，若是該鎖，則執(zhí)行delete進(jìn)行鎖釋放。
4、 分布式鎖的簡(jiǎn)單實(shí)現(xiàn)代碼：
/**
* 分布式鎖的簡(jiǎn)單實(shí)現(xiàn)代碼
* Created by liuyang on 2017/4/20.
*/
public class DistributedLock {
? ? private final JedisPool jedisPool;
? ? public DistributedLock(JedisPool jedisPool) {
? ? ? ? this.jedisPool = jedisPool;
? ? }
? ? /**
? ? * 加鎖
? ? * @param lockName? ? ? 鎖的key
? ? * @param acquireTimeout 獲取超時(shí)時(shí)間
? ? * @param timeout? ? ? ? 鎖的超時(shí)時(shí)間
? ? * @return 鎖標(biāo)識(shí)
? ? */
? ? public String lockWithTimeout(String lockName, long acquireTimeout, long timeout) {
? ? ? ? Jedis conn = null;
? ? ? ? String retIdentifier = null;
? ? ? ? try {
? ? ? ? ? ? // 獲取連接
? ? ? ? ? ? conn = jedisPool.getResource();
? ? ? ? ? ? // 隨機(jī)生成一個(gè)value
? ? ? ? ? ? String identifier = UUID.randomUUID().toString();
? ? ? ? ? ? // 鎖名，即key值
? ? ? ? ? ? String lockKey = "lock:" + lockName;
? ? ? ? ? ? // 超時(shí)時(shí)間，上鎖后超過(guò)此時(shí)間則自動(dòng)釋放鎖
? ? ? ? ? ? int lockExpire = (int) (timeout / 1000);
? ? ? ? ? ? // 獲取鎖的超時(shí)時(shí)間，超過(guò)這個(gè)時(shí)間則放棄獲取鎖
? ? ? ? ? ? long end = System.currentTimeMillis() + acquireTimeout;
? ? ? ? ? ? while (System.currentTimeMillis() < end) {
? ? ? ? ? ? ? ? if (conn.setnx(lockKey, identifier) == 1) {
? ? ? ? ? ? ? ? ? ? conn.expire(lockKey, lockExpire);
? ? ? ? ? ? ? ? ? ? // 返回value值，用于釋放鎖時(shí)間確認(rèn)
? ? ? ? ? ? ? ? ? ? retIdentifier = identifier;
? ? ? ? ? ? ? ? ? ? return retIdentifier;
? ? ? ? ? ? ? ? }
? ? ? ? ? ? ? ? // 返回-1代表key沒(méi)有設(shè)置超時(shí)時(shí)間，為key設(shè)置一個(gè)超時(shí)時(shí)間
? ? ? ? ? ? ? ? if (conn.ttl(lockKey) == -1) {
? ? ? ? ? ? ? ? ? ? conn.expire(lockKey, lockExpire);
? ? ? ? ? ? ? ? }
? ? ? ? ? ? ? ? try {
? ? ? ? ? ? ? ? ? ? Thread.sleep(10);
? ? ? ? ? ? ? ? } catch (InterruptedException e) {
? ? ? ? ? ? ? ? ? ? Thread.currentThread().interrupt();
? ? ? ? ? ? ? ? }
? ? ? ? ? ? }
? ? ? ? } catch (JedisException e) {
? ? ? ? ? ? e.printStackTrace();
? ? ? ? } finally {
? ? ? ? ? ? if (conn != null) {
? ? ? ? ? ? ? ? conn.close();
? ? ? ? ? ? }
? ? ? ? }
? ? ? ? return retIdentifier;
? ? }
? ? /**
? ? * 釋放鎖
? ? * @param lockName? 鎖的key
? ? * @param identifier 釋放鎖的標(biāo)識(shí)
? ? * @return
? ? */
? ? public boolean releaseLock(String lockName, String identifier) {
? ? ? ? Jedis conn = null;
? ? ? ? String lockKey = "lock:" + lockName;
? ? ? ? boolean retFlag = false;
? ? ? ? try {
? ? ? ? ? ? conn = jedisPool.getResource();
? ? ? ? ? ? while (true) {
? ? ? ? ? ? ? ? // 監(jiān)視lock，準(zhǔn)備開(kāi)始事務(wù)
? ? ? ? ? ? ? ? conn.watch(lockKey);
? ? ? ? ? ? ? ? // 通過(guò)前面返回的value值判斷是不是該鎖，若是該鎖，則刪除，釋放鎖
? ? ? ? ? ? ? ? if (identifier.equals(conn.get(lockKey))) {
? ? ? ? ? ? ? ? ? ? Transaction transaction = conn.multi();
? ? ? ? ? ? ? ? ? ? transaction.del(lockKey);
? ? ? ? ? ? ? ? ? ? List<Object> results = transaction.exec();
? ? ? ? ? ? ? ? ? ? if (results == null) {
? ? ? ? ? ? ? ? ? ? ? ? continue;
? ? ? ? ? ? ? ? ? ? }
? ? ? ? ? ? ? ? ? ? retFlag = true;
? ? ? ? ? ? ? ? }
? ? ? ? ? ? ? ? conn.unwatch();
? ? ? ? ? ? ? ? break;
? ? ? ? ? ? }
? ? ? ? } catch (JedisException e) {
? ? ? ? ? ? e.printStackTrace();
? ? ? ? } finally {
? ? ? ? ? ? if (conn != null) {
? ? ? ? ? ? ? ? conn.close();
? ? ? ? ? ? }
? ? ? ? }
? ? ? ? return retFlag;
? ? }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
5、測(cè)試剛才實(shí)現(xiàn)的分布式鎖
例子中使用50個(gè)線程模擬秒殺一個(gè)商品，使用–運(yùn)算符來(lái)實(shí)現(xiàn)商品減少，從結(jié)果有序性就可以看出是否為加鎖狀態(tài)。
模擬秒殺服務(wù)，在其中配置了jedis線程池，在初始化的時(shí)候傳給分布式鎖，供其使用。
/**
* Created by liuyang on 2017/4/20.
*/
public class Service {
? ? private static JedisPool pool = null;
? ? private DistributedLock lock = new DistributedLock(pool);
? ? int n = 500;
? ? static {
? ? ? ? JedisPoolConfig config = new JedisPoolConfig();
? ? ? ? // 設(shè)置最大連接數(shù)
? ? ? ? config.setMaxTotal(200);
? ? ? ? // 設(shè)置最大空閑數(shù)
? ? ? ? config.setMaxIdle(8);
? ? ? ? // 設(shè)置最大等待時(shí)間
? ? ? ? config.setMaxWaitMillis(1000 * 100);
? ? ? ? // 在borrow一個(gè)jedis實(shí)例時(shí)，是否需要驗(yàn)證，若為true，則所有jedis實(shí)例均是可用的
? ? ? ? config.setTestOnBorrow(true);
? ? ? ? pool = new JedisPool(config, "127.0.0.1", 6379, 3000);
? ? }
? ? public void seckill() {
? ? ? ? // 返回鎖的value值，供釋放鎖時(shí)候進(jìn)行判斷
? ? ? ? String identifier = lock.lockWithTimeout("resource", 5000, 1000);
? ? ? ? System.out.println(Thread.currentThread().getName() + "獲得了鎖");
? ? ? ? System.out.println(--n);
? ? ? ? lock.releaseLock("resource", identifier);
? ? }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
模擬線程進(jìn)行秒殺服務(wù)：
public class ThreadA extends Thread {
? ? private Service service;
? ? public ThreadA(Service service) {
? ? ? ? this.service = service;
? ? }
? ? @Override
? ? public void run() {
? ? ? ? service.seckill();
? ? }
}
public class Test {
? ? public static void main(String[] args) {
? ? ? ? Service service = new Service();
? ? ? ? for (int i = 0; i < 50; i++) {
? ? ? ? ? ? ThreadA threadA = new ThreadA(service);
? ? ? ? ? ? threadA.start();
? ? ? ? }
? ? }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
結(jié)果如下，結(jié)果為有序的：
若注釋掉使用鎖的部分：
public void seckill() {
? ? // 返回鎖的value值，供釋放鎖時(shí)候進(jìn)行判斷
? ? //String indentifier = lock.lockWithTimeout("resource", 5000, 1000);
? ? System.out.println(Thread.currentThread().getName() + "獲得了鎖");
? ? System.out.println(--n);
? ? //lock.releaseLock("resource", indentifier);
}
1
2
3
4
5
6
7
從結(jié)果可以看出，有一些是異步進(jìn)行的：
5、基于ZooKeeper的實(shí)現(xiàn)方式
ZooKeeper是一個(gè)為分布式應(yīng)用提供一致性服務(wù)的開(kāi)源組件，它內(nèi)部是一個(gè)分層的文件系統(tǒng)目錄樹(shù)結(jié)構(gòu)，規(guī)定同一個(gè)目錄下只能有一個(gè)唯一文件名?；赯ooKeeper實(shí)現(xiàn)分布式鎖的步驟如下：
（1）創(chuàng)建一個(gè)目錄mylock；
（2）線程A想獲取鎖就在mylock目錄下創(chuàng)建臨時(shí)順序節(jié)點(diǎn)；
（3）獲取mylock目錄下所有的子節(jié)點(diǎn)，然后獲取比自己小的兄弟節(jié)點(diǎn)，如果不存在，則說(shuō)明當(dāng)前線程順序號(hào)最小，獲得鎖；
（4）線程B獲取所有節(jié)點(diǎn)，判斷自己不是最小節(jié)點(diǎn)，設(shè)置監(jiān)聽(tīng)比自己次小的節(jié)點(diǎn)；
（5）線程A處理完，刪除自己的節(jié)點(diǎn)，線程B監(jiān)聽(tīng)到變更事件，判斷自己是不是最小的節(jié)點(diǎn)，如果是則獲得鎖。
這里推薦一個(gè)Apache的開(kāi)源庫(kù)Curator，它是一個(gè)ZooKeeper客戶端，Curator提供的InterProcessMutex是分布式鎖的實(shí)現(xiàn)，acquire方法用于獲取鎖，release方法用于釋放鎖。
優(yōu)點(diǎn)：具備高可用、可重入、阻塞鎖特性，可解決失效死鎖問(wèn)題。
缺點(diǎn)：因?yàn)樾枰l繁的創(chuàng)建和刪除節(jié)點(diǎn)，性能上不如Redis方式。
