卷土的博客

SO_BACKLOG 设置的过小，高峰期有很多连接来了，就会被拒绝，报拒绝连接错误。控制全连接队列的大小，可以容下适量连接。所以SO_BACKLOG设置的要大一些。属于ServerSocketChannel参数。SO_BACKLOG设置值。

1.ServerBootstrap.option方法，给ServerSocketChannel配置参数的。2.ServerBootstrap.childOption方法，给SocketChannel配置参数的。客户端是Bootstrap.option方法配置参数。

使用简单，但是效率不高。jdk序列化和反序列化。

1.网络设备出现故障，例如网卡，机房等。底层的TCP连接已经断开，但应用程序没有感知到，仍然占着资源。2.公网网络不稳定，出现丢包。若果连续出现丢包，这时现象就是客户端数据发不出去，服务端也一直收不到数据，就这么一直耗着。3.应用程序线程阻塞，无法进行数据读写。Netty提供监测连接假死手段空闲状态检测器。

1.正常断开，客户端调用了ctx.channel().close();2.异常断开，比如客户端挂掉了。

如果自定义类是MessageToMessageCodec的子类就是线程共享的，可以被@Sharable修饰的。ByteToMessageCodec的子类不能被@Sharable修饰。这样的handler，创建一个实例就够了。handler被注解@Sharable修饰的。

用来第一时间判定是否是无效数据包。：主持协议升级。：消息正文到底采用那种序列化方式，可以由此扩展，例如：json,protobuf（google的序列化算法，基于二进制，虽然可读性不好，但是字节数占用更少）,hessian（基于二进制）,jdk（缺点多，不能跨平台，性能也不好）。就是把复杂的对象以一种通用的格式，让各个平台都支持的格式来进行传输。：登录、注册、单聊、群聊...跟业务相关。：为了双工通信，提供异步能力。

上面HttpServerCodec处理器会得到两个对象，有时候我们只关注其中一个数据对象。简化上面的写法，使用。Netty已经把Http协议的编解码器实现好了，只需要简单的配置就可以使用。Http协议比Redis协议复杂的多，如果程序员自己去实现，工作量大。命名规范上后缀是codec 就表示该类就包含了解码，又包含了编码。请求来了，对请求request进行解码。需要HttpServerCodec。响应要返回给浏览器，对响应进行编码。处理器，只关注某一个对象。：包含请求行和请求头。

只要遵照了一定的协议，就可以跟设计这个协议的服务器端进行通信。这些协议并不需要我们自己去开发的，netty都已经做好了。$8 表示zhangsan的长度，8个字节。以上是自己按照redis协议进行编码测试。$3表示 set 命令的长度，3个字节。说明：回车换行变成字节数据还可以这么写。$4 表示name的长度，4个字节。*3 表示有三个元素。

表示从第头开始就是4个字节的数据长度，后面就是数据的实际内容。这样就错了，把数据版本的1个字节也算到真实的数据内容里面去了，就会导致实际的数据内容就会少一个字节。所以变成了Hello, worl 又把数据内容的最后一个字节d算到下一次数据的长度字节里面去了，就错乱了。initalBytesToStrip = 5 表示剥离了数据中的数据长度4个字节+数据版本1个字节。如果给数据添加一个版本号在数据的长度和 实际数据内容之间。第一部分是数据的长度4个字节的int。第二部分是数据的版本号，一个字节。

3</b> (= the length of HDR1 + LEN) 表示剥离了HDR1和Length。<b>lengthAdjustment</b> = <b>1

基于换行/n （linux）或回车换行/r/n(windows)进行分割。使用LIneBasedFrameDecoder构造方法，需要设定一个最大长度。如果超过了最大长度，还是没有找到换行符，就这位这个数据段太长了，抛出ToolLongFrameException。

2.当客户端消息过来，长度不够定长则等待。等待消息长度够了，再处理。这就保证了是一条完整的消息。如果长度超过了定长，也会把定长段的消息进行处理，剩下的消息和后面的消息合并。3.这个定长帧解码器handler一定要放在pipeline的第一个，因为先要拿到正确解码的消息，后面的handler才能处理的是正确解码后的完整消息。定长解码器能够解决黏包、半包问题，但是消息是定长的，不够定长的消息，占用的字节数也是定长那么大，就造成了空间浪费。1.设定一条消息的定长。要找到所有可能发送的消息，

/调整netty的接收缓冲区ByteBuf, AdaptiveRecvByteBufAllocator设置最小值就是16，所以在调小是不行的。从滑动窗口看，在服务端保证有足够的缓冲区。默认服务端的滑动窗口足够大。所以不要再设置SO_RCVBUF的值，使用默认的就可以了。如果在服务端调整netty的接收缓冲区ByteBuf为16字节，客户端发送数据位18个字节。客户端发送一次完整的消息，然后就把与服务端的链接断开。服务端读到的结果就是-1。服务器就知道 从链接建立到断开，发送的数据是一条完整的数据。

服务端代码客户端代码从日志信息看出：服务端收到了160个字节这是一个黏包的现象，客户端发了十次，每次发送16个字节。但是服务端一次性接受了160个字节。

特别说明：之前创建的ByteBuffer都是：//默认获取的是直接内存这样创建只是自己写一些测试练习使用。真正项目开发中，还是建议在handler中的创建：在服务端发送数据给客户端的时候。

1.池化-可以重用池中ByteBuf实例，更节约内存，减少内存溢出的可能。2.读写指针分离，不需要像ByteBuffer一样切换读写模式。3.可以自动扩容。4.支持链式调用，使用更流畅。5.很多地方体现零拷贝，例如：slice,duplicate,CompositeByteBuf。

