高並發編程thirft源碼解析
我用的thrift模式：
網絡編程模式
arg.selectorThreads(Integer.parseInt(mProp.get("LogServerSelectorThread").toString()));
這步驟是啟動了多個線程，每個線程裏面有個bocking queue隊列，隊列元素是socketchannel，線程啟動後就不斷消費這個隊列
並不是select使用了多線程，而是便利selectkey時，沒當有一個連接socketchannel進來就加入隊列，
arg.workerThreads(Integer.parseInt(mProp.get("LogServerWorkThread").toString())); //worker線程數
這一步其實是處理selector的連接數，內部使用了ExcuteService這個線程池，
每天有個連接進來，就是用從這個線程池裏面任意取一個線程來執行下面這個方法，目的是分別client到一個指定SelectorThread線程裏面
invoker.submit(new Runnable() { public void run() { doAddAccept(targetThread, client); } });
問題1: 為什麽這裏使用了兩個多線程，為什麽不用一個就夠了呢？
我的分析是：
1、如果用一個線程池，那麽不斷有連接進來，就會不斷生成一個線程處理，
每個線程都要處理完這些數據才會釋放，那麽並發高度時候，就會有大量的處理線程積壓，
這個線程池就會不斷膨脹，最終崩潰
2、如果每個線程內部采用一個隊列，那就要分別啟動這些線程，並加入socketchannel到這個隊列裏面
thirft調度策略有：FAIR_ACCEPT和FAST_ACCEPT，默認是後者，
就是說FAST_ACCEPT模式其實就是答案裏說的，只是用了一個線程池模式，沒有用ExcuteServcie
問題2: SelectorThread內部為什麽用blocking queue，而不用concurrent queue呢?
因為這個queue不需要共享，blocking queue效率更快
高並發編程thirft源碼解析