自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

面試官:講講高并發(fā)場景下如何優(yōu)化加鎖方式?

開發(fā) 架構(gòu)
很多時(shí)候,我們在并發(fā)編程中,涉及到加鎖操作時(shí),對代碼塊的加鎖操作真的合理嗎?還有沒有需要優(yōu)化的地方呢?

 [[346345]]

作者個(gè)人研發(fā)的在高并發(fā)場景下,提供的簡單、穩(wěn)定、可擴(kuò)展的延遲消息隊(duì)列框架,具有精準(zhǔn)的定時(shí)任務(wù)和延遲隊(duì)列處理功能。自開源半年多以來,已成功為十幾家中小型企業(yè)提供了精準(zhǔn)定時(shí)調(diào)度方案,經(jīng)受住了生產(chǎn)環(huán)境的考驗(yàn)。為使更多童鞋受益,現(xiàn)給出開源框架地址:

https://github.com/sunshinelyz/mykit-delay

寫在前面

很多時(shí)候,我們在并發(fā)編程中,涉及到加鎖操作時(shí),對代碼塊的加鎖操作真的合理嗎?還有沒有需要優(yōu)化的地方呢?

問題闡述

在《【高并發(fā)】優(yōu)化加鎖方式時(shí)竟然死鎖了!!》一文中,我們介紹了產(chǎn)生死鎖時(shí)的四個(gè)必要條件,只有四個(gè)條件同時(shí)具備時(shí)才能發(fā)生死鎖。其中,我們在阻止請求與保持條件時(shí),采用了一次性申請所有的資源的方式。例如在我們完成轉(zhuǎn)賬操作的過程中,我們一次性申請賬戶A和賬戶B,兩個(gè)賬戶都申請成功后,再執(zhí)行轉(zhuǎn)賬的操作。其中,在我們實(shí)現(xiàn)的轉(zhuǎn)賬方法中,使用了死循環(huán)來循環(huán)獲取資源,直到同時(shí)獲取到賬戶A和賬戶B為止,核心代碼如下所示。

  1. //一次申請轉(zhuǎn)出賬戶和轉(zhuǎn)入賬戶,直到成功 
  2. while(!requester.applyResources(this, target)){ 
  3.     //循環(huán)體為空 
  4.     ; 

如果ResourcesRequester類的applyResources()方法執(zhí)行的時(shí)間非常短,并且程序并發(fā)帶來的沖突不大,程序循環(huán)幾次到幾十次就可以同時(shí)獲取到轉(zhuǎn)出賬戶和轉(zhuǎn)入賬戶,這種方案就是可行的。

但是,如果ResourcesRequester類的applyResources()方法執(zhí)行的時(shí)間比較長,或者說,程序并發(fā)帶來的沖突比較大,此時(shí),可能需要循環(huán)成千上萬次才能同時(shí)獲取到轉(zhuǎn)出賬戶和轉(zhuǎn)入賬戶。這樣就太消耗CPU資源了,此時(shí),這種方案就是不可行的了。

那么,有沒有什么方式對這種方案進(jìn)行優(yōu)化呢?

問題分析

既然使用死循環(huán)一直獲取資源這種方案存在問題,那我們換位思考一下。當(dāng)線程執(zhí)行時(shí),發(fā)現(xiàn)條件不滿足,是不是可以讓線程進(jìn)入等待狀態(tài)?當(dāng)條件滿足的時(shí)候,通知等待的線程重新執(zhí)行?

也就是說,如果線程需要的條件不滿足,我們就讓線程進(jìn)入等待狀態(tài);如果線程需要的條件滿足時(shí),我們再通知等待的線程重新執(zhí)行。這樣,就能夠避免程序進(jìn)行循環(huán)等待進(jìn)而消耗CPU的問題。

那么,問題又來了!當(dāng)條件不滿足時(shí),如何實(shí)現(xiàn)讓線程等待?當(dāng)條件滿足時(shí),又如何喚醒線程呢?

不錯(cuò),這是個(gè)問題!不過這個(gè)問題解決起來也非常簡單。簡單的說,就是使用線程的等待與通知機(jī)制。

線程的等待與通知機(jī)制

我們可以使用線程的等待與通知機(jī)制來優(yōu)化阻止請求與保持條件時(shí),循環(huán)獲取賬戶資源的問題。具體的等待與通知機(jī)制如下所示。

執(zhí)行的線程首先獲取互斥鎖,如果線程繼續(xù)執(zhí)行時(shí),需要的條件不滿足,則釋放互斥鎖,并進(jìn)入等待狀態(tài);當(dāng)線程繼續(xù)執(zhí)行需要的條件滿足時(shí),就通知等待的線程,重新獲取互斥鎖。

那么,說了這么多,Java支持這種線程的等待與通知機(jī)制嗎?其實(shí),這個(gè)問題問的就有點(diǎn)廢話了,Java這么優(yōu)秀(牛逼)的語言肯定支持啊,而且實(shí)現(xiàn)起來也比較簡單。

Java實(shí)現(xiàn)線程的等待與通知機(jī)制

實(shí)現(xiàn)方式

其實(shí),使用Java語言實(shí)現(xiàn)線程的等待與通知機(jī)制有多種方式,這里我就簡單的列舉一種方式,其他的方式大家可以自行思考和實(shí)現(xiàn),有不懂的地方也可以問我!

在Java語言中,實(shí)現(xiàn)線程的等待與通知機(jī)制,一種簡單的方式就是使用synchronized并結(jié)合wait()、notify()和notifyAll()方法來實(shí)現(xiàn)。

實(shí)現(xiàn)原理

我們使用synchronized加鎖時(shí),只允許一個(gè)線程進(jìn)入synchronized保護(hù)的代碼塊,也就是臨界區(qū)。如果一個(gè)線程進(jìn)入了臨界區(qū),則其他的線程會進(jìn)入阻塞隊(duì)列里等待,這個(gè)阻塞隊(duì)列和synchronized互斥鎖是一對一的關(guān)系,也就是說,一把互斥鎖對應(yīng)著一個(gè)獨(dú)立的阻塞隊(duì)列。

在并發(fā)編程中,如果一個(gè)線程獲得了synchronized互斥鎖,但是不滿足繼續(xù)向下執(zhí)行的條件,則需要進(jìn)入等待狀態(tài)。此時(shí),可以使用Java中的wait()方法來實(shí)現(xiàn)。當(dāng)調(diào)用wait()方法后,當(dāng)前線程就會被阻塞,并且會進(jìn)入一個(gè)等待隊(duì)列中進(jìn)行等待,這個(gè)由于調(diào)用wait()方法而進(jìn)入的等待隊(duì)列也是互斥鎖的等待隊(duì)列。而且,線程在進(jìn)入等待隊(duì)列的同時(shí),會釋放自身獲得的互斥鎖,這樣,其他線程就有機(jī)會獲得互斥鎖,進(jìn)而進(jìn)入臨界區(qū)了。整個(gè)過程可以表示成下圖所示。

當(dāng)線程執(zhí)行的條件滿足時(shí),可以使用Java提供的notify()和notifyAll()方法來通知互斥鎖等待隊(duì)列中的線程,我們可以使用下圖來簡單的表示這個(gè)過程。

這里,需要注意如下事項(xiàng):

(1)使用notify()和notifyAll()方法通知線程時(shí),調(diào)用notify()和notifyAll()方法時(shí),滿足線程的執(zhí)行條件,但是當(dāng)線程真正執(zhí)行的時(shí)候,條件可能已經(jīng)不再滿足了,可能有其他線程已經(jīng)進(jìn)入臨界區(qū)執(zhí)行。

(2)被通知的線程繼續(xù)執(zhí)行時(shí),需要先獲取互斥鎖,因?yàn)樵谡{(diào)用wait()方法等待時(shí)已經(jīng)釋放了互斥鎖。

(3)wait()、notify()和notifyAll()方法操作的隊(duì)列是互斥鎖的等待隊(duì)列,如果synchronized鎖定的是this對象,則一定要使用this.wait()、this.notify()和this.notifyAll()方法;如果synchronized鎖定的是target對象,則一定要使用target.wait()、target.notify()和target.notifyAll()方法。

(4)wait()、notify()和notifyAll()方法調(diào)用的前提是已經(jīng)獲取了相應(yīng)的互斥鎖,也就是說,wait()、notify()和notifyAll()方法都是在synchronized方法中或代碼塊中調(diào)用的。如果在synchronized方法外或代碼塊外調(diào)用了三個(gè)方法,或者鎖定的對象是this,使用target對象調(diào)用三個(gè)方法的話,JVM會拋出java.lang.IllegalMonitorStateException異常。

具體實(shí)現(xiàn)

實(shí)現(xiàn)邏輯

在實(shí)現(xiàn)之前,我們還需要考慮以下幾個(gè)問題:

  • 選擇哪個(gè)互斥鎖

在之前的程序中,我們在TansferAccount類中,存在一個(gè)ResourcesRequester 類的單例對象,所以,我們是可以使用this作為互斥鎖的。這一點(diǎn)大家需要重點(diǎn)理解。

  • 線程執(zhí)行轉(zhuǎn)賬操作的條件

轉(zhuǎn)出賬戶和轉(zhuǎn)入賬戶都沒有被分配過。

  • 線程什么時(shí)候進(jìn)入等待狀態(tài)

線程繼續(xù)執(zhí)行需要的條件不滿足的時(shí)候,進(jìn)入等待狀態(tài)。

  • 什么時(shí)候通知等待的線程執(zhí)行

當(dāng)存在線程釋放賬戶的資源時(shí),通知等待的線程繼續(xù)執(zhí)行。

綜上,我們可以得出以下核心代碼。

  1. while(不滿足條件){ 
  2.     wait(); 

那么,問題來了!為何是在while循環(huán)中調(diào)用wait()方法呢?因?yàn)楫?dāng)wait()方法返回時(shí),有可能線程執(zhí)行的條件已經(jīng)改變,也就是說,之前條件是滿足的,但是現(xiàn)在已經(jīng)不滿足了,所以要重新檢驗(yàn)條件是否滿足。

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

