我的新浪微博：http://weibo.com/freshairbrucewoo。
歡迎大家相互交流，共同提高技術。
這個協議類不建議投入到實際的生產環境（除非自己做了很強的壓力和全面的測試）。這個密集協議的最大作用就是儘可能使用小的空間，密集協議類有兩種類型的實例對象，一種是獨立的，它不被使用在rpc通信中，而只是用於編碼和解碼；另一種是非獨立的實例類型，它可以用於rpc通信，不過現在還不支持這種類型的實例。
要使用這個密集協議類來進行編碼和解碼必須支持Thrift自己實現的一直特殊的記錄數據類型形式：就是type_spec屬性，它的主要作用就是用於本地化反射機制來進行讀寫數據。
最佳的實踐方法如下：
（1）永遠不要使用可選的原語或容器類型；
（2）如果數據類型非常的大或非常的稀少那麼使用結構體類型（struct）；
（3）所有整數類型使用可變長的，能夠使用i64類型避免膨脹；
（4）永遠不要以任何方式修改結構體的定義而不改變換成的鍵，否則會造成恐慌的錯誤。
這個密集協議類繼承至二進制協議類，所以可以直接使用二進制協議類的一些協議方法。
那麼這個協議類相比前面的協議類又有什麼優勢和不足。既然這個協議類是後面逐漸發展起來的，那麼它肯定有自己的優勢和適合的應用場景，據我學習之，它的優勢如下：
（1）相比較二進制協議它使用了可變長編碼，當然緊湊協議類也實現了這個來減少整數型數據的傳輸流量，那麼它相對於緊湊協議類又有什麼優勢？請看下面一條；
（2）相對於緊湊協議類它減少了一部分元數據的傳輸，例如struct結構裏面的字段id和數據類型，這樣就極大的減少了流量，當然速度也就自然提升了不少。
雖然它有這些優勢，但是它的缺陷也是比較明顯的，主要有以下三點：
（1）抽象將失去效果；
（2）必須維持第二個代碼生成器；
（3）想要保持與舊版本的兼容將是是非常困難的。
通過它的優勢和缺陷的分析發現，它們都是那麼的鮮明，所以選擇這個協議作爲傳輸層之上的協議類型需要經過比較慎重的考慮，優點其實就是靠犧牲抽象性、易維護和向前兼容來提升數據傳輸速度和減少流量。
那麼實現這個協議類需要用到什麼特殊的技術，通過代碼和註釋發現，主要兩點技術，一個是可變長編碼，這個在緊湊協議類中已經實現和介紹；另一個技術就是消除一些傳輸的元數據。消除元數據的傳輸需要支持Thrift的編譯器和犧牲一些二進制協議的向前和向後的兼容性。
上面分析了密集協議類的優秀和不足，但是就目前而言這個類還是處於試驗的階段，不能投入真正的生產環境，所以就不具體分析代碼的實現了，有興趣的同仁們可以自己看看代碼的實現，使用到的技術前面已經介紹了。