欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

Java多線程之鎖學(xué)習(xí)(增強(qiáng)版)

 更新時(shí)間:2023年02月26日 15:26:59   作者:劉架構(gòu)  
這篇文章主要為大家詳細(xì)介紹了Java多線程中鎖的相關(guān)知識(shí),文中的示例代碼講解詳細(xì),對(duì)我們了解線程有一定幫助,需要的可以參考一下

阻塞鎖

含義:多個(gè)線程同時(shí)調(diào)用一個(gè)方法的時(shí)候,所有的線程都被排隊(duì)處理了,讓線程進(jìn)入阻塞狀態(tài)進(jìn)行等待,當(dāng)獲得相應(yīng)的信號(hào)(喚醒、時(shí)間)時(shí),才能進(jìn)入線程的準(zhǔn)備就緒的狀態(tài)。通過競(jìng)爭(zhēng)。進(jìn)入運(yùn)行狀態(tài)。

Java中,能夠進(jìn)入\退出、阻塞狀態(tài)或包含阻塞鎖的方法有 ,synchronized 關(guān)鍵字(其中的重量鎖),ReentrantLock,Object.wait()\notify()

實(shí)例代碼如下

// 在main方法中,開啟100個(gè)線程執(zhí)行 lock() 方法
// 開啟10個(gè)線程執(zhí)行 unlock() 方法
// 此時(shí)進(jìn)行加鎖和解鎖之后,加鎖多于解鎖的時(shí)候,就會(huì)一直阻塞等待
public class Demo01 {
    private boolean isLocked = false;

    public synchronized void lock() throws InterruptedException {
        while (isLocked) {
            // 當(dāng)其他線程進(jìn)來,即處于等待阻塞狀態(tài)   
            wait();
        }
        System.out.println("Demo01.lock");
        isLocked = true;
    }

    public synchronized void unlock() {
        isLocked = false;
        System.out.println("Demo01.unlock");
        notify();
    }

    public static void main(String[] args) {
        Demo01 demo01 = new Demo01();
        for (int i = 0; i < 100; i++) {
            new Thread(() -> {
                try {
                    demo01.lock();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }).start();
        }
        for (int i = 0; i < 10; i++) {
            new Thread(() -> {
                demo01.unlock();
            }).start();
        }
    }
}

由于被調(diào)用的方法越耗時(shí),線程越多的時(shí)候,等待的線程等待的時(shí)間也就越長(zhǎng),甚至于幾分鐘或者幾十分鐘。對(duì)于Web等對(duì)反應(yīng)時(shí)間要求很高的系統(tǒng)來說,這是不可行的,因此需要讓其非阻塞,可以在沒有拿到鎖之后馬上返回,告訴客戶稍后重試。

非阻塞鎖

含義:多個(gè)線程同時(shí)調(diào)用一個(gè)方法的時(shí)候,當(dāng)某一個(gè)線程最先獲取到鎖,這時(shí)其他線程沒拿到鎖,這時(shí)就直接返回,只有當(dāng)最先獲取的鎖的線程釋放鎖,其他線程的鎖才能進(jìn)來,在它釋放之前其他線程都會(huì)獲取失敗

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

// 非阻塞鎖
public class Demo02 {
    private boolean isLocked = false;

    public synchronized boolean lock() throws InterruptedException {
        if (isLocked) {
            return false;
        }
        System.out.println("Demo01.lock");
        isLocked = true;
        return true;
    }

    public synchronized boolean unlock() {
        if (isLocked) {
            System.out.println("Demo01.unlock");
            isLocked = !isLocked;
            return true;
        }
        return false;
    }

    public static void main(String[] args) {
        Demo02 demo01 = new Demo02();
        for (int i = 0; i < 100; i++) {
            new Thread(() -> {
                try {
                    if (demo01.lock()) {
                        System.out.println("獲取鎖失敗");
                    }
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }).start();
        }
        for (int i = 0; i < 1000; i++) {
            new Thread(() -> {
                if (demo01.unlock()) {
                    System.out.println("解鎖成功");
                }
            }).start();
        }
    }
}

鎖的四種狀態(tài)

鎖的狀態(tài)總共有四種:無鎖狀態(tài)、偏向鎖、輕量級(jí)鎖和重量級(jí)鎖。隨著鎖的競(jìng)爭(zhēng),鎖可以從偏向鎖升級(jí)到輕量級(jí)鎖,再升級(jí)的重量級(jí)鎖(但是鎖的升級(jí)是單向的,也就是說只能從低到高升級(jí),不會(huì)出現(xiàn)鎖的降級(jí))JDK 1.6中默認(rèn)是開啟偏向鎖和輕量級(jí)鎖的,

注意:HotSpot JVM是支持鎖降級(jí)的 但是因?yàn)榻导?jí)的效率太低了,所以在開發(fā)中不使用降級(jí)的操作

但是鎖的狀態(tài)時(shí)存在哪里的呢?

鎖存在Java的對(duì)象頭中的Mark Work。Mark Work默認(rèn)不僅存放著鎖標(biāo)志位,還存放對(duì)象hashCode等信息。運(yùn)行時(shí),會(huì)根據(jù)鎖的狀態(tài),修改Mark Work的存儲(chǔ)內(nèi)容。如果對(duì)象是數(shù)組類型,則虛擬機(jī)用3個(gè)字寬存儲(chǔ)對(duì)象頭,如果對(duì)象是非數(shù)組類型,則用2字寬存儲(chǔ)對(duì)象頭。在32位虛擬機(jī)中,一字寬等于四字節(jié),即32bit。

字寬(Word): 內(nèi)存大小的單位概念, 對(duì)于 32 位處理器 1 Word = 4 Bytes, 64 位處理器 1 Word = 8 Bytes

每一個(gè) Java 對(duì)象都至少占用 2 個(gè)字寬的內(nèi)存(數(shù)組類型占用3個(gè)字寬)。

  • 第一個(gè)字寬也被稱為對(duì)象頭Mark Word。 對(duì)象頭包含了多種不同的信息, 其中就包含對(duì)象鎖相關(guān)的信息。
  • 第二個(gè)字寬是指向定義該對(duì)象類信息(class metadata)的指針

無鎖狀態(tài)

在代碼剛剛進(jìn)入同步塊的時(shí)候,就處于無鎖狀態(tài)。

偏向鎖

概念:偏向鎖會(huì)偏向于第一個(gè)訪問鎖的線程,如果在接下來的運(yùn)行過程中,該鎖沒有被其他的線程訪問,則持有偏向鎖的線程將永遠(yuǎn)不需要觸發(fā)同步。也就是說,偏向鎖在資源無競(jìng)爭(zhēng)的情況下消除了同步語句,連CAS操作都不做了,提高了程序的運(yùn)行性能

引入偏向鎖是為了在無多線程競(jìng)爭(zhēng)的情況下盡量減少不必要的輕量鎖執(zhí)行路徑。因?yàn)檩p量級(jí)鎖的獲取以及釋放依賴多次CAS原子指令,而偏向鎖只需要在置換ThreadID的時(shí)候依賴一次原子指令(由于一旦出現(xiàn)多線程競(jìng)爭(zhēng)的情況就必須撤銷偏向鎖,所以偏向鎖的撤銷操作的性能損耗必須小于節(jié)省下來的CAS原子指令的性能消耗)上面說過,輕量級(jí)鎖是為了在多線程交替執(zhí)行同步塊時(shí)提高性能,而偏向鎖則是在只有一個(gè)線程執(zhí)行同步塊的時(shí)候進(jìn)一步提高性能。

輕量級(jí)鎖

