#
這是一份歷盡千辛萬苦，遲來卻依舊讓人無比激動的圣誕禮物。就在大約1個小時之前，Pod 2g的博客終于迎來了更新，標題更是醒目的“A4 release”，等待終于結束了。
Pod 2g在博客中稱，基于他的研發成果，Chronic Dev Team（帶頭大哥p0sixninja，代表作綠毒）和iPhone Dev Team（帶頭大哥肌肉男，代表作紅雪）經過測試后，于今天正式發布A4設備的iOS 5.0.1完美
越獄。
無論是已經不完美
越獄的用戶，還是從未使用RedSn0w
越獄的用戶，均可使用本次
越獄方案進行完美
越獄。支持設備：iPhone 3GS/4，iPad1代，iPod touch 3/4。與此同時，Pod 2g建議大家在蘋果發布iOS 5.0.2時不要升級，以免
越獄漏洞被封堵。
越獄工具下載，請點擊跳轉。 使用最新版RedSn0w完美
越獄iOS 5.0.1教程：
首先當然是要將手上的設備升級到iOS 5.0.1了。向小白溫馨提示：不要直接連接iTunes之后點擊升級5.0.1，因為這樣一來設備上的部分軟件還會保留，不利于后面的
越獄。正確做法：直接通過iTunes安裝蘋果官方的5.0.1固件即可。
第一步：從我們給出的鏈接地址下載Mac/Windows版RedSn0w 0.9.10b1。解壓后打開redsn0w.exe，點擊Jailbreak。
第二步：此時要確保需要
越獄的設備與電腦連接，點擊Next
第三步：進入DFU模式。具體操作方法RedSn0w已經給出：先按電源鍵三秒左右，等待跳轉之后再按下Home鍵，此時不要放開電源鍵，再次跳轉之后放開電源鍵，Home鍵保持不動。
第四步：最后放開Home鍵之后就是驗證設備和準備
越獄的過程了，需要花上一點時間。
第五步：驗證完成后，出彈出以下圖框，第一個打勾選項為安裝Cydia，此時點擊Next。這時候RedSn0w會上傳RAM Disk和Kernel，最后就是進行
越獄了，整個過程估計耗時5分鐘左右。
第六步：此時iPod touch 4（iOS 5.0.1）已完美
越獄。
iOS 5.0.1完美
越獄方法2：
以上是使用最新版本的RedSn0w v0.9.10b1進行的完美
越獄。假如你的設備之前已經升級iOS 5.0.1，并且已通過RedSn0w進行過不完美
越獄，那么這里還有一種來自綠毒團隊Chronic Dev Team的方法，支持iPhone 3GS/4, iPhone 4 CDMA, iPad 1, iPod touch 3/4。這種方法更為簡單直接：
第一步：進入Cydia，搜索到Corona Untether 5.0.1
第二步：點擊安裝，Cydia會幫你完成接下來的工作
沒有第三步了。
完美
越獄完成，你現在已經可以安全重啟這些設備了。
Cydia成功出現在iOS 5.0.1系統當中，還只是第一步而已。各位在
越獄之后，先不要急著進入Cydia，因為Cydia在IOS5.0+的固件下，添加源會閃退，以下是處理方法：
點擊設備中的設置→通用→多語言環境→語言中，選擇English（英文），進入英文環境。這時候Cydia不會出現閃退，所以可以在這個時候添加源。
加入源的步驟如下：
第一步：點擊下方Manage（管理）,進入Source（軟件源）
第二步：點擊右上方Edit（編輯）
第三步：點擊左上方Add（加入）
第四步：彈入方框后輸入apt.weiphone.com（威鋒源）后，點擊Add Source（加入軟件源）
第五步：如果彈出一個警告窗口，請無視它，點擊Add Anyway（仍然加入），之后就會進入源的安裝中了。
第六步：安裝完成之后，點擊右下的Search（搜索），輸入afc2，就會出現一個叫做“afc2服務補丁”的文件。
第七步：點擊進入“afc2服務補丁”的文件之后，點擊右上的Install（安裝），跳轉頁面之后在點擊右上角的Confirm，之后就是安裝文件了。
第八步：到了這步，大家可以下載iFunBox了(
iFunBox下載地址請點擊跳轉）。下載完成后，打開iFunBox，選擇路徑文件系統/var/mobile/Library中找到Keyboard文件夾，并將其拖出桌面。
第九步：然后再選擇路徑文件系統/var/root/Library，將桌面的Keyboard文件夾拖入其中。
OK了，完成這步之后，就解決了你在簡體中文環境下，iOS5.0+系統使用Cydia崩潰的情況。之后就能在切換回簡體中文了。最后可不要忘了安裝 AppSync for iOS 5.0，只要在搜索中搜索就能看見，點擊安裝之后就能安裝破解過后的后綴名為ipa的軟件了。
最后，我們仍然要再次重申的是，本次
越獄僅支持iOS 5.0.1。大神的博客里寫得很清楚了，5.0的完美
越獄目前還在測試之中，相信不久之后就會放出。另外，兩個版本的
越獄都不支持iPhone 4S和iPad 2，希望大家注意了。
周末聽了項目管理的課程，很有感觸，有很多記憶深刻的點，比如不要揣摩要提問，要先管理后產品，勝者先勝而后戰，敗者先戰而求勝。然而，讓我印象最深的是估算工時這點事，不禁讓我想起自己的經歷來。
最開始剛參加工作時是在一家翻譯公司做它內部的協同系統，兩個程序員，老大和我，老大是30歲的老程序員，安排工作很隨性，每天早上，點點系統，然后想想接下來要做什么，然后，叫上我，說，把這棵樹實現一下吧，然后，再說，需要多長時間？我想一會兒，不就是一棵樹嗎，說，1小時。老大點點頭，說，好，1天。再一天，老大又交給我一項任務，這次任務量大一些，要實現一個完整的模塊，我同樣是想了想，說3天，老大點點頭，說，好，9天。老大總是這樣，只要是我作出的估算，他總要乘以3，對此我是不以為然的，這也太保守了。不過好消息是，一年下來我們從未加過班，幾乎所有的工作都按計劃完成了，日子過得輕松而又悠閑，經常有些時間寫點自己喜歡的其他代碼，一點也不像程序員。
第二份工作就是IT公司了，做企業應用開發。老大使用干特圖來進行工期管理，項目開始之前，老大已經分好大的模塊了，這些模塊比我第一家公司所謂的模塊要大的多，需要以周來估算。這天，老大叫上我，問，這個門戶的模塊需要幾周完成？我想一想，門戶以前沒有接觸過，學習需要一周，開發需要兩周，再留一周測試，說，四周。老大點點頭，說，好，我再給你加一周學習時間，于是用鼠標在project上拖出一條長長的藍線來。幾個程序員每個都拖出一條藍線來，三個程序員，八個模塊，藍線短的就再估算一個模塊，這樣，一條一條藍線拼起來，最長的那條就成了關鍵路徑，也決定了交付日期，交付日期定在五個月以后。于是就開始開發，那時年輕，無知者無畏，還是單身，加班就不是問題，三個人周六都在公司，吭嗤吭嗤，還真在五個月后給吭嗤完了。于是開始請測試妹妹測試，這一測試問題就來了，很多模塊根本就是不可用，只是能夠增刪改查，很多功能點都沒有考慮到，易用性就更別談了，也難怪，系統設計、實現、測試都被一個只會寫代碼的程序員包了，既當運動員又當裁判員，能想清楚才怪，于是繼續吭嗤，這不吭嗤還好，一吭嗤不得了，又吭嗤出五個月來，再看看jira，幾百個bug，每個人都很絕望，老大手一揮，說，哪個軟件沒有bug，停止開發，修復最重要的bug，然后發布。
第二個項目做完，開始反思，為什么延期這么長估算這么不準，想了很久，覺得是因為估算的粒度太大，時間超過一周，對估算的開發量實際就失去計算了，只剩下一個大概的印象，而為了不成為關鍵路徑不在老大面前丟臉，拍胸脯的情況也發生了，沒事，加幾個班就搞定了。同時，缺少系統需求說明，這樣，在一個錯誤時間內完成一個不可能完成的任務，質量可想而知，趕進度獻禮工程不僅政府在做，程序員同樣在做。
這樣，到了第三年，自己開始負責一個項目了，吸取了教訓，開發估算時，估算的工作量不能超過1周，一旦超過就需要繼續分解再進行估算。估算下來，這個項目需要四個月完成，又想起第一個老大的乘三法則，心里顫了一下，難道需要12個月？不能這樣，這樣這個項目就被取消了。自己帶了僥幸的心理，團隊的成員都很強，事后也證明這個團隊的個人能力都很強，因為有兩個人現在在知名外企，一個在淘寶，一個在騰訊，小公司組成這樣豪華的陣容是很難得的，唯一不幸的是，我是那個項目經理。我把交付時間定在了四個月之后，開發進度整體還是順利的，稍微有延期，每周需要延一到兩天，這樣，我把時間又延長了一個月。天知道，意外發生了，因為我的一句批評，一個成員離職了！我痛哭的發現，項目又要延一個月了，于是，接下來，我就流涕了，六個月時間，公司沒有那么多錢投入了！我開始加班，要求其他人也加一些班，意外接著發生，有人生病了，有人有急事要請假了，到最后，終于發現，按估算完成是完全不可能的。最后，項目就被取消了，悲催的項目經理。
繼續反思，為什么估算不準，這次我自以為原因很清楚，就是沒有考慮項目風險，沒有考慮到人會離職，沒有考慮到人會請假，沒有考慮到人會生病，甚至，沒有考慮到人一天工作的產出不是八小時。我太樂觀了。我再一次想起來我的第一個老大。
新的公司，新的估算方式，不再一個人估算而是一伙人估算，特性不估算，故事點再估算，沒有需求不估算，不一次性估算，迭代估算。這次似乎沒有問題了，但客戶總是需要一個大的時間點的，于是每個迭代都會排定故事優先級，確保交付前交付的是最有價值的，此外，還有專職的業務分析和漂亮的測試美眉，一切看起來都很好。新公司第一個項目也確實輕松的，但第三個和第四個卻都失敗了，第三個項目在遇到一個很難解決的性能問題時陷入了一片混亂當中，迭代經理甚至自己都失去對整個項目的可視化了，她不知道項目上線究竟需要滿足什么條件，于是項目在一次次的下周二上線的空頭承諾中成了整個公司的笑柄。幸福的項目總是相似，不幸的項目各有各的不幸。第四個項目在一次項目中期的架構重寫中崩潰了，重寫耗去了團隊太多的時間，而由于對未知領域知識的不正確估算再次令項目雪上加霜，而更加致命的是，項目目標直到最后一刻也沒有發生變化，依舊是要在六個月后上線，于是，程序員們就內存溢出了。
樂觀、管理混亂、領域知識不熟，這些都導致了項目延期，工時等于工期嗎？不等于，工期永遠是假的，工時估計的準確，混亂的管理同樣會毀掉它。更嚴重的不是項目延期，而是項目本來就是老板拍腦袋的結果，想想某個項目，如果不說我們能快速交付就根本得不到它，而得到它后怎么辦，那只能拜春哥了！
摘要: 所需軟件 Apache :apache_2.0.63 1 個 【apache_2.0.63-win32-x86-no_ssl.msi】 Tomcat: apache-tomcat-5.5.23 (zip版) 2個 mod_jk:: mod_jk-apache-2.0.55.so 1個 部署說明 在同一臺機器上部署，即充當Apache負載服務器，又安裝兩個Tomcat Web服務...
閱讀全文
在application server下，比如常見的weblogic，glassfish，jboss等，由于javaee規范的要求，一般不容許直接啟動線程。因此在常見的異步/并行任務執行上，會遭遇到比普通javase程序更多的麻煩。
典型例子，在javase中，jdk1.5后就引入了java.util.concurrent包，提供Executor這個非常好用的框架，完美的滿足一下典型需求：
1. 同步變異步
請求進來后，將請求封裝為task，交給Executor執行，原線程可以立即返回
2. 并行執行
請求進來后，將請求拆分為若干個task，例如下發短信，有100個收件人就可以按照每個收件人一個task來執行，這樣可以通過Executor來并行執行這些請求，遠比循環執行要快的多。
3. 等待任務結束
有時有要求調用線程必須等待所有任務完成后再繼續運行的需要，此外還有超時等細節設置要求。
而在application server，為了避開自己啟動線程的弊端，只好通過其他的方式來完成類似的功能。
目前我們的項目開發中主要有三種實現方式：
1. jms queue
通過jms來實現異步和并發，然后自己通過編碼方式完成調用線程等待所有任務執行成功。
這個方案比較通用，因為jms是javaee的標準，所有的application server上都支持。因此天然具有跨application server的能力。
缺點就比較多了，首先jms是需要實現串行化的，因此對task是有要求，不能串行化的類是不能傳遞的。另外串行化的性能損失比較大，造成性能和穩定性問題，這個在大壓力下比較突出，基本我們目前在考慮放棄這個方案，而且逐步將原有的實現替換掉。
這個方案還有另外一個缺點，配置麻煩，維護困難：需要創建jsm queque, connection factory, MDB等，如果系統中使用的多了，配置起來很羅嗦，修改時容許出錯。
2. commonj work manager
這個是weblogic和WebSphere上支持的一個很實用的解決方案，個人感覺使用上非常舒服，配置簡單，只要在weblogic-ejb-jar.xml中間中簡單配置：
< work-manager >
< name > wm/taskDistributionWorkManager </ name >
< min-threads-constraint >
< name > minthreads </ name >
< count > 1 </ count >
</ min-threads-constraint >
< max-threads-constraint >
< name > maxthreads </ name >
< count > 100 </ count >
</ max-threads-constraint >
</ work-manager > 使用時用jdni lookup到就可以使用了。功能和使用方式和executor框架很類似，同樣提供future，而且提供一個非常實用的waitAll()方法論支持等待任務完成。
這個方案的性能非常好，和jms相比提升極大，運行也穩定。缺點就是不是標準，只有weblogic和WebSphere執行，在glassfish，jboss上無法使用。
3. JCA work manager
這個是JCA標準了，glassfish，jboss都支持的，和commonj work manager很像，但是，很遺憾的是沒有future的支持，而且也沒有類似的waitAll()方法，只能自己編碼實現。
spring為glassfish提供了一個工具類"org.springframework.jca.work.WorkManagerTaskExecutor"，簡化了JCA work manager的使用。
JCA work manager的性能和穩定性都還不錯，對比jms要好的多。
JBOSS下的配置
jboss-web.xml
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<resource-ref id="ResourceRef_1163654014164">
<description>WorkManager</description>
<res-ref-name>jboss.jca:service=WorkManager</res-ref-name>
<res-type>org.jboss.resource.work.JBossWorkManager</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
<jndi-name>WorkManager</jndi-name>
</resource-ref>
</jboss-web>
applicationContext.xml
<bean id="taskExecutor" class="org.springframework.jca.work.jboss.JBossWorkManagerTaskExecutor">
<property name="workManagerName" value="WorkManager"/>
<property name="resourceRef" value="true"/>
</bean>
從目前我們項目的使用經驗上看，jms是準備要被淘汰的了(其實我是一直對jms不感冒的，尤其是在有性能要求的地方，想不出用jms的理由)。目前項目要求同時支持weblogic和glassfish，因此commonj work manager和JCA work manager剛好對應于weblogic和glassfish平臺。實際使用中，是在這兩個work manager上封裝了一個通用的接口，然后再有commonj work manager和JCA work manager兩個實現，在運行時通過判斷平臺來自動選擇注入其中的一個。
摘要: 用ThreadPoolExecutor的時候，又想知道被執行的任務的執行情況，這時就可以用FutureTask。ThreadPoolTask
Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->package com.paul.threadP...
閱讀全文
這是一堂關于UML基礎知識的補習課；現在我們做項目時間都太緊了，基本上都沒有做過真正的class級別的詳細設計，更別提使用UML來實現規范建模了；本篇主要就以前自己一直感覺很迷糊的幾種class之間的關系進行整理，讓我們在真正用UML進行比如類圖設計時能夠更加清晰明了；以下就分別介紹這幾種關系：
繼承
指的是一個類（稱為子類、子接口）繼承另外的一個類（稱為父類、父接口）的功能，并可以增加它自己的新功能的能力，繼承是類與類或者接口與接口之間最常見的關系；在Java中此類關系通過關鍵字extends明確標識，在設計時一般沒有爭議性；
實現
指的是一個class類實現interface接口（可以是多個）的功能；實現是類與接口之間最常見的關系；在Java中此類關系通過關鍵字implements明確標識，在設計時一般沒有爭議性；
依賴
可以簡單的理解，就是一個類A使用到了另一個類B，而這種使用關系是具有偶然性的、、臨時性的、非常弱的，但是B類的變化會影響到A；比如某人要過河，需要借用一條船，此時人與船之間的關系就是依賴；表現在代碼層面，為類B作為參數被類A在某個method方法中使用；
關聯
他體現的是兩個類、或者類與接口之間語義級別的一種強依賴關系，比如我和我的朋友；這種關系比依賴更強、不存在依賴關系的偶然性、關系也不是臨時性的，一般是長期性的，而且雙方的關系一般是平等的、關聯可以是單向、雙向的；表現在代碼層面，為被關聯類B以類屬性的形式出現在關聯類A中，也可能是關聯類A引用了一個類型為被關聯類B的全局變量；
聚合
聚合是關聯關系的一種特例，他體現的是整體與部分、擁有的關系，即has-a的關系，此時整體與部分之間是可分離的，他們可以具有各自的生命周期，部分可以屬于多個整體對象，也可以為多個整體對象共享；比如計算機與CPU、公司與員工的關系等；表現在代碼層面，和關聯關系是一致的，只能從語義級別來區分；
組合
組合也是關聯關系的一種特例，他體現的是一種contains-a的關系，這種關系比聚合更強，也稱為強聚合；他同樣體現整體與部分間的關系，但此時整體與部分是不可分的，整體的生命周期結束也就意味著部分的生命周期結束；比如你和你的大腦；表現在代碼層面，和關聯關系是一致的，只能從語義級別來區分；
對于繼承、實現這兩種關系沒多少疑問，他們體現的是一種類與類、或者類與接口間的縱向關系；其他的四者關系則體現的是類與類、或者類與接口間的引用、橫向關系，是比較難區分的，有很多事物間的關系要想準備定位是很難的，前面也提到，這幾種關系都是語義級別的，所以從代碼層面并不能完全區分各種關系；但總的來說，后幾種關系所表現的強弱程度依次為：組合>聚合>關聯>依賴；
大多數并發應用程序是以執行任務（task）為基本單位進行管理的。通常情況下，我們會為每個任務單獨創建一個線程來執行。這樣會帶來兩個問題：一，大量的線程（>100）會消耗系統資源，使線程調度的開銷變大，引起性能下降；二，對于生命周期短暫的任務，頻繁地創建和消亡線程并不是明智的選擇。因為創建和消亡線程的開銷可能會大于使用多線程帶來的性能好處。
一個比較簡單的線程池至少應包含線程池管理器、工作線程、任務隊列、任務接口等部分。其中線程池管理器（ThreadPool Manager）的作用是創建、銷毀并管理線程池，將工作線程放入線程池中；工作線程是一個可以循環執行任務的線程，在沒有任務時進行等待；任務隊列的作用是提供一種緩沖機制，將沒有處理的任務放在任務隊列中；任務接口是每個任務必須實現的接口，主要用來規定任務的入口、任務執行完后的收尾工作、任務的執行狀態等，工作線程通過該接口調度任務的執行。下面的代碼實現了創建一個線程池，以及從線程池中取出線程的操作。
在多線程大師Doug Lea的貢獻下，在JDK1.5中加入了許多對并發特性的支持，例如：線程池。
1.核心線程(任務)：我們定義的線程，即實現了Runnable接口的類，是我們將要放到線程池中執行的類，如實例代碼中的CountService類
2.工作線程：由線程池中創建的線程，是用來獲得核心線程并執行核心線程的線程（比較拗口哦,具體看代碼就知道是什么東東了）。
簡單理解就三個概念：線程、線程池和任務。任務：就是要執行的業務邏輯；線程：任務是要放到線程中去執行的；線程池：主要是控制當前正在執行的線程的數量和將要被執行的線程隊列。一、簡介
線程池類為 java.util.concurrent.ThreadPoolExecutor，常用構造方法為：
ThreadPoolExecutor(int corePoolSize, int maximumPoolSize,long keepAliveTime, TimeUnit unit,BlockingQueue<Runnable> workQueue,RejectedExecutionHandler handler) corePoolSize： 線程池維護線程的最少數量
maximumPoolSize：線程池維護線程的最大數量
keepAliveTime： 線程池維護線程所允許的空閑時間
unit： 線程池維護線程所允許的空閑時間的單位
workQueue： 線程池所使用的緩沖隊列
handler： 線程池對拒絕任務的處理策略
一個任務通過 execute(Runnable)方法被添加到線程池，任務就是一個 Runnable類型的對象，任務的執行方法就是 Runnable類型對象的run()方法。
當一個任務通過execute(Runnable)方法欲添加到線程池時：
如果此時線程池中的數量小于corePoolSize，即使線程池中的線程都處于空閑狀態，也要創建新的線程來處理被添加的任務。
如果此時線程池中的數量等于 corePoolSize，但是緩沖隊列 workQueue未滿，那么任務被放入緩沖隊列。
如果此時線程池中的數量大于corePoolSize，緩沖隊列workQueue滿，并且線程池中的數量小于maximumPoolSize，建新的線程來處理被添加的任務。
如果此時線程池中的數量大于corePoolSize，緩沖隊列workQueue滿，并且線程池中的數量等于maximumPoolSize，那么通過 handler所指定的策略來處理此任務。
也就是：處理任務的優先級為：
核心線程corePoolSize、任務隊列workQueue、最大線程maximumPoolSize，如果三者都滿了，使用handler處理被拒絕的任務。
當線程池中的線程數量大于 corePoolSize時，如果某線程空閑時間超過keepAliveTime，線程將被終止。這樣，線程池可以動態的調整池中的線程數。
unit可選的參數為java.util.concurrent.TimeUnit中的幾個靜態屬性：
NANOSECONDS、MICROSECONDS、MILLISECONDS、SECONDS。
workQueue我常用的是：java.util.concurrent.ArrayBlockingQueue
handler有四個選擇：
ThreadPoolExecutor.AbortPolicy()
拋出java.util.concurrent.RejectedExecutionException異常
ThreadPoolExecutor.CallerRunsPolicy()
重試添加當前的任務，他會自動重復調用execute()方法
ThreadPoolExecutor.DiscardOldestPolicy()
拋棄舊的任務
ThreadPoolExecutor.DiscardPolicy()
拋棄當前的任務
二、一般用法舉例
package com.paul.threadPool;
import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
public class TestThreadPool 
{
private static int produceTaskSleepTime = 10;
private static int produceTaskMaxNumber = 10;
public static void main(String[] args) {
// 構造一個線程池
ThreadPoolExecutor threadPool = new ThreadPoolExecutor(2, 4, 3,
TimeUnit.SECONDS, new ArrayBlockingQueue<Runnable>(3),
new ThreadPoolExecutor.CallerRunsPolicy());
for (int i = 1; i <= produceTaskMaxNumber; i++) {
try {
String task = "task@ " + i;
System.out.println("創建任務并提交到線程池中：" + task);
threadPool.execute(new ThreadPoolTask(task));
Thread.sleep(produceTaskSleepTime);
} catch (Exception e) {
e.printStackTrace();
}
}
}
}
package com.paul.threadPool;
import java.io.Serializable;
public class ThreadPoolTask implements Runnable, Serializable {
private static final long serialVersionUID = 0;
// 保存任務所需要的數據
private Object threadPoolTaskData;
private static int consumeTaskSleepTime = 2000;
ThreadPoolTask(Object tasks) {
this.threadPoolTaskData = tasks;
}
public synchronized void run() {
// 處理一個任務，這里的處理方式太簡單了，僅僅是一個打印語句
System.out.println("開始執行任務：" + threadPoolTaskData);
try {
// //便于觀察，等待一段時間
Thread.sleep(consumeTaskSleepTime);
} catch (Exception e) {
e.printStackTrace();
}
threadPoolTaskData = null;
}
public Object getTask() {
return this.threadPoolTaskData;
}
} 說明：
1、在這段程序中，一個任務就是一個Runnable類型的對象，也就是一個ThreadPoolTask類型的對象。
2、一般來說任務除了處理方式外，還需要處理的數據，處理的數據通過構造方法傳給任務。
3、在這段程序中，main()方法相當于一個殘忍的領導，他派發出許多任務，丟給一個叫 threadPool的任勞任怨的小組來做。
這個小組里面隊員至少有兩個，如果他們兩個忙不過來，任務就被放到任務列表里面。
如果積壓的任務過多，多到任務列表都裝不下(超過3個)的時候，就雇傭新的隊員來幫忙。但是基于成本的考慮，不能雇傭太多的隊員，至多只能雇傭 4個。
如果四個隊員都在忙時，再有新的任務，這個小組就處理不了了，任務就會被通過一種策略來處理，我們的處理方式是不停的派發，直到接受這個任務為止(更殘忍！呵呵)。
因為隊員工作是需要成本的，如果工作很閑，閑到 3SECONDS都沒有新的任務了，那么有的隊員就會被解雇了，但是，為了小組的正常運轉，即使工作再閑，小組的隊員也不能少于兩個。
4、通過調整 produceTaskSleepTime和 consumeTaskSleepTime的大小來實現對派發任務和處理任務的速度的控制，改變這兩個值就可以觀察不同速率下程序的工作情況。
5、通過調整4中所指的數據，再加上調整任務丟棄策略，換上其他三種策略，就可以看出不同策略下的不同處理方式。
6、對于其他的使用方法，參看jdk的幫助，很容易理解和使用。
摘要: 有依賴的包管理，可以部署到TOMCAT 6.X，可以使用JETTY作開發測試，可以生成站點，作CHECK STYLE，PMD代碼檢查，代碼覆蓋率，生成JAVA DOC。
Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/--><project ...
閱讀全文