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

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

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

    
    

    


    

        

    
	

    
	
    
		
    
			
				
    xylz,imxylz
    
				
    關注后端架構、中間件、分布式和并發編程
    
			    		
		
    
	
    

    

    
	
    
		
    
			
 
 ::
首頁 ::
新隨筆 ::
聯系 ::
聚合
 ::
管理 ::


			
			
				

    
	
    
		
    
			
			
			
				 
				111 
				隨筆 ::
				10 文章
				::
				2680 評論
				::
				0 Trackbacks
			
		
    
	
    

    

			    		
		
    
	
    

    


    


    
	
					


    
			  
	#

    


		
    
			
			
			
    
				     摘要: 當Ajax遇到GBK/GB2312，我們恨不能將所有項目的編碼統一改為UTF-8。顯然這個做法，成本太高了。下面給出了一個完善的解決方案。此方案不僅僅限于Ajax提交數據，也適用于普通訪問請求。  閱讀全文
			
    
			
			
    
				posted @ 2011-06-10 23:46 imxylz 閱讀(8728) | 評論 (6) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				
			
    
			
			
    
				posted @ 2011-04-12 14:02 imxylz 閱讀(3355) | 評論 (0) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要: 本節中將探討線程池是如何處理任務結果以及延遲、周期性任務調度是如何實現的。

    結合上節線程池的原理和實現，徹底分析了線程池對任務的結果處理，尤其是對延遲、周期性任務是如何執行的。

    這也是并發系列中源碼分析的最后一小節。  閱讀全文
			
    
			
			
    
				posted @ 2011-02-13 20:21 imxylz 閱讀(11284) | 評論 (6) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要: 這一節中我們將詳細討論線程池是如何執行一個任務的，尤其是如何處理線程池的大小、核心大小、最大大小、任務隊列等之間的關系的。  閱讀全文
			
    
			
			
    
				posted @ 2011-02-11 23:48 imxylz 閱讀(11674) | 評論 (2) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要: 我們根據線程池的要求也很能夠猜測出其數據結構出來。

    線程池需要支持多個線程并發執行，因此有一個線程集合Collection來執行線程任務；

    涉及任務的異步執行，因此需要有一個集合來緩存任務隊列Collection；

    很顯然在多個線程之間協調多個任務，那么就需要一個線程安全的任務集合，同時還需要支持阻塞、超時操作，那么BlockingQueue是必不可少的；

    既然是線程池，出發點就是提高系統性能同時降低資源消耗，那么線程池的大小就有限制，因此需要有一個核心線程池大小（線程個數）和一個最大線程池大小（線程個數），有一個計數用來描述當前線程池大小；

    如果是有限的線程池大小，那么長時間不使用的線程資源就應該銷毀掉，這樣就需要一個線程空閑時間的計數來描述線程何時被銷毀；

    前面描述過線程池也是有生命周期的，因此需要有一個狀態來描述線程池當前的運行狀態；

    線程池的任務隊列如果有邊界，那么就需要有一個任務拒絕策略來處理過多的任務，同時在線程池的銷毀階段也需要有一個任務拒絕策略來處理新加入的任務；

    上面種  閱讀全文
			
    
			
			
    
				posted @ 2011-01-18 23:43 imxylz 閱讀(16089) | 評論 (6) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要: 在JDK 5.0之前，java.util.Timer/TimerTask是唯一的內置任務調度方法，而且在很長一段時間里很熱衷于使用這種方式進行周期性任務調度。

    首先研究下Timer/TimerTask的特性（至于javax.swing.Timer就不再研究了）。

    上面三段代碼反映了Timer/TimerTask的以下特性：

    Timer對任務的調度是基于絕對時間的。

    所有的TimerTask只有一個線程TimerThread來執行，因此同一時刻只有一個TimerTask在執行。

    任何一個TimerTask的執行異常都會導致Timer終止所有任務。

    由于基于絕對時間并且是單線程執行，因此在多個任務調度時，長時間執行的任務被執行后有可能導致短時間任務快速在短時間內被執行多次或者干脆丟棄多個任務。  閱讀全文
			
    
			
			
    
				posted @ 2011-01-10 23:39 imxylz 閱讀(14461) | 評論 (32) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要: 上一節中提到關閉線程池過程中需要對新提交的任務進行處理。這個是java.util.concurrent.RejectedExecutionHandler處理的邏輯。

     

    在沒有分析線程池原理之前先來分析下為什么有任務拒絕的情況發生。

    這里先假設一個前提：線程池有一個任務隊列，用于緩存所有待處理的任務，正在處理的任務將從任務隊列中移除。因此在任務隊列長度有限的情況下就會出現新任務的拒絕處理問題，需要有一種策略來處理應該加入任務隊列卻因為隊列已滿無法加入的情況。另外在線程池關閉的時候也需要對任務加入隊列操作進行額外的協調處理。

     

    RejectedExecutionHandler提供了四種方式來處理任務拒絕策略。  閱讀全文
			
    
			
			
    
				posted @ 2011-01-08 22:47 imxylz 閱讀(9977) | 評論 (0) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要: 本著開發的原則，既然用到了別人家的東西，所以決定公開出來，也算是給別人一個參考。  閱讀全文
			
    
			
			
    
				posted @ 2011-01-05 10:00 imxylz 閱讀(4602) | 評論 (1) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要:  

    我們知道線程是有多種執行狀態的，同樣管理線程的線程池也有多種狀態。JVM會在所有線程（非后臺daemon線程）全部終止后才退出，為了節省資源和有效釋放資源關閉一個線程池就顯得很重要。有時候無法正確的關閉線程池，將會阻止JVM的結束。

    線程池Executor是異步的執行任務，因此任何時刻不能夠直接獲取提交的任務的狀態。這些任務有可能已經完成，也有可能正在執行或者還在排隊等待執行。因此關閉線程池可能出現一下幾種情況：

    平緩關閉：已經啟動的任務全部執行完畢，同時不再接受新的任務

    立即關閉：取消所有正在執行和未執行的任務

    另外關閉線程池后對于任務的狀態應該有相應的反饋信息。  閱讀全文
			
    
			
			
    
				posted @ 2011-01-04 22:54 imxylz 閱讀(12583) | 評論 (6) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要: Java里面線程池的頂級接口是Executor，但是嚴格意義上講Executor并不是一個線程池，而只是一個執行線程的工具。真正的線程池接口是ExecutorService。

    下面這張圖完整描述了線程池的類體系結構。  閱讀全文
			
    
			
			
    
				posted @ 2010-12-21 23:32 imxylz 閱讀(13778) | 評論 (4) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要: 從這一節開始正式進入線程池的部分。其實整個體系已經拖了很長的時間，因此后面的章節會加快速度，甚至只是一個半成品或者簡單化，以后有時間的慢慢補充、完善。

    其實線程池是并發包里面很重要的一部分，在實際情況中也是使用很多的一個重要組件。

    下圖描述的是線程池API的一部分。廣義上的完整線程池可能還包括Thread/Runnable、Timer/TimerTask等部分。這里只介紹主要的和高級的API以及架構和原理。  閱讀全文
			
    
			
			
    
				posted @ 2010-12-19 13:24 imxylz 閱讀(11961) | 評論 (5) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要: 最近的項目使用的是舊的ibatis2.x版本，有時候為了方便調試，想輸出SQL執行的語句和參數。我記得應該有某些logger的日志級別修改為DEBUG就可以看到。當然為了方便可以直接在log4j（如果使用log4j的話）的root日志級別修改為DEBUG，并且輸出appender的接受級別修改為DEBUG就可以了。這樣是可以看到日志信息（SQL/參數）等，但是同時也輸出了過多的其它logger信息，顯然在一個稍微大一點的系統里面debug的信息應該都是非常多的，不說別的，光是spring的日志就夠好多頁了。

    為了解決過多的日志，翻出ibatis源碼，看了下。ibatis的執行流程大致是這樣的。  閱讀全文
			
    
			
			
    
				posted @ 2010-12-05 15:17 imxylz 閱讀(3530) | 評論 (3) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				
			
    
			
			
    
				posted @ 2010-12-03 16:13 imxylz 閱讀(10046) | 評論 (7) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				
			
    
			
			
    
				posted @ 2010-11-24 14:34 imxylz 閱讀(6271) | 評論 (16) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要: 本小節是《并發容器》的最后一部分，這一個小節描述的是針對List/Set接口的一個線程版本。

    在《并發隊列與Queue簡介》中介紹了并發容器的一個概括，主要描述的是Queue的實現。其中特別提到一點LinkedList是List/Queue的實現，但是LinkedList確實非線程安全的。不管BlockingQueue還是ConcurrentMap的實現，我們發現都是針對鏈表的實現，當然盡可能的使用CAS或者Lock的特性，同時都有通過鎖部分容器來提供并發的特性。而對于List或者Set而言，增、刪操作其實都是針對整個容器，因此每次操作都不可避免的需要鎖定整個容器空間，性能肯定會大打折扣。要實現一個線程安全的List/Set，只需要在修改操作的時候進行同步即可，比如使用java.util.Collections.synchronizedList(List)或者java.util.Collections.synchronizedSet(Set)。當然也可以使用Lock來實現線程安全的List/Set。

    通常情況下我們的高并發都發生在“多讀少寫”的情況，因此如果  閱讀全文
			
    
			
			
    
				posted @ 2010-11-23 22:22 imxylz 閱讀(14697) | 評論 (1) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要: 可以在對中對元素進行配對和交換的線程的同步點。每個線程將條目上的某個方法呈現給 exchange 方法，與伙伴線程進行匹配，并且在返回時接收其伙伴的對象。Exchanger 可能被視為 SynchronousQueue 的雙向形式。

    換句話說Exchanger提供的是一個交換服務，允許原子性的交換兩個（多個）對象，但同時只有一對才會成功。先看一個簡單的實例模型。  閱讀全文
			
    
			
			
    
				posted @ 2010-11-22 22:31 imxylz 閱讀(7748) | 評論 (0) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				
			
    
			
			
    
				posted @ 2010-11-02 16:09 imxylz 閱讀(5767) | 評論 (19) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要: 這個小節介紹Queue的最后一個工具，也是最強大的一個工具。從名稱上就可以看到此工具的特點：雙向并發阻塞隊列。所謂雙向是指可以從隊列的頭和尾同時操作，并發只是線程安全的實現，阻塞允許在入隊出隊不滿足條件時掛起線程，這里說的隊列是指支持FIFO/FILO實現的鏈表。

     

    首先看下LinkedBlockingDeque的數據結構。通常情況下從數據結構上就能看出這種實現的優缺點，這樣就知道如何更好的使用工具了。  閱讀全文
			
    
			
			
    
				posted @ 2010-08-18 16:01 imxylz 閱讀(9752) | 評論 (5) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				
			
    
			
			
    
				posted @ 2010-08-12 00:54 imxylz 閱讀(3126) | 評論 (14) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要:  

    有一段時間沒有更新了。接著上節繼續吧。

    Queue除了前面介紹的實現外，還有一種雙向的Queue實現Deque。這種隊列允許在隊列頭和尾部進行入隊出隊操作，因此在功能上比Queue顯然要更復雜。下圖描述的是Deque的完整體系圖。需要說明的是LinkedList也已經加入了Deque的一部分（LinkedList是從jdk1.2 開始就存在數據結構）。  閱讀全文
			
    
			
			
    
				posted @ 2010-08-12 00:13 imxylz 閱讀(13607) | 評論 (4) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要:  

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

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

    對于一個Queue而言，同樣可以使用數組實現。使用數組的好處在于各個元素之間原生就是通過數組的索引關聯起來的，一次元素之間就是有序的，在通過索引操作數組就方便多了。當然也有它不利的一面，擴容起來比較麻煩，同時刪除一個元素也比較低效。

    ArrayBlockingQueue 就是Queue的一種數組實現。  閱讀全文
			
    
			
			
    
				posted @ 2010-07-27 22:04 imxylz 閱讀(12937) | 評論 (0) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要: 在《并發容器 part 4 并發隊列與Queue簡介》節中的類圖中可以看到，對于Queue來說，BlockingQueue是主要的線程安全版本。這是一個可阻塞的版本，也就是允許添加/刪除元素被阻塞，直到成功為止。

    BlockingQueue相對于Queue而言增加了兩個操作：put/take。下面是一張整理的表格。  閱讀全文
			
    
			
			
    
				posted @ 2010-07-24 00:02 imxylz 閱讀(19641) | 評論 (6) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要: ConcurrentLinkedQueue是Queue的一個線程安全實現。先來看一段文檔說明。

    一個基于鏈接節點的無界線程安全隊列。此隊列按照 FIFO（先進先出）原則對元素進行排序。隊列的頭部 是隊列中時間最長的元素。隊列的尾部 是隊列中時間最短的元素。新的元素插入到隊列的尾部，隊列獲取操作從隊列頭部獲得元素。當多個線程共享訪問一個公共 collection 時，ConcurrentLinkedQueue 是一個恰當的選擇。此隊列不允許使用 null 元素。

     

    由于ConcurrentLinkedQueue只是簡單的實現了一個隊列Queue，因此從API的角度講，沒有多少值的介紹，使用起來也很簡單，和前面遇到的所有FIFO隊列都類似。出隊列只能操作頭節點，入隊列只能操作尾節點，任意節點操作就需要遍歷完整的隊列。

    重點放在解釋ConcurrentLinkedQueue的原理和實現上。  閱讀全文
			
    
			
			
    
				posted @ 2010-07-23 14:11 imxylz 閱讀(20016) | 評論 (2) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要: Queue是JDK 5以后引入的新的集合類，它屬于Java Collections Framework的成員，在Collection集合中和List/Set是同一級別的接口。通常來講Queue描述的是一種FIFO的隊列，當然不全都是，比如PriorityQueue是按照優先級的順序（或者說是自然順序，借助于Comparator接口）。

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

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

     

    ConcurrentHashMap原理

     

    在讀寫鎖章節部分介紹過一種是用讀寫鎖實現Map的方法。此種方法看起來可以實現Map響應的功能，而且吞吐量也應該不錯。但是通過前面對讀寫鎖原理的分析后知道，讀寫鎖的適合場景是讀操作>>寫操作，也就是讀操作應該占據大部分操作，另外讀寫鎖存在一個很嚴重的問題是讀寫操作不能同時發生。要想解決讀寫同時進行問題（至少不同元素的讀寫分離），那么就只能將鎖拆分，不同的元素擁有不同的鎖，這種技術就是“鎖分離”技術。

    默認情況下ConcurrentHashMap是用了16個類似HashMap 的結構，其中每一個HashMap擁有一個獨占鎖。也就是說最終的效果就是通過某種Hash算法，將任何一個元素均勻的映射到某個HashMap的Map.Entry上面，而對某個一個元素的操作就集中在其分布的HashMap上，與其它HashMap無關。這樣就支持最多16個并發的寫操作。  閱讀全文
			
    
			
			
    
				posted @ 2010-07-20 17:48 imxylz 閱讀(21013) | 評論 (9) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要: 本來想比較全面和深入的談談ConcurrentHashMap的，發現網上有很多對HashMap和ConcurrentHashMap分析的文章，因此本小節盡可能的分析其中的細節，少一點理論的東西，多談談內部設計的原理和思想。

    要談ConcurrentHashMap的構造，就不得不談HashMap的構造，因此先從HashMap開始簡單介紹。

     

    HashMap原理

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

    有了存取對象的容器后還需要以下兩個條件才能完成Map所需要的條件。  閱讀全文
			
    
			
			
    
				posted @ 2010-07-20 00:22 imxylz 閱讀(22910) | 評論 (3) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要: 從這一節開始正式進入并發容器的部分，來看看JDK 6帶來了哪些并發容器。

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

     

    在介紹ConcurrencyMap之前先來回顧下Map的體系結構。下圖描述了Map的體系結構，其中藍色字體的是JDK 5以后新增的并發容器。  閱讀全文
			
    
			
			
    
				posted @ 2010-07-19 15:25 imxylz 閱讀(24631) | 評論 (8) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				
			
    
			
			
    
				posted @ 2010-07-16 11:59 imxylz 閱讀(9033) | 評論 (4) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要:  

    主要談談鎖的性能以及其它一些理論知識，內容主要的出處是《Java Concurrency in Practice》，結合自己的理解和實際應用對鎖機制進行一個小小的總結。

     

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

    這一節主要是談談讀寫鎖的實現。

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

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

    在ReentrantReadWriteLock里面的鎖主體就是一個Sync，也就是上面提到的FairSync或者NonfairSync，所以說實際  閱讀全文
			
    
			
			
    
				posted @ 2010-07-15 00:41 imxylz 閱讀(20308) | 評論 (1) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要: 從這一節開始介紹鎖里面的最后一個工具：讀寫鎖(ReadWriteLock)。

    ReentrantLock 實現了標準的互斥操作，也就是一次只能有一個線程持有鎖，也即所謂獨占鎖的概念。前面的章節中一直在強調這個特點。顯然這個特點在一定程度上面減低了吞吐量，實際上獨占鎖是一種保守的鎖策略，在這種情況下任何“讀/讀”，“寫/讀”，“寫/寫”操作都不能同時發生。但是同樣需要強調的一個概念是，鎖是有一定的開銷的，當并發比較大的時候，鎖的開銷就比較客觀了。所以如果可能的話就盡量少用鎖，非要用鎖的話就嘗試看能否改造為讀寫鎖。

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

    說白了，Semaphore是一個計數器，在計數器不為0的時候對線程就放行，一旦達到0，那么所有請求資源的新線程都會被阻塞，包括增加請求到許可的線程，也就是說Semaphore不是可重入的。每一次請求一個許可都會導致計數器減少1，同樣每次釋放一個許可都會導致計數器增加1，一旦達到了0，新的許可請求線程將被掛起。

    緩存池整好使用此思想來實現的，比如鏈接池、對象池等。  閱讀全文
			
    
			
			
    
				posted @ 2010-07-13 22:41 imxylz 閱讀(23366) | 評論 (2) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要:  

    如果說CountDownLatch是一次性的，那么CyclicBarrier正好可以循環使用。它允許一組線程互相等待，直到到達某個公共屏障點 (common barrier point)。所謂屏障點就是一組任務執行完畢的時刻。

       閱讀全文
			
    
			
			
    
				posted @ 2010-07-12 23:33 imxylz 閱讀(22377) | 評論 (2) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要: 此小節介紹幾個與鎖有關的有用工具。

    閉鎖（Latch）

    閉鎖（Latch）：一種同步方法，可以延遲線程的進度直到線程到達某個終點狀態。通俗的講就是，一個閉鎖相當于一扇大門，在大門打開之前所有線程都被阻斷，一旦大門打開所有線程都將通過，但是一旦大門打開，所有線程都通過了，那么這個閉鎖的狀態就失效了，門的狀態也就不能變了，只能是打開狀態。也就是說閉鎖的狀態是一次性的，它確保在閉鎖打開之前所有特定的活動都需要在閉鎖打開之后才能完成。

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

    Release/TryRelease

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

    在沒有深入了解內部機制及實現之前，先了解下為什么會存在公平鎖和非公平鎖。公平鎖保證一個阻塞的線程最終能夠獲得鎖，因為是有序的，所以總是可以按照請求的順序獲得鎖。不公平鎖意味著后請求鎖的線程可能在其前面排列的休眠線程恢復前拿到鎖，這樣就有可能提高并發的性能。這是因為通常情況下掛起的線程重新開始與它真正開始運行，二者之間會產生嚴重的延時。因此非公平鎖就可以利用這段時間完成操作。這是非公平鎖在某些時候比公平鎖性能要好的原因之一。  閱讀全文
			
    
			
			
    
				posted @ 2010-07-07 00:05 imxylz 閱讀(40167) | 評論 (6) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要: 在理解J.U.C原理以及鎖機制之前，我們來介紹J.U.C框架最核心也是最復雜的一個基礎類：java.util.concurrent.locks.AbstractQueuedSynchronizer。

    

    AQS

    AbstractQueuedSynchronizer，簡稱AQS，是J.U.C最復雜的一個類，導致絕大多數講解并發原理或者實戰的時候都不會提到此類。但是虛心的作者愿意借助自己有限的能力和精力來探討一二（參考資源中也有一些作者做了部分的分析。）。

    首先從理論知識開始，在了解了相關原理后會針對源碼進行一些分析，最后加上一些實戰來描述。  閱讀全文
			
    
			
			
    
				posted @ 2010-07-06 18:29 imxylz 閱讀(53043) | 評論 (3) | 編輯 收藏
			
    
		
    
		
    
	
		
    
			
			
			
    
				     摘要: 前面的章節主要談談原子操作，至于與原子操作一些相關的問題或者說陷阱就放到最后的總結篇來整體說明。從這一章開始花少量的篇幅談談鎖機制。

    上一個章節中談到了鎖機制，并且針對于原子操作談了一些相關的概念和設計思想。接下來的文章中，盡可能的深入研究鎖機制，并且理解里面的原理和實際應用場合。

    盡管synchronized在語法上已經足夠簡單了，在JDK 5之前只能借助此實現，但是由于是獨占鎖，性能卻不高，因此JDK 5以后就開始借助于JNI來完成更高級的鎖實現。

    JDK 5中的鎖是接口java.util.concurrent.locks.Lock。另外java.util.concurrent.locks.ReadWriteLock提供了一對可供讀寫并發的鎖。根據前面的規則，我們從java.util.concurrent.locks.Lock的API開始。  閱讀全文
			
    
			
			
    
				posted @ 2010-07-05 13:37 imxylz 閱讀(42225) | 評論 (11) | 編輯 收藏
			
    
		
    
		
    
	
    列出全部內容
    
	共3頁: 上一頁 1 2 3 下一頁 

    

				

    




    

    ©2009-2014 IMXYLZ
    

    
    
        
	



