xylz,imxylz

     摘要: 世界邦旅行網(wǎng)創(chuàng)業(yè)團(tuán)隊(duì)(北京)招聘Java工程師/PHP工程師/測(cè)試工程師/前端工程師/移動(dòng)開(kāi)發(fā)工程師等  閱讀全文

     摘要: Bash 為了提高命令的解析速度，將解析過(guò)的命令的全路徑保存在hash表中，因此下次執(zhí)行的時(shí)候就無(wú)需進(jìn)行再次解析。如果在shell中修改了已經(jīng)緩存過(guò)的命令路徑，那么bash可能不能立即生效。這樣就會(huì)發(fā)生命令不能解析或者文件不存在的問(wèn)題，盡管可執(zhí)行文件確實(shí)存在。  閱讀全文

     摘要: OS X 下批量轉(zhuǎn)換圖片格式。  閱讀全文

     摘要: Google的web字體在我朝訪問(wèn)巨慢，尤其是HTTPS方式更慢，本文幫助大家解決octopress默認(rèn)的google web字體訪問(wèn)太慢的問(wèn)題。  閱讀全文

     摘要: JRebel最新版本6.0.0的下載地址及個(gè)人學(xué)習(xí)使用版本。  閱讀全文

     摘要: 本文描述如何申請(qǐng)2.5$每年的SSL證書(shū)，并啟用Nginx的HTTPS訪問(wèn)。  閱讀全文

     摘要: 線程池

并發(fā)最常見(jiàn)用于線程池，顯然使用線程池可以有效的提高吞吐量。
最常見(jiàn)、比較復(fù)雜一個(gè)場(chǎng)景是Web容器的線程池。Web容器使用線程池同步或者異步處理HTTP請(qǐng)求，同時(shí)這也可以有效的復(fù)用HTTP連接，降低資源申請(qǐng)的開(kāi)銷。通常我們認(rèn)為HTTP請(qǐng)求時(shí)非常昂貴的，并且也是比較耗費(fèi)資源和性能的，所以線程池在這里就扮演了非常重要的角色。
在線程池的章節(jié)中非常詳細(xì)的討論了線程池的原理和使用，同時(shí)也提到了，線程池的配置和參數(shù)對(duì)性能的影響是巨大的。不盡如此，受限于資源（機(jī)器的性能、網(wǎng)絡(luò)的帶寬等等）、依賴的服務(wù)，客戶端的響應(yīng)速度等，線程池的威力也不會(huì)一直增長(zhǎng)。達(dá)到了線程池的瓶頸后，性能和吞吐量都會(huì)大幅度降低。
一直增加機(jī)器的性能或者增大線程的個(gè)數(shù)，并不一定能有效的提高吞吐量。高并發(fā)的情況下，機(jī)器的負(fù)載會(huì)大幅提升，這時(shí)候機(jī)器的穩(wěn)定性、服務(wù)的可靠性都會(huì)下降。
盡管如此，線程池依然是提高吞吐量的一個(gè)有效措施，配合合適的參數(shù)能夠有效的充分利用資源，提高資源的利用率。  閱讀全文

     摘要: 死鎖與活躍度

前面談了很多并發(fā)的特性和工具，但是大部分都是和鎖有關(guān)的。我們使用鎖來(lái)保證線程安全，但是這也會(huì)引起一些問(wèn)題。
鎖順序死鎖(lock-ordering deadlock)：多個(gè)線程試圖通過(guò)不同的順序獲得多個(gè)相同的資源，則發(fā)生的循環(huán)鎖依賴現(xiàn)象。
動(dòng)態(tài)的鎖順序死鎖（Dynamic Lock Order Deadlocks）：多個(gè)線程通過(guò)傳遞不同的鎖造成的鎖順序死鎖問(wèn)題。
資源死鎖（Resource Deadlocks）：線程間相互等待對(duì)方持有的鎖，并且誰(shuí)都不會(huì)釋放自己持有的鎖發(fā)生的死鎖。也就是說(shuō)當(dāng)現(xiàn)場(chǎng)持有和等待的目標(biāo)成為資源，就有可能發(fā)生此死鎖。這和鎖順序死鎖不一樣的地方是，競(jìng)爭(zhēng)的資源之間并沒(méi)有嚴(yán)格先后順序，僅僅是相互依賴而已。  閱讀全文

     摘要: 剛看到這個(gè)月的編程語(yǔ)言排行榜，很顯然java的霸主地位很快就會(huì)在發(fā)達(dá)國(guó)家被擠掉，C語(yǔ)言依然是王者（想想上個(gè)月自己買的兩個(gè)C語(yǔ)言的書(shū)，冷汗直流）。看來(lái)我遲早要回歸C，這才是真正的王道。



