Netty组件-拦截器与ByteBuf

于 2024-05-21 12:11:19 发布
阅读量264 收藏 4
点赞数 5
文章标签： java nio 网络 学习
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_46863837/article/details/139089200
版权

Handler & Pipeline

ChannelHandler 用来处理 Channel 上的各种事件，分为入站、出站两种。所有 ChannelHandler 被连成一串，就是 Pipeline

  • 入站处理器通常是 ChannelInboundHandlerAdapter 的子类，主要用来读取客户端数据，写回结果
  • 出站处理器通常是 ChannelOutboundHandlerAdapter 的子类，主要对写回结果进行加工

打个比喻，每个 Channel 是一个产品的加工车间，Pipeline 是车间中的流水线，ChannelHandler 就是流水线上的各道工序，而后面要讲的 ByteBuf 是原材料，经过很多工序的加工：先经过一道道入站工序，再经过一道道出站工序最终变成产品
先搞清楚顺序，服务端

new ServerBootstrap()
    .group(new NioEventLoopGroup())
    .channel(NioServerSocketChannel.class)
    .childHandler(new ChannelInitializer<NioSocketChannel>() {
        protected void initChannel(NioSocketChannel ch) {
            ch.pipeline().addLast(new ChannelInboundHandlerAdapter(){
                @Override
                public void channelRead(ChannelHandlerContext ctx, Object msg) {
                    System.out.println(1);
                    ctx.fireChannelRead(msg); // 1
                }
            });
            ch.pipeline().addLast(new ChannelInboundHandlerAdapter(){
                @Override
                public void channelRead(ChannelHandlerContext ctx, Object msg) {
                    System.out.println(2);
                    ctx.fireChannelRead(msg); // 2
                }
            });
            ch.pipeline().addLast(new ChannelInboundHandlerAdapter(){
                @Override
                public void channelRead(ChannelHandlerContext ctx, Object msg) {
                    System.out.println(3);
                    ctx.channel().write(msg); // 3
                }
            });
            ch.pipeline().addLast(new ChannelOutboundHandlerAdapter(){
                @Override
                public void write(ChannelHandlerContext ctx, Object msg, 
                                  ChannelPromise promise) {
                    System.out.println(4);
                    ctx.write(msg, promise); // 4
                }
            });
            ch.pipeline().addLast(new ChannelOutboundHandlerAdapter(){
                @Override
                public void write(ChannelHandlerContext ctx, Object msg, 
                                  ChannelPromise promise) {
                    System.out.println(5);
                    ctx.write(msg, promise); // 5
                }
            });
            ch.pipeline().addLast(new ChannelOutboundHandlerAdapter(){
                @Override
                public void write(ChannelHandlerContext ctx, Object msg, 
                                  ChannelPromise promise) {
                    System.out.println(6);
                    ctx.write(msg, promise); // 6
                }
            });
        }
    })
    .bind(8080);

客户端

new Bootstrap()
    .group(new NioEventLoopGroup())
    .channel(NioSocketChannel.class)
    .handler(new ChannelInitializer<Channel>() {
        @Override
        protected void initChannel(Channel ch) {
            ch.pipeline().addLast(new StringEncoder());
        }
    })
    .connect("127.0.0.1", 8080)
    .addListener((ChannelFutureListener) future -> {
        future.channel().writeAndFlush("hello,world");
    });

服务器端打印顺序：1→2→3→6→5→4

  • ChannelInboundHandlerAdapter 是按照 addLast 的顺序执行的
  • 而 ChannelOutboundHandlerAdapter 是按照 addLast 的逆序执行的。

ChannelPipeline 的实现是一个 ChannelHandlerContext（包装了 ChannelHandler） 组成的双向链表
image.png

  1. 入站处理器中，ctx.fireChannelRead(msg) 是 调用下一个入站处理器
    • 如果注释掉 1 处代码，则仅会打印 1
    • 如果注释掉 2 处代码，则仅会打印 1 2
  2. 3 处的 ctx.channel().write(msg)会 从尾部开始触发 后续出站处理器的执行
    • 如果注释掉 3 处代码，则仅会打印 1 2 3
  3. 类似的，出站处理器中，ctx.write(msg, promise) 的调用也会 触发上一个出站处理器
    • 如果注释掉 6 处代码，则仅会打印 1 2 3 6
