qq_25046827的博客

因为像TCP和UDP这种底层协议只能发送字节流，因此当我们在开发一些远程过程调用（RPC）的程序时，需要将应用层的Java POJO对象序列化成字节流，数据接收端再反序列化成Java POJO对象。理论上对于性能要求不是太高的服务器程序可以选择JSON系列的序列化框架，而对于性能要求较高的服务器程序则应该选择传输效率更高的二进制序列化框架如Protobuf。

这种模式的优点是解决了前面的新连接被严重阻塞的问题，在一定程度上极大地提高了服务器的吞吐量。而且线程的反复创建、销毁、线程的切换也需要代价。这种方法最大的问题就是如果前一个网络连接的处理没有结束，那么后面的连接请求没法被接收，于是后面的请求统统会被阻塞住，服务器的吞吐量就太低了。在单线程反应器模式中，Reactor反应器和Handler处理器都执行在同一条线程上（dispatch方法是直接调用run方法，没有创建新的线程），因此当其中某个Handler阻塞时，会导致其他所有的Handler都得不到执行。

这样就会导致一个结果@Sharable共享实例不是线程层面安全的，因此@Sharable共享的业务处理器，如果需要操作的数据不仅仅是局部变量，则需要进行线程的同步控制，以保证操作是线程层面安全的。出站处理用到的ByteBuf缓冲区一般是要发送的消息，通常由Handler业务处理器所申请而分配的，在每一个出站Handler业务处理器的处理完成后，最后数据包回来到出站的最后一棒HeadHandler，在数据输出完成后，ByteBuf会被释放一次，如果计数器为0，将被彻底释放掉。

OverrideSystem.out.println("解码出一个整数:" + i);@OverrideSystem.out.println("打印出一个整数:" + integer);使用上面的Byte2IngeterDecoder证书解码器需要先对ByteBuf的长度进行检查，如果有足够的字节，才进行整数的读取。这种长度的判断可以由Netty的ReplayingDecoder类来完成。

该方法的返回值为一个AttributeKey实例，它的泛型类型为实际上的key-value键值对中value的键值对中value的实际类型。可以通过AttributeMap的attr方法，根据key取得Attribute类型的value，然后根据value实例完成最终的两个重要操作：设置（set）和取值（get）。Netty中的Channel通道类，有类似于Map的容器功能，可以通过“key-value”键值对的形式来保存任何Java Object的值。

客户端的心跳检测对于任何长连接的应用来说，都是一个非常基础的功能。要理解心跳的重要性，首先需要从网络连接假死的现象说起。

*每次发多少数据到网络中与当前网络的拥塞情况和服务端返回的TCP窗口的大小有关，涉及TCP的流量控制和拥塞控制，并且与Netty的反压有关。，它除了JDK自带的epoll模型的封装，还额外封装了一套，这两者都是epoll模型的封装，只是JDK的epoll模型是水平触发的，而Netty采用JNI重写的边缘触发。所谓背压，是进行流量控制的一种方案。TCP是面向字节流传输的协议，它把客户端提交的请求数据看作一连串的无结构的字节流，并不知道所传送的字节流的含义，也并不关心有多少数据流入TCP输出缓冲区中。