精品成人亚洲,亚洲日韩制服综合无码

參考地址：
https://blog.csdn.net/qq_34337272/article/details/81252853
https://blog.csdn.net/wufaliang003/article/details/78797203

并發(fā)業(yè)務(wù)場(chǎng)景

庫(kù)存業(yè)務(wù)，stock(sid, num)，其中：
sid為庫(kù)存id
num為庫(kù)存值

image.png

如上圖所示，兩個(gè)并發(fā)的查詢(xún)庫(kù)存操作，同時(shí)從數(shù)據(jù)庫(kù)都得到了庫(kù)存是5。
接下來(lái)用戶(hù)發(fā)生了并發(fā)的庫(kù)存扣減動(dòng)作：

image.png

如上圖所示：
用戶(hù)1購(gòu)買(mǎi)了3個(gè)庫(kù)存，于是庫(kù)存要設(shè)置為2
用戶(hù)2購(gòu)買(mǎi)了2個(gè)庫(kù)存，于是庫(kù)存要設(shè)置為3
這兩個(gè)設(shè)置庫(kù)存的接口并發(fā)執(zhí)行，庫(kù)存會(huì)先變成2，再變成3，導(dǎo)致數(shù)據(jù)不一致（實(shí)際賣(mài)出了5件商品，但庫(kù)存只扣減了2，最后一次設(shè)置庫(kù)存會(huì)覆蓋和掩蓋前一次并發(fā)操作）

不一致原因分析

出現(xiàn)數(shù)據(jù)不一致的根本原因，是設(shè)置操作發(fā)生的時(shí)候，沒(méi)有檢查庫(kù)存與查詢(xún)出來(lái)的庫(kù)存有沒(méi)有變化，理論上：
僅庫(kù)存為5的時(shí)候，用戶(hù)1的庫(kù)存設(shè)置2才能成功
僅庫(kù)存為5的時(shí)候，用戶(hù)2的庫(kù)存設(shè)置3才能成功
實(shí)際執(zhí)行的時(shí)候：
庫(kù)存為5，用戶(hù)1的set stock 2確實(shí)應(yīng)該成功
庫(kù)存變?yōu)?了，用戶(hù)2的set stock 3應(yīng)該失敗掉

CAS優(yōu)化

大家常說(shuō)的“Compare And Set”（CAS），是一種常見(jiàn)的降低讀寫(xiě)鎖沖突，保證數(shù)據(jù)一致性的樂(lè)觀鎖機(jī)制。
針對(duì)上述庫(kù)存扣減的例子，CAS升級(jí)很容易，將庫(kù)存設(shè)置接口執(zhí)行的SQL：
update stock set num= $num_new where sid=$ sid
升級(jí)為：
update stock set num= $num_new where sid=$ sid and num=$num_old
即可。

什么是ABA問(wèn)題

CAS樂(lè)觀鎖機(jī)制確實(shí)能夠提升吞吐，并保證一致性，但在極端情況下可能會(huì)出現(xiàn)ABA問(wèn)題。
什么是ABA問(wèn)題？
考慮如下操作：
并發(fā)1（上）：獲取出數(shù)據(jù)的初始值是A，后續(xù)計(jì)劃實(shí)施CAS樂(lè)觀鎖，期望數(shù)據(jù)仍是A的時(shí)候，修改才能成功
并發(fā)2：將數(shù)據(jù)修改成B
并發(fā)3：將數(shù)據(jù)修改回A
并發(fā)1（下）：CAS樂(lè)觀鎖，檢測(cè)發(fā)現(xiàn)初始值還是A，進(jìn)行數(shù)據(jù)修改
上述并發(fā)環(huán)境下，并發(fā)1在修改數(shù)據(jù)時(shí)，雖然還是A，但已經(jīng)不是初始條件的A了，中間發(fā)生了A變B，B又變A的變化，此A已經(jīng)非彼A，數(shù)據(jù)卻成功修改，可能導(dǎo)致錯(cuò)誤，這就是CAS引發(fā)的所謂的ABA問(wèn)題。
庫(kù)存操作，出現(xiàn)ABA問(wèn)題并不會(huì)對(duì)業(yè)務(wù)產(chǎn)生影響。

再看一個(gè)堆棧操作的例子：

image.png

并發(fā)1（上）：讀取棧頂?shù)脑貫椤癆1”

image.png

