介绍t-io和netty的区别，这个是问的比较多的问题，这里作为t-io的作者，罗列几个最大的区别int-io优势API设计通俗易懂，尽量避免引入自创概念——最小化学习成本接管大量业务资源的绑定和自动解绑，开发者只需要无脑调用API即可完成绑定和解绑定函数，如果把这个处理丢给业务开发者，是极其复杂和容易出错的：多线程环境下的集合管理必须同步和安全，同步的设计必须既安全又高效。是不是很容易忘记加锁或者加死锁导致系统卡死？为什么其他类似的框架出于各种原因避免实现这些功能？与业务挂钩的东西都不好。抽象会消耗框架性能。复杂且容易出错。内置丰富易用的API，开发者可以用一种方法处理大量业务。提供生产级展示示范工程。有经验的开发者可以稍微修改一下。没有经验的开发者可以在生产环境中使用，可以作为入门级演示代码文档专心看官网，用户无需到处学习无用错误的文档——进一步降低学习成本和试错成本.netty最大的优势就是大量的公共协议大量基于netty的高层框架的实现。与netty相比，有大量的公共协议实现。目前只有t-io官方提供的http和websocketnetty使用了零拷贝。反复平衡后，t-io放弃了零拷贝。原因如下：零拷贝只是一种提高性能的手段（或算法）。对于用户来说，框架使用什么算法并不重要，重要的是最终目的是否达到——netty使用零拷贝提升性能，t-io创建同步安全线程池提升性能是一种手段，但是同一个目标。虽然零复制减少了复制过程，但它也消耗了其他计算机资源。堆外资源的管理必然会增加t-io代码的复杂度，使得t-io用户很难在源代码层控制t-io的一些类似框架引入堆外资源管理后，在某些场景下性能确实有所提升，但是这个过程也增加了很多严重的bug。t-io的性能已经够好了，把精力花在服务业务上，而不是性能PK领域。t-io自创正是因为如此，t-io内部对线程的调度特别简单。和netty的零拷贝一样，这也是提高性能和简化编程的一种手段，并不是最终目的。t-io内置了业务数据管理能力，这是一个非常重要的能力。网络编程数据绑定和发布是一个极其考验开发者水平的功能。即使是经验丰富的高级开发工程师也容易出现死锁和OOM。甚至导致整个项目的失败。例1：如果做IM，是否需要映射群组和群组成员的关系？在t-io中，只需要Tio.bindGroup()就可以完成tcp连接和group关系的绑定例2：点对点消息，你想为userid发送一条消息，对吧？在t-io中，只需要Tio.bindUser()就可以完成tcp连接与用户的关系。绑定通过Tio.bindXxx()绑定的业务资源。不用担心TCP连接断开后资源不会释放。t-io有严格的算法保证这些资源被快速有序的释放（不得不提醒：释放资源涉及到多线程操作，极易出错）！Netty有大量书籍可供查阅；t-io提供即时战斗力的showcase项目（付费文档用户可下载最新版本），用户不需要太多时间即可完成可用于生产项目的网络编程脚手架t-io的编程模型和API和netty有很大的不同。t-io的API设计更方便工程师使用，所以一个Tio。不用满街找调用netty的部分API的方法，因为暴露了设计模式，让行内人一看就知道是什么设计模式io，当然还有性能排行t-io的门槛还是很高的，t-io背后的人很多（t-io的性能比t-io刚出来的时候差很多，因为业务数据管理能力，阻塞发送能力，同步发送能力，流量监控和回调比较耗性能），请参考：TFB性能PK平台带来业务PK时，t-io性能往往优于netty。这样做的原因大概是：使用Netty需要自己写代码来完成业务数据管理、流量监控等，而这些任务已经拖慢了barenetty，而这些任务已经内置到t-io中，所以性能给t-io带来的损失是非常有限的，请参考netty和t-io的对比测试结果。T-io提供了极其方便的分块和同步发送。netty似乎没有这些能力。用户需要多写代码才能实现阻塞发送：消息发送给对方后，代码同步下发：对方收到消息返回相同的synSeq消息，然后执行代码。易学性：从市场反馈来看，t-iodesign的概念似乎更容易被工程师理解和接受，2014年老板要我用netty，所以就简单看了《netty权威指南》。这本书是我放弃netty的最后一根稻草。我真的不明白。我很难理解所提供的示例。用于生产项目（真感觉，当然，也许我太擅长了。我的另一个很好很年轻的同事也看过这本书，他也说他在云端。投票给netty。其实一个好的框架不需要太多的文档。当t-io刚出来的时候，只有几个展示项目。第一批t-io用户用这些展示柜完成了他们的项目，口耳相传很快。现在t-io官方已经提供了比较完善的文档，再加上含金量十足的showcase项目，t-io非常好用。如果你以前用过netty或者mina，再用t-io，说不定你会觉得前所未有的爽！详情请参考：https://www.tiocloud.com/doc/...