主站蜘蛛池模板：
色哟哟国产精品免费观看|
日韩在线视频线视频免费网站|
a毛片视频免费观看影院|
亚洲精品第一国产综合精品99|
亚洲AV日韩AV永久无码色欲|
国产精品麻豆免费版|
美女免费视频一区二区|
四虎影视精品永久免费|
一个人看的www在线免费视频|
国产精品亚洲mnbav网站
|
亚洲av纯肉无码精品动漫|
日韩视频在线免费|
免费人成网上在线观看|
亚洲日韩精品一区二区三区无码|
一级有奶水毛片免费看|
亚洲AV乱码一区二区三区林ゆな|
99在线免费观看视频|
亚洲中文字幕久在线|
成在线人永久免费视频播放|
日亚毛片免费乱码不卡一区|
亚洲国产一成人久久精品|
91精品手机国产免费|
国产人成亚洲第一网站在线播放|
国产精品视_精品国产免费|
EEUSS影院WWW在线观看免费|
亚洲第一精品福利|
卡一卡二卡三在线入口免费|
国产亚洲福利精品一区二区|
精品久久香蕉国产线看观看亚洲|
中文字幕在线免费观看|
噜噜综合亚洲AV中文无码|
亚洲午夜国产精品无码老牛影视|
69pao强力打造免费高清|
亚洲国产高清国产拍精品|
亚洲一区二区三区偷拍女厕|
国产精品入口麻豆免费观看|
美女被免费网站视频在线|
亚洲另类激情综合偷自拍|
国产美女被遭强高潮免费网站|
中文字幕免费在线播放|
久久综合久久综合亚洲|