“輕量級(jí)”是相對(duì)于使用操作系統(tǒng)互斥量來實(shí)現(xiàn)傳統(tǒng)鎖而言的。但是首先需要強(qiáng)調(diào)一點(diǎn)的是,輕量級(jí)鎖并不是用來代替重量級(jí)鎖的,它的本意是在沒有多線程競(jìng)爭(zhēng)的前提下,減少傳統(tǒng)的重量級(jí)鎖使用產(chǎn)生的性能消耗。

在解釋輕量級(jí)鎖的執(zhí)行過程過程之前,我們要先明白一點(diǎn),輕量級(jí)鎖使用的場(chǎng)景是線程交替同步塊的情況,如果存在同一時(shí)間訪問同一鎖的情況,就會(huì)導(dǎo)致輕量級(jí)鎖膨脹為重量級(jí)。

重量級(jí)鎖

synchronized是通過對(duì)象內(nèi)部的一個(gè)監(jiān)視器鎖(monitor)實(shí)現(xiàn)的。但是monitor底層又依賴于底層操作系統(tǒng)的Mutex Lock實(shí)現(xiàn)的。而操作系統(tǒng)實(shí)現(xiàn)線程之間的切換就需要從用戶態(tài)切換到核心態(tài),切換的成本很高,狀態(tài)之間的轉(zhuǎn)化需要相對(duì)比較長(zhǎng)的時(shí)間,這就是synchronized效率低的原因,因此,這種依賴于操作系統(tǒng)的Mutex Lock所實(shí)現(xiàn)的鎖被稱之為“重量級(jí)鎖”

可重入鎖

可重入鎖也叫做遞歸鎖,指的是同一線程外層函數(shù)獲得鎖之后,內(nèi)存遞歸函數(shù)仍然有獲得該鎖的代碼,但是不受影響

Java中ReentrantLock和synchronized都是可重入鎖 自旋鎖不是可重入鎖

可重入鎖的最大作用就是避免死鎖

下面是一段實(shí)例代碼

public class Test implements Runnable {

    public synchronized void get() {
        System.out.println(Thread.currentThread().getId());
        set();
    }

    public synchronized void set() {
        System.out.println(Thread.currentThread().getId());
    }

    @Override
    public void run() {
        get();
    }

    public static void main(String[] args) {
        Test ss = new Test();
        new Thread(ss).start();
        new Thread(ss).start();
        new Thread(ss).start();
    }
}
// 執(zhí)行結(jié)果
// 11
// 11
// 12
// 12
// 13
// 13
public class Test2 implements Runnable {
    ReentrantLock lock = new ReentrantLock();

    public void get() {
        lock.lock();
        try {
            System.out.println(Thread.currentThread().getId());
            set();
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            lock.unlock();
        }
    }

    public void set() {
        lock.lock();
        try {
            System.out.println(Thread.currentThread().getId());
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            lock.unlock();
        }
    }

    @Override
    public void run() {
        get();
    }

    public static void main(String[] args) {
        Test ss = new Test();
        new Thread(ss).start();
        new Thread(ss).start();
        new Thread(ss).start();
    }
}
// 執(zhí)行結(jié)果
// 11
// 11
// 12
// 12
// 13
// 13

自旋鎖

public class SpinLock {
    private AtomicReference<Thread> owner = new AtomicReference<>();

    public void lock() {
        Thread current = Thread.currentThread();
        while (!owner.compareAndSet(null, current)) {
        }
    }

    public void unlock() {
        Thread current = Thread.currentThread();
        owner.compareAndSet(current, null);
    }

改進(jìn)的自旋鎖

public class SpinLock1 {
    private AtomicReference<Thread> owner =new AtomicReference<>();
    private int count =0;
    public void lock(){
        Thread current = Thread.currentThread();
        if(current==owner.get()) {
            count++;
            return ;
        }
        while(!owner.compareAndSet(null, current)){
        }
    }
    public void unlock (){
        Thread current = Thread.currentThread();
        if(current==owner.get()){
            if(count!=0){
                count--;
            }else{
                owner.compareAndSet(current, null);
            }
        }
    }
}

讀寫鎖

Lock接口以及其對(duì)象,使用它,很優(yōu)雅的控制了競(jìng)爭(zhēng)資源的安全訪問,但是這種鎖不區(qū)別讀寫 - 為普通鎖

為了提高性能,Java提供了讀寫鎖,在讀的地方使用讀鎖,在寫的時(shí)候使用寫鎖,靈活控制,如果沒有寫鎖的情況下。讀是無阻塞的,在一定情況下提高了程序的執(zhí)行效率。下面我們來看源代碼(Lock接口和Condition接口在上一篇Java - 多線程 - 鎖和提升 第1篇已經(jīng)分析過,此處不再分析)

public class ReentrantReadWriteLock
    implements ReadWriteLock, java.io.Serializable {
    private static final long serialVersionUID = -6992448646407690164L;

    // 讀鎖內(nèi)部類對(duì)象
    private final ReentrantReadWriteLock.ReadLock readerLock;

    // 寫鎖內(nèi)部類對(duì)象
    private final ReentrantReadWriteLock.WriteLock writerLock;

    // 執(zhí)行所有的同步機(jī)制
    final Sync sync;

    // 無參構(gòu)造函數(shù) 調(diào)用有參構(gòu)造 ReentrantReadWriteLock(boolean fair)
    public ReentrantReadWriteLock() {
        this(false);
    }

    // 有參構(gòu)造函數(shù) 是否創(chuàng)建公平鎖
    public ReentrantReadWriteLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync();
        readerLock = new ReadLock(this);
        writerLock = new WriteLock(this);
    }

    //  返回讀鎖和寫鎖的對(duì)象
    public ReentrantReadWriteLock.WriteLock writeLock() { return writerLock; }
    public ReentrantReadWriteLock.ReadLock  readLock()  { return readerLock; }

    // 繼承自 AbstractQueueSynchronizer 的Sync
    abstract static class Sync extends AbstractQueuedSynchronizer {
        private static final long serialVersionUID = 6317671515068378041L;

        // 共享移位
        static final int SHARED_SHIFT   = 16;
        // 共享單位
        static final int SHARED_UNIT    = (1 << SHARED_SHIFT);
        // 最大數(shù)量
        static final int MAX_COUNT      = (1 << SHARED_SHIFT) - 1;
        // 獨(dú)占
        static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;

        // 返回共享鎖的數(shù)量 
        static int sharedCount(int c)    { return c >>> SHARED_SHIFT; }
        // 返回獨(dú)占鎖的數(shù)量
        static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }

        // 每線程讀取保持計(jì)數(shù)的計(jì)數(shù)器
        static final class HoldCounter {
            int count = 0;
            // 使用id 而不是使用引用 避免垃圾殘留
            final long tid = getThreadId(Thread.currentThread());
        }

        // 線程本地子類
        static final class ThreadLocalHoldCounter
            extends ThreadLocal<HoldCounter> {
            public HoldCounter initialValue() {
                return new HoldCounter();
            }
        }

        // 當(dāng)前線程持有的可重入鎖的數(shù)量,只在構(gòu)造函數(shù)和readObject中初始化,
        // 當(dāng)線程的讀取保持計(jì)數(shù)下降到0的時(shí)候刪除
        private transient ThreadLocalHoldCounter readHolds;

        // 獲取readLock的最后一個(gè)線程的保持計(jì)數(shù)
        private transient HoldCounter cachedHoldCounter;

        // 第一個(gè)獲得讀的線程
        private transient Thread firstReader = null;
        // 計(jì)數(shù)器
        private transient int firstReaderHoldCount;

        Sync() {
            readHolds = new ThreadLocalHoldCounter();
            setState(getState()); // ensures visibility of readHolds
        }

        // 當(dāng)前線程獲取鎖的時(shí)候由于策略超過其他等待線程而應(yīng)阻止,返回true
        abstract boolean readerShouldBlock();