非常令人吃驚的是C++語(yǔ)言依然不夠堅(jiān)挺，由于Windows 7/Windows 8的發(fā)力，C#很快就會(huì)搶占C++的市場(chǎng)，估計(jì)很快就會(huì)將C++從前三名中擠下去。



iPhone/iPad的熱銷讓Object C繼續(xù)火熱，前十的位置還是可以持續(xù)很久的，這一點(diǎn)毋庸置疑。移動(dòng)設(shè)備開(kāi)發(fā)的高端人才現(xiàn)在是高薪難求，如果有時(shí)間我也要繼續(xù)關(guān)注下。  閱讀全文

     摘要: Zookeeper客戶端和服務(wù)端維持一個(gè)長(zhǎng)連接，每隔10s向服務(wù)端發(fā)送一個(gè)心跳，服務(wù)端返回客戶端一個(gè)響應(yīng)。這就是一個(gè)Session連接，擁有全局唯一的session id。Session連接通常是一直有效，如果因?yàn)榫W(wǎng)絡(luò)原因斷開(kāi)了連接，客戶端會(huì)使用相同的session id進(jìn)行重連。由于服務(wù)端保留了session的各種狀態(tài)，尤其是各種瞬時(shí)節(jié)點(diǎn)是否刪除依賴于session是否失效。
Session失效問(wèn)題

通?？蛻舳酥鲃?dòng)關(guān)閉連接認(rèn)為是一次session失效。另外也有可能因?yàn)槠渌粗?，例如網(wǎng)絡(luò)超時(shí)導(dǎo)致的session失效問(wèn)題。在服務(wù)端看來(lái)，無(wú)法區(qū)分session失效是何種情況，一次一旦發(fā)生session失效，一定時(shí)間后就會(huì)將session持有的所有watcher以及瞬時(shí)節(jié)點(diǎn)刪除。
而對(duì)于Zookeeper客戶端而言，一旦發(fā)生失效不知道是否該重連，這涉及到watcher和瞬時(shí)節(jié)點(diǎn)問(wèn)題，因此Zookeeper客戶端認(rèn)為，一旦發(fā)生了seesion失效，那么就認(rèn)為客戶端死掉了。從而所有操作都不能夠進(jìn)行。參考 How should I handle SESSION  閱讀全文

     摘要: 為了提高性能，最近將Redis從2.2.x的最新版2.2.12升級(jí)到2.4.x(2.4.2)，驚喜的發(fā)現(xiàn)內(nèi)存占用節(jié)省了很多。大贊！


有人說(shuō)Redis的作者是一個(gè)勤奮的人，深表同意！


本來(lái)升級(jí)是為了增加批量操作從而提高性能，沒(méi)想到內(nèi)存占用節(jié)省了很多。

對(duì)于32位的操作系統(tǒng)而言，節(jié)省內(nèi)存62%，對(duì)于64位操作系統(tǒng)而言節(jié)省73%。非?？捎^。  閱讀全文

     摘要: 當(dāng)Ajax遇到GBK/GB2312，我們恨不能將所有項(xiàng)目的編碼統(tǒng)一改為UTF-8。顯然這個(gè)做法，成本太高了。下面給出了一個(gè)完善的解決方案。此方案不僅僅限于Ajax提交數(shù)據(jù)，也適用于普通訪問(wèn)請(qǐng)求。  閱讀全文

     摘要: 本節(jié)中將探討線程池是如何處理任務(wù)結(jié)果以及延遲、周期性任務(wù)調(diào)度是如何實(shí)現(xiàn)的。
