共计 2203 个字符，预计需要花费 6 分钟才能阅读完成。
引言
t-io 和 netty 的差别，这是个被大量问及的问题，在此，作为 t -io 作者，列一些差异化的货色
t-io 的最大劣势
API 设计易懂，尽量避免引入借鉴概念——最大限度升高学习老本
接管了大量业务资源的绑定与主动解绑，开发人员只须要无脑地调用 API 即可实现绑定与解绑性能，这个解决如果丢给业务开发人员是极其简单易错的：
多线程环境下的汇合治理都是要同步平安的，同步的设计既要平安又要高效
一是容易遗记开释资源从而导致 OOM，二是容易遗记加锁或是加了死锁从而导 致零碎假死
其它同类框架为何以各种理由回避实现这些性能？和业务挂钩的都不好形象
会耗费框架性能
简单易错内置了丰盛的易用的 API，开发人员一个办法就能搞定很多业务事件
提供了生产级别的 showcase 示范工程
有教训的开发人员稍事批改即可用在生产环境
没教训的开发人员能够当作入门的示范代码文档集中在官网，用户不须要到处学习无用的、谬误的文档——进一步升高学习老本和试错老本
netty 的最大劣势
大量私有协定的实现
大量基于 netty 的高层框架
其它比照
netty 有大量私有协定的实现，t-io 官网目前提供的仅有 http 和 websocket
netty 用到了零拷贝，这一点 t -io 在平衡再三之后，放弃了零拷贝，起因如下:
零拷贝只是改善性能的伎俩（或叫算法），对用户而言，框架采纳什么算法并不重要，重要的是最终的目标是否达成——netty 用零拷贝来改善性能，t-io 借鉴同步平安线程池来改善性能，都是伎俩，必由之路。
零拷贝在缩小拷贝过程的同时，也耗费了计算机其它资源
堆外资源的治理势必减少 t -io 代码的复杂度，使 t -io 用户难以在源代码层驾驭 t -io
局部同类框架引入堆外资源管理后，在某些场景确实是晋升了性能，但这个过程也减少了很多重大 BUG
t-io 的性能曾经足够好，把精力花在服务业务上，而不是性能 PK 场上t-io 借鉴了同步线程池，正是有了这个，t-io 外部调度线程时就显得尤为简略，与 netty 的零拷贝一样，这也是改善性能与简化编程的伎俩，而不是最终目标。
t-io 内置了业务数据管理能力，这是个十分重要的能力，网络编程数据绑定和开释是件极其考验开发人员程度的性能，哪怕是经验丰富的资深开发工程师也极容易死锁和 OOM，甚至因而导致整个我的项目的失败。
举例一：你做 im，你要做群组与群员关系映射吧？在 t -io 中，您只须要 Tio.bindGroup()即可实现 tcp 连贯和这个群组关系的绑定
举例二：点对点音讯，你要针对用户 id 发消息吧？在 t -io 中，您只须要 Tio.bindUser()即可实现 tcp 连贯和 user 的关系绑定
通过 Tio.bindXxx()绑定的业务资源，不必放心 TCP 连贯断开后资源开释不掉，t-io 领有严格的算法保障这些资源失去疾速有序地开释（不得不揭示：开释资源波及到多线程操作，极易出错）！netty 有大量书籍可供查阅；t-io 提供了领有即战力的 showcase 工程（付费文档用户可下载最新版），用户并不需要太多工夫即可实现可用于生产我的项目的网络编程脚手架
t-io 和 netty 的编程模型和 API 差别极大
t-io 的 API 设计更多的是让工程师用起来难受，所以特意减少了一个 Tio.java，专门搁置罕用的 API，这样用户找起来就十分不便，不必满大街找办法调用
netty 的局部 API 是把设计模式裸露进去了，让内行人一看就晓得这是个什么设计模式做的在性能测试上的差别
在 TFB 平台上，netty 的性能远超 t -io，当然 t -io 的性能排名仍然非常靠前，排在 t -io 前面的大有人在（t-io 当初的性能比刚进去时的 t -io 差了很多，因为业务数据管理能力、阻塞发送能力、同步发送能力、流量监控与回调，是比拟耗费性能的），请参考：TFB 性能 PK 平台
带上业务进行 PK 时，t-io 性能常常优于 netty，这其中的起因大略就是：用 netty 须要本人写代码实现业务数据的治理、流量监控等工作，而这些工作拖了裸 netty 的后腿，而这些工作曾经被 t -io 内置了，所以给 t -io 带来的性能损耗就很无限，请参考 netty 和 t -io 比照测试后果t-io 提供了极其便捷的阻塞发送、同步发送，这些能力在 netty 中貌似没有，须要用户写较多的代码能力实现
阻塞发送：音讯发送到对方后，才往下执行代码
同步发送：对方收到音讯，并回了同样的 synSeq 音讯，才往下执行代码易学水平：从市场反馈来看，t-io 设计的概念仿佛更容易被工程师们所了解与承受，2014 年老板想让我用 netty，所以简略地看过《netty 权威指南》，这本书是我放弃 netty 的最初一根稻草，真的看不太懂，提供的示例我很难将其用在生产我的项目中（实在感触，当然兴许是我太菜，我另一个十分优良且年老的共事也看过这本书，同样示意云里雾里）
不少用户在抉择时，感觉 t -io 文档没有 netty 多，转而投 netty，实际上，一个好框架，并不需要太多的文档，t-io 在刚进去时，只有几个 showcase 工程，第一批 t -io 用户用这些 showcase 就实现了本人的我的项目，并且口碑迅速散开。当初 t -io 官网曾经提供了绝对残缺的文档，再配上含金量十足的 showcase 工程，应用 t -io 曾经很容易了
如果已经应用过 netty 或 mina，再来应用 t -io，兴许你会感觉到前所未有的爽！
具体请参考：https://www.tiocloud.com/doc/…