ctx.channel().write(msg) vs ctx.write(msg)
  • 都是触发出站处理器的执行
  • ctx.channel().write(msg) 从尾部开始查找出站处理器
  • ctx.write(msg) 是从当前节点找上一个出站处理器
  • 3 处的 ctx.channel().write(msg) 如果改为 ctx.write(msg) 仅会打印 1 2 3，因为节点3 之前没有其它出站处理器了
  • 6 处的 ctx.write(msg, promise) 如果改为 ctx.channel().write(msg) 会打印 1 2 3 6 6 6… 因为 ctx.channel().write() 是从尾部开始查找，结果又是节点6 自己

图1 - 服务端 pipeline 触发的原始流程，图中数字代表了处理步骤的先后次序
image.png

ByteBuf

是对字节数据的封装

1）创建

创建了一个默认的 ByteBuf（池化基于直接内存的 ByteBuf），初始容量是 10

ByteBuf buffer = ByteBufAllocator.DEFAULT.buffer(10);
log(buffer);

输出

read index:0 write index:0 capacity:10

其中 log 方法参考如下

private static void log(ByteBuf buffer) {
    int length = buffer.readableBytes();
    int rows = length / 16 + (length % 15 == 0 ? 0 : 1) + 4;
    StringBuilder buf = new StringBuilder(rows * 80 * 2)
        .append("read index:").append(buffer.readerIndex())
        .append(" write index:").append(buffer.writerIndex())
        .append(" capacity:").append(buffer.capacity())
        .append(NEWLINE);
    appendPrettyHexDump(buf, buffer);
    System.out.println(buf.toString());
}

2）直接内存 vs 堆内存

可以使用下面的代码来创建池化基于堆的 ByteBuf

ByteBuf buffer = ByteBufAllocator.DEFAULT.heapBuffer(10);

也可以使用下面的代码来创建池化基于直接内存的 ByteBuf

ByteBuf buffer = ByteBufAllocator.DEFAULT.directBuffer(10);
  • 直接内存创建和销毁的代价昂贵，但读写性能高（少一次内存复制），适合配合池化功能一起用
  • 直接内存对 GC 压力小，因为这部分内存不受 JVM 垃圾回收的管理，但也要注意及时主动释放

3）池化 vs 非池化

池化的最大意义在于可以重用 ByteBuf，优点有

  • 没有池化，则每次都得创建新的 ByteBuf 实例，这个操作对直接内存代价昂贵，就算是堆内存，也会增加 GC 压力
  • 有了池化，则可以重用池中 ByteBuf 实例，并且采用了与 jemalloc 类似的内存分配算法提升分配效率
  • 高并发时，池化功能更节约内存，减少内存溢出的可能

池化功能是否开启，可以通过下面的系统环境变量来设置

-Dio.netty.allocator.type={unpooled|pooled}
  • 4.1 以后，非 Android 平台默认启用池化实现，Android 平台启用非池化实现
  • 4.1 之前，池化功能还不成熟，默认是非池化实现

4）组成

ByteBuf 由四部分组成
image.png
最开始读写指针都在 0 位置

5）写入

方法列表，省略一些不重要的方法

方法签名含义备注
writeBoolean(boolean value)写入 boolean 值用一字节 01|00 代表 true|false
writeByte(int value)写入 byte 值
writeShort(int value)写入 short 值
writeInt(int value)写入 int 值Big Endian，即 0x250，写入后 00 00 02 50
writeIntLE(int value)写入 int 值Little Endian，即 0x250，写入后 50 02 00 00
writeLong(long value)写入 long 值
writeChar(int value)写入 char 值
writeFloat(float value)写入 float 值
writeDouble(double value)写入 double 值
writeBytes(ByteBuf src)写入 netty 的 ByteBuf
writeBytes(byte[] src)写入 byte[]
writeBytes(ByteBuffer src)写入 nio 的 ByteBuffer
int writeCharSequence(CharSequence sequence, Charset charset)写入字符串

