<rt id="bn8ez"></rt>
<label id="bn8ez"></label>
  • 

    • <span id="bn8ez"></span>
    

    <label id="bn8ez"><meter id="bn8ez"></meter></label>
    

    
    

    


    

        

    
	

    
	
    
		
    
			
				
    xylz,imxylz
    
				
    關(guān)注后端架構(gòu)、中間件、分布式和并發(fā)編程
    
			    		
		
    
	
    

    

    
	
    
		
    
			
 
 ::
首頁(yè) ::
新隨筆 ::
聯(lián)系 ::
聚合
 ::
管理 ::


			
			
				

    
	
    
		
    
			
			
			
				 
				111 
				隨筆 ::
				10 文章
				::
				2680 評(píng)論
				::
				0 Trackbacks
			
		
    
	
    

    

			    		
		
    
	
    

    


    


    
	
					

    07 2010 檔案
    

    
	

    

			
    
				
				
				
    
					     摘要:  

    在Set中有一個(gè)排序的集合SortedSet，用來(lái)保存按照自然順序排列的對(duì)象。Queue中同樣引入了一個(gè)支持排序的FIFO模型。

    并發(fā)隊(duì)列與Queue簡(jiǎn)介 中介紹了，PriorityQueue和PriorityBlockingQueue就是支持排序的Queue。顯然一個(gè)支持阻塞的排序Queue要比一個(gè)非線程安全的Queue實(shí)現(xiàn)起來(lái)要復(fù)雜的多，因此下面只介紹PriorityBlockingQueue，至于PriorityQueue只需要去掉Blocking功能就基本相同了。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-30 16:15 imxylz 閱讀(14146) | 評(píng)論 (0)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 在上一節(jié)中詳細(xì)分析了LinkedBlockingQueue 的實(shí)現(xiàn)原理。實(shí)現(xiàn)一個(gè)可擴(kuò)展的隊(duì)列通常有兩種方式：一種方式就像LinkedBlockingQueue一樣使用鏈表，也就是每一個(gè)元素帶有下一個(gè)元素的引用，這樣的隊(duì)列原生就是可擴(kuò)展的；另外一種就是通過(guò)數(shù)組實(shí)現(xiàn)，一旦隊(duì)列的大小達(dá)到數(shù)組的容量的時(shí)候就將數(shù)組擴(kuò)充一倍（或者一定的系數(shù)倍），從而達(dá)到擴(kuò)容的目的。常見(jiàn)的ArrayList就屬于第二種。前面章節(jié)介紹過(guò)的HashMap確是綜合使用了這兩種方式。

    對(duì)于一個(gè)Queue而言，同樣可以使用數(shù)組實(shí)現(xiàn)。使用數(shù)組的好處在于各個(gè)元素之間原生就是通過(guò)數(shù)組的索引關(guān)聯(lián)起來(lái)的，一次元素之間就是有序的，在通過(guò)索引操作數(shù)組就方便多了。當(dāng)然也有它不利的一面，擴(kuò)容起來(lái)比較麻煩，同時(shí)刪除一個(gè)元素也比較低效。

    ArrayBlockingQueue 就是Queue的一種數(shù)組實(shí)現(xiàn)。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-27 22:04 imxylz 閱讀(12950) | 評(píng)論 (0)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 在《并發(fā)容器 part 4 并發(fā)隊(duì)列與Queue簡(jiǎn)介》節(jié)中的類(lèi)圖中可以看到，對(duì)于Queue來(lái)說(shuō)，BlockingQueue是主要的線程安全版本。這是一個(gè)可阻塞的版本，也就是允許添加/刪除元素被阻塞，直到成功為止。

    BlockingQueue相對(duì)于Queue而言增加了兩個(gè)操作：put/take。下面是一張整理的表格。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-24 00:02 imxylz 閱讀(19661) | 評(píng)論 (6)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: ConcurrentLinkedQueue是Queue的一個(gè)線程安全實(shí)現(xiàn)。先來(lái)看一段文檔說(shuō)明。

    一個(gè)基于鏈接節(jié)點(diǎn)的無(wú)界線程安全隊(duì)列。此隊(duì)列按照 FIFO（先進(jìn)先出）原則對(duì)元素進(jìn)行排序。隊(duì)列的頭部 是隊(duì)列中時(shí)間最長(zhǎng)的元素。隊(duì)列的尾部 是隊(duì)列中時(shí)間最短的元素。新的元素插入到隊(duì)列的尾部，隊(duì)列獲取操作從隊(duì)列頭部獲得元素。當(dāng)多個(gè)線程共享訪問(wèn)一個(gè)公共 collection 時(shí)，ConcurrentLinkedQueue 是一個(gè)恰當(dāng)?shù)倪x擇。此隊(duì)列不允許使用 null 元素。

     

    由于ConcurrentLinkedQueue只是簡(jiǎn)單的實(shí)現(xiàn)了一個(gè)隊(duì)列Queue，因此從API的角度講，沒(méi)有多少值的介紹，使用起來(lái)也很簡(jiǎn)單，和前面遇到的所有FIFO隊(duì)列都類(lèi)似。出隊(duì)列只能操作頭節(jié)點(diǎn)，入隊(duì)列只能操作尾節(jié)點(diǎn)，任意節(jié)點(diǎn)操作就需要遍歷完整的隊(duì)列。

    重點(diǎn)放在解釋ConcurrentLinkedQueue的原理和實(shí)現(xiàn)上。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-23 14:11 imxylz 閱讀(20042) | 評(píng)論 (2)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: Queue是JDK 5以后引入的新的集合類(lèi)，它屬于Java Collections Framework的成員，在Collection集合中和List/Set是同一級(jí)別的接口。通常來(lái)講Queue描述的是一種FIFO的隊(duì)列，當(dāng)然不全都是，比如PriorityQueue是按照優(yōu)先級(jí)的順序（或者說(shuō)是自然順序，借助于Comparator接口）。

    下圖描述了Java Collections Framework中Queue的整個(gè)家族體系。

    對(duì)于Queue而言是在Collection的基礎(chǔ)上增加了offer/remove/poll/element/peek方法，另外重新定義了add方法。對(duì)于這六個(gè)方法，有不同的定義。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-21 12:21 imxylz 閱讀(21469) | 評(píng)論 (5)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 在上一篇中介紹了HashMap的原理，這一節(jié)是ConcurrentMap的最后一節(jié)，所以會(huì)完整的介紹ConcurrentHashMap的實(shí)現(xiàn)。

     

    ConcurrentHashMap原理

     

    在讀寫(xiě)鎖章節(jié)部分介紹過(guò)一種是用讀寫(xiě)鎖實(shí)現(xiàn)Map的方法。此種方法看起來(lái)可以實(shí)現(xiàn)Map響應(yīng)的功能，而且吞吐量也應(yīng)該不錯(cuò)。但是通過(guò)前面對(duì)讀寫(xiě)鎖原理的分析后知道，讀寫(xiě)鎖的適合場(chǎng)景是讀操作>>寫(xiě)操作，也就是讀操作應(yīng)該占據(jù)大部分操作，另外讀寫(xiě)鎖存在一個(gè)很?chē)?yán)重的問(wèn)題是讀寫(xiě)操作不能同時(shí)發(fā)生。要想解決讀寫(xiě)同時(shí)進(jìn)行問(wèn)題（至少不同元素的讀寫(xiě)分離），那么就只能將鎖拆分，不同的元素?fù)碛胁煌逆i，這種技術(shù)就是“鎖分離”技術(shù)。

    默認(rèn)情況下ConcurrentHashMap是用了16個(gè)類(lèi)似HashMap 的結(jié)構(gòu)，其中每一個(gè)HashMap擁有一個(gè)獨(dú)占鎖。也就是說(shuō)最終的效果就是通過(guò)某種Hash算法，將任何一個(gè)元素均勻的映射到某個(gè)HashMap的Map.Entry上面，而對(duì)某個(gè)一個(gè)元素的操作就集中在其分布的HashMap上，與其它HashMap無(wú)關(guān)。這樣就支持最多16個(gè)并發(fā)的寫(xiě)操作。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-20 17:48 imxylz 閱讀(21032) | 評(píng)論 (9)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 本來(lái)想比較全面和深入的談?wù)凜oncurrentHashMap的，發(fā)現(xiàn)網(wǎng)上有很多對(duì)HashMap和ConcurrentHashMap分析的文章，因此本小節(jié)盡可能的分析其中的細(xì)節(jié)，少一點(diǎn)理論的東西，多談?wù)剝?nèi)部設(shè)計(jì)的原理和思想。

    要談ConcurrentHashMap的構(gòu)造，就不得不談HashMap的構(gòu)造，因此先從HashMap開(kāi)始簡(jiǎn)單介紹。

     

    HashMap原理

    我們從頭開(kāi)始設(shè)想。要將對(duì)象存放在一起，如何設(shè)計(jì)這個(gè)容器。目前只有兩條路可以走，一種是采用分格技術(shù)，每一個(gè)對(duì)象存放于一個(gè)格子中，這樣通過(guò)對(duì)格子的編號(hào)就能取到或者遍歷對(duì)象；另一種技術(shù)就是采用串聯(lián)的方式，將各個(gè)對(duì)象串聯(lián)起來(lái)，這需要各個(gè)對(duì)象至少帶有下一個(gè)對(duì)象的索引（或者指針）。顯然第一種就是數(shù)組的概念，第二種就是鏈表的概念。所有的容器的實(shí)現(xiàn)其實(shí)都是基于這兩種方式的，不管是數(shù)組還是鏈表，或者二者俱有。HashMap采用的就是數(shù)組的方式。

    有了存取對(duì)象的容器后還需要以下兩個(gè)條件才能完成Map所需要的條件。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-20 00:22 imxylz 閱讀(22930) | 評(píng)論 (3)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 從這一節(jié)開(kāi)始正式進(jìn)入并發(fā)容器的部分，來(lái)看看JDK 6帶來(lái)了哪些并發(fā)容器。

    在JDK 1.4以下只有Vector和Hashtable是線程安全的集合（也稱并發(fā)容器，Collections.synchronized*系列也可以看作是線程安全的實(shí)現(xiàn)）。從JDK 5開(kāi)始增加了線程安全的Map接口ConcurrentMap和線程安全的隊(duì)列BlockingQueue（盡管Queue也是同時(shí)期引入的新的集合，但是規(guī)范并沒(méi)有規(guī)定一定是線程安全的，事實(shí)上一些實(shí)現(xiàn)也不是線程安全的，比如PriorityQueue、ArrayDeque、LinkedList等，在Queue章節(jié)中會(huì)具體討論這些隊(duì)列的結(jié)構(gòu)圖和實(shí)現(xiàn)）。

     

    在介紹ConcurrencyMap之前先來(lái)回顧下Map的體系結(jié)構(gòu)。下圖描述了Map的體系結(jié)構(gòu)，其中藍(lán)色字體的是JDK 5以后新增的并發(fā)容器。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-19 15:25 imxylz 閱讀(24650) | 評(píng)論 (8)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2010-07-16 11:59 imxylz 閱讀(9042) | 評(píng)論 (4)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要:  

    主要談?wù)勬i的性能以及其它一些理論知識(shí)，內(nèi)容主要的出處是《Java Concurrency in Practice》，結(jié)合自己的理解和實(shí)際應(yīng)用對(duì)鎖機(jī)制進(jìn)行一個(gè)小小的總結(jié)。

     

    首先需要強(qiáng)調(diào)的一點(diǎn)是：所有鎖（包括內(nèi)置鎖和高級(jí)鎖）都是有性能消耗的，也就是說(shuō)在高并發(fā)的情況下，由于鎖機(jī)制帶來(lái)的上下文切換、資源同步等消耗是非常可觀的。在某些極端情況下，線程在鎖上的消耗可能比線程本身的消耗還要多。所以如果可能的話，在任何情況下都盡量少用鎖，如果不可避免那么采用非阻塞算法是一個(gè)不錯(cuò)的解決方案，但是卻也不是絕對(duì)的。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-16 00:15 imxylz 閱讀(16585) | 評(píng)論 (2)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要:  

    這一節(jié)主要是談?wù)勛x寫(xiě)鎖的實(shí)現(xiàn)。

    上一節(jié)中提到，ReadWriteLock看起來(lái)有兩個(gè)鎖：readLock/writeLock。如果真的是兩個(gè)鎖的話，它們之間又是如何相互影響的呢？

    事實(shí)上在ReentrantReadWriteLock里鎖的實(shí)現(xiàn)是靠java.util.concurrent.locks.ReentrantReadWriteLock.Sync完成的。這個(gè)類(lèi)看起來(lái)比較眼熟，實(shí)際上它是AQS的一個(gè)子類(lèi)，這中類(lèi)似的結(jié)構(gòu)在CountDownLatch、ReentrantLock、Semaphore里面都存在。同樣它也有兩種實(shí)現(xiàn)：公平鎖和非公平鎖，也就是java.util.concurrent.locks.ReentrantReadWriteLock.FairSync和java.util.concurrent.locks.ReentrantReadWriteLock.NonfairSync。這里暫且不提。

    在ReentrantReadWriteLock里面的鎖主體就是一個(gè)Sync，也就是上面提到的FairSync或者NonfairSync，所以說(shuō)實(shí)際  閱讀全文
				
    
				
				
    
					posted @ 2010-07-15 00:41 imxylz 閱讀(20323) | 評(píng)論 (1)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 從這一節(jié)開(kāi)始介紹鎖里面的最后一個(gè)工具：讀寫(xiě)鎖(ReadWriteLock)。

    ReentrantLock 實(shí)現(xiàn)了標(biāo)準(zhǔn)的互斥操作，也就是一次只能有一個(gè)線程持有鎖，也即所謂獨(dú)占鎖的概念。前面的章節(jié)中一直在強(qiáng)調(diào)這個(gè)特點(diǎn)。顯然這個(gè)特點(diǎn)在一定程度上面減低了吞吐量，實(shí)際上獨(dú)占鎖是一種保守的鎖策略，在這種情況下任何“讀/讀”，“寫(xiě)/讀”，“寫(xiě)/寫(xiě)”操作都不能同時(shí)發(fā)生。但是同樣需要強(qiáng)調(diào)的一個(gè)概念是，鎖是有一定的開(kāi)銷(xiāo)的，當(dāng)并發(fā)比較大的時(shí)候，鎖的開(kāi)銷(xiāo)就比較客觀了。所以如果可能的話就盡量少用鎖，非要用鎖的話就嘗試看能否改造為讀寫(xiě)鎖。

    ReadWriteLock描述的是：一個(gè)資源能夠被多個(gè)讀線程訪問(wèn)，或者被一個(gè)寫(xiě)線程訪問(wèn)，但是不能同時(shí)存在讀寫(xiě)線程。也就是說(shuō)讀寫(xiě)鎖使用的場(chǎng)合是一個(gè)共享資源被大量讀取操作，而只有少量的寫(xiě)操作（修改數(shù)據(jù)）。清單1描述了ReadWriteLock的API。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-14 14:18 imxylz 閱讀(24267) | 評(píng)論 (4)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: Semaphore 是一個(gè)計(jì)數(shù)信號(hào)量。從概念上講，信號(hào)量維護(hù)了一個(gè)許可集。如有必要，在許可可用前會(huì)阻塞每一個(gè) acquire()，然后再獲取該許可。每個(gè) release() 添加一個(gè)許可，從而可能釋放一個(gè)正在阻塞的獲取者。但是，不使用實(shí)際的許可對(duì)象，Semaphore 只對(duì)可用許可的號(hào)碼進(jìn)行計(jì)數(shù)，并采取相應(yīng)的行動(dòng)。

    說(shuō)白了，Semaphore是一個(gè)計(jì)數(shù)器，在計(jì)數(shù)器不為0的時(shí)候?qū)€程就放行，一旦達(dá)到0，那么所有請(qǐng)求資源的新線程都會(huì)被阻塞，包括增加請(qǐng)求到許可的線程，也就是說(shuō)Semaphore不是可重入的。每一次請(qǐng)求一個(gè)許可都會(huì)導(dǎo)致計(jì)數(shù)器減少1，同樣每次釋放一個(gè)許可都會(huì)導(dǎo)致計(jì)數(shù)器增加1，一旦達(dá)到了0，新的許可請(qǐng)求線程將被掛起。

    緩存池整好使用此思想來(lái)實(shí)現(xiàn)的，比如鏈接池、對(duì)象池等。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-13 22:41 imxylz 閱讀(23385) | 評(píng)論 (2)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要:  

    如果說(shuō)CountDownLatch是一次性的，那么CyclicBarrier正好可以循環(huán)使用。它允許一組線程互相等待，直到到達(dá)某個(gè)公共屏障點(diǎn) (common barrier point)。所謂屏障點(diǎn)就是一組任務(wù)執(zhí)行完畢的時(shí)刻。

       閱讀全文
				
    
				
				
    
					posted @ 2010-07-12 23:33 imxylz 閱讀(22395) | 評(píng)論 (2)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 此小節(jié)介紹幾個(gè)與鎖有關(guān)的有用工具。

    閉鎖（Latch）

    閉鎖（Latch）：一種同步方法，可以延遲線程的進(jìn)度直到線程到達(dá)某個(gè)終點(diǎn)狀態(tài)。通俗的講就是，一個(gè)閉鎖相當(dāng)于一扇大門(mén)，在大門(mén)打開(kāi)之前所有線程都被阻斷，一旦大門(mén)打開(kāi)所有線程都將通過(guò)，但是一旦大門(mén)打開(kāi)，所有線程都通過(guò)了，那么這個(gè)閉鎖的狀態(tài)就失效了，門(mén)的狀態(tài)也就不能變了，只能是打開(kāi)狀態(tài)。也就是說(shuō)閉鎖的狀態(tài)是一次性的，它確保在閉鎖打開(kāi)之前所有特定的活動(dòng)都需要在閉鎖打開(kāi)之后才能完成。

    CountDownLatch是JDK 5+里面閉鎖的一個(gè)實(shí)現(xiàn)，允許一個(gè)或者多個(gè)線程等待某個(gè)事件的發(fā)生。CountDownLatch有一個(gè)正數(shù)計(jì)數(shù)器，countDown方法對(duì)計(jì)數(shù)器做減操作，await方法等待計(jì)數(shù)器達(dá)到0。所有await的線程都會(huì)阻塞直到計(jì)數(shù)器為0或者等待線程中斷或者超時(shí)。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-09 09:21 imxylz 閱讀(29345) | 評(píng)論 (6)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 這是一份完整的Java 并發(fā)整理筆記，記錄了我最近幾年學(xué)習(xí)Java并發(fā)的一些心得和體會(huì)。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-08 19:17 imxylz 閱讀(168327) | 評(píng)論 (43)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 本小節(jié)介紹鎖釋放Lock.unlock()。

    Release/TryRelease

    unlock操作實(shí)際上就調(diào)用了AQS的release操作，釋放持有的鎖。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-08 12:33 imxylz 閱讀(30502) | 評(píng)論 (11)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 接上篇，這篇從Lock.lock/unlock開(kāi)始。特別說(shuō)明在沒(méi)有特殊情況下所有程序、API、文檔都是基于JDK 6.0的。

    在沒(méi)有深入了解內(nèi)部機(jī)制及實(shí)現(xiàn)之前，先了解下為什么會(huì)存在公平鎖和非公平鎖。公平鎖保證一個(gè)阻塞的線程最終能夠獲得鎖，因?yàn)槭怯行虻模钥偸强梢园凑照?qǐng)求的順序獲得鎖。不公平鎖意味著后請(qǐng)求鎖的線程可能在其前面排列的休眠線程恢復(fù)前拿到鎖，這樣就有可能提高并發(fā)的性能。這是因?yàn)橥ǔＧ闆r下掛起的線程重新開(kāi)始與它真正開(kāi)始運(yùn)行，二者之間會(huì)產(chǎn)生嚴(yán)重的延時(shí)。因此非公平鎖就可以利用這段時(shí)間完成操作。這是非公平鎖在某些時(shí)候比公平鎖性能要好的原因之一。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-07 00:05 imxylz 閱讀(40185) | 評(píng)論 (6)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 在理解J.U.C原理以及鎖機(jī)制之前，我們來(lái)介紹J.U.C框架最核心也是最復(fù)雜的一個(gè)基礎(chǔ)類(lèi)：java.util.concurrent.locks.AbstractQueuedSynchronizer。

    

    AQS

    AbstractQueuedSynchronizer，簡(jiǎn)稱AQS，是J.U.C最復(fù)雜的一個(gè)類(lèi)，導(dǎo)致絕大多數(shù)講解并發(fā)原理或者實(shí)戰(zhàn)的時(shí)候都不會(huì)提到此類(lèi)。但是虛心的作者愿意借助自己有限的能力和精力來(lái)探討一二（參考資源中也有一些作者做了部分的分析。）。

    首先從理論知識(shí)開(kāi)始，在了解了相關(guān)原理后會(huì)針對(duì)源碼進(jìn)行一些分析，最后加上一些實(shí)戰(zhàn)來(lái)描述。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-06 18:29 imxylz 閱讀(53060) | 評(píng)論 (3)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 前面的章節(jié)主要談?wù)勗硬僮鳎劣谂c原子操作一些相關(guān)的問(wèn)題或者說(shuō)陷阱就放到最后的總結(jié)篇來(lái)整體說(shuō)明。從這一章開(kāi)始花少量的篇幅談?wù)勬i機(jī)制。

    上一個(gè)章節(jié)中談到了鎖機(jī)制，并且針對(duì)于原子操作談了一些相關(guān)的概念和設(shè)計(jì)思想。接下來(lái)的文章中，盡可能的深入研究鎖機(jī)制，并且理解里面的原理和實(shí)際應(yīng)用場(chǎng)合。

    盡管synchronized在語(yǔ)法上已經(jīng)足夠簡(jiǎn)單了，在JDK 5之前只能借助此實(shí)現(xiàn)，但是由于是獨(dú)占鎖，性能卻不高，因此JDK 5以后就開(kāi)始借助于JNI來(lái)完成更高級(jí)的鎖實(shí)現(xiàn)。

    JDK 5中的鎖是接口java.util.concurrent.locks.Lock。另外java.util.concurrent.locks.ReadWriteLock提供了一對(duì)可供讀寫(xiě)并發(fā)的鎖。根據(jù)前面的規(guī)則，我們從java.util.concurrent.locks.Lock的API開(kāi)始。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-05 13:37 imxylz 閱讀(42244) | 評(píng)論 (11)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 在JDK 5之前Java語(yǔ)言是靠synchronized關(guān)鍵字保證同步的，這會(huì)導(dǎo)致有鎖（后面的章節(jié)還會(huì)談到鎖）。

    鎖機(jī)制存在以下問(wèn)題：

    （1）在多線程競(jìng)爭(zhēng)下，加鎖、釋放鎖會(huì)導(dǎo)致比較多的上下文切換和調(diào)度延時(shí)，引起性能問(wèn)題。

    （2）一個(gè)線程持有鎖會(huì)導(dǎo)致其它所有需要此鎖的線程掛起。

    （3）如果一個(gè)優(yōu)先級(jí)高的線程等待一個(gè)優(yōu)先級(jí)低的線程釋放鎖會(huì)導(dǎo)致優(yōu)先級(jí)倒置，引起性能風(fēng)險(xiǎn)。

    volatile是不錯(cuò)的機(jī)制，但是volatile不能保證原子性。因此對(duì)于同步最終還是要回到鎖機(jī)制上來(lái)。

    獨(dú)占鎖是一種悲觀鎖，synchronized就是一種獨(dú)占鎖，會(huì)導(dǎo)致其它所有需要鎖的線程掛起，等待持有鎖的線程釋放鎖。而另一個(gè)更加有效的鎖就是樂(lè)觀鎖。所謂樂(lè)觀鎖就是，每次不加鎖而是假設(shè)沒(méi)有沖突而去完成某項(xiàng)操作，如果因?yàn)闆_突失敗就重試，直到成功為止。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-04 18:03 imxylz 閱讀(48033) | 評(píng)論 (19)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 在這個(gè)小結(jié)里面重點(diǎn)討論原子操作的原理和設(shè)計(jì)思想。

    由于在下一個(gè)章節(jié)中會(huì)談到鎖機(jī)制，因此此小節(jié)中會(huì)適當(dāng)引入鎖的概念。

    在Java Concurrency in Practice中是這樣定義線程安全的：

    當(dāng)多個(gè)線程訪問(wèn)一個(gè)類(lèi)時(shí)，如果不用考慮這些線程在運(yùn)行時(shí)環(huán)境下的調(diào)度和交替運(yùn)行，并且不需要額外的同步及在調(diào)用方代碼不必做其他的協(xié)調(diào)，這個(gè)類(lèi)的行為仍然是正確的，那么這個(gè)類(lèi)就是線程安全的。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-03 20:40 imxylz 閱讀(46630) | 評(píng)論 (16)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 在這一部分開(kāi)始討論數(shù)組原子操作和一些其他的原子操作。

    AtomicIntegerArray/AtomicLongArray/AtomicReferenceArray的API類(lèi)似，選擇有代表性的AtomicIntegerArray來(lái)描述這些問(wèn)題。

    int get(int i)

    獲取位置 i 的當(dāng)前值。很顯然，由于這個(gè)是數(shù)組操作，就有索引越界的問(wèn)題（IndexOutOfBoundsException異常）。

     

    對(duì)于下面的API起始和AtomicInteger是類(lèi)似的，這種通過(guò)方法、參數(shù)的名稱就能夠得到函數(shù)意義的寫(xiě)法是非常值得稱贊的。在《重構(gòu)：改善既有代碼的設(shè)計(jì)》和《代碼整潔之道》中都非常推崇這種做法。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-02 14:19 imxylz 閱讀(48190) | 評(píng)論 (6)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 從相對(duì)簡(jiǎn)單的Atomic入手（java.util.concurrent是基于Queue的并發(fā)包，而Queue，很多情況下使用到了Atomic操作，因此首先從這里開(kāi)始）。很多情況下我們只是需要一個(gè)簡(jiǎn)單的、高效的、線程安全的遞增遞減方案。注意，這里有三個(gè)條件：簡(jiǎn)單，意味著程序員盡可能少的操作底層或者實(shí)現(xiàn)起來(lái)要比較容易；高效意味著耗用資源要少，程序處理速度要快；線程安全也非常重要，這個(gè)在多線程下能保證數(shù)據(jù)的正確性。這三個(gè)條件看起來(lái)比較簡(jiǎn)單，但是實(shí)現(xiàn)起來(lái)卻難以令人滿意。

    通常情況下，在Java里面，++i或者--i不是線程安全的，這里面有三個(gè)獨(dú)立的操作：或者變量當(dāng)前值，為該值+1/-1，然后寫(xiě)回新的值。在沒(méi)有額外資源可以利用的情況下，只能使用加鎖才能保證讀-改-寫(xiě)這三個(gè)操作時(shí)“原子性”的。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-01 15:21 imxylz 閱讀(65877) | 評(píng)論 (2)  編輯
				
    
			
    
			
    
	


    


    


				

    




    

    ©2009-2014 IMXYLZ
    

    
    
        
	