并發(fā)2：進(jìn)行了2次出棧

image.png

并發(fā)3：又進(jìn)行了1次出棧

image.png

并發(fā)1（下）：實(shí)施CAS樂(lè)觀鎖，發(fā)現(xiàn)棧頂還是“A1”，于是修改為A2

此時(shí)會(huì)出現(xiàn)系統(tǒng)錯(cuò)誤，因?yàn)榇恕癆1”非彼“A1”

ABA問(wèn)題的優(yōu)化

ABA問(wèn)題導(dǎo)致的原因，是CAS過(guò)程中只簡(jiǎn)單進(jìn)行了“值”的校驗(yàn)，再有些情況下，“值”相同不會(huì)引入錯(cuò)誤的業(yè)務(wù)邏輯（例如庫(kù)存），有些情況下，“值”雖然相同，卻已經(jīng)不是原來(lái)的數(shù)據(jù)了。

優(yōu)化方向：CAS不能只比對(duì)“值”，還必須確保的是原來(lái)的數(shù)據(jù)，才能修改成功。

常見(jiàn)實(shí)踐：“版本號(hào)”的比對(duì)，一個(gè)數(shù)據(jù)一個(gè)版本，版本變化，即使值相同，也不應(yīng)該修改成功。

庫(kù)存的并發(fā)讀寫(xiě)例子，引入版本號(hào)的具體實(shí)踐如下：

（1）庫(kù)存表由

stock(sid, num)

升級(jí)為

stock(sid, num, version)

（2）查詢(xún)庫(kù)存時(shí)同時(shí)查詢(xún)版本號(hào)

select num from stock where sid=$sid

升級(jí)為

select num, version from stock where sid=$sid

image.png

假設(shè)有并發(fā)操作，都會(huì)將版本號(hào)查詢(xún)出來(lái)

（3）設(shè)置庫(kù)存時(shí)，必須版本號(hào)相同，并且版本號(hào)要修改

舊版本“值”比對(duì)CAS

update stock set num= $num_new where sid=$ sid and num=$num_old

升級(jí)為“版本號(hào)”比對(duì)CAS

update stock set num= $num_new, version=$ version_new

where sid= $sid and version=$ version_old

image.png

此時(shí)假設(shè)有并發(fā)操作，第一個(gè)操作，比對(duì)版本號(hào)成功，于是把庫(kù)存和版本號(hào)都進(jìn)行了修改。

image.png

同時(shí)存在的第二個(gè)并發(fā)操作，比對(duì)版本號(hào)發(fā)生了變化，也是庫(kù)存應(yīng)該修改失敗。

什么是自旋鎖？

自旋鎖（spinlock）：是指當(dāng)一個(gè)線程在獲取鎖的時(shí)候，如果鎖已經(jīng)被其它線程獲取，那么該線程將循環(huán)等待，然后不斷的判斷鎖是否能夠被成功獲取，直到獲取到鎖才會(huì)退出循環(huán)。

獲取鎖的線程一直處于活躍狀態(tài)，但是并沒(méi)有執(zhí)行任何有效的任務(wù)，使用這種鎖會(huì)造成busy-waiting。

它是為實(shí)現(xiàn)保護(hù)共享資源而提出一種鎖機(jī)制。其實(shí)，自旋鎖與互斥鎖比較類(lèi)似，它們都是為了解決對(duì)某項(xiàng)資源的互斥使用。無(wú)論是互斥鎖，還是自旋鎖，在任何時(shí)刻，最多只能有一個(gè)保持者，也就說(shuō)，在任何時(shí)刻最多只能有一個(gè)執(zhí)行單元獲得鎖。但是兩者在調(diào)度機(jī)制上略有不同。對(duì)于互斥鎖，如果資源已經(jīng)被占用，資源申請(qǐng)者只能進(jìn)入睡眠狀態(tài)。但是自旋鎖不會(huì)引起調(diào)用者睡眠，如果自旋鎖已經(jīng)被別的執(zhí)行單元保持，調(diào)用者就一直循環(huán)在那里看是否該自旋鎖的保持者已經(jīng)釋放了鎖，”自旋”一詞就是因此而得名。

Java如何實(shí)現(xiàn)自旋鎖？

下面是個(gè)簡(jiǎn)單的例子：

