1.總體介紹：
CMS(Concurrent Mark-Sweep)是以犧牲吞吐量為代價來獲得最短回收停頓時間的垃圾回收器。對于要求服務器響應速度的應用上，這種垃圾回收器非常適合。在啟動JVM參數加上
-XX:+UseConcMarkSweepGC ，這個參數表示對于老年代的回收采用CMS。CMS采用的基礎算法是：標記—清除。
2.CMS過程：
- 初始標記(STW initial mark)
- 并發標記(Concurrent marking)
- 并發預清理(Concurrent precleaning)
- 重新標記(STW remark)
- 并發清理(Concurrent sweeping)
- 并發重置(Concurrent reset)
初始標記 ：在這個階段，需要虛擬機停頓正在執行的任務，官方的叫法STW(Stop The Word)。這個過程從垃圾回收的"根對象"開始，只掃描到能夠和"根對象"直接關聯的對象，并作標記。所以這個過程雖然暫停了整個JVM，但是很快就完成了。
并發標記 ：這個階段緊隨初始標記階段，在初始標記的基礎上繼續向下追溯標記。并發標記階段，應用程序的線程和并發標記的線程并發執行，所以用戶不會感受到停頓。
并發預清理 ：并發預清理階段仍然是并發的。在這個階段，虛擬機查找在執行并發標記階段新進入老年代的對象(可能會有一些對象從新生代晉升到老年代，或者有一些對象被分配到老年代)。通過重新掃描，減少下一個階段"重新標記"的工作，因為下一個階段會Stop The World。
重新標記 ：這個階段會暫停虛擬機，收集器線程掃描在CMS堆中剩余的對象。掃描從"跟對象"開始向下追溯，并處理對象關聯。
并發清理 ：清理垃圾對象，這個階段收集器線程和應用程序線程并發執行。
并發重置 ：這個階段，重置CMS收集器的數據結構，等待下一次垃圾回收。
CSM執行過程：
3.CMS缺點
- CMS回收器采用的基礎算法是Mark-Sweep。所有CMS不會整理、壓縮堆空間。這樣就會有一個問題：經過CMS收集的堆會產生空間碎片。 CMS不對堆空間整理壓縮節約了垃圾回收的停頓時間，但也帶來的堆空間的浪費。為了解決堆空間浪費問題，CMS回收器不再采用簡單的指針指向一塊可用堆空間來為下次對象分配使用。而是把一些未分配的空間匯總成一個列表，當JVM分配對象空間的時候，會搜索這個列表找到足夠大的空間來hold住這個對象。
- 需要更多的CPU資源。從上面的圖可以看到，為了讓應用程序不停頓，CMS線程和應用程序線程并發執行，這樣就需要有更多的CPU，單純靠線程切換是不靠譜的。并且，重新標記階段，為空保證STW快速完成，也要用到更多的甚至所有的CPU資源。當然，多核多CPU也是未來的趨勢！
- CMS的另一個缺點是它需要更大的堆空間。因為CMS標記階段應用程序的線程還是在執行的，那么就會有堆空間繼續分配的情況，為了保證在CMS回收完堆之前還有空間分配給正在運行的應用程序，必須預留一部分空間。也就是說，CMS不會在老年代滿的時候才開始收集。相反，它會嘗試更早的開始收集，已避免上面提到的情況：在回收完成之前，堆沒有足夠空間分配！默認當老年代使用68%的時候，CMS就開始行動了。 – XX:CMSInitiatingOccupancyFraction =n 來設置這個閥值。
總得來說，CMS回收器減少了回收的停頓時間，但是降低了堆空間的利用率。
4.啥時候用CMS
如果你的應用程序對停頓比較敏感，并且在應用程序運行的時候可以提供更大的內存和更多的CPU(也就是硬件牛逼)，那么使用CMS來收集會給你帶來好處。還有，如果在JVM中，有相對較多存活時間較長的對象(老年代比較大)會更適合使用CMS。
JBOSS默認配置會有一個后臺漏洞，漏洞發生在
jboss.deployment命名空間 中的
addURL()函數,該函數可以遠程下載一個war壓縮包并解壓訪問http://www.safe3.com.cn:8080/jmx-console/ 后臺，如下圖
下拉找到如下圖所示
點擊
flavor=URL,type=DeploymentScanner進入
在輸入框中寫入war壓縮文件webshell的url地址，如上圖點擊invoke執行界面獲得一個jsp的webshell，如下圖
臨時漏洞修補辦法：給jmx-console加上訪問密碼
1.在
${jboss.server.home.dir}/deploy下面找到jmx-console.war目錄編輯WEB-INF/web.xml文件 去掉 security-constraint 塊的注釋，使其起作用 2.編輯WEB-INF/classes/jmx-console-users.properties或server/default/conf/props/jmx-console-users.properties (version >=4.0.2)和 WEB-INF/classes/jmx-console-roles.properties 或server/default/conf/props/jmx-console-roles.properties(version >=4.0.2) 添加用戶名密碼 3.編輯WEB-INF/jboss-web.xml去掉 security-domain 塊的注釋 ，security-domain值的映射文件為 login-config.xml （該文件定義了登錄授權方式）
這是一份歷盡千辛萬苦，遲來卻依舊讓人無比激動的圣誕禮物。就在大約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...
閱讀全文