        // 如果由于試圖超越其他等待線程的策略而導(dǎo)致當(dāng)前線程在嘗試獲取寫鎖(且有資格這樣做)
        // 時(shí)應(yīng)阻塞,則返回true
        abstract boolean writerShouldBlock();

        // 嘗試釋放
        protected final boolean tryRelease(int releases) {
            if (!isHeldExclusively())
                throw new IllegalMonitorStateException();
            int nextc = getState() - releases;
            boolean free = exclusiveCount(nextc) == 0;
            if (free)
                setExclusiveOwnerThread(null);
            setState(nextc);
            return free;
        }

        // 嘗試增加
        protected final boolean tryAcquire(int acquires) {
            /*
             * Walkthrough:
             * 1. If read count nonzero or write count nonzero
             *    and owner is a different thread, fail.
             * 2. If count would saturate, fail. (This can only
             *    happen if count is already nonzero.)
             * 3. Otherwise, this thread is eligible for lock if
             *    it is either a reentrant acquire or
             *    queue policy allows it. If so, update state
             *    and set owner.
             */
            Thread current = Thread.currentThread();
            int c = getState();
            int w = exclusiveCount(c);
            if (c != 0) {
                // (Note: if c != 0 and w == 0 then shared count != 0)
                if (w == 0 || current != getExclusiveOwnerThread())
                    return false;
                if (w + exclusiveCount(acquires) > MAX_COUNT)
                    throw new Error("Maximum lock count exceeded");
                // Reentrant acquire
                setState(c + acquires);
                return true;
            }
            if (writerShouldBlock() ||
                !compareAndSetState(c, c + acquires))
                return false;
            setExclusiveOwnerThread(current);
            return true;
        }

        // 嘗試釋放共享鎖
        protected final boolean tryReleaseShared(int unused) {
            Thread current = Thread.currentThread();
            if (firstReader == current) {
                // assert firstReaderHoldCount > 0;
                if (firstReaderHoldCount == 1)
                    firstReader = null;
                else
                    firstReaderHoldCount--;
            } else {
                HoldCounter rh = cachedHoldCounter;
                if (rh == null || rh.tid != getThreadId(current))
                    rh = readHolds.get();
                int count = rh.count;
                if (count <= 1) {
                    readHolds.remove();
                    if (count <= 0)
                        throw unmatchedUnlockException();
                }
                --rh.count;
            }
            for (;;) {
                int c = getState();
                int nextc = c - SHARED_UNIT;
                if (compareAndSetState(c, nextc))
                    // Releasing the read lock has no effect on readers,
                    // but it may allow waiting writers to proceed if
                    // both read and write locks are now free.
                    return nextc == 0;
            }
        }

        // 非法的監(jiān)視器狀態(tài)異常
        private IllegalMonitorStateException unmatchedUnlockException() {
            return new IllegalMonitorStateException(
                "attempt to unlock read lock, not locked by current thread");
        }

        // 嘗試加共享鎖
        protected final int tryAcquireShared(int unused) {
            /*
             * Walkthrough:
             * 1. If write lock held by another thread, fail.
             * 2. Otherwise, this thread is eligible for
             *    lock wrt state, so ask if it should block
             *    because of queue policy. If not, try
             *    to grant by CASing state and updating count.
             *    Note that step does not check for reentrant
             *    acquires, which is postponed to full version
             *    to avoid having to check hold count in
             *    the more typical non-reentrant case.
             * 3. If step 2 fails either because thread
             *    apparently not eligible or CAS fails or count
             *    saturated, chain to version with full retry loop.
             */
            Thread current = Thread.currentThread();
            int c = getState();
            if (exclusiveCount(c) != 0 &&
                getExclusiveOwnerThread() != current)
                return -1;
            int r = sharedCount(c);
            if (!readerShouldBlock() &&
                r < MAX_COUNT &&
                compareAndSetState(c, c + SHARED_UNIT)) {
                if (r == 0) {
                    firstReader = current;
                    firstReaderHoldCount = 1;
                } else if (firstReader == current) {
                    firstReaderHoldCount++;
                } else {
                    HoldCounter rh = cachedHoldCounter;
                    if (rh == null || rh.tid != getThreadId(current))
                        cachedHoldCounter = rh = readHolds.get();
                    else if (rh.count == 0)
                        readHolds.set(rh);
                    rh.count++;
                }
                return 1;
            }
            return fullTryAcquireShared(current);
        }

        // 讀取的完整版本,可處理CAS丟失和tryAcquireShared中未處理的可重入讀取
        final int fullTryAcquireShared(Thread current) {

            HoldCounter rh = null;
            for (;;) {
                int c = getState();
                if (exclusiveCount(c) != 0) {
                    if (getExclusiveOwnerThread() != current)
                        return -1;

                } else if (readerShouldBlock()) {

                    if (firstReader == current) {
                        // assert firstReaderHoldCount > 0;
                    } else {
                        if (rh == null) {
                            rh = cachedHoldCounter;
                            if (rh == null || rh.tid != getThreadId(current)) {
                                rh = readHolds.get();
                                if (rh.count == 0)
                                    readHolds.remove();
                            }
                        }
                        if (rh.count == 0)
                            return -1;
                    }
                }
                if (sharedCount(c) == MAX_COUNT)
                    throw new Error("Maximum lock count exceeded");
                if (compareAndSetState(c, c + SHARED_UNIT)) {
                    if (sharedCount(c) == 0) {
                        firstReader = current;
                        firstReaderHoldCount = 1;
                    } else if (firstReader == current) {
                        firstReaderHoldCount++;
                    } else {
                        if (rh == null)
                            rh = cachedHoldCounter;
                        if (rh == null || rh.tid != getThreadId(current))
                            rh = readHolds.get();
                        else if (rh.count == 0)
                            readHolds.set(rh);
                        rh.count++;
                        cachedHoldCounter = rh; // cache for release
                    }
                    return 1;
                }
            }
        }

        // 執(zhí)行tryLock進(jìn)行寫入,從而在兩種模式下都可以進(jìn)行插入,這與tryAcquire的作用相同
        // 只是缺少對(duì) writerShouldBlock的調(diào)用
        final boolean tryWriteLock() {
            Thread current = Thread.currentThread();
            int c = getState();
            if (c != 0) {
                int w = exclusiveCount(c);
                if (w == 0 || current != getExclusiveOwnerThread())
                    return false;
                if (w == MAX_COUNT)
                    throw new Error("Maximum lock count exceeded");
            }
            if (!compareAndSetState(c, c + 1))
                return false;
            setExclusiveOwnerThread(current);
            return true;
        }

        // 執(zhí)行tryLock進(jìn)行讀取,從而在兩種模式下都可以進(jìn)行插入。 
        // 除了沒有調(diào)用readerReaderShouldBlock以外,這與tryAcquireShared的作用相同。
        final boolean tryReadLock() {
            Thread current = Thread.currentThread();
            for (;;) {
                int c = getState();
                if (exclusiveCount(c) != 0 &&
                    getExclusiveOwnerThread() != current)
                    return false;
                int r = sharedCount(c);
                if (r == MAX_COUNT)
                    throw new Error("Maximum lock count exceeded");
                if (compareAndSetState(c, c + SHARED_UNIT)) {
                    if (r == 0) {
                        firstReader = current;
                        firstReaderHoldCount = 1;
                    } else if (firstReader == current) {
                        firstReaderHoldCount++;
                    } else {
                        HoldCounter rh = cachedHoldCounter;
                        if (rh == null || rh.tid != getThreadId(current))
                            cachedHoldCounter = rh = readHolds.get();
                        else if (rh.count == 0)
                            readHolds.set(rh);
                        rh.count++;
                    }
                    return true;
                }
            }
        }

