FJJJJJ

Netty的线程模型Reactor单线程模型Reactor单线程模型，是指所有的IO操作都在同一个NIO线程上面完成。NIO线程的职责如下：作为NIO服务端，接收客户端的TCP连接；作为NIO客户端，向服务端发起TCP连接；读取通信对端的请求或者应答消息；向通信对端发送消息请求或者应答消息。由于 Reactor模式使用的是异步非阻塞I/O，所有的IO操作都不会导致阻塞，理论上一个线程可以独立处理所有IO相关的操作。从架构层面看，一个NIO线程确实可以完成其承担的职责。例如，通过 Acce

Pipeline是什么在之前的Netty编程中我们可以看到需要添加一个解码器或者是一个处理器或者是一个粘包拆包处理器，都需要在一个pipeline中添加进去，那么这个pipeline到底是个什么东西？ChannelPipeline点进pipeline()方法发现是一个ChannelPipeline对象首先ChannelPipeline本质上其实是一个Map<String, DefaultChannelHandlerContext>存储DefaultChannelHandlerCon

我们选择一个编解码框架的时，往往会考虑以下几个因素：是否支持跨语言，支持的语言种类是否丰富；编码后的码流大小编解码的性能；类库是否小巧，API使用是否方便使用者需要手工开发的工作量和难度。package main.com.phei.netty.codec.serializable;import java.io.Serializable;import java.nio.ByteBuffer;/** * @author Administrator * @version 1.0 *

粘包与拆包但凡是使用的TCP协议的都会遇到这个问题，TCP是个“流”协议，所谓流，就是没有界限的一串数据。大家可以想想河里的流水，是连成一片的，其间并没有分界线。TCP底层并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行包的划分，所以在业务上认为，一个完整的包可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的TCP粘包和拆包问题。举个栗子：本来客户端要想服务端发送两条数据分别是：第一条：11，第二条22，会发生以下几种情况：服务端接受到

Nettypackage main.com.phei.netty.basic;import io.netty.bootstrap.ServerBootstrap;import io.netty.channel.ChannelFuture;import io.netty.channel.ChannelInitializer;import io.netty.channel.ChannelOption;import io.netty.channel.EventLoopGroup;import io

BIO下图的通信模型图来熟悉下BIO的服务端通信模型：采用BIO通信模型的服务端，通常由一个独立的 Acceptor线程负责监听客户端的连接，它接收到客户端连接请求之后为每个客户端创建一个新的线程进行链路处理，处理完成之后，通过输出流返回应答给客户端，线程销毁。这就是典型的一请求一应答通信模型。该模型最大的问题就是缺乏弹性伸缩能力，当客户端并发访问量增加后，服务端的线程个数和客户端并发访问数呈1:1的正比关系，由于线程是Java虚拟机非常宝贵的系统资源，当线程数膨胀之后，系统的性能将急剧下降，随着并发

I/O基础入门Java1.4之前的IO并不完善，只有同步阻塞的BIO，通常导致通信线程长时间阻塞，直到之后的NIO出现。Linux 网络 I/O模型简介Linux的内核将所有外部设备都看做一个文件来操作，对一个文件的读写操作会调用内核提供的系统命令，返回一个 file descriptor(fd，文件描述符）。而对一个 socket的读写也会有相应的描述符，称为 socketed( socket描述符），描述符就是一个数字，它指向内核中的一个结构体（文件路径，数据区等一些属性） ----Net