結(jié)合上節(jié)線程池的原理和實(shí)現(xiàn)，徹底分析了線程池對(duì)任務(wù)的結(jié)果處理，尤其是對(duì)延遲、周期性任務(wù)是如何執(zhí)行的。
這也是并發(fā)系列中源碼分析的最后一小節(jié)。  閱讀全文

     摘要: 這一節(jié)中我們將詳細(xì)討論線程池是如何執(zhí)行一個(gè)任務(wù)的，尤其是如何處理線程池的大小、核心大小、最大大小、任務(wù)隊(duì)列等之間的關(guān)系的。  閱讀全文

     摘要: 我們根據(jù)線程池的要求也很能夠猜測(cè)出其數(shù)據(jù)結(jié)構(gòu)出來(lái)。
線程池需要支持多個(gè)線程并發(fā)執(zhí)行，因此有一個(gè)線程集合Collection來(lái)執(zhí)行線程任務(wù)；
涉及任務(wù)的異步執(zhí)行，因此需要有一個(gè)集合來(lái)緩存任務(wù)隊(duì)列Collection；
很顯然在多個(gè)線程之間協(xié)調(diào)多個(gè)任務(wù)，那么就需要一個(gè)線程安全的任務(wù)集合，同時(shí)還需要支持阻塞、超時(shí)操作，那么BlockingQueue是必不可少的；
既然是線程池，出發(fā)點(diǎn)就是提高系統(tǒng)性能同時(shí)降低資源消耗，那么線程池的大小就有限制，因此需要有一個(gè)核心線程池大?。ň€程個(gè)數(shù)）和一個(gè)最大線程池大小（線程個(gè)數(shù)），有一個(gè)計(jì)數(shù)用來(lái)描述當(dāng)前線程池大??；
如果是有限的線程池大小，那么長(zhǎng)時(shí)間不使用的線程資源就應(yīng)該銷毀掉，這樣就需要一個(gè)線程空閑時(shí)間的計(jì)數(shù)來(lái)描述線程何時(shí)被銷毀；
前面描述過(guò)線程池也是有生命周期的，因此需要有一個(gè)狀態(tài)來(lái)描述線程池當(dāng)前的運(yùn)行狀態(tài)；
線程池的任務(wù)隊(duì)列如果有邊界，那么就需要有一個(gè)任務(wù)拒絕策略來(lái)處理過(guò)多的任務(wù)，同時(shí)在線程池的銷毀階段也需要有一個(gè)任務(wù)拒絕策略來(lái)處理新加入的任務(wù)；
上面種  閱讀全文

     摘要: 在JDK 5.0之前，java.util.Timer/TimerTask是唯一的內(nèi)置任務(wù)調(diào)度方法，而且在很長(zhǎng)一段時(shí)間里很熱衷于使用這種方式進(jìn)行周期性任務(wù)調(diào)度。
首先研究下Timer/TimerTask的特性（至于javax.swing.Timer就不再研究了）。
上面三段代碼反映了Timer/TimerTask的以下特性：
Timer對(duì)任務(wù)的調(diào)度是基于絕對(duì)時(shí)間的。
所有的TimerTask只有一個(gè)線程TimerThread來(lái)執(zhí)行，因此同一時(shí)刻只有一個(gè)TimerTask在執(zhí)行。
任何一個(gè)TimerTask的執(zhí)行異常都會(huì)導(dǎo)致Timer終止所有任務(wù)。
由于基于絕對(duì)時(shí)間并且是單線程執(zhí)行，因此在多個(gè)任務(wù)調(diào)度時(shí)，長(zhǎng)時(shí)間執(zhí)行的任務(wù)被執(zhí)行后有可能導(dǎo)致短時(shí)間任務(wù)快速在短時(shí)間內(nèi)被執(zhí)行多次或者干脆丟棄多個(gè)任務(wù)。  閱讀全文

     摘要: 上一節(jié)中提到關(guān)閉線程池過(guò)程中需要對(duì)新提交的任務(wù)進(jìn)行處理。這個(gè)是java.util.concurrent.RejectedExecutionHandler處理的邏輯。