        // 是否獨(dú)占鎖
        protected final boolean isHeldExclusively() {
            return getExclusiveOwnerThread() == Thread.currentThread();
        }

        // 返回Condition對(duì)象
        final ConditionObject newCondition() {
            return new ConditionObject();
        }

        // 返回獨(dú)占鎖
        final Thread getOwner() {
            return ((exclusiveCount(getState()) == 0) ?
                    null :
                    getExclusiveOwnerThread());
        }

        // 獲取readLock所得個(gè)數(shù)
        final int getReadLockCount() {
            return sharedCount(getState());
        }

        // 判斷是否是 writeLock 鎖
        final boolean isWriteLocked() {
            return exclusiveCount(getState()) != 0;
        }

        // 獲得寫鎖的數(shù)量
        final int getWriteHoldCount() {
            return isHeldExclusively() ? exclusiveCount(getState()) : 0;
        }

        // 獲得讀鎖的數(shù)量
        final int getReadHoldCount() {
            if (getReadLockCount() == 0)
                return 0;

            Thread current = Thread.currentThread();
            if (firstReader == current)
                return firstReaderHoldCount;

            HoldCounter rh = cachedHoldCounter;
            if (rh != null && rh.tid == getThreadId(current))
                return rh.count;

            int count = readHolds.get().count;
            if (count == 0) readHolds.remove();
            return count;
        }

        // 序列化
        private void readObject(java.io.ObjectInputStream s)
            throws java.io.IOException, ClassNotFoundException {
            s.defaultReadObject();
            readHolds = new ThreadLocalHoldCounter();
            setState(0); // reset to unlocked state
        }

        // 獲取數(shù)量
        final int getCount() { return getState(); }
    }

    // 非公平鎖
    static final class NonfairSync extends Sync {
        private static final long serialVersionUID = -8159625535654395037L;
        final boolean writerShouldBlock() {
            return false; // writers can always barge
        }
        final boolean readerShouldBlock() {
            return apparentlyFirstQueuedIsExclusive();
        }
    }

    // 公平鎖
    static final class FairSync extends Sync {
        private static final long serialVersionUID = -2274990926593161451L;
        final boolean writerShouldBlock() {
            return hasQueuedPredecessors();
        }
        final boolean readerShouldBlock() {
            return hasQueuedPredecessors();
        }
    }

    // 讀鎖實(shí)現(xiàn)了 Lock 接口
    public static class ReadLock implements Lock, java.io.Serializable {
        private static final long serialVersionUID = -5992448646407690164L;
        private final Sync sync;

        // 初始化,獲得是否是公平讀鎖
        protected ReadLock(ReentrantReadWriteLock lock) {
            sync = lock.sync;
        }

        // 加鎖 是共享鎖
        public void lock() {
            sync.acquireShared(1);
        }

        // 鎖中斷
        public void lockInterruptibly() throws InterruptedException {
            sync.acquireSharedInterruptibly(1);
        }

        // 調(diào)用加鎖
        public boolean tryLock() {
            return sync.tryReadLock();
        }

        // 超時(shí)加鎖
        public boolean tryLock(long timeout, TimeUnit unit)
            throws InterruptedException {
            return sync.tryAcquireSharedNanos(1, unit.toNanos(timeout));
        }

        // 解鎖
        public void unlock() {
            sync.releaseShared(1);
        }

        // Condition 對(duì)象
        public Condition newCondition() {
            throw new UnsupportedOperationException();
        }

        // toString方法
        public String toString() {
            int r = sync.getReadLockCount();
            return super.toString() +
                "[Read locks = " + r + "]";
        }
    }

    // 寫鎖
    public static class WriteLock implements Lock, java.io.Serializable {
        private static final long serialVersionUID = -4992448646407690164L;
        private final Sync sync;

        // 寫鎖初始化
        protected WriteLock(ReentrantReadWriteLock lock) {
            sync = lock.sync;
        }

        // 加鎖
        public void lock() {
            sync.acquire(1);
        }

        // 鎖中斷
        public void lockInterruptibly() throws InterruptedException {
            sync.acquireInterruptibly(1);
        }

        // 加鎖
        public boolean tryLock( ) {
            return sync.tryWriteLock();
        }

        // 超時(shí)加鎖
        public boolean tryLock(long timeout, TimeUnit unit)
            throws InterruptedException {
            return sync.tryAcquireNanos(1, unit.toNanos(timeout));
        }

        // 解鎖,調(diào)用 release 減1
        public void unlock() {
            sync.release(1);
        }

        // Condition對(duì)象
        public Condition newCondition() {
            return sync.newCondition();
        }

        // toString方法
        public String toString() {
            Thread o = sync.getOwner();
            return super.toString() + ((o == null) ?
                                       "[Unlocked]" :
                                       "[Locked by thread " + o.getName() + "]");
        }

        // 是否有獨(dú)占的線程
        public boolean isHeldByCurrentThread() {
            return sync.isHeldExclusively();
        }

        // 獲取寫鎖的數(shù)量
        public int getHoldCount() {
            return sync.getWriteHoldCount();
        }
    }

    // 判斷是否是公平鎖
    public final boolean isFair() {
        return sync instanceof FairSync;
    }

    // 判斷是否是獨(dú)占鎖
    protected Thread getOwner() {
        return sync.getOwner();
    }

    // 獲取讀鎖的個(gè)數(shù)
    public int getReadLockCount() {
        return sync.getReadLockCount();
    }

    // 判斷是否是寫鎖
    public boolean isWriteLocked() {
        return sync.isWriteLocked();
    }

    // 判斷鎖是否被當(dāng)前線程持有
    public boolean isWriteLockedByCurrentThread() {
        return sync.isHeldExclusively();
    }

    // 查詢當(dāng)前線程對(duì)該鎖的可重入寫入次數(shù)
    public int getWriteHoldCount() {
        return sync.getWriteHoldCount();
    }

    // 查詢當(dāng)前線程對(duì)該鎖的可重讀次數(shù)
    public int getReadHoldCount() {
        return sync.getReadHoldCount();
    }

    // 返回寫線程的集合
    protected Collection<Thread> getQueuedWriterThreads() {
        return sync.getExclusiveQueuedThreads();
    }

    // 返回讀線程的集合
    protected Collection<Thread> getQueuedReaderThreads() {
        return sync.getSharedQueuedThreads();
    }

    // 查詢是否有任何線程正在等待獲取讀或?qū)戞i
    public final boolean hasQueuedThreads() {
        return sync.hasQueuedThreads();
    }

    //  查詢指定線程是否在等待讀或者寫鎖
    public final boolean hasQueuedThread(Thread thread) {
        return sync.isQueued(thread);
    }

    // 獲取等待隊(duì)列的長(zhǎng)度
    public final int getQueueLength() {
        return sync.getQueueLength();
    }

    // 獲得等待隊(duì)列中的線程集合
    protected Collection<Thread> getQueuedThreads() {
        return sync.getQueuedThreads();
    }

    // 查詢是否有任何線程正在等待與寫鎖關(guān)聯(lián)的給定條件
    public boolean hasWaiters(Condition condition) {
        if (condition == null)
            throw new NullPointerException();
        if (!(condition instanceof AbstractQueuedSynchronizer.ConditionObject))
            throw new IllegalArgumentException("not owner");
        return sync.hasWaiters((AbstractQueuedSynchronizer.ConditionObject)condition);
    }

    // 查詢是否有任何線程正在等待與寫鎖關(guān)聯(lián)的給定條件的長(zhǎng)度
    public int getWaitQueueLength(Condition condition) {
        if (condition == null)
            throw new NullPointerException();
        if (!(condition instanceof AbstractQueuedSynchronizer.ConditionObject))
            throw new IllegalArgumentException("not owner");
        return sync.getWaitQueueLength((AbstractQueuedSynchronizer.ConditionObject)condition);
    }

    // 獲得給定條件等待線程的集合
    protected Collection<Thread> getWaitingThreads(Condition condition) {
        if (condition == null)
            throw new NullPointerException();
        if (!(condition instanceof AbstractQueuedSynchronizer.ConditionObject))
            throw new IllegalArgumentException("not owner");
        return sync.getWaitingThreads((AbstractQueuedSynchronizer.ConditionObject)condition);
    }

    // toString()方法
    public String toString() {
        int c = sync.getCount();
        int w = Sync.exclusiveCount(c);
        int r = Sync.sharedCount(c);

        return super.toString() +
            "[Write locks = " + w + ", Read locks = " + r + "]";
    }

    // 獲取線程ID
    static final long getThreadId(Thread thread) {
        return UNSAFE.getLongVolatile(thread, TID_OFFSET);
    }

    // Unsafe對(duì)象
    private static final sun.misc.Unsafe UNSAFE;
    private static final long TID_OFFSET;
    static {
        try {
            UNSAFE = sun.misc.Unsafe.getUnsafe();
            Class<?> tk = Thread.class;
            TID_OFFSET = UNSAFE.objectFieldOffset
                (tk.getDeclaredField("tid"));
        } catch (Exception e) {
            throw new Error(e);
        }
    }
}

