BIO，NIO 以及netty

BIO NIO AIO三者的技术实现以及之间的区别
小编把代码传到了我的github上
地址为 :https://github.com/dragonwanglong/nettyStudygit
代码的核心，Echo程序模型，通过网络实现基础的echo操作
bio 阻塞io处理 java1.0的时候就有， 在程序开发里面，java最小的处理单元就是线程，也就是说每一个线程可以进行IO的处理，在处理之中 该线程无法进行其他任何操作，小编 写了一个BIO的例子 ，多线程是不可能无限制创造的，如果产生的线程过多，那么直接问题在于，处理性能降低，响应速度变慢，需要去区分操作系统的线程，（内核线程 用户线程）,没有直接联系，需要使用固定线程, 所以最好与内核线程区分开。
[bio] 烧水过程中 需要我们一直盯着水壶 那么在这个过程当中 什么动作都干不了
nio 同步非阻塞IO处理

JDK1.4之后加入了nio的并发包
在nio中采用了Reactor事件处理模型,注册的汇集点就是selector,所以一个selector负责管理所有的channel
[nio] 烧水，不会一直傻站着盯着水壶，采用轮询的方式来观察谁是否烧开，直到水烧开为止。
nio的处理是基于channel实现的，我们要实现我们的seletor seletor负责管理所有的channel

AIO 异步非阻塞IO,aio是jdk1.7的时候推出的模型, future可以异步获取结果，callable是可以返回信息的线程任务实现,AIO是用了本地操作系统的IO操作处理方式,当有IO操作产生的时候，会启动一个单独的线程，它将我们所有的IO操作全部交由我们的系统完成，只需要知道返回结果即可。主要的模式是基于操作回调的方式来完成处理的， 如果以烧水为例子，在烧水的过程当中，你不需要去关注这个水的状态，在烧水完成后才进行通知。

之所以在开发之中使用系统实现的程序类，核心意义在于 它可以帮助开发者隐藏协议的实现细节，但是在开发中依然会发现如下细节：
1.程序实现方法上的差异，因为代码的底层会有实现琐碎问题。
2.在现在给定的通讯里面并没有解决长连接的问题，一旦发送稍微大的文件 很有可能无法传送。
3，在数据较大的时候无法解决粘包与拆包的问题。
4，实现的协议细节操作不好控制。
5，在很多项目开发中 rpc底层实现，需要用到大量的IO通讯问题，如果直接使用原始的程序类，开发难度过高。
Netty的产生正应允时代的要求，可以简化大量繁琐的程序代码，官网: https://netty.io/
Dubbo使用了netty作为底层通讯实现，Netty是基于 nio实现的，也采用了线程池的概念，最新版本为"4.1.31" 一开始为了进一步提高netty的处理性能，所以研发了5.0版本，（修改了一些类名称 方法名，通讯算法）发现性能没有比4.0提升，所以netty 5.x暂时不会出更新的版本了，而主要更新netty4.0
在AIO模型里面，会出现采用了回调的处理模式，例如：连接成功，信息的读取，失败等操作都会有一些列读取,参考文档:


双端的处理操作
如果在实现netty的过程之中只是进行这些简单的NIO包装处理实际上没有任何优势的。netty的出现是为了解决传输问题，最为重要的情况就是粘包与拆包的问题，
如果数据稍微有点大，（又不是很大的时候）如果有多条数据的发送（缓冲区大小问题）粘包与拆包有如下集中解决方案


我们可以发现，重复发送大量消息时，会出现消息乱的情况
A，设置消息的边界内容，例如，每一个消息使用"\n"结尾操作，
在客户端和服务端分别追加拆包器，并且客户端发送的消息末尾加上系统环境分隔符


实现代码放入github
序列化操作 java原生实现 （性能比较差），JSON(Restful) ,Messagepack,Marshalling,AVRO…下面这个例子是加上对象的编码 解码器 传输