在沒(méi)有分析線程池原理之前先來(lái)分析下為什么有任務(wù)拒絕的情況發(fā)生。
這里先假設(shè)一個(gè)前提：線程池有一個(gè)任務(wù)隊(duì)列，用于緩存所有待處理的任務(wù)，正在處理的任務(wù)將從任務(wù)隊(duì)列中移除。因此在任務(wù)隊(duì)列長(zhǎng)度有限的情況下就會(huì)出現(xiàn)新任務(wù)的拒絕處理問(wèn)題，需要有一種策略來(lái)處理應(yīng)該加入任務(wù)隊(duì)列卻因?yàn)殛?duì)列已滿無(wú)法加入的情況。另外在線程池關(guān)閉的時(shí)候也需要對(duì)任務(wù)加入隊(duì)列操作進(jìn)行額外的協(xié)調(diào)處理。

RejectedExecutionHandler提供了四種方式來(lái)處理任務(wù)拒絕策略。  閱讀全文

     摘要: 本著開(kāi)發(fā)的原則，既然用到了別人家的東西，所以決定公開(kāi)出來(lái)，也算是給別人一個(gè)參考。  閱讀全文

     摘要:
我們知道線程是有多種執(zhí)行狀態(tài)的，同樣管理線程的線程池也有多種狀態(tài)。JVM會(huì)在所有線程（非后臺(tái)daemon線程）全部終止后才退出，為了節(jié)省資源和有效釋放資源關(guān)閉一個(gè)線程池就顯得很重要。有時(shí)候無(wú)法正確的關(guān)閉線程池，將會(huì)阻止JVM的結(jié)束。
線程池Executor是異步的執(zhí)行任務(wù)，因此任何時(shí)刻不能夠直接獲取提交的任務(wù)的狀態(tài)。這些任務(wù)有可能已經(jīng)完成，也有可能正在執(zhí)行或者還在排隊(duì)等待執(zhí)行。因此關(guān)閉線程池可能出現(xiàn)一下幾種情況：
平緩關(guān)閉：已經(jīng)啟動(dòng)的任務(wù)全部執(zhí)行完畢，同時(shí)不再接受新的任務(wù)
立即關(guān)閉：取消所有正在執(zhí)行和未執(zhí)行的任務(wù)
另外關(guān)閉線程池后對(duì)于任務(wù)的狀態(tài)應(yīng)該有相應(yīng)的反饋信息。  閱讀全文

     摘要: Java里面線程池的頂級(jí)接口是Executor，但是嚴(yán)格意義上講Executor并不是一個(gè)線程池，而只是一個(gè)執(zhí)行線程的工具。真正的線程池接口是ExecutorService。
下面這張圖完整描述了線程池的類體系結(jié)構(gòu)。  閱讀全文

     摘要: 從這一節(jié)開(kāi)始正式進(jìn)入線程池的部分。其實(shí)整個(gè)體系已經(jīng)拖了很長(zhǎng)的時(shí)間，因此后面的章節(jié)會(huì)加快速度，甚至只是一個(gè)半成品或者簡(jiǎn)單化，以后有時(shí)間的慢慢補(bǔ)充、完善。