總結(jié):

  • 從讀寫鎖的實(shí)現(xiàn)代碼,我們可以看到,其本質(zhì)還是使用了AQS的獨(dú)占鎖和共享鎖實(shí)現(xiàn)了讀寫分離。
  • 當(dāng)需要進(jìn)行讀的時(shí)候使用共享鎖,當(dāng)需要寫的時(shí)候使用獨(dú)占鎖
  • 同時(shí),ReentrantReadWriteLock也提供了默認(rèn)的非公平機(jī)制,當(dāng)然也可以使用構(gòu)造方法設(shè)置是否是公平鎖

互斥鎖

互斥鎖指的是一次最多只能有一個(gè)線程持有的鎖。如Java的Lock

互斥鎖也是為了保護(hù)共享資源的同步,在任何時(shí)刻,最多只能有一個(gè)保持者,也就說,在任何時(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)釋放了鎖。

悲觀鎖

悲觀鎖,顧名思義就是狠悲觀,認(rèn)為每次拿去的數(shù)據(jù)都會(huì)被修改,所以在每次拿鎖的時(shí)候都會(huì)上鎖,這樣別人想拿到這個(gè)數(shù)據(jù)就會(huì)block到直到他拿到鎖。傳統(tǒng)的數(shù)據(jù)庫(kù)就使用了很多的這種的機(jī)制:如行鎖、表鎖、讀鎖、寫鎖等,都是在做操作之前上鎖。共享鎖、排他鎖、獨(dú)占鎖是悲觀鎖的一種實(shí)現(xiàn)。

Java中的悲觀鎖,最典型的就是synchronized。而AQS框架下的鎖,先嘗試使用CAS樂觀鎖去獲取鎖,獲取不到才會(huì)轉(zhuǎn)為悲觀鎖,如ReentrantLock

樂觀鎖

樂觀鎖,顧名思義就是很樂觀,每次拿去的數(shù)據(jù)都認(rèn)為不會(huì)被修改,所以不會(huì)上鎖。但是在更新的時(shí)候會(huì)判斷一下在此期間別人有沒有去更新這個(gè)數(shù)據(jù),對(duì)于此過程出現(xiàn)的ABA問題,可以使用版本號(hào)進(jìn)行控制。

樂觀鎖用于多讀的場(chǎng)景,數(shù)據(jù)庫(kù)提供的類似于write_condition機(jī)制都是使用了樂觀鎖,使用CAS保證這個(gè)操作的原子性

樂觀鎖和悲觀鎖的比較

  • 樂觀鎖不是數(shù)據(jù)庫(kù)自己實(shí)現(xiàn)的,悲觀鎖是數(shù)據(jù)庫(kù)自己實(shí)現(xiàn)的
  • 兩種鎖各有優(yōu)缺點(diǎn),不能認(rèn)為一種好于另外一種,樂觀鎖適用于寫少的場(chǎng)景,也就是沖突發(fā)生很少的情況,這樣省了鎖的開銷,加大了系統(tǒng)的吞吐量。
  • 但是如果經(jīng)常發(fā)生沖突,上次應(yīng)用不會(huì)retry,此時(shí)為了保證安全和維持性能,應(yīng)該使用悲觀鎖

公平鎖

公平鎖。就是字面意思,公平的,是非搶占式的,一個(gè)一個(gè)排好隊(duì),等待執(zhí)行,但是有缺點(diǎn)。如果某個(gè)線程執(zhí)行的時(shí)間過長(zhǎng),會(huì)導(dǎo)致阻塞。比如ReentrantLock中的內(nèi)部類 FairSync和ReentrantReadWriteLock中的內(nèi)部類FairSync都是公平鎖

非公平鎖

非公平鎖,及時(shí)字面以自,搶占式的,不管誰先來,誰后來,搶到了就是我的。比如ReentrantLock中的內(nèi)部類 NonfairSync和ReentrantReadWriteLock中的內(nèi)部類NonfairSync都是非公平鎖

顯示鎖和內(nèi)置鎖

顯示鎖,是人為手動(dòng)的鎖,如:ReentrantLock、Lock鎖,也就是說,實(shí)現(xiàn)了Lock的鎖都是顯示鎖

內(nèi)置鎖:內(nèi)置鎖使用synchronized,內(nèi)置鎖是互斥鎖

Java中每個(gè)對(duì)象都可以用作一個(gè)實(shí)現(xiàn)同步的鎖。 線程進(jìn)入同步代碼塊或方法的時(shí)候會(huì)自動(dòng)獲得該鎖,在退出同步代碼塊或方法時(shí)會(huì)釋放該鎖。獲得內(nèi)置鎖的唯一途徑就是進(jìn)入這個(gè)鎖的保護(hù)的同步代碼塊或方法。

輪詢鎖和定時(shí)鎖

由tryLock實(shí)現(xiàn),與無條件獲取鎖模式相比,它們具有更完善的錯(cuò)誤恢復(fù)機(jī)制??杀苊馑梨i的發(fā)生

boolean tryLock():僅在調(diào)用時(shí)鎖為空閑狀態(tài)才獲取該鎖。如果鎖可用,則獲取鎖,并立即返回值 true。如果鎖不可用,則此方法將立即返回值 false。

tryLock的重載 tryLock(time,TimeUnit)就是定時(shí)鎖

對(duì)象鎖和類鎖

Java的對(duì)象鎖和類鎖,其實(shí)也就是 Java - 多線程 - 鎖和提升 第1篇開篇所說的8鎖 8鎖核心思想

  • 關(guān)鍵字在實(shí)例方法上,鎖為當(dāng)前實(shí)例
  • 關(guān)鍵字在靜態(tài)方法上,鎖為當(dāng)前Class對(duì)象
  • 關(guān)鍵字在代碼塊上,鎖為括號(hào)里面的對(duì)象

1.對(duì)象鎖和類鎖在基本概念上和內(nèi)置鎖是一致的,但是,兩個(gè)鎖是有很大的區(qū)別,對(duì)象鎖適用于對(duì)象的實(shí)例方法,或者一個(gè)對(duì)象實(shí)例上的,類鎖是作用于類的靜態(tài)方法或者一個(gè)類的class對(duì)象上的。

2.類的實(shí)例可以有多個(gè),但是每個(gè)類只有一個(gè)class對(duì)象,不同實(shí)例的對(duì)象鎖是互不相干的,但是每個(gè)類只有一個(gè)類鎖。