注意

  • 这些方法的未指明返回值的，其返回值都是 ByteBuf，意味着可以链式调用
  • 网络传输，默认习惯是 Big Endian

先写入 4 个字节

buffer.writeBytes(new byte[]{1, 2, 3, 4});
log(buffer);

结果是

read index:0 write index:4 capacity:10
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 01 02 03 04                                     |....            |
+--------+-------------------------------------------------+----------------+

再写入一个 int 整数，也是 4 个字节

buffer.writeInt(5);
log(buffer);

结果是

read index:0 write index:8 capacity:10
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 01 02 03 04 00 00 00 05                         |........        |
+--------+-------------------------------------------------+----------------+

还有一类方法是 set 开头的一系列方法，也可以写入数据，但不会改变写指针位置

6）扩容

再写入一个 int 整数时，容量不够了（初始容量是 10），这时会引发扩容

buffer.writeInt(6);
log(buffer);

扩容规则是

  • 如何写入后数据大小未超过 512，则选择下一个 16 的整数倍，例如写入后大小为 12 ，则扩容后 capacity 是 16
  • 如果写入后数据大小超过 512，则选择下一个 2^n，例如写入后大小为 513，则扩容后 capacity 是 210=1024（29=512 已经不够了）
  • 扩容不能超过 max capacity 会报错

结果是

read index:0 write index:12 capacity:16
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 01 02 03 04 00 00 00 05 00 00 00 06             |............    |
+--------+-------------------------------------------------+----------------+

7）读取

例如读了 4 次，每次一个字节

System.out.println(buffer.readByte());
System.out.println(buffer.readByte());
System.out.println(buffer.readByte());
System.out.println(buffer.readByte());
log(buffer);

读过的内容，就属于废弃部分了，再读只能读那些尚未读取的部分

1
2
3
4
read index:4 write index:12 capacity:16
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 00 00 00 05 00 00 00 06                         |........        |
+--------+-------------------------------------------------+----------------+

如果需要重复读取 int 整数 5，怎么办？
可以在 read 前先做个标记 mark

buffer.markReaderIndex();
System.out.println(buffer.readInt());
log(buffer);

结果

5
read index:8 write index:12 capacity:16
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 00 00 00 06                                     |....            |
+--------+-------------------------------------------------+----------------+

这时要重复读取的话，重置到标记位置 reset

buffer.resetReaderIndex();
log(buffer);

这时

read index:4 write index:12 capacity:16
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 00 00 00 05 00 00 00 06                         |........        |
+--------+-------------------------------------------------+----------------+

还有种办法是采用 get 开头的一系列方法，这些方法不会改变 read index

8）retain & release

由于 Netty 中有堆外内存的 ByteBuf 实现，堆外内存最好是手动来释放，而不是等 GC 垃圾回收。

  • UnpooledHeapByteBuf 使用的是 JVM 内存，只需等 GC 回收内存即可
  • UnpooledDirectByteBuf 使用的就是直接内存了，需要特殊的方法来回收内存
  • PooledByteBuf 和它的子类使用了池化机制，需要更复杂的规则来回收内存

回收内存的源码实现，请关注下面方法的不同实现
protected abstract void deallocate()

Netty 这里采用了引用计数法来控制回收内存，每个 ByteBuf 都实现了 ReferenceCounted 接口

引用技术控制垃圾回收有风险–>《深入了解java虚拟机》45页左右

  • 每个 ByteBuf 对象的初始计数为 1
  • 调用 release 方法计数减 1，如果计数为 0，ByteBuf 内存被回收
  • 调用 retain 方法计数加 1，表示调用者没用完之前，其它 handler 即使调用了 release 也不会造成回收
  • 当计数为 0 时，底层内存会被回收，这时即使 ByteBuf 对象还在，其各个方法均无法正常使用

谁来负责 release 呢？
不是我们想象的（一般情况下）

ByteBuf buf = ...
try {
    ...
} finally {
    buf.release();
}

