真实的国产乱ⅩXXX66竹夫人,五月香六月婷婷激情综合,亚洲日本VA一区二区三区,亚洲精品一区二区三区麻豆

成都創(chuàng)新互聯(lián)網(wǎng)站制作重慶分公司

Java中的15種鎖是什么

這篇“Java中的15種鎖是什么”文章的知識(shí)點(diǎn)大部分人都不太理解,所以小編給大家總結(jié)了以下內(nèi)容,內(nèi)容詳細(xì),步驟清晰,具有一定的借鑒價(jià)值,希望大家閱讀完這篇文章能有所收獲,下面我們一起來看看這篇“Java中的15種鎖是什么”文章吧。

創(chuàng)新互聯(lián)是一家專注于網(wǎng)站建設(shè)、做網(wǎng)站與策劃設(shè)計(jì),肇州網(wǎng)站建設(shè)哪家好?創(chuàng)新互聯(lián)做網(wǎng)站,專注于網(wǎng)站建設(shè)10年,網(wǎng)設(shè)計(jì)領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:肇州等地區(qū)。肇州做網(wǎng)站價(jià)格咨詢:13518219792

公平鎖 / 非公平鎖

公平鎖

  • 公平鎖是指多個(gè)線程按照申請(qǐng)鎖的順序來獲取鎖。

非公平鎖

  • 非公平鎖是指多個(gè)線程獲取鎖的順序并不是按照申請(qǐng)鎖的順序,有可能后申請(qǐng)的線程比先申請(qǐng)的線程優(yōu)先獲取鎖。有可能,會(huì)造成優(yōu)先級(jí)反轉(zhuǎn)或者饑餓現(xiàn)象。

對(duì)于Java ReentrantLock而言,通過構(gòu)造函數(shù)指定該鎖是否是公平鎖,默認(rèn)是非公平鎖。非公平鎖的優(yōu)點(diǎn)在于吞吐量比公平鎖大。 對(duì)于Synchronized而言,也是一種非公平鎖。由于其并不像ReentrantLock是通過AQS的來實(shí)現(xiàn)線程調(diào)度,所以并沒有任何辦法使其變成公平鎖。

可重入鎖 / 不可重入鎖

可重入鎖

廣義上的可重入鎖指的是可重復(fù)可遞歸調(diào)用的鎖,在外層使用鎖之后,在內(nèi)層仍然可以使用,并且不發(fā)生死鎖(前提得是同一個(gè)對(duì)象或者class),這樣的鎖就叫做可重入鎖。ReentrantLock和synchronized都是可重入鎖

synchronized void setA() throws Exception{
 Thread.sleep(1000);
 setB();
}
synchronized void setB() throws Exception{
 Thread.sleep(1000);
}

上面的代碼就是一個(gè)可重入鎖的一個(gè)特點(diǎn),如果不是可重入鎖的話,setB可能不會(huì)被當(dāng)前線程執(zhí)行,可能造成死鎖。

不可重入鎖

不可重入鎖,與可重入鎖相反,不可遞歸調(diào)用,遞歸調(diào)用就發(fā)生死鎖。看到一個(gè)經(jīng)典的講解,使用自旋鎖來模擬一個(gè)不可重入鎖,代碼如下

import java.util.concurrent.atomic.AtomicReference;
public class UnreentrantLock {
 private AtomicReference owner = new AtomicReference();
 public void lock() {
 Thread current = Thread.currentThread();
 //這句是很經(jīng)典的“自旋”語法,AtomicInteger中也有
 for (;;) {
 if (!owner.compareAndSet(null, current)) {
 return;
 }
 }
 }
 public void unlock() {
 Thread current = Thread.currentThread();
 owner.compareAndSet(current, null);
 }
}

代碼也比較簡單,使用原子引用來存放線程,同一線程兩次調(diào)用lock()方法,如果不執(zhí)行unlock()釋放鎖的話,第二次調(diào)用自旋的時(shí)候就會(huì)產(chǎn)生死鎖,這個(gè)鎖就不是可重入的,而實(shí)際上同一個(gè)線程不必每次都去釋放鎖再來獲取鎖,這樣的調(diào)度切換是很耗資源的。