3.其實(shí)類鎖只是一個(gè)概念上的東西,并不是真實(shí)存在的,它只是用來幫我們理解鎖定實(shí)例方法和靜態(tài)方法的區(qū)別。

4.synchronized只是一個(gè)內(nèi)置的加鎖機(jī)制,當(dāng)某個(gè)方法加上synchronized關(guān)鍵字的后,就表明要獲得該內(nèi)置鎖才能執(zhí)行,并不能阻止其他線程訪問不需要獲得該鎖的方法。

5.調(diào)用對(duì)象的wait()方法的時(shí)候,會(huì)釋放持有的對(duì)象鎖,以便于調(diào)用 notify() 方法使用。notify()調(diào)用之后,會(huì)等到notify()所在的線程執(zhí)行完畢之后再釋放鎖。

鎖粗化

就是將多次連接在一起的加鎖、解鎖操作合并為一次,將多個(gè)連續(xù)的鎖拓展為一個(gè)更大的鎖。

通常情況下,為了保證多線程間的有效并發(fā),會(huì)要求每個(gè)線程持有鎖的時(shí)間盡可能短,但是大某些情況下,一個(gè)程序?qū)ν粋€(gè)鎖不間斷、高頻地請(qǐng)求、同步與釋放,會(huì)消耗掉一定的系統(tǒng)資源,因?yàn)殒i的講求、同步與釋放本身會(huì)帶來性能損耗,這樣高頻的鎖請(qǐng)求就反而不利于系統(tǒng)性能的優(yōu)化了,雖然單次同步操作的時(shí)間可能很短。鎖粗化就是告訴我們?nèi)魏问虑槎加袀€(gè)度,有些情況下我們反而希望把很多次鎖的請(qǐng)求合并成一個(gè)請(qǐng)求,以降低短時(shí)間內(nèi)大量鎖請(qǐng)求、同步、釋放帶來的性能損耗。

鎖消除

鎖消除即:刪除不必要的加鎖操作。根據(jù)代碼逃逸技術(shù),如果判斷到一段代碼中,堆上的數(shù)據(jù)不會(huì)逃逸出當(dāng)前線程。那么可以認(rèn)定這段代碼是線程安全的,不必要加鎖。

鎖消除是發(fā)生在編譯器級(jí)別的一種鎖優(yōu)化方式。有時(shí)候我們寫的代碼完全不需要加鎖,卻執(zhí)行了加鎖操作。

比如,StringBuffer類的append操作:

@Override
public synchronized StringBuffer append(String str) {
    toStringCache = null;
    super.append(str);
    return this;
}

從源碼中可以看出,append方法用了synchronized關(guān)鍵詞,它是線程安全的。但我們可能僅在線程內(nèi)部把StringBuffer當(dāng)作局部變量使用:

public class Demo {
    public static void main(String[] args) {
        long start = System.currentTimeMillis();
        int size = 10000;
        for (int i = 0; i < size; i++) {
            createStringBuffer("ic", "java");
        }
        long timeCost = System.currentTimeMillis() - start;
        System.out.println("createStringBuffer:" + timeCost + " ms");
    }
    public static String createStringBuffer(String str1, String str2) {
        StringBuffer sBuf = new StringBuffer();
        // append方法是同步操作
        sBuf.append(str1);
        sBuf.append(str2);
        return sBuf.toString();
    }
}

代碼中createStringBuffer方法中的局部對(duì)象sBuf,就只在該方法內(nèi)的作用域有效,不同線程同時(shí)調(diào)用createStringBuffer()方法時(shí),都會(huì)創(chuàng)建不同的sBuf對(duì)象,因此此時(shí)的append操作若是使用同步操作,就是白白浪費(fèi)的系統(tǒng)資源。

這時(shí)我們可以通過編譯器將其優(yōu)化,將鎖消除,前提是java必須運(yùn)行在server模式(server模式會(huì)比client模式作更多的優(yōu)化),同時(shí)必須開啟逃逸分析:

-server -XX:+DoEscapeAnalysis -XX:+EliminateLocks

其中+DoEscapeAnalysis表示開啟逃逸分析,+EliminateLocks表示鎖消除。

逃逸分析:比如上面的代碼,它要看sBuf是否可能逃出它的作用域?如果將sBuf作為方法的返回值進(jìn)行返回,那么它在方法外部可能被當(dāng)作一個(gè)全局對(duì)象使用,就有可能發(fā)生線程安全問題,這時(shí)就可以說sBuf這個(gè)對(duì)象發(fā)生逃逸了,因而不應(yīng)將append操作的鎖消除,但我們上面的代碼沒有發(fā)生鎖逃逸,鎖消除就可以帶來一定的性能提升。

信號(hào)量

信號(hào)量有一個(gè)線程同步工具:Semaphore

下面我們來分析一下源碼

public class Semaphore implements java.io.Serializable {
    private static final long serialVersionUID = -3222578661600680210L;

    // Sync鎖
    private final Sync sync;

    // Sync實(shí)現(xiàn)了AbstractQueueSynchronizer
    abstract static class Sync extends AbstractQueuedSynchronizer {
        private static final long serialVersionUID = 1192457210091910933L;

        //  初始化版本初始值
        Sync(int permits) {
            setState(permits);
        }

        // 獲取狀態(tài)
        final int getPermits() {
            return getState();
        }

        // 不公平嘗試共享
        final int nonfairTryAcquireShared(int acquires) {
            for (;;) {
                int available = getState();
                int remaining = available - acquires;
                if (remaining < 0 ||
                    compareAndSetState(available, remaining))
                    return remaining;
            }
        }

        // 嘗試釋放共享
        protected final boolean tryReleaseShared(int releases) {
            for (;;) {
                int current = getState();
                int next = current + releases;
                if (next < current) // overflow
                    throw new Error("Maximum permit count exceeded");
                if (compareAndSetState(current, next))
                    return true;
            }
        }

        // 減少狀態(tài)的指定值
        final void reducePermits(int reductions) {
            for (;;) {
                int current = getState();
                int next = current - reductions;
                if (next > current) // underflow
                    throw new Error("Permit count underflow");
                if (compareAndSetState(current, next))
                    return;
            }
        }

        final int drainPermits() {
            for (;;) {
                int current = getState();
                if (current == 0 || compareAndSetState(current, 0))
                    return current;
            }
        }
    }

    // 非公平鎖
    static final class NonfairSync extends Sync {
        private static final long serialVersionUID = -2694183684443567898L;

        NonfairSync(int permits) {
            super(permits);
        }

        protected int tryAcquireShared(int acquires) {
            return nonfairTryAcquireShared(acquires);
        }
    }

    // 公平鎖
    static final class FairSync extends Sync {
        private static final long serialVersionUID = 2014338818796000944L;

        FairSync(int permits) {
            super(permits);
        }

        protected int tryAcquireShared(int acquires) {
            for (;;) {
                if (hasQueuedPredecessors())
                    return -1;
                int available = getState();
                int remaining = available - acquires;
                if (remaining < 0 ||
                    compareAndSetState(available, remaining))
                    return remaining;
            }
        }
    }

    // 構(gòu)造方法 設(shè)置初始版本號(hào)
    public Semaphore(int permits) {
        sync = new NonfairSync(permits);
    }

    // 構(gòu)造方法
    public Semaphore(int permits, boolean fair) {
        sync = fair ? new FairSync(permits) : new NonfairSync(permits);
    }

    // 增加1
    public void acquire() throws InterruptedException {
        sync.acquireSharedInterruptibly(1);
    }

    // 不間斷地獲取
    public void acquireUninterruptibly() {
        sync.acquireShared(1);
    }