public class SpinLock {
    private AtomicReference<Thread> cas = new AtomicReference<Thread>();
    public void lock() {
        Thread current = Thread.currentThread();
        // 利用CAS
        while (!cas.compareAndSet(null, current)) {
            // DO nothing
        }
    }
    public void unlock() {
        Thread current = Thread.currentThread();
        cas.compareAndSet(current, null);
    }
}

lock（)方法利用的CAS，當(dāng)?shù)谝粋€(gè)線程A獲取鎖的時(shí)候，能夠成功獲取到，不會(huì)進(jìn)入while循環(huán)，如果此時(shí)線程A沒(méi)有釋放鎖，另一個(gè)線程B又來(lái)獲取鎖，此時(shí)由于不滿(mǎn)足CAS，所以就會(huì)進(jìn)入while循環(huán)，不斷判斷是否滿(mǎn)足CAS，直到A線程調(diào)用unlock方法釋放了該鎖。

自旋鎖存在的問(wèn)題

如果某個(gè)線程持有鎖的時(shí)間過(guò)長(zhǎng)，就會(huì)導(dǎo)致其它等待獲取鎖的線程進(jìn)入循環(huán)等待，消耗CPU。使用不當(dāng)會(huì)造成CPU使用率極高。
上面Java實(shí)現(xiàn)的自旋鎖不是公平的，即無(wú)法滿(mǎn)足等待時(shí)間最長(zhǎng)的線程優(yōu)先獲取鎖。不公平的鎖就會(huì)存在“線程饑餓”問(wèn)題。

自旋鎖的優(yōu)點(diǎn)

自旋鎖不會(huì)使線程狀態(tài)發(fā)生切換，一直處于用戶(hù)態(tài)，即線程一直都是active的；不會(huì)使線程進(jìn)入阻塞狀態(tài)，減少了不必要的上下文切換，執(zhí)行速度快
非自旋鎖在獲取不到鎖的時(shí)候會(huì)進(jìn)入阻塞狀態(tài)，從而進(jìn)入內(nèi)核態(tài)，當(dāng)獲取到鎖的時(shí)候需要從內(nèi)核態(tài)恢復(fù)，需要線程上下文切換。（線程被阻塞后便進(jìn)入內(nèi)核（Linux）調(diào)度狀態(tài)，這個(gè)會(huì)導(dǎo)致系統(tǒng)在用戶(hù)態(tài)與內(nèi)核態(tài)之間來(lái)回切換，嚴(yán)重影響鎖的性能）

可重入的自旋鎖和不可重入的自旋鎖

文章開(kāi)始的時(shí)候的那段代碼，仔細(xì)分析一下就可以看出，它是不支持重入的，即當(dāng)一個(gè)線程第一次已經(jīng)獲取到了該鎖，在鎖釋放之前又一次重新獲取該鎖，第二次就不能成功獲取到。由于不滿(mǎn)足CAS，所以第二次獲取會(huì)進(jìn)入while循環(huán)等待，而如果是可重入鎖，第二次也是應(yīng)該能夠成功獲取到的。

而且，即使第二次能夠成功獲取，那么當(dāng)?shù)谝淮吾尫沛i的時(shí)候，第二次獲取到的鎖也會(huì)被釋放，而這是不合理的。

為了實(shí)現(xiàn)可重入鎖，我們需要引入一個(gè)計(jì)數(shù)器，用來(lái)記錄獲取鎖的線程數(shù)。

public class ReentrantSpinLock {
    private AtomicReference<Thread> cas = new AtomicReference<Thread>();
    private int count;
    public void lock() {
        Thread current = Thread.currentThread();
        if (current == cas.get()) { // 如果當(dāng)前線程已經(jīng)獲取到了鎖，線程數(shù)增加一，然后返回
            count++;
            return;
        }
        // 如果沒(méi)獲取到鎖，則通過(guò)CAS自旋
        while (!cas.compareAndSet(null, current)) {
            // DO nothing
        }
    }
    public void unlock() {
        Thread cur = Thread.currentThread();
        if (cur == cas.get()) {
            if (count > 0) {// 如果大于0，表示當(dāng)前線程多次獲取了該鎖，釋放鎖通過(guò)count減一來(lái)模擬
                count--;
            } else {// 如果count==0，可以將鎖釋放，這樣就能保證獲取鎖的次數(shù)與釋放鎖的次數(shù)是一致的了。
                cas.compareAndSet(cur, null);
            }
        }
    }
}