把它變成一個(gè)可重入鎖 :

import java.util.concurrent.atomic.AtomicReference;
public class UnreentrantLock {
 private AtomicReference owner = new AtomicReference();
 private int state = 0;
 public void lock() {
 Thread current = Thread.currentThread();
 if (current == owner.get()) {
 state++;
 return;
 }
 //這句是很經(jīng)典的“自旋”式語法,AtomicInteger中也有
 for (;;) {
 if (!owner.compareAndSet(null, current)) {
 return;
 }
 }
 }
 public void unlock() {
 Thread current = Thread.currentThread();
 if (current == owner.get()) {
 if (state != 0) {
 state--;
 } else {
 owner.compareAndSet(current, null);
 }
 }
 }
}

在執(zhí)行每次操作之前,判斷當(dāng)前鎖持有者是否是當(dāng)前對(duì)象,采用state計(jì)數(shù),不用每次去釋放鎖。

ReentrantLock中可重入鎖實(shí)現(xiàn)

這里看非公平鎖的鎖獲取方法:

final boolean nonfairTryAcquire(int acquires) {
	final Thread current = Thread.currentThread();
	int c = getState();
	if (c == 0) {
		if (compareAndSetState(0, acquires)) {
			setExclusiveOwnerThread(current);
			return true;
		}
	}
	//就是這里
	else if (current == getExclusiveOwnerThread()) {
		int nextc = c + acquires;
		if (nextc < 0) // overflow
			throw new Error("Maximum lock count exceeded");
		setState(nextc);
		return true;
	}
	return false;
}

在AQS中維護(hù)了一個(gè)private volatile int state來計(jì)數(shù)重入次數(shù),避免了頻繁的持有釋放操作,這樣既提升了效率,又避免了死鎖。

獨(dú)享鎖 / 共享鎖

獨(dú)享鎖和共享鎖在你去讀C.U.T包下的ReeReentrantLock和ReentrantReadWriteLock你就會(huì)發(fā)現(xiàn),它倆一個(gè)是獨(dú)享一個(gè)是共享鎖。

  • 獨(dú)享鎖 :該鎖每一次只能被一個(gè)線程所持有。

  • 共享鎖 :該鎖可被多個(gè)線程共有,典型的就是ReentrantReadWriteLock里的讀鎖,它的讀鎖是可以被共享的,但是它的寫鎖確每次只能被獨(dú)占。

另外讀鎖的共享可保證并發(fā)讀是非常高效的,但是讀寫和寫寫,寫讀都是互斥的。

獨(dú)享鎖與共享鎖也是通過AQS來實(shí)現(xiàn)的,通過實(shí)現(xiàn)不同的方法,來實(shí)現(xiàn)獨(dú)享或者共享。 對(duì)于Synchronized而言,當(dāng)然是獨(dú)享鎖。

互斥鎖 / 讀寫鎖

互斥鎖

在訪問共享資源之前對(duì)進(jìn)行加鎖操作,在訪問完成之后進(jìn)行解鎖操作。 加鎖后,任何其他試圖再次加鎖的線程會(huì)被阻塞,直到當(dāng)前進(jìn)程解鎖。

如果解鎖時(shí)有一個(gè)以上的線程阻塞,那么所有該鎖上的線程都被編程就緒狀態(tài), 第一個(gè)變?yōu)榫途w狀態(tài)的線程又執(zhí)行加鎖操作,那么其他的線程又會(huì)進(jìn)入等待。 在這種方式下,只有一個(gè)線程能夠訪問被互斥鎖保護(hù)的資源

讀寫鎖

讀寫鎖既是互斥鎖,又是共享鎖,read模式是共享,write是互斥(排它鎖)的。

讀寫鎖有三種狀態(tài) :讀加鎖狀態(tài)、寫加鎖狀態(tài)和不加鎖狀態(tài)

讀寫鎖在Java中的具體實(shí)現(xiàn)就是 ReadWriteLock

