<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ā)編程
    
			    		
		
    
	
    

    

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


			
			
				

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

    

			    		
		
    
	
    

    


    


    
	
					

    J2EE
    

    
	Java Core Knowledge/Java Web Solution

    

			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2013-10-16 00:33 imxylz 閱讀(9151) | 評論 (8)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2013-08-17 17:44 imxylz 閱讀(3853) | 評論 (3)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2012-12-26 12:02 imxylz 閱讀(17542) | 評論 (31)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2012-03-15 18:30 imxylz 閱讀(11511) | 評論 (16)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2012-02-08 16:41 imxylz 閱讀(4030) | 評論 (1)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 剛看到這個(gè)月的編程語言排行榜，很顯然java的霸主地位很快就會在發(fā)達(dá)國家被擠掉，C語言依然是王者（想想上個(gè)月自己買的兩個(gè)C語言的書，冷汗直流）。看來我遲早要回歸C，這才是真正的王道。

    

    

    

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

    

    

    

    iPhone/iPad的熱銷讓Object C繼續(xù)火熱，前十的位置還是可以持續(xù)很久的，這一點(diǎn)毋庸置疑。移動設(shè)備開發(fā)的高端人才現(xiàn)在是高薪難求，如果有時(shí)間我也要繼續(xù)關(guān)注下。  閱讀全文
				
    
				
				
    
					posted @ 2011-12-06 11:25 imxylz 閱讀(4636) | 評論 (8)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: Zookeeper客戶端和服務(wù)端維持一個(gè)長連接，每隔10s向服務(wù)端發(fā)送一個(gè)心跳，服務(wù)端返回客戶端一個(gè)響應(yīng)。這就是一個(gè)Session連接，擁有全局唯一的session id。Session連接通常是一直有效，如果因?yàn)榫W(wǎng)絡(luò)原因斷開了連接，客戶端會使用相同的session id進(jìn)行重連。由于服務(wù)端保留了session的各種狀態(tài)，尤其是各種瞬時(shí)節(jié)點(diǎn)是否刪除依賴于session是否失效。

    Session失效問題

    

    通常客戶端主動關(guān)閉連接認(rèn)為是一次session失效。另外也有可能因?yàn)槠渌粗颍缇W(wǎng)絡(luò)超時(shí)導(dǎo)致的session失效問題。在服務(wù)端看來，無法區(qū)分session失效是何種情況，一次一旦發(fā)生session失效，一定時(shí)間后就會將session持有的所有watcher以及瞬時(shí)節(jié)點(diǎn)刪除。

    而對于Zookeeper客戶端而言，一旦發(fā)生失效不知道是否該重連，這涉及到watcher和瞬時(shí)節(jié)點(diǎn)問題，因此Zookeeper客戶端認(rèn)為，一旦發(fā)生了seesion失效，那么就認(rèn)為客戶端死掉了。從而所有操作都不能夠進(jìn)行。參考 How should I handle SESSION  閱讀全文
				
    
				
				
    
					posted @ 2011-12-05 13:57 imxylz 閱讀(28614) | 評論 (8)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2011-06-17 09:25 imxylz 閱讀(5196) | 評論 (3)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2011-06-12 00:24 imxylz 閱讀(11252) | 評論 (36)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 當(dāng)Ajax遇到GBK/GB2312，我們恨不能將所有項(xiàng)目的編碼統(tǒng)一改為UTF-8。顯然這個(gè)做法，成本太高了。下面給出了一個(gè)完善的解決方案。此方案不僅僅限于Ajax提交數(shù)據(jù)，也適用于普通訪問請求。  閱讀全文
				
    
				
				
    
					posted @ 2011-06-10 23:46 imxylz 閱讀(8730) | 評論 (6)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 這一節(jié)中我們將詳細(xì)討論線程池是如何執(zhí)行一個(gè)任務(wù)的，尤其是如何處理線程池的大小、核心大小、最大大小、任務(wù)隊(duì)列等之間的關(guān)系的。  閱讀全文
				
    
				
				
    
					posted @ 2011-02-11 23:48 imxylz 閱讀(11675) | 評論 (2)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 本著開發(fā)的原則，既然用到了別人家的東西，所以決定公開出來，也算是給別人一個(gè)參考。  閱讀全文
				
    
				
				
    
					posted @ 2011-01-05 10:00 imxylz 閱讀(4602) | 評論 (1)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: Java里面線程池的頂級接口是Executor，但是嚴(yán)格意義上講Executor并不是一個(gè)線程池，而只是一個(gè)執(zhí)行線程的工具。真正的線程池接口是ExecutorService。

    下面這張圖完整描述了線程池的類體系結(jié)構(gòu)。  閱讀全文
				
    
				
				
    
					posted @ 2010-12-21 23:32 imxylz 閱讀(13779) | 評論 (4)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 最近的項(xiàng)目使用的是舊的ibatis2.x版本，有時(shí)候?yàn)榱朔奖阏{(diào)試，想輸出SQL執(zhí)行的語句和參數(shù)。我記得應(yīng)該有某些logger的日志級別修改為DEBUG就可以看到。當(dāng)然為了方便可以直接在log4j（如果使用log4j的話）的root日志級別修改為DEBUG，并且輸出appender的接受級別修改為DEBUG就可以了。這樣是可以看到日志信息（SQL/參數(shù)）等，但是同時(shí)也輸出了過多的其它logger信息，顯然在一個(gè)稍微大一點(diǎn)的系統(tǒng)里面debug的信息應(yīng)該都是非常多的，不說別的，光是spring的日志就夠好多頁了。

    為了解決過多的日志，翻出ibatis源碼，看了下。ibatis的執(zhí)行流程大致是這樣的。  閱讀全文
				
    
				
				
    
					posted @ 2010-12-05 15:17 imxylz 閱讀(3530) | 評論 (3)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2010-12-03 16:13 imxylz 閱讀(10046) | 評論 (7)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2010-11-02 16:09 imxylz 閱讀(5769) | 評論 (19)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2010-08-12 00:54 imxylz 閱讀(3127) | 評論 (14)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2010-07-16 11:59 imxylz 閱讀(9033) | 評論 (4)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要:  

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

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

    事實(shí)上在ReentrantReadWriteLock里鎖的實(shí)現(xiàn)是靠java.util.concurrent.locks.ReentrantReadWriteLock.Sync完成的。這個(gè)類看起來比較眼熟，實(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，所以說實(shí)際  閱讀全文
				
    
				
				
    
					posted @ 2010-07-15 00:41 imxylz 閱讀(20310) | 評論 (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è)讀線程訪問，或者被一個(gè)寫線程訪問，但是不能同時(shí)存在讀寫線程。也就是說讀寫鎖使用的場合是一個(gè)共享資源被大量讀取操作，而只有少量的寫操作（修改數(shù)據(jù)）。清單1描述了ReadWriteLock的API。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-14 14:18 imxylz 閱讀(24254) | 評論 (4)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: Semaphore 是一個(gè)計(jì)數(shù)信號量。從概念上講，信號量維護(hù)了一個(gè)許可集。如有必要，在許可可用前會阻塞每一個(gè) acquire()，然后再獲取該許可。每個(gè) release() 添加一個(gè)許可，從而可能釋放一個(gè)正在阻塞的獲取者。但是，不使用實(shí)際的許可對象，Semaphore 只對可用許可的號碼進(jìn)行計(jì)數(shù)，并采取相應(yīng)的行動。

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

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

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

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

    閉鎖（Latch）

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

    CountDownLatch是JDK 5+里面閉鎖的一個(gè)實(shí)現(xiàn)，允許一個(gè)或者多個(gè)線程等待某個(gè)事件的發(fā)生。CountDownLatch有一個(gè)正數(shù)計(jì)數(shù)器，countDown方法對計(jì)數(shù)器做減操作，await方法等待計(jì)數(shù)器達(dá)到0。所有await的線程都會阻塞直到計(jì)數(shù)器為0或者等待線程中斷或者超時(shí)。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-09 09:21 imxylz 閱讀(29330) | 評論 (6)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 本小節(jié)介紹鎖釋放Lock.unlock()。

    Release/TryRelease

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

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

    

    AQS

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

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

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

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

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

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

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

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

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

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

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

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

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

    當(dāng)多個(gè)線程訪問一個(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 閱讀(46609) | 評論 (16)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 在這一部分開始討論數(shù)組原子操作和一些其他的原子操作。

    AtomicIntegerArray/AtomicLongArray/AtomicReferenceArray的API類似，選擇有代表性的AtomicIntegerArray來描述這些問題。

    int get(int i)

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

     

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

    通常情況下，在Java里面，++i或者--i不是線程安全的，這里面有三個(gè)獨(dú)立的操作：或者變量當(dāng)前值，為該值+1/-1，然后寫回新的值。在沒有額外資源可以利用的情況下，只能使用加鎖才能保證讀-改-寫這三個(gè)操作時(shí)“原子性”的。  閱讀全文
				
    
				
				
    
					posted @ 2010-07-01 15:21 imxylz 閱讀(65854) | 評論 (2)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 去年年底有一個(gè)Guice的研究計(jì)劃，可惜由于工作“繁忙”加上實(shí)際工作中沒有用上導(dǎo)致“無疾而終”，最終只是完成了Guice的初步學(xué)習(xí)教程，深入的研究沒有繼續(xù)進(jìn)行下去。

    最近一直用的比較多的就是java.util.concurrent(J.U.C)，實(shí)際上這塊一直也沒有完全深入研究，這次準(zhǔn)備花點(diǎn)時(shí)間研究下Java里面整個(gè)并發(fā)體系。初步的設(shè)想包括比較大的方便（包括硬件、軟件、思想以及誤區(qū)等等），因此可能會持續(xù)較長的時(shí)間。這塊內(nèi)容也是Java在多線程方面引以為豪的一部分，深入這一部分不僅對整個(gè)Java體系有更深的了解，也對工作、學(xué)習(xí)的態(tài)度有多幫助。  閱讀全文
				
    
				
				
    
					posted @ 2010-06-30 18:09 imxylz 閱讀(69420) | 評論 (8)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2010-01-31 00:00 imxylz 閱讀(19889) | 評論 (0)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 以前有段時(shí)間需要知道某些類在什么jar包中，這樣當(dāng)出現(xiàn)ClassNotFoundException或者NoClassDefFoundError的時(shí)候我們就可以去找這個(gè)類在什么jar包中然后去引用此jar包即可。在我們的系統(tǒng)很小的時(shí)候我恨不能都將jar包放入eclipse中，這樣借助 eclipse平臺查找類就非常方便了。包括非常有用的Ctrl+Shift+T,Ctrl+T,Reference search等等，但是當(dāng)工程多了大了的時(shí)候，上百個(gè)jar包放入eclipse中那個(gè)速度完全不是我能忍受的，稍微動一下就看到CPU一直在那抖動。好吧，用maven，更慢，簡直受不了，所以大多數(shù)時(shí)候Maven是一個(gè)比較好的批處理工具，和UI結(jié)合起來還不是很好用。

    

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

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

    

            * 允許添加jar包，zip包

            * 允許匹  閱讀全文
				
    
				
				
    
					posted @ 2009-12-31 17:07 imxylz 閱讀(20885) | 評論 (11)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 本章節(jié)繼續(xù)討論Google Guice與第三方的整合，這里主要討論如何整合JMX的服務(wù)，通過guice-jmx插件我們可以很方便的將我們的服務(wù)注入到JMX服務(wù)中，這樣就能夠通過遠(yuǎn)程調(diào)用來控制我們的服務(wù)。  閱讀全文
				
    
				
				
    
					posted @ 2009-12-31 15:35 imxylz 閱讀(19869) | 評論 (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 閱讀(27369) | 評論 (5)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 本章節(jié)主要講Guice中如何開發(fā)Servlet，當(dāng)然了作為IOC的容器，Guice在這方面仍然局限于依賴注入功能。作為WEB方面的開發(fā)就不能不提Struts，這里著重談如何與Struts 2進(jìn)行整合。  閱讀全文
				
    
				
				
    
					posted @ 2009-12-27 22:58 imxylz 閱讀(16781) | 評論 (1)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 本章節(jié)主要討論Guice中AOP的使用，其中花了一些篇幅談AOP的概念，然后通過一些API和例子來說明AOP的具體使用過程。  閱讀全文
				
    
				
				
    
					posted @ 2009-12-27 00:16 imxylz 閱讀(17776) | 評論 (2)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 本章節(jié)繼續(xù)討論依賴注入的其他話題，包括作用域（scope，這里有一個(gè)與線程綁定的作用域例子）、立即初始化（Eagerly Loading Bindings）、運(yùn)行階段（Stage）、選項(xiàng)注入（Optional Injection）等等。   閱讀全文
				
    
				
				
    
					posted @ 2009-12-25 18:02 imxylz 閱讀(16620) | 評論 (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) | 評論 (1)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 基于Google Guice 2.0的入門教程，本章節(jié)主要講類的依賴注入，也就是IOC容器的核心組件。  閱讀全文
				
    
				
				
    
					posted @ 2009-12-22 23:28 imxylz 閱讀(35743) | 評論 (5)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 本文將探討單例模式的各種情況，并給出相應(yīng)的建議。

    單例模式應(yīng)該是設(shè)計(jì)模式中比較簡單的一個(gè)，但是在多線程并發(fā)的環(huán)境下使用卻是不那么簡單了。

    本文將探討在多線程下靜態(tài)域單例模式、雙重檢查鎖機(jī)制、類延時(shí)加載、同步鎖等機(jī)制的相關(guān)技術(shù)問題。  閱讀全文
				
    
				
				
    
					posted @ 2009-12-18 23:15 imxylz 閱讀(7345) | 評論 (4)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					     摘要: 大家都知道HashMap不是線程安全的，但是大家的理解可能都不是十分準(zhǔn)確。很顯然讀寫同一個(gè)key會導(dǎo)致不一致大家都能理解，但是如果讀寫一個(gè)總是存在HashMap中且不變的對象會有問題么？我們來試試看。  閱讀全文
				
    
				
				
    
					posted @ 2009-12-18 18:20 imxylz 閱讀(6164) | 評論 (2)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2009-09-27 16:51 imxylz 閱讀(1338) | 評論 (1)  編輯
				
    
			
    
			
    
	
			
    
				
				
				
    
					
				
    
				
				
    
					posted @ 2009-07-29 22:04 imxylz 閱讀(3261) | 評論 (4)  編輯
				
    
			
    
			
    
	


    


    


				

    




    

    ©2009-2014 IMXYLZ
    

    
    
        
	



主站蜘蛛池模板：
毛片免费在线观看网址|
中文字幕av免费专区|
美女视频黄免费亚洲|
亚洲AV综合色区无码二区偷拍|
91在线精品亚洲一区二区|
亚洲国产成人久久精品影视|
亚洲成AV人片在线观看无|
亚洲毛片αv无线播放一区|
亚洲一区精品无码|
久久精品国产亚洲av麻|
久久亚洲国产成人精品性色|
亚洲综合精品香蕉久久网97|
亚洲国产精品成人精品软件|
亚洲天堂免费在线|
亚洲jizzjizz少妇|
一级黄色毛片免费看|
中文字幕av免费专区|
日韩精品无码免费一区二区三区
|
亚洲AV无码一区二区三区人|
亚洲AV无码久久久久网站蜜桃|
亚洲欧洲无码AV不卡在线|
久久亚洲色WWW成人欧美|
h视频免费高清在线观看|
岛国岛国免费V片在线观看|
日韩精品无码免费一区二区三区|
亚洲视频在线免费看|
破了亲妺妺的处免费视频国产|
免费成人在线观看|
亚洲成AV人片在线观看无|
亚洲国产成人久久精品app|
亚洲av无码一区二区三区天堂
|
亚洲一级大黄大色毛片|
亚洲av午夜国产精品无码中文字|
特黄特色的大片观看免费视频|
女人隐私秘视频黄www免费|
黄色免费网站网址|
www.亚洲色图.com|
亚洲视频在线免费观看|
亚洲精品乱码久久久久久V
|
亚洲中文字幕久久久一区|
一级看片免费视频|