自旋鎖的其他變種

1. TicketLock

TicketLock主要解決的是公平性的問(wèn)題。

思路：每當(dāng)有線程獲取鎖的時(shí)候，就給該線程分配一個(gè)遞增的id，我們稱(chēng)之為排隊(duì)號(hào)，同時(shí)，鎖對(duì)應(yīng)一個(gè)服務(wù)號(hào)，每當(dāng)有線程釋放鎖，服務(wù)號(hào)就會(huì)遞增，此時(shí)如果服務(wù)號(hào)與某個(gè)線程排隊(duì)號(hào)一致，那么該線程就獲得鎖，由于排隊(duì)號(hào)是遞增的，所以就保證了最先請(qǐng)求獲取鎖的線程可以最先獲取到鎖，就實(shí)現(xiàn)了公平性。

可以想象成銀行辦理業(yè)務(wù)排隊(duì)，排隊(duì)的每一個(gè)顧客都代表一個(gè)需要請(qǐng)求鎖的線程，而銀行服務(wù)窗口表示鎖，每當(dāng)有窗口服務(wù)完成就把自己的服務(wù)號(hào)加一，此時(shí)在排隊(duì)的所有顧客中，只有自己的排隊(duì)號(hào)與服務(wù)號(hào)一致的才可以得到服務(wù)。

實(shí)現(xiàn)代碼：

public class TicketLock {
    /**
     * 服務(wù)號(hào)
     */
    private AtomicInteger serviceNum = new AtomicInteger();
    /**
     * 排隊(duì)號(hào)
     */
    private AtomicInteger ticketNum = new AtomicInteger();
    /**
     * lock:獲取鎖，如果獲取成功，返回當(dāng)前線程的排隊(duì)號(hào)，獲取排隊(duì)號(hào)用于釋放鎖. <br/>
     *
     * @return
     */
    public int lock() {
        int currentTicketNum = ticketNum.incrementAndGet();
        while (currentTicketNum != serviceNum.get()) {
            // Do nothing
        }
        return currentTicketNum;
    }
    /**
     * unlock:釋放鎖，傳入當(dāng)前持有鎖的線程的排隊(duì)號(hào) <br/>
     *
     * @param ticketnum
     */
    public void unlock(int ticketnum) {
        serviceNum.compareAndSet(ticketnum, ticketnum + 1);
    }
}

上面的實(shí)現(xiàn)方式是，線程獲取鎖之后，將它的排隊(duì)號(hào)返回，等該線程釋放鎖的時(shí)候，需要將該排隊(duì)號(hào)傳入。但這樣是有風(fēng)險(xiǎn)的，因?yàn)檫@個(gè)排隊(duì)號(hào)是可以被修改的，一旦排隊(duì)號(hào)被不小心修改了，那么鎖將不能被正確釋放。一種更好的實(shí)現(xiàn)方式如下：

public class TicketLockV2 {
    /**
     * 服務(wù)號(hào)
     */
    private AtomicInteger serviceNum = new AtomicInteger();
    /**
     * 排隊(duì)號(hào)
     */
    private AtomicInteger ticketNum = new AtomicInteger();
    /**
     * 新增一個(gè)ThreadLocal，用于存儲(chǔ)每個(gè)線程的排隊(duì)號(hào)
     */
    private ThreadLocal<Integer> ticketNumHolder = new ThreadLocal<Integer>();
    public void lock() {
        int currentTicketNum = ticketNum.incrementAndGet();
        // 獲取鎖的時(shí)候，將當(dāng)前線程的排隊(duì)號(hào)保存起來(lái)
        ticketNumHolder.set(currentTicketNum);
        while (currentTicketNum != serviceNum.get()) {
            // Do nothing
        }
    }
    public void unlock() {
        // 釋放鎖，從ThreadLocal中獲取當(dāng)前線程的排隊(duì)號(hào)
        Integer currentTickNum = ticketNumHolder.get();
        serviceNum.compareAndSet(currentTickNum, currentTickNum + 1);
    }
}

上面的實(shí)現(xiàn)方式是將每個(gè)線程的排隊(duì)號(hào)放到了ThreadLocal中。

TicketLock存在的問(wèn)題:

多處理器系統(tǒng)上，每個(gè)進(jìn)程/線程占用的處理器都在讀寫(xiě)同一個(gè)變量serviceNum ，每次讀寫(xiě)操作都必須在多個(gè)處理器緩存之間進(jìn)行緩存同步，這會(huì)導(dǎo)致繁重的系統(tǒng)總線和內(nèi)存的流量，大大降低系統(tǒng)整體的性能。

下面介紹的MCSLock和CLHLock就是解決這個(gè)問(wèn)題的。

2. CLHLock

CLH鎖是一種基于鏈表的可擴(kuò)展、高性能、公平的自旋鎖，申請(qǐng)線程只在本地變量上自旋，它不斷輪詢(xún)前驅(qū)的狀態(tài)，如果發(fā)現(xiàn)前驅(qū)釋放了鎖就結(jié)束自旋，獲得鎖。

實(shí)現(xiàn)代碼如下：

import java.util.concurrent.atomic.AtomicReferenceFieldUpdater;
/**
 * CLH的發(fā)明人是：Craig，Landin and Hagersten。
 * 代碼來(lái)源：http://ifeve.com/java_lock_see2/
 */
public class CLHLock {
    /**
     * 定義一個(gè)節(jié)點(diǎn)，默認(rèn)的lock狀態(tài)為true
     */
    public static class CLHNode {
        private volatile boolean isLocked = true;
    }
    /**
     * 尾部節(jié)點(diǎn),只用一個(gè)節(jié)點(diǎn)即可
     */
    private volatile CLHNode tail;
    private static final ThreadLocal<CLHNode> LOCAL = new ThreadLocal<CLHNode>();
    private static final AtomicReferenceFieldUpdater<CLHLock, CLHNode> UPDATER = AtomicReferenceFieldUpdater.newUpdater(CLHLock.class, CLHNode.class,
            "tail");
    public void lock() {
        // 新建節(jié)點(diǎn)并將節(jié)點(diǎn)與當(dāng)前線程保存起來(lái)
        CLHNode node = new CLHNode();
        LOCAL.set(node);
        // 將新建的節(jié)點(diǎn)設(shè)置為尾部節(jié)點(diǎn)，并返回舊的節(jié)點(diǎn)（原子操作），這里舊的節(jié)點(diǎn)實(shí)際上就是當(dāng)前節(jié)點(diǎn)的前驅(qū)節(jié)點(diǎn)
        CLHNode preNode = UPDATER.getAndSet(this, node);
        if (preNode != null) {
            // 前驅(qū)節(jié)點(diǎn)不為null表示當(dāng)鎖被其他線程占用，通過(guò)不斷輪詢(xún)判斷前驅(qū)節(jié)點(diǎn)的鎖標(biāo)志位等待前驅(qū)節(jié)點(diǎn)釋放鎖
            while (preNode.isLocked) {
            }
            preNode = null;
            LOCAL.set(node);
        }
        // 如果不存在前驅(qū)節(jié)點(diǎn)，表示該鎖沒(méi)有被其他線程占用，則當(dāng)前線程獲得鎖
    }
    public void unlock() {
        // 獲取當(dāng)前線程對(duì)應(yīng)的節(jié)點(diǎn)
        CLHNode node = LOCAL.get();
        // 如果tail節(jié)點(diǎn)等于node，則將tail節(jié)點(diǎn)更新為null，同時(shí)將node的lock狀態(tài)職位false，表示當(dāng)前線程釋放了鎖
        if (!UPDATER.compareAndSet(this, node, null)) {
            node.isLocked = false;
        }
        node = null;
    }
}

3. MCSLock

MCSLock則是對(duì)本地變量的節(jié)點(diǎn)進(jìn)行循環(huán)。

/**
 * MCS:發(fā)明人名字John Mellor-Crummey和Michael Scott
 * 代碼來(lái)源：http://ifeve.com/java_lock_see2/
 */
