SelectKey注册了写事件,不在合适的时间去除掉,会一直触发写事件,因为写事件是代码触发的 client.register(selector, SelectionKey.OP_WRITE); 或者sk.interestOps(SelectionKey.OP_WRITE) 执行了这以上任一代码都会无限触发写事件,跟读事件不同,一定注意 nio的select()的时候,只要数据通道允许写,每次select()返回的OP_WRITE都是true.所以在nio的写数据里面,我们在每次需要写数据之前把

引导一个应用程序是指对它进行配置,并使它运行起来的过程. 一.Bootstrap 类 引导类的层次结构包括一个抽象的父类和两个具体的引导子类,如图 8-1 所示 服务器致力于使用一个父 Channel 来接受来自客户端的连接,并创建子 Channel 以用于它们之间的通信: 而客户端将最可能只需要一个单独的.没有父Channel 的Channel 来用于所有的网络交互.(正如同我们将要看到的,这也 适用于无连接的传输协议,如 UDP,因为它们并不是每个连接都需要一个单独的 Channel.) 为

一.Bootstrap Bootstrap 是 Netty 提供的一个便利的工厂类, 我们可以通过它来完成 Netty 的客户端或服务器端的 Netty 初始化.下面我以 Netty 源码例子中的 Echo 服务器作为例子, 从客户端和服务器端分别分析一下Netty 的程序是如何启动的. 客户端部分 连接源码 首先, 让我们从客户端方面的代码开始 EventLoopGroup group = new NioEventLoopGroup(); try { Bootstrap b = new Boo

EventLoop 在之前介绍Bootstrap的初始化以及启动过程时,我们多次接触了NioEventLoopGroup这个类,关于这个类的理解,还需要了解netty的线程模型.NioEventLoopGroup可以理解为一组线程,这些线程每一个都可以独立地处理多个channel产生的io事件. NioEventLoopGroup初始化 我们看其中一个参数比较多的构造方法,其他一些参数较少的构造方法使用了一些默认值,使用的默认参数如下: SelectorProvider类型,用于创建socket

本篇文章主要详细分析Netty中的核心组件. 启动器Bootstrap和ServerBootstrap作为Netty构建客户端和服务端的路口,是编写Netty网络程序的第一步.它可以让我们把Netty的核心组件像搭积木一样组装在一起.在Netty Server端构建的过程中,我们需要关注三个重要的步骤 配置线程池 Channel初始化 Handler处理器构建 调度器详解 前面我们讲过NIO多路复用的设计模式之Reactor模型,Reactor模型的主要思想就是把网络连接.事件分发.任务处理的职

本系列Netty源码解析文章基于 4.1.56.Final版本 在上篇文章<聊聊Netty那些事儿之从内核角度看IO模型>中我们花了大量的篇幅来从内核角度详细讲述了五种IO模型的演进过程以及ReactorIO线程模型的底层基石IO多路复用技术在内核中的实现原理. 最后我们引出了netty中使用的主从Reactor IO线程模型. 通过上篇文章的介绍,我们已经清楚了在IO调用的过程中内核帮我们搞了哪些事情,那么俗话说的好内核领进门,修行在netty,netty在用户空间又帮我们搞了哪些事情? 那

Netty那点事(一)概述 Netty和Mina是Java世界非常知名的通讯框架.它们都出自同一个作者,Mina诞生略早,属于Apache基金会,而Netty开始在Jboss名下,后来出来自立门户netty.io.关于Mina已有@FrankHui的Mina系列文章,我正好最近也要做一些网络方面的开发,就研究一下Netty的源码,顺便分享出来了. Netty目前有两个分支:4.x和3.x.4.0分支重写了很多东西,并对项目进行了分包,规模比较庞大,入手会困难一些,而3.x版本则已经被广泛使用.本

连接管理是我们首先需要关注的,检测空闲连接以及超时对于及时释放资源来说是至关重要的.由于这是一项常见的任务,Netty特地为它提供了几个ChannelHandler实现. 用于空闲连接以及超时的ChannelHandler IdleStateHandler当连接空闲时间太长时,将会触发一个IdleStateEvent事件.然后,你可以通过在你的ChannelInboundHandler中重写userEventTriggered()方法来处理该IdleStateEvent事件 ReadTimeou

终于在课设的闲时间把netty实战的四五章给解决了 这里来记录一下第四章里面所讲的IO 首先说到IO,我想,必须要先了解阻塞,非阻塞,同步和异步这四个词 看到一个讲的很易懂的例子:https://www.cnblogs.com/George1994/p/6702084.html 那么了解完这四个词,就到了IO了 传统的IO,即阻塞IO 也就是跟之前用socket编程那样,没有数据写入到来这边的线程就一直等待,直到数据到来然后再对数据进行处理,例如打印 拿出以前的老代码 public void b

Netty 中ChannelOption的含义以及使用的场景 转自:http://www.cnblogs.com/googlemeoften/p/6082785.html 1.ChannelOption.SO_BACKLOG ChannelOption.SO_BACKLOG对应的是tcp/ip协议listen函数中的backlog参数,函数listen(int socketfd,int backlog)用来初始化服务端可连接队列,服务端处理客户端连接请求是顺序处理的,所以同一时间只能处理一个客户

理解零拷贝 零拷贝是Netty的重要特性之一,而究竟什么是零拷贝呢? WIKI中对其有如下定义: “Zero-copy” describes computer operations in which the CPU does not perform the task of copying data from one memory area to another. 从WIKI的定义中,我们看到“零拷贝”是指计算机操作的过程中,CPU不需要为数据在内存之间的拷贝消耗资源.而它通常是指计算机在网络上发

Reactor 模式在Netty中的应用 典型的Rector模式 mainReactor 服务端创建成功后,会监听Accept操作,其中ServerSocketchannel中的PipeLine中现在包含3个handler 服务端监听到连接事件后,会创建代表客户端的socketChannel,并向workgroup注册channel,监听后续该channel读写事件.一言以蔽之,bossGroup只负责接收连接请求,并创建socketChannel,分发到workgroup中执行耗时的读写操作.

何为心跳 顾名思义, 所谓心跳, 即在TCP长连接中, 客户端和服务器之间定期发送的一种特殊的数据包, 通知对方自己还在线, 以确保 TCP 连接的有效性. 为什么需要心跳 因为网络的不可靠性, 有可能在 TCP 保持长连接的过程中, 由于某些突发情况, 例如网线被拔出, 突然掉电等, 会造成服务器和客户端的连接中断. 在这些突发情况下, 如果恰好服务器和客户端之间没有交互的话, 那么它们是不能在短时间内发现对方已经掉线的. 为了解决这个问题, 我们就需要引入心跳机制. 心跳机制的工作原理是:

Netty中的那些坑(上篇) 最近开发了一个纯异步的redis客户端,算是比较深入的使用了一把netty.在使用过程中一边优化,一边解决各种坑.儿这些坑大部分基本上是Netty4对Netty3的改进部分引起的. 注:这里说的坑不是说netty不好,只是如果这些地方不注意,或者不去看netty的代码,就有可能掉进去了. 坑1: Netty 4的线程模型转变 在Netty 3的时候,upstream是在IO线程里执行的,而downstream是在业务线程里执行的.比如netty从网络读取一个包传递给

网络数据的基本单位总是字节.Java NIO 提供了 ByteBuffer 作为它 的字节容器,但是这个类使用起来过于复杂,而且也有些繁琐. Netty 的 ByteBuffer 替代品是 ByteBuf,一个强大的实现,既解决了 JDK API 的局限性, 又为网络应用程序的开发者提供了更好的 API. 一.ByteBuf 的 API Netty 的数据处理 API 通过两个组件暴露——abstract class ByteBuf 和 interface ByteBufHolder. 下面是一

Netty框架的主要线程就是I/O线程,线程模型设计的好坏,决定了系统的吞吐量.并发性和安全性等架构质量属性. 一.Netty的线程模型 在讨论Netty线程模型时候,一般首先会想到的是经典的Reactor线程模型,尽管不同的NIO框架对应Reactor模式的实现存在差异,但本质上还是遵循了Reactor的基础线程模型. Reactor的3中线程模型: Reactor单线程模型 Reactor多线程模型 主从Reactor多线程模型 见<Netty中的三种Reactor(反应堆)> NioEv

一.Channel与ChannelPipeline关系 每一个新创建的 Channel 都将会被分配一个新的 ChannelPipeline.这项关联是永久性 的:Channel 既不能附加另外一个 ChannelPipeline,也不能分离其当前的.在 Netty 组件 的生命周期中,这是一项固定的操作,不需要开发人员的任何干预. 在 Netty 中每个 Channel 都有且仅有一个 ChannelPipeline 与之对应, 它们的组成关系如下: 通过上图我们可以看到, 一个 Channe

NioEventLoopGroup的无参构造: public NioEventLoopGroup() { this(0); } 调用了单参的构造: public NioEventLoopGroup(int nThreads) { this(nThreads, (Executor)null); } 继续看到双参构造: public NioEventLoopGroup(int nThreads, Executor executor) { this(nThreads, executor, Select

在Netty使用ChannelFuture和ChannelPromise进行异步操作的处理 这是官方给出的ChannelFutur描述 * | Completed successfully | * +---------------------------+ * +----> isDone() = true | * +--------------------------+ | | isSuccess() = true | * | Uncompleted | | +=================

上一节我们讲了 Netty 的启动流程,从启动流程入手分析了 Reactor 模型的第一步:channel 如何绑定 Selector.然后讲到了 EventLoop 在启动的时候发挥了什么作用.整个启动类我们从头到尾过了一遍,今天我们来解决上节遗留的问题:Selector 如何将请求交给对应的 handler处理. 1. handler 的初始化 还是先从启动类入手: ServerBootstrap server = new ServerBootstrap().group(bossGroup,

Netty 底层是基于 TCP 协议来处理网络数据传输.我们知道 TCP 协议是面向字节流的协议,数据像流水一样在网络中传输那何来 "包" 的概念呢? TCP是四层协议不负责数据逻辑的处理,但是数据在TCP层 "流" 的时候为了保证安全和节约效率会把 "流" 做一些分包处理,比如: 发送方约定了每次数据传输的最大包大小,超过该值的内容将会被拆分成两个包发送: 发送端 和 接收端 约定每次发送数据包长度并随着网络状况动态调整接收窗口大小,这里也会出