前言

很多小伙伴在學(xué)習(xí)Java的時(shí)候，總是感覺Java多線程在實(shí)際的業(yè)務(wù)中很少使用，以至于不會(huì)花太多的時(shí)間去學(xué)習(xí)，技術(shù)債不斷累積！等到了一定程度的時(shí)候?qū)τ谂cJava多線程相關(guān)的東西就很難理解，今天需要探討的東西也是一樣的和Java多線程相關(guān)的！做好準(zhǔn)備，馬上開車！

站在用戶的角度思考問(wèn)題，與客戶深入溝通，找到鄂爾多斯網(wǎng)站設(shè)計(jì)與鄂爾多斯網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗(yàn)，讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個(gè)性化、用戶體驗(yàn)好的作品，建站類型包括：成都網(wǎng)站制作、做網(wǎng)站、外貿(mào)營(yíng)銷網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、空間域名、網(wǎng)絡(luò)空間、企業(yè)郵箱。業(yè)務(wù)覆蓋鄂爾多斯地區(qū)。

學(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í)鎖、讀寫鎖、互斥鎖等。

一、為什么要使用分布式鎖

我們?cè)陂_發(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é)果也是不對(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='鎖定中的方法';

（2）想要執(zhí)行某個(gè)方法，就使用這個(gè)方法名向表中插入數(shù)據(jù)：

INSERT INTO method_lock (method_name, desc) VALUES ('methodName', '測(cè)試的methodName');

因?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';

注意：這只是使用基于數(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)化：

• 因?yàn)槭腔跀?shù)據(jù)庫(kù)實(shí)現(xiàn)的，數(shù)據(jù)庫(kù)的可用性和性能將直接影響分布式鎖的可用性及性能，所以，數(shù)據(jù)庫(kù)需要雙機(jī)部署、數(shù)據(jù)同步、主備切換；

• 不具備可重入的特性，因?yàn)橥粋€(gè)線程在釋放鎖之前，行數(shù)據(jù)一直存在，無(wú)法再次成功插入數(shù)據(jù)，所以，需要在表中新增一列，用于記錄當(dāng)前獲取到鎖的機(jī)器和線程信息，在再次獲取鎖的時(shí)候，先查詢表中機(jī)器和線程信息是否和當(dāng)前機(jī)器和線程相同，若相同則直接獲取鎖；

• 沒(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ù)；

• 不具備阻塞鎖特性，獲取不到鎖直接返回失敗，所以需要優(yōu)化獲取邏輯，循環(huán)多次去獲取。

• 在實(shí)施的過(guò)程中會(huì)遇到各種不同的問(wèn)題，為了解決這些問(wèn)題，實(shí)現(xiàn)方式將會(huì)越來(lái)越復(fù)雜；依賴數(shù)據(jù)庫(kù)需要一定的資源開銷，性能問(wèn)題需要考慮。

五、基于Redis的實(shí)現(xiàn)方式

5.1、選用Redis實(shí)現(xiàn)分布式鎖原因：

（1）Redis有很高的性能；
（2）Redis命令對(duì)此支持較好，實(shí)現(xiàn)起來(lái)比較方便

5.2、使用命令介紹：

（1）SETNX

SETNX key val：當(dāng)且僅當(dāng)key不存在時(shí)，set一個(gè)key為val的字符串，返回1；若key存在，則什么都不做，返回0。

（2）expire

expire key timeout：為key設(shè)置一個(gè)超時(shí)時(shí)間，單位為second，超過(guò)這個(gè)時(shí)間鎖會(huì)自動(dòng)釋放，避免死鎖。

（3）delete

delete key：刪除key

在使用Redis實(shí)現(xiàn)分布式鎖的時(shí)候，主要就會(huì)使用到這三個(gè)命令。

5.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)行鎖釋放。

5.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)備開始事務(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;
    }
}

5.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);
    }
}

模擬線程進(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();
        }
    }
}

結(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);
}

從結(jié)果可以看出，有一些是異步進(jìn)行的：

六、基于ZooKeeper的實(shí)現(xiàn)方式

ZooKeeper是一個(gè)為分布式應(yīng)用提供一致性服務(wù)的開源組件，它內(nèi)部是一個(gè)分層的文件系統(tǒng)目錄樹結(jié)構(gòu)，規(guī)定同一個(gè)目錄下只能有一個(gè)唯一文件名?；赯ooKeeper實(shí)現(xiàn)分布式鎖的步驟如下：

• 創(chuàng)建一個(gè)目錄mylock；
• 線程A想獲取鎖就在mylock目錄下創(chuàng)建臨時(shí)順序節(jié)點(diǎn)；
• 獲取mylock目錄下所有的子節(jié)點(diǎn)，然后獲取比自己小的兄弟節(jié)點(diǎn)，如果不存在，則說(shuō)明當(dāng)前線程順序號(hào)最小，獲得鎖；
• 線程B獲取所有節(jié)點(diǎn)，判斷自己不是最小節(jié)點(diǎn)，設(shè)置監(jiān)聽比自己次小的節(jié)點(diǎn)；
• 線程A處理完，刪除自己的節(jié)點(diǎn)，線程B監(jiān)聽到變更事件，判斷自己是不是最小的節(jié)點(diǎn)，如果是則獲得鎖。

這里推薦一個(gè)Apache的開源庫(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方式。

七、總結(jié)

文中的三種實(shí)現(xiàn)方式，沒(méi)有在所有場(chǎng)合都是完美的，所以，應(yīng)根據(jù)不同的應(yīng)用場(chǎng)景選擇最適合的實(shí)現(xiàn)方式。

在分布式環(huán)境中，對(duì)資源進(jìn)行上鎖有時(shí)候是很重要的，比如搶購(gòu)某一資源，這時(shí)候使用分布式鎖就可以很好地控制資源。
當(dāng)然，在具體使用中，還需要考慮很多因素，比如超時(shí)時(shí)間的選取，獲取鎖時(shí)間的選取對(duì)并發(fā)量都有很大的影響，上述實(shí)現(xiàn)的分布式鎖也只是一種簡(jiǎn)單的實(shí)現(xiàn)，主要是一種思想，以上包括文中的代碼可能并不適用于正式的生產(chǎn)環(huán)境，只做入門參考！

網(wǎng)站名稱：分布式鎖簡(jiǎn)單入門以及三種實(shí)現(xiàn)方式介紹
URL鏈接：http://jinyejixie.com/article34/gggcse.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供靜態(tài)網(wǎng)站、微信小程序、云服務(wù)器、、網(wǎng)頁(yè)設(shè)計(jì)公司、ChatGPT

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)