其實(shí)線程池是并發(fā)包里面很重要的一部分，在實(shí)際情況中也是使用很多的一個(gè)重要組件。
下圖描述的是線程池API的一部分。廣義上的完整線程池可能還包括Thread/Runnable、Timer/TimerTask等部分。這里只介紹主要的和高級(jí)的API以及架構(gòu)和原理。  閱讀全文

     摘要: 最近的項(xiàng)目使用的是舊的ibatis2.x版本，有時(shí)候?yàn)榱朔奖阏{(diào)試，想輸出SQL執(zhí)行的語(yǔ)句和參數(shù)。我記得應(yīng)該有某些logger的日志級(jí)別修改為DEBUG就可以看到。當(dāng)然為了方便可以直接在log4j（如果使用log4j的話）的root日志級(jí)別修改為DEBUG，并且輸出appender的接受級(jí)別修改為DEBUG就可以了。這樣是可以看到日志信息（SQL/參數(shù)）等，但是同時(shí)也輸出了過(guò)多的其它logger信息，顯然在一個(gè)稍微大一點(diǎn)的系統(tǒng)里面debug的信息應(yīng)該都是非常多的，不說(shuō)別的，光是spring的日志就夠好多頁(yè)了。
為了解決過(guò)多的日志，翻出ibatis源碼，看了下。ibatis的執(zhí)行流程大致是這樣的。  閱讀全文

     摘要: 本小節(jié)是《并發(fā)容器》的最后一部分，這一個(gè)小節(jié)描述的是針對(duì)List/Set接口的一個(gè)線程版本。
在《并發(fā)隊(duì)列與Queue簡(jiǎn)介》中介紹了并發(fā)容器的一個(gè)概括，主要描述的是Queue的實(shí)現(xiàn)。其中特別提到一點(diǎn)LinkedList是List/Queue的實(shí)現(xiàn)，但是LinkedList確實(shí)非線程安全的。不管BlockingQueue還是ConcurrentMap的實(shí)現(xiàn)，我們發(fā)現(xiàn)都是針對(duì)鏈表的實(shí)現(xiàn)，當(dāng)然盡可能的使用CAS或者Lock的特性，同時(shí)都有通過(guò)鎖部分容器來(lái)提供并發(fā)的特性。而對(duì)于List或者Set而言，增、刪操作其實(shí)都是針對(duì)整個(gè)容器，因此每次操作都不可避免的需要鎖定整個(gè)容器空間，性能肯定會(huì)大打折扣。要實(shí)現(xiàn)一個(gè)線程安全的List/Set，只需要在修改操作的時(shí)候進(jìn)行同步即可，比如使用java.util.Collections.synchronizedList(List)或者java.util.Collections.synchronizedSet(Set)。當(dāng)然也可以使用Lock來(lái)實(shí)現(xiàn)線程安全的List/Set。
通常情況下我們的高并發(fā)都發(fā)生在“多讀少寫(xiě)”的情況，因此如果  閱讀全文

     摘要: 可以在對(duì)中對(duì)元素進(jìn)行配對(duì)和交換的線程的同步點(diǎn)。每個(gè)線程將條目上的某個(gè)方法呈現(xiàn)給 exchange 方法，與伙伴線程進(jìn)行匹配，并且在返回時(shí)接收其伙伴的對(duì)象。Exchanger 可能被視為 SynchronousQueue 的雙向形式。
換句話說(shuō)Exchanger提供的是一個(gè)交換服務(wù)，允許原子性的交換兩個(gè)（多個(gè)）對(duì)象，但同時(shí)只有一對(duì)才會(huì)成功。先看一個(gè)簡(jiǎn)單的實(shí)例模型。  閱讀全文

     摘要: 這個(gè)小節(jié)介紹Queue的最后一個(gè)工具，也是最強(qiáng)大的一個(gè)工具。從名稱上就可以看到此工具的特點(diǎn)：雙向并發(fā)阻塞隊(duì)列。所謂雙向是指可以從隊(duì)列的頭和尾同時(shí)操作，并發(fā)只是線程安全的實(shí)現(xiàn)，阻塞允許在入隊(duì)出隊(duì)不滿足條件時(shí)掛起線程，這里說(shuō)的隊(duì)列是指支持FIFO/FILO實(shí)現(xiàn)的鏈表。

首先看下LinkedBlockingDeque的數(shù)據(jù)結(jié)構(gòu)。通常情況下從數(shù)據(jù)結(jié)構(gòu)上就能看出這種實(shí)現(xiàn)的優(yōu)缺點(diǎn)，這樣就知道如何更好的使用工具了。  閱讀全文

     摘要:
有一段時(shí)間沒(méi)有更新了。接著上節(jié)繼續(xù)吧。
Queue除了前面介紹的實(shí)現(xiàn)外，還有一種雙向的Queue實(shí)現(xiàn)Deque。這種隊(duì)列允許在隊(duì)列頭和尾部進(jìn)行入隊(duì)出隊(duì)操作，因此在功能上比Queue顯然要更復(fù)雜。下圖描述的是Deque的完整體系圖。需要說(shuō)明的是LinkedList也已經(jīng)加入了Deque的一部分（LinkedList是從jdk1.2 開(kāi)始就存在數(shù)據(jù)結(jié)構(gòu)）。  閱讀全文

     摘要:
在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功能就基本相同了。  閱讀全文

     摘要: 在上一節(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)。  閱讀全文

     摘要: 在《并發(fā)容器 part 4 并發(fā)隊(duì)列與Queue簡(jiǎn)介》節(jié)中的類圖中可以看到，對(duì)于Queue來(lái)說(shuō)，BlockingQueue是主要的線程安全版本。這是一個(gè)可阻塞的版本，也就是允許添加/刪除元素被阻塞，直到成功為止。
BlockingQueue相對(duì)于Queue而言增加了兩個(gè)操作：put/take。下面是一張整理的表格。  閱讀全文

     摘要: 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ì)列都類似。出隊(duì)列只能操作頭節(jié)點(diǎn)，入隊(duì)列只能操作尾節(jié)點(diǎn)，任意節(jié)點(diǎn)操作就需要遍歷完整的隊(duì)列。