1.capacity 容量2.max capacity 最大容量3.读指针（在ByteBuf的一开始）4.写指针（在ByteBuf的一开始）读指针与写指针之间就是 还未读取的部分（可读部分）。读指针读过的部分叫做废弃的部分。跟ByteBuffer比，不需要切换读模式、写模式了。

/堆内存堆内存，分配内存效率高，读写效率低。//直接内存//默认获取的是直接内存直接内存创建和销毁的代价昂贵，但读写性能高，少一次内存复制，适合配合池化功能一起用。直接内存对GC压力小，因为这部分内存不收JVM垃圾回收的管理，但也要注意及时主动释放。

1.byteBuf创建方法。

这个channel可以直接绑定多个handler，不用写服务端代码和客户端代码。

ChannelHandler用来处理Channel上的各种事件，分为入站和出站两种。所有的ChannelHandler被连成一串，就是Pipeline。通常是的子类，主要用来读取客户端数据，写回结果。通常是的子类，主要对写回结果进行加工。默认有head和tail，一头一尾两个handler，添加的handler其实是在他们之间的。

在异步处理时，经常用到两个接口Future 和 Promise。说明：Netty中的Future与jdk中的Future同名，但是是两个接口，netty的Future继承了jdk的Future,而Promise又对Netty的Future进行了扩展。JDK的Future只能同步等待任务结束（成功、失败）才能得到结果。FutureTask.get()方法。Netty的Future可以同步等待任务结束得到结果，也可以异步方式得到结果，但都是要等任务结束。

4个医生给人看病，每个病人花费20分钟，而且医生看病的过程中是以病人为单位的，一个病人看完了才能看下一个病人。如果病人源源不断，可以计算一下4个医生一天工作8小时，处理病人总数是：4*8*3=96。

当channel调用close方法关闭了，input线程也break跳出结束了，在NioEventLoopGroup中还有线程没有结束，所以在channel调用close关闭方法以后，也应该把其他线程都结束掉。方法，将数据写入到缓冲区，具体什么时候发送数据有很多条件，比如执行flush方法就会发，还有就是数据达到了一定大小了也会发。客户端启动后，控制台可以输入消息，回车键后就发送消息到服务端。输入q，就关闭客户端的channel。方法，就是将数据写入缓冲区然后立刻发送。，同步处理关闭，调用。

服务端可以定义两个EventLoopGroup 第一个是boss,第二个是worker的。将accept事件和read,write事件分开处理。一个客户端对应一个channel，channel绑定了一个线程EventLoop，反过来一个EventLoop线程绑定了多个channel，那么当EventLoop将某一个channel上的数据交给handler处理时比较耗时，那么其它的跟这个EventLoop绑定的channel上的数据处理就会受到影响。

Netty使用的是多线程，发送数据的线程不是当前线程，如果断点右键设置默认是all, all代表当前线程停下来，剩下的其他线程也全都停下来了，那么发送数据的IO线程也停下来了，所以服务端收不到客户端发过来的数据。一旦客户端与服务端建立连接，nio线程（EventLoop）跟channel会建立一个绑定关系，关系一旦建立就不会改变。这个线程(EventLoop)就只负责这个channel的数据。从服务端的收到的数据可以看出，一个客户端都会绑定到同一个EventLoop线程给处理。

是一个单线程的执行器（同时维护了一个Selector），里面有run方法处理Channel上源源不断的io事件。1.继承java.util.concurrent.ScheduledExecutorService因此包含了线程池中所有的方法。2.继承netty自己的OrderedEventExecutor。

【代码】12.Netty入门案例。

Netty是一个异步的，基于事件驱动（采用多路复用技术Selector）的网络应用框架。用于快速开发可维护、高性能的网络服务器和客户端。IO事件发生时才会进行相应的处理。可连接，可读，可写事件。

不需要将数据放入到java的缓存中。小文件。

NIO 非阻塞IOBIO 阻塞IO。

单线程配合一个selector选择器管理多个channel上的事件。

【代码】10.处理write写事件。

网络编程中消息的长度是不太确定的，read方法读取字节数据到ByteBuffer中，ByteBuffer会有一个固定容量，单次超出容量的部分字节数据将会在下一次的ByteBuffer中，这样消息就会按照字节截断，出现消息边界问题。Type类型、Length长度、Value数据。在类型和长度已知的情况下，就可以方便的获取消息大小，分配合适的buffer，缺点是buffer需要提前分配，如果内容过大，则影响server的吞吐量。Http 2.0 是LTV格式。

把channel注册到Selector上，让Selector来管理多个channel。每次迭代的selectionKey处理完一定要从selectionKeys集合中删除。Selector都是要配合Channel的非阻塞模式下才能使用。处理客户端（正常或异常）断开连接的问题。

问题：非阻塞模式，会让线程一直在跑，太忙了，不能这么用。参考后续的Selector用法。read读取SocketChannel中的数据 是一个阻塞方法。accept等待连接 是一个阻塞方法。一个线程来处理多个连接显得力不从心。

Paths是工具类，用来获取Path实例。Path用来表示文件路径。

4.channel关闭调用close方法，不过调用FileInputStream，FileOutputStream或者RandomAccessFIle的close方法会间接调用channel的close方法。3.通过RandomAccessFile是否能读写根据构造RandomAccessFile时的读写模式决定。1.通过FileInputStream获取channel只能读。2.通过FileOutStream获取channel只能写。FileChannel只能工作在。

网络上有多条数据发送给服务端，数据之间使用了\n分隔，由于某种原因数据在接收时候，重新组合。