|
很多小伙伴在學(xué)習(xí)Java的時候,，總是感覺Java多線程在實際的業(yè)務(wù)中很少使用，以至于不會花太多的時間去學(xué)習(xí),，技術(shù)債不斷累積！等到了一定程度的時候?qū)τ谂cJava多線程相關(guān)的東西就很難理解,，今天需要探討的東西也是一樣的和Java多線程相關(guān)的,！做好準(zhǔn)備，馬上開車,！ 學(xué)過Java多線程的應(yīng)該都知道什么是鎖,，沒學(xué)過的也不用擔(dān)心，Java中的鎖可以簡單的理解為多線程情況下訪問臨界資源的一種線程同步機制,。 在學(xué)習(xí)或者使用Java的過程中進程會遇到各種各樣的鎖的概念：公平鎖,、非公平鎖,、自旋鎖、可重入鎖,、偏向鎖,、輕量級鎖、重量級鎖,、讀寫鎖,、互斥鎖等。 蒙了嗎,？不要緊,！即使你這些都不會也不要緊，因為這個和今天要探討的關(guān)系不大,，不過如果你作為一個愛學(xué)習(xí)的小伙伴,，這里也給你準(zhǔn)備了一份秘籍：《Java多線程核心技術(shù)》，一共19篇祝你一臂之力,！免費版的不過癮,，當(dāng)然也有收費版的！ 一,、為什么要使用分布式鎖我們在開發(fā)應(yīng)用的時候,，如果需要對某一個共享變量進行多線程同步訪問的時候，可以使用我們學(xué)到的Java多線程的18般武藝進行處理,，并且可以完美的運行,，毫無Bug！ 注意這是單機應(yīng)用,，也就是所有的請求都會分配到當(dāng)前服務(wù)器的JVM內(nèi)部,，然后映射為操作系統(tǒng)的線程進行處理！而這個共享變量只是在這個JVM內(nèi)部的一塊內(nèi)存空間,！ 后來業(yè)務(wù)發(fā)展,，需要做集群，一個應(yīng)用需要部署到幾臺機器上然后做負載均衡,，大致如下圖： 
上圖可以看到,，變量A存在JVM1、JVM2,、JVM3三個JVM內(nèi)存中（這個變量A主要體現(xiàn)是在一個類中的一個成員變量,，是一個有狀態(tài)的對象，例如：UserController控制器中的一個整形類型的成員變量）,，如果不加任何控制的話,，變量A同時都會在JVM分配一塊內(nèi)存,，三個請求發(fā)過來同時對這個變量操作,，顯然結(jié)果是不對的,！即使不是同時發(fā)過來，三個請求分別操作三個不同JVM內(nèi)存區(qū)域的數(shù)據(jù),，變量A之間不存在共享,，也不具有可見性，處理的結(jié)果也是不對的,！ 如果我們業(yè)務(wù)中確實存在這個場景的話,，我們就需要一種方法解決這個問題！ 為了保證一個方法或?qū)傩栽诟卟l(fā)情況下的同一時間只能被同一個線程執(zhí)行,，在傳統(tǒng)單體應(yīng)用單機部署的情況下,，可以使用Java并發(fā)處理相關(guān)的API(如ReentrantLock或Synchronized)進行互斥控制。在單機環(huán)境中,，Java中提供了很多并發(fā)處理相關(guān)的API,。但是，隨著業(yè)務(wù)發(fā)展的需要,，原單體單機部署的系統(tǒng)被演化成分布式集群系統(tǒng)后,，由于分布式系統(tǒng)多線程、多進程并且分布在不同機器上,，這將使原單機部署情況下的并發(fā)控制鎖策略失效,，單純的Java API并不能提供分布式鎖的能力。為了解決這個問題就需要一種跨JVM的互斥機制來控制共享資源的訪問,，這就是分布式鎖要解決的問題,！ 二、分布式鎖應(yīng)該具備哪些條件在分析分布式鎖的三種實現(xiàn)方式之前,，先了解一下分布式鎖應(yīng)該具備哪些條件： 1,、在分布式系統(tǒng)環(huán)境下，一個方法在同一時間只能被一個機器的一個線程執(zhí)行,；
2,、高可用的獲取鎖與釋放鎖；
3,、高性能的獲取鎖與釋放鎖,；
4、具備可重入特性,；
5,、具備鎖失效機制，防止死鎖,；
6,、具備非阻塞鎖特性，即沒有獲取到鎖將直接返回獲取鎖失敗,。
三,、分布式鎖的三種實現(xiàn)方式目前幾乎很多大型網(wǎng)站及應(yīng)用都是分布式部署的,，分布式場景中的數(shù)據(jù)一致性問題一直是一個比較重要的話題。分布式的CAP理論告訴我們“任何一個分布式系統(tǒng)都無法同時滿足一致性（Consistency）,、可用性（Availability）和分區(qū)容錯性（Partition tolerance）,，最多只能同時滿足兩項?！彼?，很多系統(tǒng)在設(shè)計之初就要對這三者做出取舍。在互聯(lián)網(wǎng)領(lǐng)域的絕大多數(shù)的場景中,，都需要犧牲強一致性來換取系統(tǒng)的高可用性,，系統(tǒng)往往只需要保證“最終一致性”，只要這個最終時間是在用戶可以接受的范圍內(nèi)即可,。 在很多場景中,，我們?yōu)榱吮ＷC數(shù)據(jù)的最終一致性，需要很多的技術(shù)方案來支持,，比如分布式事務(wù),、分布式鎖等。有的時候,，我們需要保證一個方法在同一時間內(nèi)只能被同一個線程執(zhí)行,。 基于數(shù)據(jù)庫實現(xiàn)分布式鎖；
基于緩存（Redis等）實現(xiàn)分布式鎖,；
基于Zookeeper實現(xiàn)分布式鎖,；
盡管有這三種方案，但是不同的業(yè)務(wù)也要根據(jù)自己的情況進行選型,，他們之間沒有最好只有更適合,！ 四、基于數(shù)據(jù)庫的實現(xiàn)方式基于數(shù)據(jù)庫的實現(xiàn)方式的核心思想是：在數(shù)據(jù)庫中創(chuàng)建一個表,，表中包含方法名等字段,，并在方法名字段上創(chuàng)建唯一索引，想要執(zhí)行某個方法,，就使用這個方法名向表中插入數(shù)據(jù),，成功插入則獲取鎖，執(zhí)行完成后刪除對應(yīng)的行數(shù)據(jù)釋放鎖,。 （1）創(chuàng)建一個表： 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='鎖定中的方法';
（2）想要執(zhí)行某個方法,，就使用這個方法名向表中插入數(shù)據(jù)： INSERT INTO method_lock (method_name, desc) VALUES ('methodName', '測試的methodName');
因為我們對method_name做了唯一性約束，這里如果有多個請求同時提交到數(shù)據(jù)庫的話,，數(shù)據(jù)庫會保證只有一個操作可以成功,，那么我們就可以認(rèn)為操作成功的那個線程獲得了該方法的鎖，可以執(zhí)行方法體內(nèi)容,。 （3）成功插入則獲取鎖,，執(zhí)行完成后刪除對應(yīng)的行數(shù)據(jù)釋放鎖： delete from method_lock where method_name ='methodName';注意：這只是使用基于數(shù)據(jù)庫的一種方法,，使用數(shù)據(jù)庫實現(xiàn)分布式鎖還有很多其他的玩法！ 使用基于數(shù)據(jù)庫的這種實現(xiàn)方式很簡單,，但是對于分布式鎖應(yīng)該具備的條件來說，它有一些問題需要解決及優(yōu)化： 1,、因為是基于數(shù)據(jù)庫實現(xiàn)的,，數(shù)據(jù)庫的可用性和性能將直接影響分布式鎖的可用性及性能，所以,，數(shù)據(jù)庫需要雙機部署,、數(shù)據(jù)同步、主備切換,； 2,、不具備可重入的特性，因為同一個線程在釋放鎖之前,，行數(shù)據(jù)一直存在,，無法再次成功插入數(shù)據(jù)，所以,，需要在表中新增一列,，用于記錄當(dāng)前獲取到鎖的機器和線程信息，在再次獲取鎖的時候,，先查詢表中機器和線程信息是否和當(dāng)前機器和線程相同,，若相同則直接獲取鎖； 3,、沒有鎖失效機制,，因為有可能出現(xiàn)成功插入數(shù)據(jù)后，服務(wù)器宕機了,，對應(yīng)的數(shù)據(jù)沒有被刪除,，當(dāng)服務(wù)恢復(fù)后一直獲取不到鎖，所以,，需要在表中新增一列,，用于記錄失效時間，并且需要有定時任務(wù)清除這些失效的數(shù)據(jù),； 4,、不具備阻塞鎖特性，獲取不到鎖直接返回失敗,，所以需要優(yōu)化獲取邏輯,，循環(huán)多次去獲取。 5,、在實施的過程中會遇到各種不同的問題,，為了解決這些問題,，實現(xiàn)方式將會越來越復(fù)雜；依賴數(shù)據(jù)庫需要一定的資源開銷,，性能問題需要考慮,。 五、基于Redis的實現(xiàn)方式1,、選用Redis實現(xiàn)分布式鎖原因： （1）Redis有很高的性能,；
（2）Redis命令對此支持較好，實現(xiàn)起來比較方便 2,、使用命令介紹： （1）SETNX SETNX key val：當(dāng)且僅當(dāng)key不存在時,，set一個key為val的字符串，返回1,；若key存在,，則什么都不做，返回0,。
（2）expire expire key timeout：為key設(shè)置一個超時時間,，單位為second，超過這個時間鎖會自動釋放,，避免死鎖,。（3）delete delete key：刪除key
在使用Redis實現(xiàn)分布式鎖的時候，主要就會使用到這三個命令,。 3,、實現(xiàn)思想： （1）獲取鎖的時候，使用setnx加鎖,，并使用expire命令為鎖添加一個超時時間,，超過該時間則自動釋放鎖，鎖的value值為一個隨機生成的UUID,，通過此在釋放鎖的時候進行判斷,。 （2）獲取鎖的時候還設(shè)置一個獲取的超時時間，若超過這個時間則放棄獲取鎖,。 （3）釋放鎖的時候,，通過UUID判斷是不是該鎖，若是該鎖,，則執(zhí)行delete進行鎖釋放,。 4、 分布式鎖的簡單實現(xiàn)代碼： /** * 分布式鎖的簡單實現(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 獲取超時時間 * @param timeout 鎖的超時時間 * @return 鎖標(biāo)識 */ public String lockWithTimeout(String lockName, long acquireTimeout, long timeout) { Jedis conn = null; String retIdentifier = null; try { // 獲取連接 conn = jedisPool.getResource(); // 隨機生成一個value String identifier = UUID.randomUUID().toString(); // 鎖名,，即key值 String lockKey = 'lock:' + lockName; // 超時時間,，上鎖后超過此時間則自動釋放鎖 int lockExpire = (int) (timeout / 1000); // 獲取鎖的超時時間，超過這個時間則放棄獲取鎖 long end = System.currentTimeMillis() + acquireTimeout; while (System.currentTimeMillis() < end) { if (conn.setnx(lockKey, identifier) == 1) { conn.expire(lockKey, lockExpire); // 返回value值，用于釋放鎖時間確認(rèn) retIdentifier = identifier; return retIdentifier; } // 返回-1代表key沒有設(shè)置超時時間,，為key設(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)識 * @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)備開始事務(wù) conn.watch(lockKey); // 通過前面返回的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
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、測試剛才實現(xiàn)的分布式鎖 例子中使用50個線程模擬秒殺一個商品,，使用–運算符來實現(xiàn)商品減少,，從結(jié)果有序性就可以看出是否為加鎖狀態(tài)。 模擬秒殺服務(wù),，在其中配置了jedis線程池，在初始化的時候傳給分布式鎖,，供其使用,。 /** * 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è)置最大等待時間 config.setMaxWaitMillis(1000 * 100); // 在borrow一個jedis實例時，是否需要驗證,，若為true,，則所有jedis實例均是可用的 config.setTestOnBorrow(true); pool = new JedisPool(config, '127.0.0.1', 6379, 3000); } public void seckill() { // 返回鎖的value值，供釋放鎖時候進行判斷 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
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
模擬線程進行秒殺服務(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
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值,，供釋放鎖時候進行判斷 //String indentifier = lock.lockWithTimeout('resource', 5000, 1000); System.out.println(Thread.currentThread().getName() + '獲得了鎖'); System.out.println(--n); //lock.releaseLock('resource', indentifier);}
從結(jié)果可以看出，有一些是異步進行的： 
5,、基于ZooKeeper的實現(xiàn)方式ZooKeeper是一個為分布式應(yīng)用提供一致性服務(wù)的開源組件,，它內(nèi)部是一個分層的文件系統(tǒng)目錄樹結(jié)構(gòu)，規(guī)定同一個目錄下只能有一個唯一文件名,?；赯ooKeeper實現(xiàn)分布式鎖的步驟如下： （1）創(chuàng)建一個目錄mylock；
（2）線程A想獲取鎖就在mylock目錄下創(chuàng)建臨時順序節(jié)點,；
（3）獲取mylock目錄下所有的子節(jié)點,，然后獲取比自己小的兄弟節(jié)點，如果不存在,，則說明當(dāng)前線程順序號最小,，獲得鎖；
（4）線程B獲取所有節(jié)點,，判斷自己不是最小節(jié)點,，設(shè)置監(jiān)聽比自己次小的節(jié)點；
（5）線程A處理完,，刪除自己的節(jié)點,，線程B監(jiān)聽到變更事件，判斷自己是不是最小的節(jié)點，如果是則獲得鎖,。 這里推薦一個Apache的開源庫Curator,，它是一個ZooKeeper客戶端，Curator提供的InterProcessMutex是分布式鎖的實現(xiàn),，acquire方法用于獲取鎖,，release方法用于釋放鎖。 優(yōu)點：具備高可用,、可重入,、阻塞鎖特性，可解決失效死鎖問題,。 缺點：因為需要頻繁的創(chuàng)建和刪除節(jié)點,，性能上不如Redis方式。 6,、總結(jié)上面的三種實現(xiàn)方式,，沒有在所有場合都是完美的，所以,，應(yīng)根據(jù)不同的應(yīng)用場景選擇最適合的實現(xiàn)方式,。 在分布式環(huán)境中，對資源進行上鎖有時候是很重要的,，比如搶購某一資源,，這時候使用分布式鎖就可以很好地控制資源。
當(dāng)然,，在具體使用中,，還需要考慮很多因素，比如超時時間的選取,，獲取鎖時間的選取對并發(fā)量都有很大的影響,，上述實現(xiàn)的分布式鎖也只是一種簡單的實現(xiàn)，主要是一種思想,，以上包括文中的代碼可能并不適用于正式的生產(chǎn)環(huán)境,，只做入門參考！
|