一次只有一個(gè)線程可以占有寫模式的讀寫鎖,但是多個(gè)線程可以同時(shí)占有讀模式的讀寫鎖。 只有一個(gè)線程可以占有寫狀態(tài)的鎖,但可以有多個(gè)線程同時(shí)占有讀狀態(tài)鎖,這也是它可以實(shí)現(xiàn)高并發(fā)的原因。當(dāng)其處于寫狀態(tài)鎖下,任何想要嘗試獲得鎖的線程都會(huì)被阻塞,直到寫狀態(tài)鎖被釋放;如果是處于讀狀態(tài)鎖下,允許其它線程獲得它的讀狀態(tài)鎖,但是不允許獲得它的寫狀態(tài)鎖,直到所有線程的讀狀態(tài)鎖被釋放;為了避免想要嘗試寫操作的線程一直得不到寫狀態(tài)鎖,當(dāng)讀寫鎖感知到有線程想要獲得寫狀態(tài)鎖時(shí),便會(huì)阻塞其后所有想要獲得讀狀態(tài)鎖的線程。所以讀寫鎖非常適合資源的讀操作遠(yuǎn)多于寫操作的情況。

樂觀鎖 / 悲觀鎖

悲觀鎖

總是假設(shè)最壞的情況,每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人會(huì)修改,所以每次在拿數(shù)據(jù)的時(shí)候都會(huì)上鎖,這樣別人想拿這個(gè)數(shù)據(jù)就會(huì)阻塞直到它拿到鎖( 共享資源每次只給一個(gè)線程使用,其它線程阻塞,用完后再把資源轉(zhuǎn)讓給其它線程 )。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫里邊就用到了很多這種鎖機(jī)制,比如行鎖,表鎖等,讀鎖,寫鎖等,都是在做操作之前先上鎖。Java中synchronized和ReentrantLock等獨(dú)占鎖就是悲觀鎖思想的實(shí)現(xiàn)。

樂觀鎖

總是假設(shè)最好的情況,每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人不會(huì)修改,所以不會(huì)上鎖,但是在更新的時(shí)候會(huì)判斷一下在此期間別人有沒有去更新這個(gè)數(shù)據(jù),可以使用版本號(hào)機(jī)制和CAS算法實(shí)現(xiàn)。樂 觀鎖適用于多讀的應(yīng)用類型,這樣可以提高吞吐量 ,像數(shù)據(jù)庫提供的類似于write_condition機(jī)制,其實(shí)都是提供的樂觀鎖。在Java中java.util.concurrent.atomic包下面的 原子變量類就是使用了樂觀鎖的一種實(shí)現(xiàn)方式CAS實(shí)現(xiàn)的 。

分段鎖

分段鎖其實(shí)是一種鎖的設(shè)計(jì),并不是具體的一種鎖,對(duì)于ConcurrentHashMap而言,其并發(fā)的實(shí)現(xiàn)就是通過分段鎖的形式來實(shí)現(xiàn)高效的并發(fā)操作。

并發(fā)容器類的加鎖機(jī)制是基于粒度更小的分段鎖,分段鎖也是提升多并發(fā)程序性能的重要手段之一。

在并發(fā)程序中,串行操作是會(huì)降低可伸縮性,并且上下文切換也會(huì)減低性能。在鎖上發(fā)生競爭時(shí)將通水導(dǎo)致這兩種問題,使用獨(dú)占鎖時(shí)保護(hù)受限資源的時(shí)候,基本上是采用串行方式—-每次只能有一個(gè)線程能訪問它。所以對(duì)于可伸縮性來說最大的威脅就是獨(dú)占鎖。

我們一般有三種方式降低鎖的競爭程度 : 1、減少鎖的持有時(shí)間 2、降低鎖的請(qǐng)求頻率 3、使用帶有協(xié)調(diào)機(jī)制的獨(dú)占鎖,這些機(jī)制允許更高的并發(fā)性。

在某些情況下我們可以將鎖分解技術(shù)進(jìn)一步擴(kuò)展為一組獨(dú)立對(duì)象上的鎖進(jìn)行分解,這成為分段鎖。

其實(shí)說的簡單一點(diǎn)就是 :

