Java NIO框架Netty教程(五) 消息收发次数不匹配的问题

最新推荐文章于 2024-12-07 03:55:53 发布
最新推荐文章于 2024-12-07 03:55:53 发布
阅读量702 收藏
点赞数
分类专栏： 工作 文章标签： java Netty

  • 本来周末是最好的学习时间，不过这周末收房子，可想而知事情自然也不会少。这段时间的周末，可能很少有时间学习了。见缝插针吧。

    不说废话了，好好学习。上回通过代码理解了Netty底层信息的流的传递机制，不过只是一个感性上的认识。教会你应该如何使用和使用的时候应该注意的方面。但是有一些细节的问题，并没有提及。比如在上回（《Java NIO框架Netty教程（四）- ChannelBuffer》http://www.it165.net/pro/html/201207/3198.html）的代码里，我们通过:


    view source print ?
    1. private void sendMessageByFrame(ChannelStateEvent e) {
    2. String msgOne = "Hello, ";
    3. String msgTwo = "I'm ";
    4. String msgThree = "client.";
    5. e.getChannel().write(tranStr2Buffer(msgOne));
    6. e.getChannel().write(tranStr2Buffer(msgTwo));
    7. e.getChannel().write(tranStr2Buffer(msgThree));
    8. }

    这样的方式，连续返送三次消息。但是如果你在服务端进行接收计数的话，你会发现，大部分时候都是接收到两次的事件请求。不过消息都是完整的。网上也有人提到过，进行10000次的连续放松，往往接受到的消息个数是999X的，总是就是消息数目上不匹配，这又是为何呢？笔者也只能通过阅读Netty的源码来找原因，我们一起来慢慢分析吧www.it165.net。

    起点自然是选择在e.getChannel().writer()方法上。一路跟踪首先来到了：AbstractNioWorker.java类


    view source print ?
    001. protected void write0(AbstractNioChannel<?> channel) {
    002. boolean open = true;
    003. boolean addOpWrite = false;
    004. boolean removeOpWrite = false;
    005. boolean iothread = isIoThread(channel);
    006.  
    007. long writtenBytes = 0;
    008.  
    009. final SocketSendBufferPool sendBufferPool = this.sendBufferPool;
    010. final WritableByteChannel ch = channel.channel;
    011. final Queue<MessageEvent> writeBuffer = channel.writeBufferQueue;
    012. final int writeSpinCount = channel.getConfig().getWriteSpinCount();
    013. synchronized (channel.writeLock) {
    014. channel.inWriteNowLoop = true;
    015. for (;;) {
    016. MessageEvent evt = channel.currentWriteEvent;
    017. SendBuffer buf;
    018. if (evt == null) {
    019. if ((channel.currentWriteEvent = evt = writeBuffer.poll()) == null) {
    020. removeOpWrite = true;
    021. channel.writeSuspended = false;
    022. break;
    023. }
    024.  
    025. channel.currentWriteBuffer = buf = sendBufferPool.acquire(evt.getMessage());
    026. } else {
    027. buf = channel.currentWriteBuffer;
    028. }
    029.  
    030. ChannelFuture future = evt.getFuture();
    031. try {
    032. long localWrittenBytes = 0;
    033. for (int i = writeSpinCount; i > 0; i --) {
    034. localWrittenBytes = buf.transferTo(ch);
    035. if (localWrittenBytes != 0) {
    036. writtenBytes += localWrittenBytes;
    037. break;
    038. }
    039. if (buf.finished()) {
    040. break;
    041. }
    042. }
    043.  
    044. if (buf.finished()) {
    045. // Successful write - proceed to the next message.
    046. buf.release();
    047. channel.currentWriteEvent = null;
    048. channel.currentWriteBuffer = null;
    049. evt = null;
    050. buf = null;
    051. future.setSuccess();
    052. } else {
    053. // Not written fully - perhaps the kernel buffer is full.
    054. addOpWrite = true;
    055. channel.writeSuspended = true;
    056.  
    057. if (localWrittenBytes > 0) {
    058. // Notify progress listeners if necessary.
    059. future.setProgress(
    060. localWrittenBytes,
    061. buf.writtenBytes(), buf.totalBytes());
    062. }
    063. break;
    064. }
    065. } catch (AsynchronousCloseException e) {
    066. // Doesn't need a user attention - ignore.
    067. } catch (Throwable t) {
    068. if (buf != null) {
    069. buf.release();
    070. }
    071. channel.currentWriteEvent = null;
    072. channel.currentWriteBuffer = null;
    073. buf = null;
    074. evt = null;
    075. future.setFailure(t);
    076. if (iothread) {
    077. fireExceptionCaught(channel, t);
    078. } else {
    079. fireExceptionCaughtLater(channel, t);
    080. }
    081. if (t instanceof IOException) {
    082. open = false;
    083. close(channel, succeededFuture(channel));
    084. }
    085. }
    086. }
    087. channel.inWriteNowLoop = false;
    088.  
    089. // Initially, the following block was executed after releasing
    090. // the writeLock, but there was a race condition, and it has to be
    091. // executed before releasing the writeLock:
    092. //
    093. //     https://issues.jboss.org/browse/NETTY-410
    094. //
    095. if (open) {
    096. if (addOpWrite) {
    097. setOpWrite(channel);
    098. } else if (removeOpWrite) {
    099. clearOpWrite(channel);
    100. }
    101. }
    102. }
    103. if (iothread) {
    104. fireWriteComplete(channel, writtenBytes);
    105. } else {
    106. fireWriteCompleteLater(channel, writtenBytes);
    107. }
    108. }

    这里， buf.transferTo(ch);的就是调用底层WritableByteChannel的write方法，把buffer写到管道里，传递过去。通过Debug可以看到，没调用一次这个方法，服务端的messageReceived方法就会进入断点一次。当然这个也只是表相，或者说也是在预料之内的。因为笔者从开始就怀疑是连续写入过快导致的问题，所以测试过每次write后停顿1秒。再write下一次。结果一切正常。

     
    那么我们跟到这里的意义何在呢？笔者的思路是先证明不是在write端出现的写覆盖的问题，这样就可以从read端寻找问题。这里笔者也在这里加入了一个计数，测试究竟transferTo了几次。结果确实是3次。


    view source print ?
    1. for (int i = writeSpinCount; i > 0; i --) {
    2. localWrittenBytes = buf.transferTo(ch);
    3. System.out.println(++count);

    接下来就从接收端找找原因，在NioWorker的read方法，实现如下：
    view source print ?
    01. @Override
    02. protected boolean read(SelectionKey k) {
    03. final SocketChannel ch = (SocketChannel) k.channel();
    04. final NioSocketChannel channel = (NioSocketChannel) k.attachment();
    05.  
    06. final ReceiveBufferSizePredictor predictor =
    07. channel.getConfig().getReceiveBufferSizePredictor();
    08. final int predictedRecvBufSize = predictor.nextReceiveBufferSize();
    09.  
    10. int ret = 0;
    11. int readBytes = 0;
    12. boolean failure = true;
    13.  
    14. ByteBuffer bb = recvBufferPool.acquire(predictedRecvBufSize);
    15. try {
    16. while ((ret = ch.read(bb)) > 0) {
    17. readBytes += ret;
    18. if (!bb.hasRemaining()) {
    19. break;
    20. }
    21. }
    22. failure = false;
    23. } catch (ClosedChannelException e) {
    24. // Can happen, and does not need a user attention.
    25. } catch (Throwable t) {
    26. fireExceptionCaught(channel, t);
    27. }
    28.  
    29. if (readBytes > 0) {
    30. bb.flip();
    31.  
    32. final ChannelBufferFactory bufferFactory =
    33. channel.getConfig().getBufferFactory();
    34. final ChannelBuffer buffer = bufferFactory.getBuffer(readBytes);
    35. buffer.setBytes(0, bb);
    36. buffer.writerIndex(readBytes);
    37.  
    38. recvBufferPool.release(bb);
    39.  
    40. // Update the predictor.
    41. predictor.previousReceiveBufferSize(readBytes);
    42.  
    43. // Fire the event.
    44. fireMessageReceived(channel, buffer);
    45. } else {
    46. recvBufferPool.release(bb);
    47. }
    48.  
    49. if (ret < 0 || failure) {
    50. k.cancel(); // Some JDK implementations run into an infinite loop without this.
    51. close(channel, succeededFuture(channel));
    52. return false;
    53. }
    54.  
    55. return true;
    56. }

    在这个方法的外层是一个循环，不停的遍历，如果有SelectionKey k存在，则进入此方法读取buffer中的数据。这个SelectionKey 区分只是一种类型，这个设计到Java NIO中的Seletor机制，这个笔者准备下讲穿插一下。属于Netty底层的一个重要的机制。

    messageReceived事件的触发，是在读取完当前缓冲池中所有的信息之后在触发的。这倒是可以解释，为什么即使我们收到事件的次数少，但是消息是完整的。
     
    从目前来看，Netty通过Java 的NIO机制传递数据，数据读写跟事件没有严格的绑定机制。数据是以流的形式独立存在，读写都有一个缓冲池。
     
    不过，这些还远未解决笔者的疑惑。笔者决定先了解一下Seletor机制，再回头来探索这个问题。
     
    待解决……

    下一篇：Java NIO框架Netty教程(六) Java NIO Selector模式      http://www.it165.net/pro/html/201207/3260.html

全方位技术攻关 | 带你建立Netty网络编程技术栈 ——【进阶篇】​传统NIO编程模型与实现细节探讨（3）[通信篇]
世界上并没有完美的程序，但是我们并不因此而沮丧，因为写程序就是一个不断追求完美的过程。
03-26 44
在掌握了FileChannel与Buffer的核心机制后，让我们将视野转向更复杂的网络通信领域。作为NIO三大核心组件之一，SocketChannel通过其独特的非阻塞特性，彻底改变了传统IO模型的交互范式。传统BIO模型中，套接字的accept/read/write操作可能因等待资源而永久阻塞线程，导致线程利用率低下。例如，在一个非阻塞式ServerSocketChannel上调用accept()方法，如果有连接请求来了，则返回客户端SocketChannel，否则返回null。NIO通过配置，使这些关键
Netty
最新发布
12-29 1077
粘包问题是指发送方发送的多个数据包在接收方被合并成一个数据包接收。粘包问题通常发生在发送方发送的数据包较小且频繁的情况下。比如发送方发送了两个数据包A和B，数据包A的内容是"Hello"，数据包B的内容是"World"。由于TCP是基于字节流的协议，接收方可能会将这两个数据包合并成一个数据包接收，内容为"HelloWorld"。粘包问题的原因主要有两个：1.发送方发送的数据包较小且频繁：当发送方发送的数据包较小且频繁时，TCP可能会将多个数据包合并成一个数据包发送，导致接收方接收到合并的数据包。
Java NIO框架Netty教程（五）- 消息收发次数不匹配的问题
superviser3000的博客
08-18 282
周末是最好的学习时间，不过这周末收房子，可想而知事情自然也不会少。这段时间的周末，可能很少有时间学习了。见缝插针吧。 不说废话了，好好学习。上回通过代码理解了Netty底层信息的流的传递机制，不过只是一个感性上的认识。教会你应该如何使用和使用的时候应该注意的方面。但是有一些细节的问题，并没有提及。比如在《Java NIO框架Netty教程（四）- ChannelBuffer》的代码里，我们通过:...
java Netty 之消息收发次数不匹配额问题
yjc0403的博客
03-13 1021
java Netty 之消息收发次数不匹配额问题     问题   在前面代码中，分三次发送信息：     private void sendMessageByFrame(ChannelStateEvent e) { String msgOne = "Hello, "; String msgTwo = "I'm "; String msgThree = "clien...
Java NIO框架Netty教程(七)-再谈收发信息次数问题
superviser3000的博客
08-18 240
在《Java NIO框架Netty教程（五）- 消息收发次数不匹配的问题》里我们试图分析一个消息收发次数不匹配的问题。当时笔者还是心存疑惑的。所以决定先学习一下Java NIO的Selector机制。 经过简单的了解，笔者大胆的猜测和”武断”一下该问题的原因。 首先，Selector机制让我们注册一个感兴趣的事件，然后只要有该事件发生，就会传递给接收端。我们写了三次，接收端一定会出发三次的。 ...
Netty进阶
Yellow_Star的博客
05-23 840
魔数，用来在第一时间判定是否是无效数据包版本号，可以支持协议的升级序列化算法，消息正文到底采用哪种序列化反序列化方式，可以由此扩展，例如：json、protobuf、hessian、jdk指令类型，是登录、注册、单聊、群聊… 跟业务相关请求序号，为了双工通信，提供异步能力正文长度消息正文。
Netty 框架——protobuf的使用
dhrmt的博客
12-07 1113
Netty 默认使用 Java 序列化，但其性能和跨语言支持存在一定问题，特别是 Java 序列化性能较低且无法在不同编程语言间互通。因此，使用 Protobuf（Protocol Buffers）替代 Java 原生序列化能够提高效率并支持跨语言通信。成功实现客户端与服务器间基于 Protobuf 的高效通信，服务器接收到客户端消息后打印其 ID 和 Name，客户端接收到服务器的响应消息。Netty 是一个高性能、异步事件驱动的网络通信框架，它提供了丰富的编码解码器（codec），如。
服务器_网络通信(TCP/IP网络模型，HTTP（URL），Socket，WebSocket,BIO，NIO，AIO，Mina框架，Netty框架)
binge_kong的博客
09-21 1483
通信协议 客户端和服务器之间通信所需要遵循的某种规则 网络模型OSI(Open System Interconnnection) 该模型把把网络通信分为7层（物理层，数据链路层，网络层，传输层，会话层，表示层，应用层），是设计和描述计算机网络通信的基本架构。 在实际应用中一般只是用到4层。 TCP/IP网络模型 这个模型是一系列网络协议的总层，是互联网的基础。 4个层次 链接层 对应的...
Netty - Socket.io
aRtHuR1207的博客
09-25 3179
注意，这里存在一个关键点：需要设置自定义存储工厂，以便获取 AuthorizationResult 中的 storeParams。在本示例中，我们采用 Redisson 作为存储工厂。修改nacos配置socketio:# redis服务redis:sentinel:更新socketio启动配置类/***/@Slf4j@Autowired@Autowired@Autowired@Autowired@Autowired。
基于Netty实现可靠消息传递的重发机制详解
微笑听雨
06-19 4961
本文详细介绍了如何使用Netty框架实现可靠的消息传递机制，特别是消息的重发机制。Netty本身没有内置重发功能，但通过定时任务、消息确认和重试策略，我们可以构建一个健壮的重发系统。示例代码包括客户端和服务器端的实现，展示了如何在发送消息失败或未收到确认时进行重发，确保消息可靠传递。这一机制对于需要高可靠性的数据传输应用非常有用。
Netty 粘包和拆包详解
骏马逸动，心随你动的博客
09-18 1175
1. 前言 前面几个章节主要解析了 Netty 的编码、解码问题，那么是否有了编解码器，我们的 Netty 通信就能正常了呢？ TCP 协议在传输数据时没有办法判断数据是什么时候结束的，它无法识别一段完整的信息，因此可能会导致接受到的数据和发送时的数据不一致的情况。因此需要人为的指定一种规范的协议，从而保证数据的安全性，比如：我们所熟悉的 HTTP 协议。 本节内容，我们主要需要以下两点知识 TCP 拆包、粘包的原因； TCP 拆包、粘包的解决方案。 2. 学习目的 拆包、粘包在 TCP 协
NIO之Channel
赶路人儿
02-23 1303
1、基本概念 Java NIO中，channel用于数据的传输，类似于传统BIO中的流（IOStream）的概念。 我们都知道，系统的I/O都分为两个阶段： 等待就绪：从IO设备将数据读取到内核中的过程； 操作：将数据从内核复制到进程缓冲区的过程。 Channel就可以看作是IO设备和内核区域的一个桥梁，凡是与IO设备交互都必须通过channel，而Buffer就可以看作是内核缓冲区。这样...
怎么理解 Java NIO 里面的 attachment ?
龚小帅的博客
08-10 1227
来数据的时候, 再次拿出这个容器, 继续放数据, 那么这个容器怎么可以容易的每次都有数据的时候拿到呢?去读取的, 当有部分数据到达的时候, 它就帮你读取, 读完来的数据之后, 还没读取到。在读操作上, 不去干其它事情, 当来一个字节/字符的时候, 它就读一个, 直到返回。有数据, 就通过它拿到之前装有半成品的容器, 那么可以继续放了., 再次等待它接下来的数据, 那么刚才读取的数据放哪里呢?方法附在上面, 下次当有数据来的时候, 通过。的时候, 读线程直接返回, 是由一个专门的。知道有数据的, 一旦。...
Netty 消息接收类故障案例分析
默默草
02-19 6396
背景 消息接收类故障 尽管 Netty 应用广泛，非常成熟，但是由于对 Netty 底层机制不太了解，用户在实际使用中还是会经常遇到各种问题，大部分问题都是业务使用不当导致的。Netty 使用者需要学习 Netty 的故障定位技巧，以便出了问题能够独立、快速的解决。 在各种故障中，Netty 服务端接收不到客户端消息是一种比较常见的异常，大部分场景下都是用户使用不当导致的，下面我们对常见的消息接收...
netty服务器收不到消息,Netty业务Handler接收不到消息案例
weixin_29195615的博客
08-10 2324
问题：我的服务碰到一个问题，经常有请求上来到MessageDecoder就结束了，没有继续往LogicServerHandler里面送，觉得很奇怪，是不是线程池满了？我想请教：1、 netty 5如何打印executor线程的占用情况，如空闲线程数？2、 executor设置的大小一般如何进行计算的？业务代码如下所示：解答从服务端初始化代码来看，并没有什么问题，业务LogicServerHandl...
netty服务器收不到消息,用netty写了服务端但是一直接收不到消息
weixin_39693438的博客
08-10 3008
用netty简单作了个服务端用户接收客户端信息，但是无法接收客户端发送过来的信息，channelRead打断点一直进不去，服务端发送过去的客户端倒是能接收代码如下public class MyChannelInitializer extends ChannelInitializer {@Overrideprotected void initChannel(SocketChannel channel...
Netty高性能之道
ZERO
05-05 2288
转载自：http://www.infoq.com/cn/articles/netty-high-performance 1. 异步非阻塞通信        在IO编程过程中，当需要同时处理多个客户端接入请求时，可以利用多线程或者IO多路复用技术进行处理。IO多路复用技术通过把多个IO的阻塞复用 到同一个select的阻塞上，从而使得系统在单线程的情况下可以同时处理多个客户端请求。与传统的多
netty笔记（1）--ctx.write()和channel().write()的区别
forcht
08-10 8054
刚学netty,一些细节上还不是很清楚，发现踩了很多坑。一点一点记录下来。 先看一个小demo bootstrap.group(bossGroup,workerGroup) .channel(NioServerSocketChannel.class) .localAddress(new InetSocket...
Java NIO框架Netty入门教程：HelloNetty
"Java NIO框架Netty教程" 在Java编程中，Netty是一个非常流行的、高性能的网络应用框架，它基于Java NIO（非阻塞I/O）设计，广泛用于构建高并发、低延迟的网络服务。Netty简化了网络编程的复杂性，提供了丰富的API...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值