请思考，因为 pipeline 的存在，一般需要将 ByteBuf 传递给下一个 ChannelHandler，如果在 finally 中 release 了，就失去了传递性（当然，如果在这个 ChannelHandler 内这个 ByteBuf 已完成了它的使命，那么便无须再传递）
基本规则是，谁是最后使用者，谁负责 release，详细分析如下

  • 起点，对于 NIO 实现来讲，在 io.netty.channel.nio.AbstractNioByteChannel.NioByteUnsafe#read 方法中首次创建 ByteBuf 放入 pipeline（line 163 pipeline.fireChannelRead(byteBuf)）
  • 入站 ByteBuf 处理原则
    • 对原始 ByteBuf 不做处理，调用 ctx.fireChannelRead(msg) 向后传递，这时无须 release
    • 将原始 ByteBuf 转换为其它类型的 Java 对象，这时 ByteBuf 就没用了，必须 release
    • 如果不调用 ctx.fireChannelRead(msg) 向后传递，那么也必须 release
    • 注意各种异常，如果 ByteBuf 没有成功传递到下一个 ChannelHandler，必须 release
    • 假设消息一直向后传，那么 TailContext 会负责释放未处理消息（原始的 ByteBuf）
  • 出站 ByteBuf 处理原则
    • 出站消息最终都会转为 ByteBuf 输出，一直向前传，由 HeadContext flush 后 release
  • 异常处理原则
    • 有时候不清楚 ByteBuf 被引用了多少次，但又必须彻底释放，可以循环调用 release 直到返回 true

TailContext 释放未处理消息逻辑

// io.netty.channel.DefaultChannelPipeline#onUnhandledInboundMessage(java.lang.Object)
protected void onUnhandledInboundMessage(Object msg) {
    try {
        logger.debug(
            "Discarded inbound message {} that reached at the tail of the pipeline. " +
            "Please check your pipeline configuration.", msg);
    } finally {
        ReferenceCountUtil.release(msg);
    }
}

具体代码

// io.netty.util.ReferenceCountUtil#release(java.lang.Object)
public static boolean release(Object msg) {
    if (msg instanceof ReferenceCounted) {
        return ((ReferenceCounted) msg).release();
    }
    return false;
}

9）slice 对ByteBuf进行切片

对原始 ByteBuf 进行切片成多个 ByteBuf，但切片后的 ByteBuf 并没有发生内存复制，还是使用原始 ByteBuf 的内存，切片后的 ByteBuf 维护独立的 read，write 指针，这是【零拷贝】的体现之一
image.png

  • 进行slice后的ByteBuf和slice获取的ByteBuf都不能进行写操作，切片后的 max capacity 被固定为这个区间的大小，因此不能追加 write
  • 如果切片后的ByteBuf进行了修改，那么原始ByteBuf也会被修改，因为是共用同一块内存
  • 即使原始ByteBuf和切片后的ByteBuf进行了读，也只会改变其独立的读写指针，并不会影响其他ByteBuf

原始 ByteBuf 进行一些初始操作

ByteBuf origin = ByteBufAllocator.DEFAULT.buffer(10);
origin.writeBytes(new byte[]{1, 2, 3, 4});
origin.readByte();
System.out.println(ByteBufUtil.prettyHexDump(origin));

这时调用 slice 进行切片，无参 slice 是从原始 ByteBuf 的 read index 到 write index 之间的内容进行切片，切片后的 max capacity 被固定为这个区间的大小，因此不能追加 write

ByteBuf slice = origin.slice();
System.out.println(ByteBufUtil.prettyHexDump(slice));
// slice.writeByte(5); 如果执行，会报 IndexOutOfBoundsException 异常

如果原始 ByteBuf 再次读操作（又读了一个字节），这时的 slice 不受影响，因为它有独立的读写指针

origin.readByte();
System.out.println(ByteBufUtil.prettyHexDump(origin));
System.out.println(ByteBufUtil.prettyHexDump(slice));
  • 如果 slice 的内容发生了更改，这时，原始 ByteBuf 也会受影响，因为底层都是同一块内存
slice.setByte(2, 5);
System.out.println(ByteBufUtil.prettyHexDump(slice));
System.out.println(ByteBufUtil.prettyHexDump(origin));

10）duplicate

