这篇文章主要介绍了分布式Netty源码分析的相关知识，内容详细易懂，操作简单快捷，具有一定借鉴价值，相信大家阅读完这篇分布式Netty源码分析文章都会有所收获，下面我们一起来看看吧。
看下一个简单的Netty服务器端的例子
public static void main(String[] args){
EventLoopGroup bossGroup=new NioEventLoopGroup(1);
EventLoopGroup workerGroup = new NioEventLoopGroup();
try {
ServerBootstrap serverBootstrap=new ServerBootstrap();
serverBootstrap.group(bossGroup,workerGroup)
.channel(NioServerSocketChannel.class)
.option(ChannelOption.SO_BACKLOG, 200)
.childHandler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel ch) throws Exception {
ch.pipeline().addLast(new LengthFieldBasedFrameDecoder(80,0,4,0,4));
ch.pipeline().addLast(new StringDecoder(Charset.forName("UTF-8")));
ch.pipeline().addLast(new TcpServerHandler());
}
});
ChannelFuture f=serverBootstrap.bind(8080).sync();
f.channel().closeFuture().sync();
} catch (InterruptedException e) {
e.printStackTrace();
}finally {
workerGroup.shutdownGracefully();
bossGroup.shutdownGracefully();
}
}先来简单说说上述遇到的类：
它主要包含2个方面的功能，注册Channel和执行一些Runnable任务。
即将Channel注册到Selector上，由Selector来调度Channel的相关事件，如读、写、Accept等事件。
而EventLoopGroup的设计是，它包含多个EventLoop（每一个EventLoop通常内部包含一个线程），在执行上述注册过程中是需要选择其中的一个EventLoop来执行上述注册行为，这里就出现了一个选择策略的问题，该选择策略接口是EventExecutorChooser，你也可以自定义一个实现。
从上面可以看到，EventLoopGroup做的工作大部分是一些总体性的工作如初始化上述多个EventLoop、EventExecutorChooser等，具体的注册Channel还是交给它内部的EventLoop来实现。
EventLoopGroup继承了EventExecutorGroup，EventExecutorGroup也是EventExecutor的集合，EventExecutorGroup也是掌管着EventExecutor的初始化工作，EventExecutorGroup对于Runnable任务的执行也是选择内部中的一个EventExecutor来做具体的执行工作。
netty中很多任务都是异步执行的，一旦当前线程要对某个EventLoop执行相关操作，如注册Channel到某个EventLoop，如果当前线程和所要操作的EventLoop内部的线程不是同一个，则当前线程就仅仅向EventLoop提交一个注册任务，对外返回一个ChannelFuture。
总结：EventLoopGroup含有上述2种功能，它更多的是一个集合，但是具体的功能实现还是选择内部的一个item元素来执行相关任务。 这里的内部item元素通常即实现了EventLoop，又实现了EventExecutor，如NioEventLoop等
上述EventLoopGroup可以将一个Channel注册到内部的一个EventLoop的Selector上，然后对于这个Channel的相关读写等事件，Netty专门设计了一个ChannelPipeline来进行处理。每一个Channel都有一个ChannelPipeline来处理该Channel的读写等事件。
上述serverBootstrap的bind过程如下：
创建出你所指定的NioServerSocketChannel，然后初始化一些Socket方面的参数
为上述Channel的ChannelPipeline配置一个ChannelHandler，该ChannelHandler的作用就是在该Channel成功注册到Selector上的时候，初始化一些逻辑，即initChannel方法中执行一些逻辑，该逻辑就是向ChannelPipeline中添加一个新的ChannelHandler即ServerBootstrapAcceptor
然后开始将该Channel注册到上述EventLoopGroup bossGroup中，该EventLoopGroup bossGroup会选择内部的一个EventLoop来执行实际的注册行为（这个时候就是当前线程和操作的EventLoop不是同一个线程，即该过程是异步提交一个Runnable），一旦注册完成，就执行上述ChannelHandler的initChannel方法
至此，就完成了整个bind过程。一旦EventLoop内部的Selector检测到NioServerSocketChannel有新的连接到来的事件，则会交给NioServerSocketChannel的ChannelPipeline来处理，重点就是ChannelPipeline中的上述ServerBootstrapAcceptor，ServerBootstrapAcceptor做如下操作：
1 为新的Channel的ChannelPipeline配置我们上述代码中的childHandler指定的ChannelHandler
2 将新的Channel注册到了上述EventLoopGroup workerGroup中
bind方法返回的是一个ChannelFuture，从上面我们也知道该过程是异步的，sync方法则是一直等待到该异步过程结束。
再看下f.channel().closeFuture().sync()这个方法
每一个ChannelFuture都是和一个Channel绑定的，所以可以通过ChannelFuture来获取对应绑定的Channel对象
每一个Channel对象都有一个CloseFuture closeFuture对象，上述closeFuture方法并不是去执行close方法而是获取到这个CloseFuture closeFuture对象，然后调用它的sync方法即等待这个Future的结束。一般正常情况下是不会调用这个Future的结束方法的，只是在上述过程或者其他过程出现问题的时候，如注册到EventLoop失败等才会去调用这个Feture的结束方法，所以正常情况下主线程会一直阻塞在CloseFuture closeFuture的sync方法上。
上述的bossGroup的创建问题。
我们都知道bossGroup是用来accept连接，然后将连接绑定到workerGroup中的，一般情况下bossGroup设置线程数为1即可（基本只能为1），我们同时知道Ractor模型中可以使用多个Acceptor线程来执行accept操作，加快accept的速度。
如果你想加快accept的速度，想开启多线程来accept，这时候想设置bossGroup的线程数为多个的话，就大错特错了，是根本没效果的。
结合上面的原理，只有在bind端口的时候才会创建一个ServerSocketChannel，然后注册到bossGroup内部的一个EventLoop中，仍然是单线程负责ServerSocketChannel的accept工作，而bossGroup中的多线程仅仅是为bind多个端口服务的。
我们来看下tomcat是如何允许多个Acceptor线程来执行accept操作的：
1 创建了一个ServerSocketChannel serverSock，并bind到某个端口
2 开启多个Acceptor线程，每个线程逻辑都是执行上述serverSock的accept方法
没有使用Selector来执行accept操作，可以多线程并发执行上述serverSock的accept方法。
一旦使用了Selector，基本上就相当于将ServerSocketChannel serverSock绑定到了Selector所在线程上了（Selector不是线程安全的，只能在一个线程中被调度执行）
关于“分布式Netty源码分析”这篇文章的内容就介绍到这里，感谢各位的阅读！相信大家对“分布式Netty源码分析”知识都有一定的了解，大家如果还想学习更多知识，欢迎关注亿速云行业资讯频道。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