重點(diǎn)放在解釋ConcurrentLinkedQueue的原理和實(shí)現(xiàn)上。  閱讀全文

     摘要: Queue是JDK 5以后引入的新的集合類，它屬于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è)方法，有不同的定義。  閱讀全文

     摘要: 在上一篇中介紹了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è)很嚴(yán)重的問(wèn)題是讀寫(xiě)操作不能同時(shí)發(fā)生。要想解決讀寫(xiě)同時(shí)進(jìn)行問(wèn)題（至少不同元素的讀寫(xiě)分離），那么就只能將鎖拆分，不同的元素?fù)碛胁煌逆i，這種技術(shù)就是“鎖分離”技術(shù)。
默認(rèn)情況下ConcurrentHashMap是用了16個(gè)類似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ě)操作。  閱讀全文

     摘要: 本來(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所需要的條件。  閱讀全文

     摘要: 從這一節(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ā)容器。  閱讀全文

     摘要:
主要談?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ì)的。  閱讀全文

     摘要:
這一節(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)比較眼熟，實(shí)際上它是AQS的一個(gè)子類，這中類似的結(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í)際  閱讀全文

     摘要: 從這一節(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)銷的，當(dāng)并發(fā)比較大的時(shí)候，鎖的開(kāi)銷就比較客觀了。所以如果可能的話就盡量少用鎖，非要用鎖的話就嘗試看能否改造為讀寫(xiě)鎖。
ReadWriteLock描述的是：一個(gè)資源能夠被多個(gè)讀線程訪問(wèn)，或者被一個(gè)寫(xiě)線程訪問(wèn)，但是不能同時(shí)存在讀寫(xiě)線程。也就是說(shuō)讀寫(xiě)鎖使用的場(chǎng)合是一個(gè)共享資源被大量讀取操作，而只有少量的寫(xiě)操作（修改數(shù)據(jù)）。清單1描述了ReadWriteLock的API。  閱讀全文

     摘要: 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ì)象池等。  閱讀全文

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

     摘要: 此小節(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í)。  閱讀全文

     摘要: 這是一份完整的Java 并發(fā)整理筆記，記錄了我最近幾年學(xué)習(xí)Java并發(fā)的一些心得和體會(huì)。  閱讀全文

     摘要: 本小節(jié)介紹鎖釋放Lock.unlock()。