【零拷贝】的体现之一，就好比截取了原始 ByteBuf 所有内容，并且没有 max capacity 的限制，也是与原始 ByteBuf 使用同一块底层内存，只是读写指针是独立的
image.png

11）copy

会将底层内存数据进行深拷贝，因此无论读写，都与原始 ByteBuf 无关

12）CompositeByteBuf

【零拷贝】的体现之一，可以将多个 ByteBuf 合并为一个逻辑上的 ByteBuf，避免拷贝
有两个 ByteBuf 如下

ByteBuf buf1 = ByteBufAllocator.DEFAULT.buffer(5);
buf1.writeBytes(new byte[]{1, 2, 3, 4, 5});
ByteBuf buf2 = ByteBufAllocator.DEFAULT.buffer(5);
buf2.writeBytes(new byte[]{6, 7, 8, 9, 10});
System.out.println(ByteBufUtil.prettyHexDump(buf1));
System.out.println(ByteBufUtil.prettyHexDump(buf2));

输出

         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 01 02 03 04 05                                  |.....           |
+--------+-------------------------------------------------+----------------+
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 06 07 08 09 0a                                  |.....           |
+--------+-------------------------------------------------+----------------+

现在需要一个新的 ByteBuf，内容来自于刚才的 buf1 和 buf2，如何实现？
方法1：

ByteBuf buf3 = ByteBufAllocator.DEFAULT
    .buffer(buf1.readableBytes()+buf2.readableBytes());
buf3.writeBytes(buf1);
buf3.writeBytes(buf2);
System.out.println(ByteBufUtil.prettyHexDump(buf3));

结果

         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 01 02 03 04 05 06 07 08 09 0a                   |..........      |
+--------+-------------------------------------------------+----------------+

这种方法好不好？回答是不太好，因为进行了数据的内存复制操作

方法2：

CompositeByteBuf buf3 = ByteBufAllocator.DEFAULT.compositeBuffer();
// true 表示增加新的 ByteBuf 自动递增 write index, 否则 write index 会始终为 0
buf3.addComponents(true, buf1, buf2);

结果是一样的

         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 01 02 03 04 05 06 07 08 09 0a                   |..........      |
+--------+-------------------------------------------------+----------------+

CompositeByteBuf 是一个组合的 ByteBuf，它内部维护了一个 Component 数组，每个 Component 管理一个 ByteBuf，记录了这个 ByteBuf 相对于整体偏移量等信息，代表着整体中某一段的数据。

  • 优点，对外是一个虚拟视图，组合这些 ByteBuf 不会产生内存复制
  • 缺点，复杂了很多，多次操作会带来性能的损耗

13）Unpooled

Unpooled 是一个工具类，类如其名，提供了非池化的 ByteBuf 创建、组合、复制等操作
这里仅介绍其跟【零拷贝】相关的 wrappedBuffer 方法，可以用来包装 ByteBuf

ByteBuf buf1 = ByteBufAllocator.DEFAULT.buffer(5);
buf1.writeBytes(new byte[]{1, 2, 3, 4, 5});
ByteBuf buf2 = ByteBufAllocator.DEFAULT.buffer(5);
buf2.writeBytes(new byte[]{6, 7, 8, 9, 10});

// 当包装 ByteBuf 个数超过一个时, 底层使用了 CompositeByteBuf
ByteBuf buf3 = Unpooled.wrappedBuffer(buf1, buf2);
System.out.println(ByteBufUtil.prettyHexDump(buf3));

输出

         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 01 02 03 04 05 06 07 08 09 0a                   |..........      |
+--------+-------------------------------------------------+----------------+

也可以用来包装普通字节数组，底层也不会有拷贝操作

ByteBuf buf4 = Unpooled.wrappedBuffer(new byte[]{1, 2, 3}, new byte[]{4, 5, 6});
System.out.println(buf4.getClass());
System.out.println(ByteBufUtil.prettyHexDump(buf4));

输出

