<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
			
		
    
	
    

    

			    		
		
    
	
    

    


    


    
	
					

    J2EE
    

    
	Java Core Knowledge/Java Web Solution

    

			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2013-10-16 00:33 imxylz 閱讀(9150) | 評(píng)論 (8)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2013-08-17 17:44 imxylz 閱讀(3851) | 評(píng)論 (3)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2012-12-26 12:02 imxylz 閱讀(17540) | 評(píng)論 (31)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2012-03-15 18:30 imxylz 閱讀(11510) | 評(píng)論 (16)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2012-02-08 16:41 imxylz 閱讀(4029) | 評(píng)論 (1)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 剛看到這個(gè)月的編程語(yǔ)言排行榜，很顯然java的霸主地位很快就會(huì)在發(fā)達(dá)國(guó)家被擠掉，C語(yǔ)言依然是王者（想想上個(gè)月自己買的兩個(gè)C語(yǔ)言的書，冷汗直流）。看來(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è)備開發(fā)的高端人才現(xiàn)在是高薪難求，如果有時(shí)間我也要繼續(xù)關(guān)注下。  閱讀全文
				
    
				
				
    
					posted @ 2011-12-06 11:25 imxylz 閱讀(4634) | 評(píng)論 (8)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: Zookeeper客戶端和服務(wù)端維持一個(gè)長(zhǎng)連接，每隔10s向服務(wù)端發(fā)送一個(gè)心跳，服務(wù)端返回客戶端一個(gè)響應(yīng)。這就是一個(gè)Session連接，擁有全局唯一的session id。Session連接通常是一直有效，如果因?yàn)榫W(wǎng)絡(luò)原因斷開了連接，客戶端會(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(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  閱讀全文
				
    
				
				
    
					posted @ 2011-12-05 13:57 imxylz 閱讀(28612) | 評(píng)論 (8)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2011-06-17 09:25 imxylz 閱讀(5195) | 評(píng)論 (3)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2011-06-12 00:24 imxylz 閱讀(11250) | 評(píng)論 (36)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 當(dāng)Ajax遇到GBK/GB2312，我們恨不能將所有項(xiàng)目的編碼統(tǒng)一改為UTF-8。顯然這個(gè)做法，成本太高了。下面給出了一個(gè)完善的解決方案。此方案不僅僅限于Ajax提交數(shù)據(jù)，也適用于普通訪問(wèn)請(qǐng)求。  閱讀全文
				
    
				
				
    
					posted @ 2011-06-10 23:46 imxylz 閱讀(8728) | 評(píng)論 (6)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 這一節(jié)中我們將詳細(xì)討論線程池是如何執(zhí)行一個(gè)任務(wù)的，尤其是如何處理線程池的大小、核心大小、最大大小、任務(wù)隊(duì)列等之間的關(guān)系的。  閱讀全文
				
    
				
				
    
					posted @ 2011-02-11 23:48 imxylz 閱讀(11674) | 評(píng)論 (2)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 本著開發(fā)的原則，既然用到了別人家的東西，所以決定公開出來(lái)，也算是給別人一個(gè)參考。  閱讀全文
				
    
				
				
    
					posted @ 2011-01-05 10:00 imxylz 閱讀(4601) | 評(píng)論 (1)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: Java里面線程池的頂級(jí)接口是Executor，但是嚴(yán)格意義上講Executor并不是一個(gè)線程池，而只是一個(gè)執(zhí)行線程的工具。真正的線程池接口是ExecutorService。

    下面這張圖完整描述了線程池的類體系結(jié)構(gòu)。  閱讀全文
				
    
				
				
    
					posted @ 2010-12-21 23:32 imxylz 閱讀(13778) | 評(píng)論 (4)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 最近的項(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í)行流程大致是這樣的。  閱讀全文
				
    
				
				
    
					posted @ 2010-12-05 15:17 imxylz 閱讀(3530) | 評(píng)論 (3)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2010-12-03 16:13 imxylz 閱讀(10046) | 評(píng)論 (7)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2010-11-02 16:09 imxylz 閱讀(5767) | 評(píng)論 (19)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2010-08-12 00:54 imxylz 閱讀(3126) | 評(píng)論 (14)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2010-07-16 11:59 imxylz 閱讀(9033) | 評(píng)論 (4)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要:  

    這一節(jié)主要是談?wù)勛x寫鎖的實(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í)際  閱讀全文
				
    
				
				
    
					posted @ 2010-07-15 00:41 imxylz 閱讀(20308) | 評(píng)論 (1)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 從這一節(jié)開始介紹鎖里面的最后一個(gè)工具：讀寫鎖(ReadWriteLock)。

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

    ReadWriteLock描述的是：一個(gè)資源能夠被多個(gè)讀線程訪問(wèn)，或者被一個(gè)寫線程訪問(wèn)，但是不能同時(shí)存在讀寫線程。也就是說(shuō)讀寫鎖使用的場(chǎng)合是一個(gè)共享資源被大量讀取操作，而只有少量的寫操作（修改數(shù)據(jù)）。清單1描述了ReadWriteLock的API。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-14 14:18 imxylz 閱讀(24252) | 評(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 閱讀(23366) | 評(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 閱讀(22377) | 評(píng)論 (2)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 此小節(jié)介紹幾個(gè)與鎖有關(guān)的有用工具。

    閉鎖（Latch）

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

    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 閱讀(29328) | 評(píng)論 (6)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 本小節(jié)介紹鎖釋放Lock.unlock()。

    Release/TryRelease

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

    在沒有深入了解內(nèi)部機(jī)制及實(shí)現(xiàn)之前，先了解下為什么會(huì)存在公平鎖和非公平鎖。公平鎖保證一個(gè)阻塞的線程最終能夠獲得鎖，因?yàn)槭怯行虻模钥偸强梢园凑照?qǐng)求的順序獲得鎖。不公平鎖意味著后請(qǐng)求鎖的線程可能在其前面排列的休眠線程恢復(fù)前拿到鎖，這樣就有可能提高并發(fā)的性能。這是因?yàn)橥ǔＧ闆r下掛起的線程重新開始與它真正開始運(yùn)行，二者之間會(huì)產(chǎn)生嚴(yán)重的延時(shí)。因此非公平鎖就可以利用這段時(shí)間完成操作。這是非公平鎖在某些時(shí)候比公平鎖性能要好的原因之一。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-07 00:05 imxylz 閱讀(40166) | 評(píng)論 (6)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 在理解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í)開始，在了解了相關(guān)原理后會(huì)針對(duì)源碼進(jìn)行一些分析，最后加上一些實(shí)戰(zhàn)來(lái)描述。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-06 18:29 imxylz 閱讀(53043) | 評(píng)論 (3)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 前面的章節(jié)主要談?wù)勗硬僮鳎劣谂c原子操作一些相關(guān)的問(wèn)題或者說(shuō)陷阱就放到最后的總結(jié)篇來(lái)整體說(shuō)明。從這一章開始花少量的篇幅談?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以后就開始借助于JNI來(lái)完成更高級(jí)的鎖實(shí)現(xiàn)。

    JDK 5中的鎖是接口java.util.concurrent.locks.Lock。另外java.util.concurrent.locks.ReadWriteLock提供了一對(duì)可供讀寫并發(fā)的鎖。根據(jù)前面的規(guī)則，我們從java.util.concurrent.locks.Lock的API開始。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-05 13:37 imxylz 閱讀(42225) | 評(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è)更加有效的鎖就是樂觀鎖。所謂樂觀鎖就是，每次不加鎖而是假設(shè)沒有沖突而去完成某項(xiàng)操作，如果因?yàn)闆_突失敗就重試，直到成功為止。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-04 18:03 imxylz 閱讀(48006) | 評(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è)類時(shí)，如果不用考慮這些線程在運(yùn)行時(shí)環(huán)境下的調(diào)度和交替運(yùn)行，并且不需要額外的同步及在調(diào)用方代碼不必做其他的協(xié)調(diào)，這個(gè)類的行為仍然是正確的，那么這個(gè)類就是線程安全的。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-03 20:40 imxylz 閱讀(46607) | 評(píng)論 (16)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 在這一部分開始討論數(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ù)意義的寫法是非常值得稱贊的。在《重構(gòu)：改善既有代碼的設(shè)計(jì)》和《代碼整潔之道》中都非常推崇這種做法。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-02 14:19 imxylz 閱讀(48169) | 評(píng)論 (6)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 從相對(duì)簡(jiǎn)單的Atomic入手（java.util.concurrent是基于Queue的并發(fā)包，而Queue，很多情況下使用到了Atomic操作，因此首先從這里開始）。很多情況下我們只是需要一個(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，然后寫回新的值。在沒有額外資源可以利用的情況下，只能使用加鎖才能保證讀-改-寫這三個(gè)操作時(shí)“原子性”的。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-01 15:21 imxylz 閱讀(65852) | 評(píng)論 (2)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 去年年底有一個(gè)Guice的研究計(jì)劃，可惜由于工作“繁忙”加上實(shí)際工作中沒有用上導(dǎo)致“無(wú)疾而終”，最終只是完成了Guice的初步學(xué)習(xí)教程，深入的研究沒有繼續(xù)進(jìn)行下去。

    最近一直用的比較多的就是java.util.concurrent(J.U.C)，實(shí)際上這塊一直也沒有完全深入研究，這次準(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)度有多幫助。  閱讀全文
				
    
				
				
    
					posted @ 2010-06-30 18:09 imxylz 閱讀(69417) | 評(píng)論 (8)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2010-01-31 00:00 imxylz 閱讀(19888) | 評(píng)論 (0)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 以前有段時(shí)間需要知道某些類在什么jar包中，這樣當(dāng)出現(xiàn)ClassNotFoundException或者NoClassDefFoundError的時(shí)候我們就可以去找這個(gè)類在什么jar包中然后去引用此jar包即可。在我們的系統(tǒng)很小的時(shí)候我恨不能都將jar包放入eclipse中，這樣借助 eclipse平臺(tái)查找類就非常方便了。包括非常有用的Ctrl+Shift+T,Ctrl+T,Reference search等等，但是當(dāng)工程多了大了的時(shí)候，上百個(gè)jar包放入eclipse中那個(gè)速度完全不是我能忍受的，稍微動(dòng)一下就看到CPU一直在那抖動(dòng)。好吧，用maven，更慢，簡(jiǎn)直受不了，所以大多數(shù)時(shí)候Maven是一個(gè)比較好的批處理工具，和UI結(jié)合起來(lái)還不是很好用。

    

    我發(fā)現(xiàn)我非常需要這個(gè)從jar包中尋找類的功能，我只需要看看我的類在什么地方而已，僅次而已！于是自己就寫了一個(gè)類查找器。非常簡(jiǎn)單就是遍歷所有的jar包中的類，當(dāng)匹配類名稱的時(shí)候就顯示類所在的jar包。

    有以下幾個(gè)特性：

    

            * 允許添加jar包，zip包

            * 允許匹  閱讀全文
				
    
				
				
    
					posted @ 2009-12-31 17:07 imxylz 閱讀(20884) | 評(píng)論 (11)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 本章節(jié)繼續(xù)討論Google Guice與第三方的整合，這里主要討論如何整合JMX的服務(wù)，通過(guò)guice-jmx插件我們可以很方便的將我們的服務(wù)注入到JMX服務(wù)中，這樣就能夠通過(guò)遠(yuǎn)程調(diào)用來(lái)控制我們的服務(wù)。  閱讀全文
				
    
				
				
    
					posted @ 2009-12-31 15:35 imxylz 閱讀(19867) | 評(píng)論 (3)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: Google Guice 整合第三方組件。

    

    在《Google Guice 入門教程06 – Web 和Servlet》 中我們看到了Guice 整合Struts 2的應(yīng)用。本章節(jié)繼續(xù)討論Guice整合其它第三方組件的應(yīng)用。

    

    本章節(jié)重點(diǎn)談Guice與DWR和Spring的整合。

      閱讀全文
				
    
				
				
    
					posted @ 2009-12-29 00:11 imxylz 閱讀(27367) | 評(píng)論 (5)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 本章節(jié)主要講Guice中如何開發(fā)Servlet，當(dāng)然了作為IOC的容器，Guice在這方面仍然局限于依賴注入功能。作為WEB方面的開發(fā)就不能不提Struts，這里著重談如何與Struts 2進(jìn)行整合。  閱讀全文
				
    
				
				
    
					posted @ 2009-12-27 22:58 imxylz 閱讀(16780) | 評(píng)論 (1)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 本章節(jié)主要討論Guice中AOP的使用，其中花了一些篇幅談AOP的概念，然后通過(guò)一些API和例子來(lái)說(shuō)明AOP的具體使用過(guò)程。  閱讀全文
				
    
				
				
    
					posted @ 2009-12-27 00:16 imxylz 閱讀(17776) | 評(píng)論 (2)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 本章節(jié)繼續(xù)討論依賴注入的其他話題，包括作用域（scope，這里有一個(gè)與線程綁定的作用域例子）、立即初始化（Eagerly Loading Bindings）、運(yùn)行階段（Stage）、選項(xiàng)注入（Optional Injection）等等。   閱讀全文
				
    
				
				
    
					posted @ 2009-12-25 18:02 imxylz 閱讀(16619) | 評(píng)論 (1)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 在我們64位的CenterOS上，指定了JVM的最大堆內(nèi)存為5500M，但是在top和進(jìn)程status中可以看到實(shí)際占用內(nèi)存已經(jīng)遠(yuǎn)遠(yuǎn)大于5500M，那么JVM到底占用多大內(nèi)存？如果做到控制JVM的占用內(nèi)存大小？  閱讀全文
				
    
				
				
    
					posted @ 2009-12-23 19:51 imxylz 閱讀(3549) | 評(píng)論 (1)  編輯
				
    
			
    
			
    
	


    
Full J2EE Archive

    


				

    




    

    ©2009-2014 IMXYLZ
    

    
    
        
	



主站蜘蛛池模板：
亚洲综合激情另类小说区|
国产精品99久久免费|
亚洲大尺度无码专区尤物|
两个人看的www视频免费完整版|
亚洲人配人种jizz|
最新中文字幕免费视频|
亚洲精品影院久久久久久|
精品无码人妻一区二区免费蜜桃|
免费视频专区一国产盗摄|
亚洲自偷自偷在线成人网站传媒|
亚洲日韩中文字幕一区|
国产老女人精品免费视频|
午夜在线免费视频|
亚洲视频在线播放|
成年大片免费视频|
三年片在线观看免费|
中国china体内裑精亚洲日本|
国产大片免费天天看|
亚洲天天做日日做天天欢毛片
|
亚洲图片在线观看|
国产jizzjizz视频全部免费|
精品国产污污免费网站入口
|
国产亚洲婷婷香蕉久久精品|
亚洲美女视频免费|
无码av免费一区二区三区试看|
亚洲毛片av日韩av无码|
天天操夜夜操免费视频|
18禁美女裸体免费网站|
久草视频在线免费看|
一进一出60分钟免费视频|
国产亚洲精品成人久久网站
|
亚洲一区免费在线观看|
国产亚洲综合色就色|
最近2019年免费中文字幕高清
|
a级精品九九九大片免费看|
亚洲成电影在线观看青青|
成人毛片免费观看视频在线
|
老子影院午夜伦不卡亚洲|
亚洲一区二区精品视频|
啦啦啦手机完整免费高清观看|
亚洲国产熟亚洲女视频|