我們優(yōu)化后的ResourcesRequester類的代碼如下所示。

  1. public class ResourcesRequester{ 
  2.     //存放申請資源的集合 
  3.     private List<Object> resources = new ArrayList<Object>(); 
  4.     //一次申請所有的資源 
  5.     public synchronized void applyResources(Object source, Object target){ 
  6.         while(resources.contains(source) || resources.contains(target)){ 
  7.             try{ 
  8.                 wait(); 
  9.             }catch(Exception e){ 
  10.                 e.printStackTrace(); 
  11.             } 
  12.         } 
  13.         resources.add(source); 
  14.         resources.add(targer); 
  15.     } 
  16.      
  17.     //釋放資源 
  18.     public synchronized void releaseResources(Object source, Object target){ 
  19.         resources.remove(source); 
  20.         resources.remove(target); 
  21.         notifyAll(); 
  22.     } 

生成ResourcesRequester單例對象的Holder類ResourcesRequesterHolder的代碼如下所示。

  1. public class ResourcesRequesterHolder{ 
  2.     private ResourcesRequesterHolder(){} 
  3.      
  4.     public static ResourcesRequester getInstance(){ 
  5.         return Singleton.INSTANCE.getInstance(); 
  6.     } 
  7.     private enum Singleton{ 
  8.         INSTANCE; 
  9.         private ResourcesRequester singleton; 
  10.         Singleton(){ 
  11.             singleton = new ResourcesRequester(); 
  12.         } 
  13.         public ResourcesRequester getInstance(){ 
  14.             return singleton; 
  15.         } 
  16.     } 

執(zhí)行轉(zhuǎn)賬操作的類的代碼如下所示。

  1. public class TansferAccount{ 
  2.     //賬戶的余額 
  3.     private Integer balance; 
  4.     //ResourcesRequester類的單例對象 
  5.     private ResourcesRequester requester; 
  6.     
  7.     public TansferAccount(Integer balance){ 
  8.         this.balance = balance; 
  9.         this.requester = ResourcesRequesterHolder.getInstance(); 
  10.     } 
  11.     //轉(zhuǎn)賬操作 
  12.     public void transfer(TansferAccount target, Integer transferMoney){ 
  13.         //一次申請轉(zhuǎn)出賬戶和轉(zhuǎn)入賬戶,直到成功 
  14.         requester.applyResources(this, target)) 
  15.         try{ 
  16.             //對轉(zhuǎn)出賬戶加鎖 
  17.             synchronized(this){ 
  18.                 //對轉(zhuǎn)入賬戶加鎖 
  19.                 synchronized(target){ 
  20.                     if(this.balance >= transferMoney){ 
  21.                         this.balance -= transferMoney; 
  22.                         target.balance += transferMoney; 
  23.                     }    
  24.                 } 
  25.             } 
  26.         }finally{ 
  27.             //最后釋放賬戶資源 
  28.             requester.releaseResources(this, target); 
  29.         } 
  30.     } 

可以看到,我們在程序中通知處于等待狀態(tài)的線程時(shí),使用的是notifyAll()方法而不是notify()方法。那notify()方法和notifyAll()方法兩者有什么區(qū)別呢?

notify()和notifyAll()的區(qū)別

  • notify()方法

隨機(jī)通知等待隊(duì)列中的一個(gè)線程。

  • notifyAll()方法

通知等待隊(duì)列中的所有線程。

在實(shí)際工作過程中,如果沒有特殊的要求,盡量使用notifyAll()方法。因?yàn)槭褂胣otify()方法是有風(fēng)險(xiǎn)的,可能會導(dǎo)致某些線程永久不會被通知到!

 本文轉(zhuǎn)載自微信公眾號「 冰河技術(shù)」,可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系 冰河技術(shù)公眾號。

 

責(zé)任編輯:武曉燕 來源: 冰河技術(shù)
相關(guān)推薦

2022-04-29 08:17:38

RPC遠(yuǎn)程代理代理模式

2020-11-06 07:11:40

內(nèi)存虛擬Redis

2020-09-07 06:28:37

Nginx靜態(tài)負(fù)載均衡動態(tài)負(fù)載均衡

2024-02-28 10:14:47

Redis數(shù)據(jù)硬盤

2020-07-28 00:58:20

IP地址子網(wǎng)TCP

2021-01-13 05:27:02

服務(wù)器性能高并發(fā)

2020-09-14 06:57:30

緩存穿透雪崩

2021-08-02 17:21:08

設(shè)計(jì)模式訂閱

2024-09-29 00:00:00

高并發(fā)交易所宕機(jī)

2021-04-26 09:05:55

高并發(fā)索引MySQL

2023-07-13 08:19:30

HaspMapRedis元素

2023-03-08 07:46:53

面試官優(yōu)化結(jié)構(gòu)體

2025-02-26 03:00:00

2025-02-28 00:03:22

高并發(fā)TPS系統(tǒng)

2015-08-13 10:29:12

面試面試官

2020-11-02 07:02:10

加載鏈接初始化

2019-06-06 10:55:02

JDK高并發(fā)框架

2024-09-18 09:02:14

單核服務(wù)器線程切換

2025-04-29 02:00:00

高并發(fā)系統(tǒng)場景

2025-03-26 01:25:00

MySQL優(yōu)化事務(wù)
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號