    // 從此信號(hào)量獲取許可,直到獲得一個(gè)許可為止,將一直阻塞
    public void acquireUninterruptibly() {
        sync.acquireShared(1);
    }

    // 僅在調(diào)用時(shí)可用時(shí),才從此信號(hào)量獲取許可
    public boolean tryAcquire() {
        return sync.nonfairTryAcquireShared(1) >= 0;
    }

    // 定時(shí)設(shè)置
    public boolean tryAcquire(long timeout, TimeUnit unit)
        throws InterruptedException {
        return sync.tryAcquireSharedNanos(1, unit.toNanos(timeout));
    }

    // 釋放
    public void release() {
        sync.releaseShared(1);
    }

    // 設(shè)置指定的個(gè)數(shù)
    public void acquire(int permits) throws InterruptedException {
        if (permits < 0) throw new IllegalArgumentException();
        sync.acquireSharedInterruptibly(permits);
    }

    // 獲得許可證的給定數(shù)目從這個(gè)信號(hào),阻塞直到所有可用。
    public void acquireUninterruptibly(int permits) {
        if (permits < 0) throw new IllegalArgumentException();
        sync.acquireShared(permits);
    }

    // 獲得許可證的給定數(shù)目從此信號(hào)量,只有在所有可在調(diào)用的時(shí)候。
    public boolean tryAcquire(int permits) {
        if (permits < 0) throw new IllegalArgumentException();
        return sync.nonfairTryAcquireShared(permits) >= 0;
    }

    // 收購(gòu)從此信號(hào)量許可證的給定數(shù)量,如果所有給定的等待時(shí)間內(nèi)變得可用,并且當(dāng)前線程未被中斷 
    public boolean tryAcquire(int permits, long timeout, TimeUnit unit)
        throws InterruptedException {
        if (permits < 0) throw new IllegalArgumentException();
        return sync.tryAcquireSharedNanos(permits, unit.toNanos(timeout));
    }

    // 釋放
    public void release(int permits) {
        if (permits < 0) throw new IllegalArgumentException();
        sync.releaseShared(permits);
    }

    // 返回現(xiàn)在的剩余值
    public int availablePermits() {
        return sync.getPermits();
    }

    // 返回減少之后的值
    public int drainPermits() {
        return sync.drainPermits();
    }

    // 減少指定個(gè)數(shù)的值
    protected void reducePermits(int reduction) {
        if (reduction < 0) throw new IllegalArgumentException();
        sync.reducePermits(reduction);
    }

    // 判斷是否時(shí)公平鎖
    public boolean isFair() {
        return sync instanceof FairSync;
    }

    // 判斷隊(duì)列是否有線程 
    public final boolean hasQueuedThreads() {
        return sync.hasQueuedThreads();
    }

    // 返回線程的長(zhǎng)度
    public final int getQueueLength() {
        return sync.getQueueLength();
    }

    // 返回隊(duì)列線程的集合
    protected Collection<Thread> getQueuedThreads() {
        return sync.getQueuedThreads();
    }

    // toString() 方法
    public String toString() {
        return super.toString() + "[Permits = " + sync.getPermits() + "]";
    }
}

總結(jié):

我們發(fā)現(xiàn)其本質(zhì)還是 AbstractQueueSynchronizer 中的共享模式和獨(dú)占模式

此類也有公平和非公平的實(shí)現(xiàn)

獨(dú)享鎖

獨(dú)享鎖,也叫獨(dú)占鎖,意思是鎖A只能被一個(gè)鎖擁有,如synchronized,

ReentrantLock是獨(dú)享鎖,他是基于AQS實(shí)現(xiàn)的,在ReentrantLock源碼中, 使用一個(gè)int類型的成員變量state來表示同步狀態(tài),當(dāng)state>0時(shí)表示已經(jīng)獲取了鎖 。 而當(dāng)c等于0的時(shí)候說明當(dāng)前沒有線程占有鎖,它提供了三個(gè)方法(getState()、setState(int newState)、compareAndSetState(int expect,int update))來對(duì)同步狀態(tài)state進(jìn)行操作,所以AQS可以確保對(duì)state的操作是安全的。

// 它默認(rèn)是非公平鎖
public ReentrantLock() {
    sync = new NonfairSync();
}

// 創(chuàng)建ReentrantLock,公平鎖or非公平鎖
public ReentrantLock(boolean fair) {
    sync = fair ? new FairSync() : new NonfairSync();
}

// 而他會(huì)分別調(diào)用lock方法和unlock方法來釋放鎖
public void lock() {
    sync.lock();
}

public void unlock() {
    sync.release(1);
}

但是其實(shí)他不僅僅是會(huì)調(diào)用lock和unlock方法,因?yàn)槲覀兊木€程不可能一點(diǎn)問題沒有,如果說進(jìn)入到了waiting狀態(tài),在這個(gè)時(shí)候如果沒有unpark()方法,就沒有辦法來喚醒他, 所以,也就接踵而至出現(xiàn)了tryLock(),tryLock(long,TimeUnit)來做一些嘗試加鎖或者說是超時(shí)來滿足某些特定的場(chǎng)景的需求了

ReentrantLock會(huì)保證method-body在同一時(shí)間只有一個(gè)線程在執(zhí)行這段代碼,或者說,同一時(shí)刻只有一個(gè)線程的lock方法會(huì)返回。其余線程會(huì)被掛起,直到獲取鎖。

從這里我們就能看出,其實(shí)ReentrantLock實(shí)現(xiàn)的就是一個(gè)獨(dú)占鎖的功能:有且只有一個(gè)線程獲取到鎖,其余線程全部掛起,直到該擁有鎖的線程釋放鎖,被掛起的線程被喚醒重新開始競(jìng)爭(zhēng)鎖。而在源碼中通過AQS來獲取獨(dú)享鎖是通過調(diào)用acquire方法,其實(shí)這個(gè)方法是阻塞的

共享鎖

從我們之前的獨(dú)享所就能看得出來,獨(dú)享鎖是使用的一個(gè)狀態(tài)來進(jìn)行鎖標(biāo)記的,共享鎖其實(shí)也差不多,但是JAVA中有不想定力兩個(gè)狀態(tài),所以區(qū)別出現(xiàn)了, 他們的鎖狀態(tài)時(shí)不一樣的。

基本的流程是一樣的,主要區(qū)別在于判斷鎖獲取的條件上,由于是共享鎖,也就允許多個(gè)線程同時(shí)獲取,所以同步狀態(tài)的數(shù)量同時(shí)的大于1的,如果同步狀態(tài)為非0,則線程就可以獲取鎖,只有當(dāng)同步狀態(tài)為0時(shí),才說明共享數(shù)量的鎖已經(jīng)被全部獲取,其余線程只能等待。

最典型的就是ReentrantReadWriteLock里的讀鎖,它的讀鎖是可以被共享的,但是它的寫鎖確每次只能被獨(dú)占。

總結(jié)

  • 獨(dú)享鎖:同時(shí)只能有一個(gè)線程獲得鎖。
  • 共享鎖:可以有多個(gè)線程同時(shí)獲得鎖。

分段鎖

在JDK1.7之前,HashMap的底層是數(shù)組+鏈表。同樣的,ConcurrentHashMap的底層樹結(jié)構(gòu)是數(shù)組+鏈表,但是和HashMap不一樣的是,ConcurrentHashMap的中存放數(shù)據(jù)是一段一段的。即由很多個(gè)Segment(段)組成的,每個(gè)Segment中都有著類似于數(shù)組+鏈表的結(jié)構(gòu)

關(guān)于Segment

1.ConcurrentHashMap由三個(gè)參數(shù)

  • initalCapacity:初始化總?cè)萘?,默認(rèn)值為16
  • loadFactor:加載因子,默認(rèn)0.75
  • concurrentLevel:并發(fā)級(jí)別,默認(rèn)16

