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