主站蜘蛛池模板：
人人狠狠综合久久亚洲88|
很黄很黄的网站免费的|
免费无码国产在线观国内自拍中文字幕
|
日韩视频在线观看免费|
国产精品青草视频免费播放|
九九九国产精品成人免费视频|
在线精品自拍亚洲第一区|
亚洲av第一网站久章草|
日韩成人精品日本亚洲|
白白色免费在线视频|
未满十八私人高清免费影院|
九九九精品视频免费|
9久热精品免费观看视频|
你懂的免费在线观看|
久久福利青草精品资源站免费|
免费国产99久久久香蕉|
91精品啪在线观看国产线免费|
久久A级毛片免费观看|
黄页网站在线观看免费高清|
人妻视频一区二区三区免费|
在线a人片天堂免费观看高清|
日韩特黄特色大片免费视频|
国产成人免费A在线视频|
亚洲精品无码激情AV|
久久亚洲国产精品一区二区|
亚洲精品福利视频|
亚洲免费电影网站|
亚洲成AV人片高潮喷水|
又长又大又粗又硬3p免费视频|
国产无遮挡又黄又爽免费网站|
一级毛片在线免费看|
9久9久女女免费精品视频在线观看|
成人毛片免费观看视频在线|
免费一级特黄特色大片在线|
亚洲桃色AV无码|
亚洲成人动漫在线观看|
亚洲国产AV无码一区二区三区|
91av免费在线视频|
最近免费中文字幕大全高清大全1
最近免费中文字幕mv在线电影
|
亚洲成色WWW久久网站|
亚洲一级高清在线中文字幕|