CometPipe數(shù)據(jù)發(fā)送一點改動
Author：放翁（文初）
場景：
前提：長連接推送（每個請求會話時間保持較久）。在事件驅(qū)動模式下，多線程可能同時完成任務(wù)并通過Http長連接下發(fā)數(shù)據(jù)，對于Response需要有一定的并發(fā)保護(hù)。
第一版
增加一個lock，獲得以后才可以使用Response。
每個線程的處理流程：get lock à use response àrelease lock。
在同一個通道的事件大量并發(fā)產(chǎn)生的時候，由于use response比較“重”，使得大量線程生命周期加大（順序的獲取鎖），上下文切換頻繁，系統(tǒng)load較高。
第二版（現(xiàn)在的版本）
去掉lock，為每一個請求會話增加一個隊列和后臺線程。
每個線程的處理流程：add message to queue。
后臺線程block to wait message and deliver。
第一版的問題不存在了，但在沒有消息下行的時候，大量后臺線程block wait，對于內(nèi)存來說還是有些浪費。
復(fù)雜卻未必有好效果的版本
從上面來看，需要做的就是防止將發(fā)送數(shù)據(jù)放入競爭事務(wù)（也就是一個時期只有一個線程負(fù)責(zé)對隊列數(shù)據(jù)的獲取和下發(fā)），需要復(fù)用線程為多個請求處理下行任務(wù)。
大致解釋一下流程：
1． 每個線程在放入隊列的時候需要先獲得讀寫鎖的讀鎖，然后將數(shù)據(jù)放入隊列。具體獲得讀鎖的目的最后談。
2． 線程判斷是否已經(jīng)有后臺支持線程來處理消息下發(fā)，如果沒有嘗試的去操作needworkerflag的原子布爾對象。
3． 線程如果成功的將needworkerflag原子布爾對象由true改成了false狀態(tài)，那么表示他獲得了取得線程事件的令牌，就向線程池發(fā)起執(zhí)行下發(fā)消息的任務(wù)。
4． 線程池收到任務(wù)后，分配一個線程循環(huán)的去獲取數(shù)據(jù)并下發(fā)，直到隊列瞬時為空。
5． 獲取寫鎖，重新再檢查隊列是否有數(shù)據(jù)，如果有下行，然后修改needworkerflag為true，最后釋放寫鎖。(用讀寫鎖就是為了在后臺線程退出時保證隊列中的被加入的數(shù)據(jù)完全被執(zhí)行，而沒有并發(fā)導(dǎo)致遺留數(shù)據(jù)在隊列但沒有任何線程處理的情況，帶來的壞處就是在這個寫鎖臨界區(qū)里面會有寫出動作會阻塞外部在那個時候放數(shù)據(jù)的過程)
設(shè)計很復(fù)雜，能夠帶來的比第二個設(shè)計好的點就是可能在消息并發(fā)較低的時候充分利用資源，但壞處還是很多的，包括線程切換，線程退出時的短時阻塞，線程池容量大小的考慮。
大家如果有更好的設(shè)計和實現(xiàn)的方式可以一起討論并給出設(shè)計和實現(xiàn)的細(xì)節(jié)說明。