如果你遇到」粘包「問題，實際上可能不是粘包問題。
使用mina的時候鋪天蓋地的都說要加上：executorfilter
fc.addlast("executor",new executorfilter(executors.newcachedthreadpool()));
我在測試的時候發現很容易出現粘包問題，ok tcp出現粘包問題很普遍，但是，問題在於我使用的是textlinecodecfactory
本身是按照\n 分隔符解析訊息的，客戶端傳送訊息也是由\n分割的。 完全沒有道理出現什麼鬼粘包問題。
mina封裝得很好，大致上需要大家配置的就那麼幾個。主要是defaultiofilterchainbuilder的配置
ok，加上了上面寫的executorfilter，通過非同步佇列處理訊息，提高效能。
問題就來了，在測試過程中，訊息居然是亂的，也就是說出現了粘包問題。測試來測試去，想來想去都無法理解這是為什麼。
最終注釋掉測試：通過。
使用newfixedthreadpool 不通過
使用newsinglethreadexecutor 通過。
由此我得出乙個結論：雖然粘包問題解決了，但是使用的executorfilter是非同步的，導致訊息是被一段段的接收並且解析的。
那麼，這些訊息之間是非同步的，對於單個訊息的解析是完全沒問題的。但是問題在於，收到位元組的時候就已經把位元組給分錯了。
去掉非同步的佇列就解決了這個問題。
以上是沒看過原始碼隨口瞎說的，對這方面了解的朋友請交流下。
看來我還要多研究，我實在是搞不懂，解析位元組也需要非同步解析？如果不是因為非同步解析位元組導致位元組分開。又怎麼會出現我所描述的問題？
如果你遇到粘包問題又無法解決，請嘗試下。
具體的需要多看下，倒是是什麼鬼原因導致位元組錯亂
fuc.
以上都說法都***有問題，
實際上我遇到的訊息混亂的問題原因出自於乙個：defaultiofilterchainbuilder 過濾器新增順序問題。
我先新增的 executorfilter 再新增的protocolcodecfilter 結果導致了非同步接收訊息後 解析訊息。
就如上面所說，我一直奇怪的是為什麼mina *** 不先解析訊息然後多執行緒非同步處理訊息。
原來這個地方的順序還有乙個 這麼bug的要求。
雖然我知道 mina的logger放在前面和後面也是由不同的，但是無法理解這個狗日的順序對mina有什麼好處。
如果說，在protocolcodecfilter 使用order executorfilter 在其後面再放乙個 其他執行緒池？這樣又有什麼好處？
總之，如果你遇到一些奇怪的問題，注意過濾器新增順序的問題！！！
先解碼，後放入佇列處理！！！
fuc. mina
粘包現象與解決辦法
一 什麼是粘包現象 須知 只有tcp有粘包現象，udp永遠不會粘包 粘包不一定會發生，如果發生了 1.可能是在客戶端已經粘了，2.客戶端沒有粘，可能是在服務端粘了 粘包現象 tcp粘包是指傳送方傳送的若干包資料到接收方接收時粘成一包，從接收緩衝區看，後一包資料的頭緊接著前一包資料的尾。成因 所謂粘包...
TCP粘包原因及解決辦法
粘包 多個資料報被連續儲存於連續的快取中，在對資料報進行讀取時由於無法確定發生方的傳送邊界，而採用某一估測值大小來進行資料讀出，若雙方的size不一致時就會使指傳送方傳送的若干包資料到接收方接收時粘成一包，從接收緩衝區看，後一包資料的頭緊接著前一包資料的尾。比如說 傳送方傳送了兩個資料，接收方一次收...
TCP的粘包和拆包問題及解決辦法（C ）
本文參考 如果客戶端連續不斷的向服務端傳送資料報時，服務端接收的資料會出現兩個資料報粘在一起的情況，這就是tcp協議中經常會遇到的粘包以及拆包的問題。我們都知道tcp屬於傳輸層的協議，傳輸層除了有tcp協議外還有udp協議。tcp tcp是基於位元組流的，雖然應用層和tcp傳輸層之間的資料互動是大小...