public class MCSLock {
    /**
     * 節(jié)點(diǎn)，記錄當(dāng)前節(jié)點(diǎn)的鎖狀態(tài)以及后驅(qū)節(jié)點(diǎn)
     */
    public static class MCSNode {
        volatile MCSNode next;
        volatile boolean isLocked = true;
    }
    private static final ThreadLocal<MCSNode> NODE = new ThreadLocal<MCSNode>();
    // 隊(duì)列
    @SuppressWarnings("unused")
    private volatile MCSNode queue;
    // queue更新器
    private static final AtomicReferenceFieldUpdater<MCSLock, MCSNode> UPDATER = AtomicReferenceFieldUpdater.newUpdater(MCSLock.class, MCSNode.class,
            "queue");
    public void lock() {
        // 創(chuàng)建節(jié)點(diǎn)并保存到ThreadLocal中
        MCSNode currentNode = new MCSNode();
        NODE.set(currentNode);
        // 將queue設(shè)置為當(dāng)前節(jié)點(diǎn)，并且返回之前的節(jié)點(diǎn)
        MCSNode preNode = UPDATER.getAndSet(this, currentNode);
        if (preNode != null) {
            // 如果之前節(jié)點(diǎn)不為null，表示鎖已經(jīng)被其他線程持有
            preNode.next = currentNode;
            // 循環(huán)判斷，直到當(dāng)前節(jié)點(diǎn)的鎖標(biāo)志位為false
            while (currentNode.isLocked) {
            }
        }
    }
    public void unlock() {
        MCSNode currentNode = NODE.get();
        // next為null表示沒(méi)有正在等待獲取鎖的線程
        if (currentNode.next == null) {
            // 更新?tīng)顟B(tài)并設(shè)置queue為null
            if (UPDATER.compareAndSet(this, currentNode, null)) {
                // 如果成功了，表示queue==currentNode,即當(dāng)前節(jié)點(diǎn)后面沒(méi)有節(jié)點(diǎn)了
                return;
            } else {
                // 如果不成功，表示queue!=currentNode,即當(dāng)前節(jié)點(diǎn)后面多了一個(gè)節(jié)點(diǎn)，表示有線程在等待
                // 如果當(dāng)前節(jié)點(diǎn)的后續(xù)節(jié)點(diǎn)為null，則需要等待其不為null（參考加鎖方法）
                while (currentNode.next == null) {
                }
            }
        } else {
            // 如果不為null，表示有線程在等待獲取鎖，此時(shí)將等待線程對(duì)應(yīng)的節(jié)點(diǎn)鎖狀態(tài)更新為false，同時(shí)將當(dāng)前線程的后繼節(jié)點(diǎn)設(shè)為null
            currentNode.next.isLocked = false;
            currentNode.next = null;
        }
    }
}

4. CLHLock 和 MCSLock

都是基于鏈表，不同的是CLHLock是基于隱式鏈表，沒(méi)有真正的后續(xù)節(jié)點(diǎn)屬性，MCSLock是顯示鏈表，有一個(gè)指向后續(xù)節(jié)點(diǎn)的屬性。
將獲取鎖的線程狀態(tài)借助節(jié)點(diǎn)(node)保存,每個(gè)線程都有一份獨(dú)立的節(jié)點(diǎn)，這樣就解決了TicketLock多處理器緩存同步的問(wèn)題。

自旋鎖與互斥鎖

自旋鎖與互斥鎖都是為了實(shí)現(xiàn)保護(hù)資源共享的機(jī)制。
無(wú)論是自旋鎖還是互斥鎖，在任意時(shí)刻，都最多只能有一個(gè)保持者。
獲取互斥鎖的線程，如果鎖已經(jīng)被占用，則該線程將進(jìn)入睡眠狀態(tài)；獲取自旋鎖的線程則不會(huì)睡眠，而是一直循環(huán)等待鎖釋放。

總結(jié)：

