《Java源码解析》之NIO的Selector机制(Part1:Selector.open())
《Java源码解析》之NIO的Selector机制(Part1:Selector.open())
https://blog.csdn.net/u010853261/article/details/53464475
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u010853261/article/details/53464475
Selector机制之Selector.open()函数的解析
在NIO中我们一般都是Channel与Selector配合使用的,一般情况下使用的方法如下:
//打开Selector来处理channel
Selector selector = Selector.open();
//将channel注册到selector中,并将channel设置成等待新的连接
serverChannel.register(selector,SelectionKey.OP_ACCEPT);
//等待处理新的事件;一直阻塞直到下一个事件到来才唤醒.此方法执行处于阻塞模式的选择操作。仅在至少选择一个通道、调用此选择器的 wakeup 方法,或者当前的线程已中断(以先到者为准)后此方法才返回。
selector.select();
1
2
3
4
5
6
这篇博客我们主要从Selector.open()函数开始,一步步分析Selector机制。
首先我们进入Selector.open();函数,在JDK源码中定义如下:
public static Selector open() throws IOException {
return SelectorProvider.provider().openSelector();
}
1
2
3
查看这个函数的doc文档注释:
The new selector is created by invoking the openSelector method of the system-wide default SelectorProvider object.
意思是:通过调用系统默认的SelectorProvider(这里不同的系统会有不同的SelectorProvider实现类)的openSelector()方法来创建新的selector。
这里我们首先分析一下:
SelectorProvider.provider();
进入SelectorProvider这个类的静态方法provider(),JDK的源码如下:
public static SelectorProvider provider() {
/**
*加锁,锁的定义是:private static final Object lock = new Object();
*/
synchronized (lock) {
/**
*provider的定义是:private static SelectorProvider provider = null;
*/
if (provider != null)
return provider;
return AccessController.doPrivileged(
new PrivilegedAction<SelectorProvider>() {
public SelectorProvider run() {
if (loadProviderFromProperty())
return provider;
if (loadProviderAsService())
return provider;
provider = sun.nio.ch.DefaultSelectorProvider.create();
return provider;
}
});
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
还是先来阅读一下Javadoc中关于这个函数的功能描述:通过Java虚拟机的调用返回系统默认的selector provider。
注意:我们发现同步代码段中首先的就是一个判断:
if (provider != null)
return provider;
1
2
这个地方判断provider在当前进程是否已经被实例化过了,如果已经被实例化过了,那么就直接返回当前provider,不再执行后面的代码;否者就执行后面的代码实例化provider。这里就是一个最简单的 单例模式 的应用。
继续分析后面的代码:后面是一个AccessController.doPrivileged()这个貌似是与权限相关的,不是本文的重点,暂时不去分析这个。我们分析后面的run()方法里面的内容:
if (loadProviderFromProperty())
return provider;
if (loadProviderAsService())
return provider;
provider = sun.nio.ch.DefaultSelectorProvider.create();
return provider;
1
2
3
4
5
6
loadProviderFromProperty()这个函数判断如果系统属性java.nio.channels.spi.SelectorProvider 已经被定义了,则该属性名看作具体提供者类的完全限定名。加载并实例化该类;如果此进程失败,则抛出未指定的错误。
loadProviderAsService()这个函数判断:如果在对系统类加载器可见的 jar 文件中安装了提供者类,并且该 jar 文件包含资源目录 META-INF/services 中名为 java.nio.channels.spi.SelectorProvider 的提供者配置文件,则采用在该文件中指定的第一个类名称。加载并实例化该类;如果此进程失败,则抛出未指定的错误。
最后,如果未通过上述的方式制定任何provider,则实例化系统默认的provider并返回该结果(一般情况下,都是这种情况。)
这个地方需要注意的是:这里系统默认的provider在不同系统上是不一样的,下面用一个表格来表示:
系统 provider 备注
MacOSX KQueueSelectorProvider 无
Linux 。 无
Windows 。 无
进入sun.nio.ch.DefaultSelectorProvider.create();
这里系统会根据不同的操作系统返回不同的provider;我们来看一下系统默认的provider;由于我用的是Mac-OSX 的系统进入之后源码如下:
public static SelectorProvider create() {
return new KQueueSelectorProvider();
}
1
2
3
所以OSX默认的provider是KQueueSelectorProvider。继续进入KQueueSelectorProvider的构造函数,源码如下:
public KQueueSelectorProvider() {
}
1
2
这是一个空的构造函数,所以SelectorProvider.provider();
最后返回的就是KQueueSelectorProvider;下面给个示图显示类的继承关系:
我们继续看SelectorProvider.provider().openSelector();
后面调用的也就是KQueueSelectorProvider.openSelector();源码如下:
public AbstractSelector openSelector() throws IOException {
return new KQueueSelectorImpl(this);
}
1
2
3
所以最后返回的就是KQueueSelectorImpl这个实现类的实例。我们看一下这个类的继承关系图:
下面就是分析KQueueSelectorImpl的构造函数,来窥探一下selector的运行原理:
//构造函数
KQueueSelectorImpl(SelectorProvider var1) {
//调用父类的构造函数,传入的是一个SelectorProvider,在Mac上是KQueueSelectorProvider
super(var1);
long var2 = IOUtil.makePipe(false);//native方法
this.fd0 = (int)(var2 >>> 32);//高32位存放的是Pipe管道的读端的文件描述符
this.fd1 = (int)var2;//低32位存放的是Pipe管道的写端的文件描述符
this.kqueueWrapper = new KQueueArrayWrapper();
this.kqueueWrapper.initInterrupt(this.fd0, this.fd1);
this.fdMap = new HashMap();
this.totalChannels = 1;
}
1
2
3
4
5
6
7
8
9
10
11
12
IOUtil.makePipe(false); 是一个static native方法,所以我们没办法查看源码。但是我们可以知道该函数返回了一个非堵塞的管道(pipe),底层是通过Linux的pipe系统调用实现的;创建了一个管道pipe并返回了一个64为的long型整数,该数的高32位存放了该管道读端的文件描述符,低32位存放了该pipe的写端的文件描述符。
下面又创建了一个KQueueArrayWrapper对象,我们把重点放在下面的this.kqueueWrapper.initInterrupt(this.fd0, this.fd1);函数,这里把管道的读写两端的文件描述符作为参数传入,我们先来看看源码:
void initInterrupt(int var1, int var2) {
//private int outgoingInterruptFD;
//private int incomingInterruptFD;
this.outgoingInterruptFD = var2;//写端
this.incomingInterruptFD = var1;//读端
this.register0(this.kq, var1, 1, 0);
}
1
2
3
4
5
6
7
其中的register0(this.kq, var1, 1, 0);又是一个native方法。initInterrup方法,从该方法初步判断,管道应该和中断有关系;
最后定义了一个map类型的变量fdToKey,将channel的文件描述符和SelectionKey建立映射关系;
最后总结一下Selector.open()干了啥:
主要完成建立Pipe,并把pipe的读写文件描述符放入pollArray中,这个pollArray是Selector的枢纽。Linux下则是直接使用系统的pipe。
下面附图展示Selector工作原理,以Windows下为例:
---------------------
作者:惜暮
来源:CSDN
原文:https://blog.csdn.net/u010853261/article/details/53464475
版权声明:本文为博主原创文章,转载请附上博文链接!