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

最新推荐文章于 2024-12-29 23:45:27 发布
转载 最新推荐文章于 2024-12-29 23:45:27 发布 · 728 阅读 · 0
文章标签：

#java #Netty

本文深入探讨了Netty框架下数据流传递的底层机制，通过分析ChannelBuffer类的方法，揭示了消息传递过程中可能出现的问题，并通过实验验证了连续快速发送消息时接收端计数异常的原因。同时，文章解释了Java NIO机制如何实现数据的独立流式传递，以及Netty如何利用缓冲池管理数据读写过程。最后，文章指出Netty与Java NIO的结合为高效的数据传输提供了有力的支持。

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

    不说废话了，好好学习。上回通过代码理解了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 379
在掌握了FileChannel与Buffer的核心机制后，让我们将视野转向更复杂的网络通信领域。作为NIO三大核心组件之一，SocketChannel通过其独特的非阻塞特性，彻底改变了传统IO模型的交互范式。传统BIO模型中，套接字的accept/read/write操作可能因等待资源而永久阻塞线程，导致线程利用率低下。例如，在一个非阻塞式ServerSocketChannel上调用accept()方法，如果有连接请求来了，则返回客户端SocketChannel，否则返回null。NIO通过配置，使这些关键
Java NIO框架Netty教程（五）- 消息收发次数不匹配的问题
superviser3000的博客
08-18 304
周末是最好的学习时间，不过这周末收房子，可想而知事情自然也不会少。这段时间的周末，可能很少有时间学习了。见缝插针吧。 不说废话了，好好学习。上回通过代码理解了Netty底层信息的流的传递机制，不过只是一个感性上的认识。教会你应该如何使用和使用的时候应该注意的方面。但是有一些细节的问题，并没有提及。比如在《Java NIO框架Netty教程（四）- ChannelBuffer》的代码里，我们通过:...
java Netty 之消息收发次数不匹配额问题
yjc0403的博客
03-13 1080
java Netty 之消息收发次数不匹配额问题     问题   在前面代码中，分三次发送信息：     private void sendMessageByFrame(ChannelStateEvent e) { String msgOne = "Hello, "; String msgTwo = "I'm "; String msgThree = "clien...
Java NIO框架Netty教程(七)-再谈收发信息次数问题
superviser3000的博客
08-18 282
在《Java NIO框架Netty教程（五）- 消息收发次数不匹配的问题》里我们试图分析一个消息收发次数不匹配的问题。当时笔者还是心存疑惑的。所以决定先学习一下Java NIO的Selector机制。 经过简单的了解，笔者大胆的猜测和”武断”一下该问题的原因。 首先，Selector机制让我们注册一个感兴趣的事件，然后只要有该事件发生，就会传递给接收端。我们写了三次，接收端一定会出发三次的。 ...
基于Netty实现可靠消息传递的重发机制详解
微笑听雨
06-19 5442
本文详细介绍了如何使用Netty框架实现可靠的消息传递机制，特别是消息的重发机制。Netty本身没有内置重发功能，但通过定时任务、消息确认和重试策略，我们可以构建一个健壮的重发系统。示例代码包括客户端和服务器端的实现，展示了如何在发送消息失败或未收到确认时进行重发，确保消息可靠传递。这一机制对于需要高可靠性的数据传输应用非常有用。
Netty 框架——protobuf的使用
dhrmt的博客
12-07 1279
Netty 默认使用 Java 序列化，但其性能和跨语言支持存在一定问题，特别是 Java 序列化性能较低且无法在不同编程语言间互通。因此，使用 Protobuf（Protocol Buffers）替代 Java 原生序列化能够提高效率并支持跨语言通信。成功实现客户端与服务器间基于 Protobuf 的高效通信，服务器接收到客户端消息后打印其 ID 和 Name，客户端接收到服务器的响应消息。Netty 是一个高性能、异步事件驱动的网络通信框架，它提供了丰富的编码解码器（codec），如。
Netty
最新发布
12-29 1323
粘包问题是指发送方发送的多个数据包在接收方被合并成一个数据包接收。粘包问题通常发生在发送方发送的数据包较小且频繁的情况下。比如发送方发送了两个数据包A和B，数据包A的内容是"Hello"，数据包B的内容是"World"。由于TCP是基于字节流的协议，接收方可能会将这两个数据包合并成一个数据包接收，内容为"HelloWorld"。粘包问题的原因主要有两个：1.发送方发送的数据包较小且频繁：当发送方发送的数据包较小且频繁时，TCP可能会将多个数据包合并成一个数据包发送，导致接收方接收到合并的数据包。
服务器_网络通信(TCP/IP网络模型，HTTP（URL），Socket，WebSocket,BIO，NIO，AIO，Mina框架，Netty框架)
binge_kong的博客
09-21 1562
通信协议 客户端和服务器之间通信所需要遵循的某种规则 网络模型OSI(Open System Interconnnection) 该模型把把网络通信分为7层（物理层，数据链路层，网络层，传输层，会话层，表示层，应用层），是设计和描述计算机网络通信的基本架构。 在实际应用中一般只是用到4层。 TCP/IP网络模型 这个模型是一系列网络协议的总层，是互联网的基础。 4个层次 链接层 对应的...
基于Netty的轻量级无锁异步事件驱动分布式网络框架
无锁异步化、事件驱动架构设计的Java Netty网络编程框架是一种面向高并发、高性能场景下的现代网络通信解决方案，尤其适用于需要处理海量长连接的应用环境。该框架基于Netty构建，结合了无锁编程模型与事件驱动机制...
Netty 学习笔记
@码农充电站的专栏
02-07 1071
Netty 是一个异步事件驱动的网络应用程序框架，可用于快速开发可维护的高性能网络服务器和客户端。
Netty多线程下响应消息乱序问题解决方案
恐龙弟旺仔的博客
02-15 3819
前言： 今天在看文章时，介绍了一个Netty_client被多线程调用发送消息出去，当服务端处理完成之后，将结果值返回给客户端，客户端无法区分是哪个线程的响应的问题的解决方案。 笔者之前在介绍Netty的代码时，其中关于Netty在Sentinel中的实战部分实际有介绍过这块，但是看代码的时候一直没有仔细想，今天看到这个问题，决定把这个问题再次详细描述下，然后把Sentinel的解决方案也再次说明下。 1.具体问题描述 在使用netty_client时，一般使用channel.writeAndF
Netty 粘包和拆包详解
骏马逸动，心随你动的博客
09-18 1216
1. 前言 前面几个章节主要解析了 Netty 的编码、解码问题，那么是否有了编解码器，我们的 Netty 通信就能正常了呢？ TCP 协议在传输数据时没有办法判断数据是什么时候结束的，它无法识别一段完整的信息，因此可能会导致接受到的数据和发送时的数据不一致的情况。因此需要人为的指定一种规范的协议，从而保证数据的安全性，比如：我们所熟悉的 HTTP 协议。 本节内容，我们主要需要以下两点知识 TCP 拆包、粘包的原因； TCP 拆包、粘包的解决方案。 2. 学习目的 拆包、粘包在 TCP 协
怎么理解 Java NIO 里面的 attachment ?
龚小帅的博客
08-10 1357
来数据的时候, 再次拿出这个容器, 继续放数据, 那么这个容器怎么可以容易的每次都有数据的时候拿到呢?去读取的, 当有部分数据到达的时候, 它就帮你读取, 读完来的数据之后, 还没读取到。在读操作上, 不去干其它事情, 当来一个字节/字符的时候, 它就读一个, 直到返回。有数据, 就通过它拿到之前装有半成品的容器, 那么可以继续放了., 再次等待它接下来的数据, 那么刚才读取的数据放哪里呢?方法附在上面, 下次当有数据来的时候, 通过。的时候, 读线程直接返回, 是由一个专门的。知道有数据的, 一旦。...
Netty中ctx.writeAndFlush与ctx.channel().writeAndFlush的区别
热门推荐
每天get√新知识
11-05 3万+
最近在写netty相关代码，发现writeAndFlush这个方法既可以在ctx上调用，也可以在channel上调用，这两者有什么区别呢，于是就做了一个小实验。
netty笔记（1）--ctx.write()和channel().write()的区别
forcht
08-10 8125
刚学netty,一些细节上还不是很清楚，发现踩了很多坑。一点一点记录下来。 先看一个小demo bootstrap.group(bossGroup,workerGroup) .channel(NioServerSocketChannel.class) .localAddress(new InetSocket...
Day386&387.Nio概述&Nio的Channel通道 -NIO
阿昌爱Java
09-10 1491
Java NIO 概述 Java NIO（New IO 或 Non Blocking IO）是从Java 1.4 版本开始引入的一个新的IO API，可以替代标准的 Java IO API。NIO 支持面向缓冲区的、基于通道的 IO 操作。NIO 将以更加高效的方式进行文件的读写操作。 1.1 阻塞 IO 通常在进行同步 I/O 操作时，如果读取数据，代码会阻塞直至有可供读取的数据。同样，写入调用将会阻塞直至数据能够写入。传统的 Server/Client 模式会基于 TPR（Thread per Requ
通俗编程——白话NIO之Channel
Floating Cat
12-16 7626
Channel简介在标准的IO当中，都是基于字节流/字符流进行操作的，而在NIO中则是是基于Channel和Buffer进行操作，其中的Channel的虽然模拟了流的概念，实则大不相同。
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、付费专栏及课程。

余额充值