容器里有多把鎖,每一把鎖用于鎖容器其中一部分?jǐn)?shù)據(jù),那么當(dāng)多線程訪問容器里不同數(shù)據(jù)段的數(shù)據(jù)時(shí),線程間就不會(huì)存在鎖競爭,從而可以有效的提高并發(fā)訪問效率,這就是ConcurrentHashMap所使用的鎖分段技術(shù),首先將數(shù)據(jù)分成一段一段的存儲(chǔ),然后給每一段數(shù)據(jù)配一把鎖,當(dāng)一個(gè)線程占用鎖訪問其中一個(gè)段數(shù)據(jù)的時(shí)候,其他段的數(shù)據(jù)也能被其他線程訪問。

比如:在ConcurrentHashMap中使用了一個(gè)包含16個(gè)鎖的數(shù)組,每個(gè)鎖保護(hù)所有散列桶的1/16,其中第N個(gè)散列桶由第(N mod 16)個(gè)鎖來保護(hù)。假設(shè)使用合理的散列算法使關(guān)鍵字能夠均勻的分部,那么這大約能使對(duì)鎖的請(qǐng)求減少到越來的1/16。也正是這項(xiàng)技術(shù)使得ConcurrentHashMap支持多達(dá)16個(gè)并發(fā)的寫入線程。

偏向鎖 / 輕量級(jí)鎖 / 重量級(jí)鎖

鎖的狀態(tài) :

  • 無鎖狀態(tài)

  • 偏向鎖狀態(tài)

  • 輕量級(jí)鎖狀態(tài)

  • 重量級(jí)鎖狀態(tài)

鎖的狀態(tài)是通過對(duì)象監(jiān)視器在對(duì)象頭中的字段來表明的。 四種狀態(tài)會(huì)隨著競爭的情況逐漸升級(jí),而且是不可逆的過程,即不可降級(jí)。 這四種狀態(tài)都不是Java語言中的鎖 ,而是Jvm為了提高鎖的獲取與釋放效率而做的優(yōu)化( 使用synchronized時(shí) )。

偏向鎖

  • 偏向鎖是指一段同步代碼一直被一個(gè)線程所訪問,那么該線程會(huì)自動(dòng)獲取鎖。降低獲取鎖的代價(jià)。

輕量級(jí)

  • 輕量級(jí)鎖是指當(dāng)鎖是偏向鎖的時(shí)候,被另一個(gè)線程所訪問,偏向鎖就會(huì)升級(jí)為輕量級(jí)鎖,其他線程會(huì)通過自旋的形式嘗試獲取鎖,不會(huì)阻塞,提高性能。

重量級(jí)鎖

  • 重量級(jí)鎖是指當(dāng)鎖為輕量級(jí)鎖的時(shí)候,另一個(gè)線程雖然是自旋,但自旋不會(huì)一直持續(xù)下去,當(dāng)自旋一定次數(shù)的時(shí)候,還沒有獲取到鎖,就會(huì)進(jìn)入阻塞,該鎖膨脹為重量級(jí)鎖。重量級(jí)鎖會(huì)讓其他申請(qǐng)的線程進(jìn)入阻塞,性能降低。

自旋鎖

我們知道CAS算法是樂觀鎖的一種實(shí)現(xiàn)方式,CAS算法中又涉及到自旋鎖,所以這里給大家講一下什么是自旋鎖。

簡單回顧一下CAS算法

CAS是英文單詞Compare and Swap(比較并交換),是一種有名的無鎖算法。無鎖編程,即不使用鎖的情況下實(shí)現(xiàn)多線程之間的變量同步,也就是在沒有線程被阻塞的情況下實(shí)現(xiàn)變量的同步,所以也叫非阻塞同步(Non-blocking Synchronization)。CAS算法涉及到三個(gè)操作數(shù)

  • 需要讀寫的內(nèi)存值 V

  • 進(jìn)行比較的值 A

  • 擬寫入的新值 B

更新一個(gè)變量的時(shí)候,只有當(dāng)變量的預(yù)期值A(chǔ)和內(nèi)存地址V當(dāng)中的實(shí)際值相同時(shí),才會(huì)將內(nèi)存地址V對(duì)應(yīng)的值修改為B,否則不會(huì)執(zhí)行任何操作。一般情況下是一個(gè)自旋操作,即不斷的重試。

什么是自旋鎖?

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