Release/TryRelease
unlock操作實(shí)際上就調(diào)用了AQS的release操作，釋放持有的鎖。  閱讀全文

     摘要: 接上篇，這篇從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í)候比公平鎖性能要好的原因之一。  閱讀全文

     摘要: 在理解J.U.C原理以及鎖機(jī)制之前，我們來(lái)介紹J.U.C框架最核心也是最復(fù)雜的一個(gè)基礎(chǔ)類：java.util.concurrent.locks.AbstractQueuedSynchronizer。

AQS
AbstractQueuedSynchronizer，簡(jiǎn)稱AQS，是J.U.C最復(fù)雜的一個(gè)類，導(dǎo)致絕大多數(shù)講解并發(fā)原理或者實(shí)戰(zhàn)的時(shí)候都不會(huì)提到此類。但是虛心的作者愿意借助自己有限的能力和精力來(lái)探討一二（參考資源中也有一些作者做了部分的分析。）。
首先從理論知識(shí)開(kāi)始，在了解了相關(guān)原理后會(huì)針對(duì)源碼進(jìn)行一些分析，最后加上一些實(shí)戰(zhàn)來(lái)描述。  閱讀全文

     摘要: 前面的章節(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)始。  閱讀全文

     摘要: 在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)闆_突失敗就重試，直到成功為止。  閱讀全文

     摘要: 在這個(gè)小結(jié)里面重點(diǎn)討論原子操作的原理和設(shè)計(jì)思想。
由于在下一個(gè)章節(jié)中會(huì)談到鎖機(jī)制，因此此小節(jié)中會(huì)適當(dāng)引入鎖的概念。
在Java Concurrency in Practice中是這樣定義線程安全的：
當(dāng)多個(gè)線程訪問(wèn)一個(gè)類時(shí)，如果不用考慮這些線程在運(yùn)行時(shí)環(huán)境下的調(diào)度和交替運(yùn)行，并且不需要額外的同步及在調(diào)用方代碼不必做其他的協(xié)調(diào)，這個(gè)類的行為仍然是正確的，那么這個(gè)類就是線程安全的。  閱讀全文

     摘要: 在這一部分開(kāi)始討論數(shù)組原子操作和一些其他的原子操作。
AtomicIntegerArray/AtomicLongArray/AtomicReferenceArray的API類似，選擇有代表性的AtomicIntegerArray來(lái)描述這些問(wèn)題。
int get(int i)
獲取位置 i 的當(dāng)前值。很顯然，由于這個(gè)是數(shù)組操作，就有索引越界的問(wèn)題（IndexOutOfBoundsException異常）。

對(duì)于下面的API起始和AtomicInteger是類似的，這種通過(guò)方法、參數(shù)的名稱就能夠得到函數(shù)意義的寫(xiě)法是非常值得稱贊的。在《重構(gòu)：改善既有代碼的設(shè)計(jì)》和《代碼整潔之道》中都非常推崇這種做法。  閱讀全文

     摘要: 從相對(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í)“原子性”的。  閱讀全文

     摘要: 去年年底有一個(gè)Guice的研究計(jì)劃，可惜由于工作“繁忙”加上實(shí)際工作中沒(méi)有用上導(dǎo)致“無(wú)疾而終”，最終只是完成了Guice的初步學(xué)習(xí)教程，深入的研究沒(méi)有繼續(xù)進(jìn)行下去。
最近一直用的比較多的就是java.util.concurrent(J.U.C)，實(shí)際上這塊一直也沒(méi)有完全深入研究，這次準(zhǔn)備花點(diǎn)時(shí)間研究下Java里面整個(gè)并發(fā)體系。初步的設(shè)想包括比較大的方便（包括硬件、軟件、思想以及誤區(qū)等等），因此可能會(huì)持續(xù)較長(zhǎng)的時(shí)間。這塊內(nèi)容也是Java在多線程方面引以為豪的一部分，深入這一部分不僅對(duì)整個(gè)Java體系有更深的了解，也對(duì)工作、學(xué)習(xí)的態(tài)度有多幫助。  閱讀全文