select&set業(yè)務(wù)場(chǎng)景，在并發(fā)時(shí)會(huì)出現(xiàn)一致性問(wèn)題
基于“值”的CAS樂(lè)觀鎖，可能導(dǎo)致ABA問(wèn)題
CAS樂(lè)觀鎖，必須保證修改時(shí)的“此數(shù)據(jù)”就是“彼數(shù)據(jù)”，應(yīng)該由“值”比對(duì)，優(yōu)化為“版本號(hào)”比對(duì)
自旋鎖：線程獲取鎖的時(shí)候，如果鎖被其他線程持有，則當(dāng)前線程將循環(huán)等待，直到獲取到鎖。
自旋鎖等待期間，線程的狀態(tài)不會(huì)改變，線程一直是用戶(hù)態(tài)并且是活動(dòng)的(active)。
自旋鎖如果持有鎖的時(shí)間太長(zhǎng)，則會(huì)導(dǎo)致其它等待獲取鎖的線程耗盡CPU。
自旋鎖本身無(wú)法保證公平性，同時(shí)也無(wú)法保證可重入性。
基于自旋鎖，可以實(shí)現(xiàn)具備公平性和可重入性質(zhì)的鎖。
TicketLock:采用類(lèi)似銀行排號(hào)叫好的方式實(shí)現(xiàn)自旋鎖的公平性，但是由于不停的讀取serviceNum，每次讀寫(xiě)操作都必須在多個(gè)處理器緩存之間進(jìn)行緩存同步，這會(huì)導(dǎo)致繁重的系統(tǒng)總線和內(nèi)存的流量，大大降低系統(tǒng)整體的性能。
CLHLock和MCSLock通過(guò)鏈表的方式避免了減少了處理器緩存同步，極大的提高了性能，區(qū)別在于CLHLock是通過(guò)輪詢(xún)其前驅(qū)節(jié)點(diǎn)的狀態(tài)，而MCS則是查看當(dāng)前節(jié)點(diǎn)的鎖狀態(tài)。
CLHLock在NUMA架構(gòu)下使用會(huì)存在問(wèn)題。在沒(méi)有cache的NUMA系統(tǒng)架構(gòu)中，由于CLHLock是在當(dāng)前節(jié)點(diǎn)的前一個(gè)節(jié)點(diǎn)上自旋,NUMA架構(gòu)中處理器訪問(wèn)本地內(nèi)存的速度高于通過(guò)網(wǎng)絡(luò)訪問(wèn)其他節(jié)點(diǎn)的內(nèi)存，所以CLHLock在NUMA架構(gòu)上不是最優(yōu)的自旋鎖。

參考資料

http://www.searchtb.com/2011/06/spinlock%E5%89%96%E6%9E%90%E4%B8%8E%E6%94%B9%E8%BF%9B.html
https://en.wikipedia.org/wiki/Spinlock
https://en.wikipedia.org/wiki/Busy_waiting
http://blog.csdn.net/chen77716/article/details/6618779
http://ifeve.com/java_lock_see4/
http://ifeve.com/java_lock_see2/
http://coderbee.net/index.php/concurrent/20131115/577

色偷偷精品伊人,欧洲久久精品,欧美综合婷婷骚逼,国产AV主播,国产最新探花在线,九色在线视频一区,伊人大交九欧美,1769亚洲,黄色成人av

CAS算法與自旋鎖 -- 轉(zhuǎn)載

CAS算法與自旋鎖 -- 轉(zhuǎn)載

并發(fā)業(yè)務(wù)場(chǎng)景

不一致原因分析

CAS優(yōu)化

什么是ABA問(wèn)題

ABA問(wèn)題的優(yōu)化

什么是自旋鎖？

Java如何實(shí)現(xiàn)自旋鎖？

自旋鎖存在的問(wèn)題

自旋鎖的優(yōu)點(diǎn)

可重入的自旋鎖和不可重入的自旋鎖

自旋鎖的其他變種

1. TicketLock

2. CLHLock

3. MCSLock

4. CLHLock 和 MCSLock

自旋鎖與互斥鎖

總結(jié)：

參考資料

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容

色偷偷精品伊人,欧洲久久精品,欧美综合婷婷骚逼,国产AV主播,国产最新探花在线,九色在线视频一区,伊人大交九 欧美,1769亚洲,黄色成人av

CAS算法與自旋鎖 -- 轉(zhuǎn)載

并發(fā)業(yè)務(wù)場(chǎng)景

不一致原因分析

CAS優(yōu)化

什么是ABA問(wèn)題

ABA問(wèn)題的優(yōu)化

什么是自旋鎖？

Java如何實(shí)現(xiàn)自旋鎖？

自旋鎖存在的問(wèn)題

自旋鎖的優(yōu)點(diǎn)

可重入的自旋鎖和不可重入的自旋鎖

自旋鎖的其他變種

1. TicketLock

2. CLHLock

3. MCSLock

4. CLHLock 和 MCSLock

自旋鎖與互斥鎖

總結(jié)：

參考資料

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容

色偷偷精品伊人,欧洲久久精品,欧美综合婷婷骚逼,国产AV主播,国产最新探花在线,九色在线视频一区,伊人大交九欧美,1769亚洲,黄色成人av

什么是自旋鎖？

Java如何實(shí)現(xiàn)自旋鎖？