本文减少代码展示，重点是理解整体类关系与结构的设计。
因为项目中用rabbitmq，特意了解一下客户端代码。它使用nio的方式也很典型，它并没有使用netty等间接使用nio，毕竟服务端是Erlang开发的，数据传输的结构简单。它使用两个Selector.open()产生的两个selector，分别处理读写的操作注册。写的数据放在一个state的队列中，循环队列注册写操作，并从队列取数据来写。
另外注册nio操作的时候，一般
attach参数
是一个持有socketChannel的对象，一般demo中直接用socketChannel读写，但实际上一般要先处理后，再读写的。
nio是低层，至于给用户用的connection是统一读写用，毕竟客户端只是一个socketChannel，而用户的channel是编号的，给用户的独立线程使用的，最终还是通过connection进行读写。
代码多了也记不住，仅画一个图：分别体现了
运行状态
与
构建运行状态的主要操作
。
**运行状态图：**来源于框架的要实现的功能，可以从作者提供的
示例
作为入口进行功能跟踪。
ConnectionFactory factory = new ConnectionFactory();
…
Connection conn = factory.newConnection();
这里最终就是通过nio（实际上支持非nio，SSL也可选）发送（接收）消息或者命令。
- 客户层的发送与接收与传输层的发送接收不一样，中间一般有一个中介，这里就是frameHandler。
- 客户端因为多线程，所以要统一到一个处理类。所以有channel（非socketChannel）与connection。
- 发送一般要消峰填谷，使用队列与异步线程。但nio底层使用注册读写操作多路复用，所以用不上线程池。
- 接收一般就是轮询机制，再考虑分配给客户的多个channel，所以必然有dispatch。
通过以上分析，差不多就整理出一个运行时状态图。
**构建运行状态：**源于对上述运行中的类的创建、初始化、关联起来。按上述运行中的引用关系创建，不是一个new就能说明，所以一般都要有工厂。
- connection的具体功能，要通过中介frameHandler实现，所以创建connection时，先创建frameHandler。
- 而创建frameHandler前，要建好读写的注册的声明，还要让nio轮询起来，处理读写声明。有点类似于发动机先转起来，设置好引用后，一挂档（放入声明）就处理起来。
- nio的select出来的key，因为Socketchannel只是底层的读写，所以一般用一个持有Socketchannel的上层处理类，作为注册读写的attach。这样一但读写条件准备好了，上层处理类先处理数据对象的转换或者序列化之类的，再用Socketchannel真正收发数据。
总的来说，rabbitmq-client源码还有很多特点，比如使用nio或bio，使用ssl或者非ssl，使用nio的读写分开的selector。这些处理都很有实站参考价值。