2.其中的并發(fā)級(jí)別控制了Segment的個(gè)數(shù)。在y一個(gè)ConcurrentHashMap創(chuàng)建后Segment的個(gè)數(shù)是不能變的,擴(kuò)容過程是改變每個(gè)Segment的大小

關(guān)于分段鎖

Segment繼承了重入鎖ReentrantLock,有了鎖的的功能。每個(gè)鎖控制的是一段,當(dāng)每個(gè)Segment越來越大的時(shí)候,鎖的粒度就越來越大了

  • 分段鎖的優(yōu)勢(shì)是保證造操作不同段map的時(shí)候進(jìn)行鎖的競(jìng)爭(zhēng)和等待。這相當(dāng)于直接對(duì)整個(gè)map同步synchronized只是有優(yōu)勢(shì)的
  • 缺點(diǎn)在于分成很多段的時(shí)候會(huì)浪費(fèi)很多的內(nèi)存空間(不連續(xù),碎片化),操作map的時(shí)候競(jìng)爭(zhēng)一個(gè)分段鎖概率狠小的時(shí)候,分段鎖反而會(huì)造成更新等操作的長(zhǎng)時(shí)間等待,分段鎖的性能會(huì)下降

JDK1.8的map實(shí)現(xiàn)

JDK中的HashMap和ConcurrentHashMap。底層數(shù)據(jù)結(jié)構(gòu)為數(shù)組+鏈表+紅黑樹。數(shù)組可以擴(kuò)容,鏈表可以轉(zhuǎn)化為紅黑樹(本篇文章不對(duì)紅黑樹做講解,之前已經(jīng)分析過)

新版的ConcurrentHashMap為什么不使用ReentrantLock而使用synchronized?

減少內(nèi)存開銷:如果使用ReenteantLock則需要節(jié)點(diǎn)繼承AQS來獲得同步支持,增加內(nèi)存開銷,而1.8中只有頭節(jié)點(diǎn)需要同步

內(nèi)部?jī)?yōu)化:synchronized是JVM直接支持的,JVM能在運(yùn)行時(shí)做出相應(yīng)的優(yōu)化措施:鎖粗化、鎖消除、鎖自旋等

鎖的粒度

首先鎖的粒度并沒有變粗,甚至變得更細(xì)了。每當(dāng)擴(kuò)容一次,ConcurrentHashMap的并發(fā)度就擴(kuò)大一倍。

Hash沖突

JDK1.7中,ConcurrentHashMap從過二次hash的方式(Segment -> HashEntry)能夠快速的找到查找的元素。在1.8中通過鏈表加紅黑樹的形式彌補(bǔ)了put、get時(shí)的性能差距。

擴(kuò)容

JDK1.8中,在ConcurrentHashmap進(jìn)行擴(kuò)容時(shí),其他線程可以通過檢測(cè)數(shù)組中的節(jié)點(diǎn)決定是否對(duì)這條鏈表(紅黑樹)進(jìn)行擴(kuò)容,減小了擴(kuò)容的粒度,提高了擴(kuò)容的效率。

死鎖案例和排查

public class DeadLockDemo {
    public static void main(String[] args) {
        String lockA = "lockA";
        String lockB = "lockB";
        MyThread myThread1 = new MyThread(lockA,lockB);
        MyThread myThread2 = new MyThread(lockB,lockA);
        new Thread(myThread1).start();
        new Thread(myThread2).start();
    }

}

class MyThread implements Runnable {

    private String lockA;
    private String lockB;

    public MyThread(String lockA, String lockB) {
        this.lockA = lockA;
        this.lockB = lockB;
    }

    @Override
    public void run() {
        synchronized (lockA) {
            System.out.println(Thread.currentThread().getName() + "lock:" + lockA + " => " + lockB);
            try {
                TimeUnit.SECONDS.sleep(2);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            synchronized (lockB) {
                System.out.println(Thread.currentThread().getName() + "lock:" + lockB + " => " + lockA);
            }
        }
    }
}

到此這篇關(guān)于Java多線程之鎖學(xué)習(xí)(增強(qiáng)版)的文章就介紹到這了,更多相關(guān)Java多線程 鎖內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!

相關(guān)文章

  • IDEA 集成log4j將SQL語句打印在控制臺(tái)上的實(shí)現(xiàn)操作

    IDEA 集成log4j將SQL語句打印在控制臺(tái)上的實(shí)現(xiàn)操作

    這篇文章主要介紹了IDEA 集成log4j將SQL語句打印在控制臺(tái)上的實(shí)現(xiàn)操作,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。一起跟隨小編過來看看吧
    2021-02-02
  • SpringMVC Json自定義序列化和反序列化的操作方法

    SpringMVC Json自定義序列化和反序列化的操作方法

    這篇文章主要介紹了SpringMVC Json自定義序列化和反序列化的操作方法,本文給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下
    2021-01-01
  • 關(guān)于Idea中的.properties文件顯示問題

    關(guān)于Idea中的.properties文件顯示問題

    這篇文章主要介紹了關(guān)于Idea中的.properties文件顯示問題,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教
    2024-07-07
  • 一個(gè)簡(jiǎn)單的Java音樂播放器

    一個(gè)簡(jiǎn)單的Java音樂播放器

    這篇文章主要為大家分享一個(gè)簡(jiǎn)單的Java音樂播放器,具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下
    2017-06-06
  • java 實(shí)現(xiàn)線程同步的方式有哪些

    java 實(shí)現(xiàn)線程同步的方式有哪些

    當(dāng)使用多個(gè)線程來訪問同一個(gè)數(shù)據(jù)時(shí),非常容易出現(xiàn)線程安全問題,所以我們用同步機(jī)制來解決這些問題,本文將詳細(xì)介紹,需要的朋友可以參考下
    2012-11-11
  • 聊聊Java Double相加出現(xiàn)的怪事

    聊聊Java Double相加出現(xiàn)的怪事

    這篇文章主要介紹了Java Double相加出現(xiàn)的怪事,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教
    2021-12-12
  • try catch finally的執(zhí)行順序深入分析

    try catch finally的執(zhí)行順序深入分析

    首先執(zhí)行try,如果有異常執(zhí)行catch,無論如何都會(huì)執(zhí)行finally,當(dāng)有return以后,函數(shù)就會(huì)把這個(gè)數(shù)據(jù)存儲(chǔ)在某個(gè)位置,然后告訴主函數(shù),我不執(zhí)行了,接下來你執(zhí)行吧,所以函數(shù)就會(huì)推出
    2013-09-09
  • ElasticSearch合理分配索引分片原理

    ElasticSearch合理分配索引分片原理

    這篇文章主要介紹了ElasticSearch合理分配索引分片原理,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下
    2020-04-04
  • MyBatis-Plus 通用IService使用詳解

    MyBatis-Plus 通用IService使用詳解

    這篇文章主要介紹了MyBatis-Plus 通用IService使用詳解,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧
    2020-08-08
  • JAVA實(shí)戰(zhàn)練習(xí)之圖書管理系統(tǒng)實(shí)現(xiàn)流程

    JAVA實(shí)戰(zhàn)練習(xí)之圖書管理系統(tǒng)實(shí)現(xiàn)流程

    隨著網(wǎng)絡(luò)技術(shù)的高速發(fā)展,計(jì)算機(jī)應(yīng)用的普及,利用計(jì)算機(jī)對(duì)圖書館的日常工作進(jìn)行管理勢(shì)在必行,本篇文章手把手帶你用Java實(shí)現(xiàn)一個(gè)圖書管理系統(tǒng),大家可以在過程中查缺補(bǔ)漏,提升水平
    2021-10-10

最新評(píng)論