它是為實(shí)現(xiàn)保護(hù)共享資源而提出一種鎖機(jī)制。其實(shí),自旋鎖與互斥鎖比較類似,它們都是為了解決對(duì)某項(xiàng)資源的互斥使用。 無論是互斥鎖,還是自旋鎖,在任何時(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)釋放了鎖,”自旋”一詞就是因此而得名。

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

下面是個(gè)簡單的例子:

public class SpinLock {
 private AtomicReference cas = new AtomicReference();
 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沒有釋放鎖,另一個(gè)線程B又來獲取鎖,此時(shí)由于不滿足CAS,所以就會(huì)進(jìn)入while循環(huán),不斷判斷是否滿足CAS,直到A線程調(diào)用unlock方法釋放了該鎖。

自旋鎖存在的問題

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

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

1、自旋鎖不會(huì)使線程狀態(tài)發(fā)生切換,一直處于用戶態(tài),即線程一直都是active的;不會(huì)使線程進(jìn)入阻塞狀態(tài),減少了不必要的上下文切換,執(zhí)行速度快 2、非自旋鎖在獲取不到鎖的時(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)在用戶態(tài)與內(nèi)核態(tài)之間來回切換,嚴(yán)重影響鎖的性能)

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

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

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

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

public class ReentrantSpinLock {
 private AtomicReference cas = new AtomicReference();
 private int count;
 public void lock() {
 Thread current = Thread.currentThread();
 if (current == cas.get()) { // 如果當(dāng)前線程已經(jīng)獲取到了鎖,線程數(shù)增加一,然后返回
 count++;
 return;
 }
 // 如果沒獲取到鎖,則通過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)前線程多次獲取了該鎖,釋放鎖通過count減一來模擬
 count--;
 } else {// 如果count==0,可以將鎖釋放,這樣就能保證獲取鎖的次數(shù)與釋放鎖的次數(shù)是一致的了。
 cas.compareAndSet(cur, null);
 }
 }
 }
}

自旋鎖與互斥鎖

  • 自旋鎖與互斥鎖都是為了實(shí)現(xiàn)保護(hù)資源共享的機(jī)制。

  • 無論是自旋鎖還是互斥鎖,在任意時(shí)刻,都最多只能有一個(gè)保持者。

  • 獲取互斥鎖的線程,如果鎖已經(jīng)被占用,則該線程將進(jìn)入睡眠狀態(tài);獲取自旋鎖的線程則不會(huì)睡眠,而是一直循環(huán)等待鎖釋放。

  • 這里推薦一下我的 Java后端技術(shù)圈子: 867857579,群里有(分布式架構(gòu)、高可擴(kuò)展、高性能、高并發(fā)、性能優(yōu)化、Spring boot、redis、ActiveMQ、等學(xué)習(xí)資源)進(jìn)群免費(fèi)送給每一位Java小伙伴,不管你是轉(zhuǎn)行,還是工作中想提升自己能力都可以,歡迎進(jìn)群一起深入交流學(xué)習(xí)!

自旋鎖總結(jié)

  • 自旋鎖:線程獲取鎖的時(shí)候,如果鎖被其他線程持有,則當(dāng)前線程將循環(huán)等待,直到獲取到鎖。

  • 自旋鎖等待期間,線程的狀態(tài)不會(huì)改變,線程一直是用戶態(tài)并且是活動(dòng)的(active)。

  • 自旋鎖如果持有鎖的時(shí)間太長,則會(huì)導(dǎo)致其它等待獲取鎖的線程耗盡CPU。

  • 自旋鎖本身無法保證公平性,同時(shí)也無法保證可重入性。

  • 基于自旋鎖,可以實(shí)現(xiàn)具備公平性和可重入性質(zhì)的鎖。

以上就是關(guān)于“Java中的15種鎖是什么”這篇文章的內(nèi)容,相信大家都有了一定的了解,希望小編分享的內(nèi)容對(duì)大家有幫助,若想了解更多相關(guān)的知識(shí)內(nèi)容,請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。


網(wǎng)站題目:Java中的15種鎖是什么
轉(zhuǎn)載注明:http://weahome.cn/article/jdcedo.html

其他資訊

在線咨詢

微信咨詢

電話咨詢

028-86922220(工作日)

18980820575(7×24)

提交需求

返回頂部