class io.netty.buffer.CompositeByteBuf
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 01 02 03 04 05 06                               |......          |
+--------+-------------------------------------------------+----------------+
💡 ByteBuf 优势
  • 池化 - 可以重用池中 ByteBuf 实例，更节约内存，减少内存溢出的可能
  • 读写指针分离，不需要像 ByteBuffer 一样切换读写模式
  • 可以自动扩容
  • 支持链式调用，使用更流畅
  • 很多地方体现零拷贝，例如 slice、duplicate、CompositeByteBuf
PangPiLoLo
关注
  • 5
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Netty源码解析 -- ChannelPipeline机制与读写过程
binecy
11-07 351
本文继续阅读Netty源码，解析ChannelPipeline事件传播原理，以及Netty读写过程。 源码分析基于Netty 4.1 ChannelPipeline Netty中的ChannelPipeline可以理解为拦截器链，维护了一个ChannelHandler链表，ChannelHandler即具体拦截器，可以在读写过程中，对数据进行处理。 ChannelHandler也可以分为两类。 ChannelInboundHandler，监控Channel状态变化，如channelActive，channe
Netty源码解析 -- 服务端启动过程
binecy
11-01 286
本文通过阅读Netty源码，解析Netty服务端启动过程。 源码分析基于Netty 4.1 Netty是一个高性能的网络通信框架，支持NIO，OIO等多种IO模式。通常，我们都是使用NIO模式，该系列文章也是解析Netty下NIO模式的实现。 首先，看一个NIO网络通信示意图 Netty中NIO网络通信过程在此基础上实现，下面来看一下具体实现。 Channel 首先，看一下Netty中的通道Channel，它代表了一个能完成IO操作的通道，提供read, write, connect, bind等方法。
netty 拦截器_以官方例子开启我们的netty源码之旅
weixin_39633252的博客
12-23 686
EchoClient类EventLoopGroupgroup=newNioEventLoopGroup();try{Bootstrapb=newBootstrap();b.group(group).channel(NioSocketChannel.class).option(ChannelOption.TCP_NODELAY,tru...
netty socket超时设置_Netty 学习和进阶策略
weixin_39717704的博客
11-28 809
背景Netty 框架的特点Netty 的一个特点就是入门相对比较容易，但是真正掌握并精通是非常困难的，原因有如下几个：涉及的知识面比较广：Netty 作为一个高性能的 NIO 通信框架，涉及到的知识点包括网络通信、多线程编程、序列化和反序列化、异步和同步编程模型、SSL/TLS 安全、内存池、HTTP、MQTT 等各种协议栈，这些知识点在 Java 语言中本身就是难点和重点，如果对这些基...
netty 简单IM 容易扩展 方便自定义拦截
walker的专栏
04-15 630
下面是父类AbstractWebSocketContext代码，这块就是执行启动流程。/*** 抽象的websocket，用来初始化加载拦截器、处理器*/@Slf4jlog.info("加载handler...");log.info("加载filter...");}else{log.warn("已经初始化过");//只允许加载一次//加载所有拦截器try {//排序@Override});
netty实战-netty.zip
11-07
2. **Channel与Bootstrap**：Channel是Netty中的核心组件，代表一个网络连接，它提供了读写数据的方法。Bootstrap是启动器，用于配置并启动服务器或客户端的连接。 3. **ByteBuf**：Netty自定义的缓冲区，优于Java...
Netty源码教程-3
10-31
ChannelHandler是Netty中的核心组件，它定义了处理I/O事件和拦截消息的接口。ChannelHandlerContext是ChannelHandler的上下文对象，提供了一种方法来与ChannelHandler链进行交互，如触发事件或向其他处理器传递消息...
Netty简介 Netty线程模型和EventLoop Codec编码与解码 ByteBuf容器
08-11
ChannelHandler是Netty中的处理逻辑组件，负责处理I/O事件或拦截数据传输。每个Handler都有一个特定的任务，如解码、业务逻辑处理、异常处理等。ChannelPipeline是Handler的容器，它按照添加的顺序执行Handler，形成...
精通并发与netty 无加密视频
04-13
第65讲：ChannelPipeline创建时机与高级拦截过滤器模式的运用 第66讲：Netty常量池实现及ChannelOption与Attribute作用分析 第67讲：Channel与ChannelHandler及ChannelHandlerContext之间的关系分析 第68讲：...
Netty框架实战应用-SchNetty.zip
最新发布
01-29
- **ChannelHandler**：处理I/O事件或拦截I/O操作，是Netty处理逻辑的核心组件，可以链式组合多个Handler。 - **ByteBuf**：Netty自定义的缓冲区，相比Java NIO的ByteBuffer，提供了更高效且安全的数据读写。 2. ...
拦截器机制及其实现原理
09-20
拦截器是Struts2框架的核心组成部分，通过本章的学习，应该掌握如下知识点： 了解AOP设计思想。 能够使用AOP设计思路，分离横切关注点 掌握Java中提供的动态代理方式实现拦截 了解拦截在开发中的意义 掌握Struts2框架的拦截机制和实现原理 掌握在Struts2应用中如何定义、配置及使用拦截器和拦截器栈 掌握拦截器的方法过滤
Netty Channel IO 事件拦截器, 自定义握手器 最佳实践
fbbwht的博客
12-13 343
如果后续恢复所有拦截器, 则可以调用ChannelInterceptors.resetAll(), 即可恢复所有拦截器, 如果只需要恢复单个拦截器直接从ChannelPipeline中根据名字获取handler, 强转之后调用reset即可。接触过物联网的小伙伴都知道, 很多私有协议在正式通信前都需要进行握手这一操作, 如果握手失败将无法进行后续的业务通信。例如在通信前可能需要确认设备型号, 协议版本, 元信息版本, 设备状态地域等等, 这些都是必须在业务通信前要确定。后续框架升级会更新此文档。
【Netty】使用 Netty 开发 HTTP 服务器 ( HTTP 请求过滤 )
让 学习 成为一种 习惯 ( 韩曙亮 の 技术博客 )
06-05 1954
一、 HTTP 服务器请求过滤功能 、 1 . HTTP 服务器资源请求过滤 、 2 . HTTP 请求过滤方法 、 二、 HTTP 服务器 ( 资源过滤 ) 代码实现 、 1 . 服务器主程序 、 2 . 服务器业务逻辑处理类 、 3 . 执行结果 、
netty自定义url过滤器抛引用异常
baidu_29468831的博客
10-20 2886
问题描述 使用netty构造服务端，使用浏览器在地址栏输入访问地址时，除了会发送目标url之外，浏览器还会额外发送一个url–>/favicon.ico，以前是在一个业务处理的hanlder中使用if判断uri，如果uri是这个的话，就不去执行业务逻辑，但是这样的话会造成业务代码与判断逻辑的耦合。所以使用一个新的handler去处理，利用netty的执行连完成后序的业务。 handler的构造执
处理器拦截器（HandlerInterceptor）详解
热门推荐
立志变成java巨头
03-19 1万+
简介 SpringWebMVC的处理器拦截器，类似于Servlet开发中的过滤器Filter，用于处理器进行预处理和后处理。 应用场景 1、日志记录，可以记录请求信息的日志，以便进行信息监控、信息统计等。 2、权限检查：如登陆检测，进入处理器检测是否登陆，如果没有直接返回到登陆页面。 3、性能监控：典型的是慢日志。 HandlerInterceptor public interface H...
Netty的那点事儿
weixin_33965305的博客
12-02 561
Netty是一个基于异步与事件驱动的网络应用程序框架，它支持快速与简单地开发可维护的高性能的服务器与客户端。 所谓事件驱动就是由通过各种事件响应来决定程序的流程，在Netty中到处都充满了异步与事件驱动，这种特点使得应用程序可以以任意的顺序响应在任意的时间点产生的事件，它带来了非常高的可伸缩性，让你的应用可以在需要处理的工作不断增长时，通过某种可行的方式或者扩大它的处理能力来适应这种增长。 Ne...
io.netty netty-handler版本时间
05-26
以下是io.netty netty-handler版本与时间的列表： - 5.0.0.Alpha1 - 2014年10月 - 5.0.0.Alpha2 - 2014年11月 - 5.0.0.Alpha3 - 2015年3月 - 5.0.0.Alpha4 - 2015年7月 - 5.0.0.Alpha5 - 2015年12月 - 5.0.0.Alpha6...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值