NioEventLoop启动和执行
NioEventLoop启动
在服务端启动的代码中,我们看到netty在注册和绑定时,判断了当前线程是否是NioEventLoop线程。如果不是,
则将这些操作包装成一个任务丢到EventExecutor中来完成。
// 调用SingleThreadEventExecutor对象的execute方法
eventLoop.execute(() -> register0(promise));
// SingleThreadEventExecutor对象的execute方法
@Override
public void execute(Runnable task) {
boolean inEventLoop = inEventLoop();
addTask(task);
if (!inEventLoop) {
startThread();
}
if (!addTaskWakesUp && wakesUpForTask(task)) {
wakeup(inEventLoop);
}
}
在execute方法中,再次判断是否是NioEventLoop线程,若不是则执行startThread方法。startThread方法通过CAS
将线程的state修改为已启动,成功后进入doStartThread方法。这个方法包装了一个任务,交由在创建NioEventLoop
时设置的Executor执行。默认情况下,它是ThreadPerTaskExecutor,也因此,它会启动一个新的线程执行任务。包装
任务的主要逻辑有3个:
- 将当前线程与nioEventLoop绑定;
- 更新上次执行的时长为当前时间-上个任务启动时间;
- 执行NioEventLoop的run方法;
private void doStartThread() {
executor.execute(() -> {
thread = Thread.currentThread();
updateLastExecutionTime();
SingleThreadEventExecutor.this.run();
});
}
至此,NioEvnetLoop就启动了。
NioEventLoop执行
当NioEventLoop启动后,就开始执行SingleThreadEventExecutor的run方法。此方法是一个死循环,也可以分为3个步骤
- 轮询channel中就绪的IO事件
- 处理轮询出的IO事件
- 处理所有任务,也包括定时任务
轮询事件
整个轮询IO事件的流程如下
switch (selectStrategy.calculateStrategy(selectNowSupplier, hasTasks())) {
case SelectStrategy.CONTINUE:
continue;
case SelectStrategy.BUSY_WAIT:
case SelectStrategy.SELECT:
select(wakenUp.getAndSet(false));
if (wakenUp.get()) {
selector.wakeup();
}
default:
}
在循环的开始阶段,调用选择策略器选择select策略,默认策略下,先判断是否有任务,若没有任务,调用selectNow(),否则进入SelectStrategy.SELECT,也即调用select(wakeUp.getAndSet(false))。
selectNow()方法
int selectNow() throws IOException {
try {
return selector.selectNow();
} finally {
if (wakenUp.get()) {
selector.wakeup();
}
}
}
nioEventLoop的selectNow方法会调用持有的Selector对象的selectNow方法。此方法轮询后,即使没有事件也会立即返回,而selector.select方法则会阻塞。
finally操作保证当wakenUp字段为true时,调用一次selector.wakeup方法,此方法会使阻塞的select方法唤醒,若当前没有select阻塞,则下一次select会立即返回。
select(boolean oldWakenUp)方法
首先看到入参为wakeup.getAndSet(false)。wakeup的作用稍后分析,这里简单提一下它的作用是控制将阻塞的selector唤醒。
详细代码如下
private void select(boolean oldWakenUp) throws IOException {
Selector selector = this.selector;
int selectCnt = 0;
// 步骤1
long currentTimeNanos = System.nanoTime();
long selectDeadLineNanos = currentTimeNanos + delayNanos(currentTimeNanos);
long normalizedDeadlineNanos = selectDeadLineNanos - initialNanoTime();
if (nextWakeupTime != normalizedDeadlineNanos) {
nextWakeupTime = normalizedDeadlineNanos;
}
for (;;) {
// 步骤2
long timeoutMillis = (selectDeadLineNanos - currentTimeNanos + 500000L) / 1000000L;
if (timeoutMillis <= 0) {
if (selectCnt == 0) {
selector.selectNow();
selectCnt = 1;
}
break;
}
// 步骤3
if (hasTasks() && wakenUp.compareAndSet(false, true)) {
selector.selectNow();
selectCnt = 1;
break;
}
// 步骤4
int selectedKeys = selector.select(timeoutMillis);
selectCnt++;
if (selectedKeys != 0 || oldWakenUp || wakenUp.get() || hasTasks() || hasScheduledTasks()) {
break;
}
// 步骤5
if (Thread.interrupted()) {
selectCnt = 1;
break;
}
// 步骤6
long time = System.nanoTime();
if (time - TimeUnit.MILLISECONDS.toNanos(timeoutMillis) >= currentTimeNanos) {
selectCnt = 1;
} else if (SELECTOR_AUTO_REBUILD_THRESHOLD > 0 &&
selectCnt >= SELECTOR_AUTO_REBUILD_THRESHOLD) {
selector = selectRebuildSelector(selectCnt);
selectCnt = 1;
break;
}
currentTimeNanos = time;
}
代码较长,可以分为6个步骤
- 步骤1计算了多种精确到纳秒级别的时间,⑴当前时间;⑵select阻塞截止时间,这里又会根据是否有定时任务来计算,若有到时间的定时任务,则取最近一个定时
任务的截止时间,若没有定时任务或定时任务还没到时间,则取1秒后;⑶规整化截止时间与下次唤醒时间
从步骤2开始,又进入一个死循环内:
- 四舍五入计算阻塞超时时间。若超时时间小于0且空轮询次数为0,执行一次selectNow后返回。
- 轮询前先判断有没有任务,若有任务,且wakeup由false设置为true了,则执行selectNow。否则会因为无法唤醒selector耽误这个任务的执行。执行完后,结束本次循环。
- 阻塞式select。阻塞结束后,发生下列条件之一时,结束本次循环:⑴轮询到了IO事件;⑵进入select(boolean wakeup)之前,参数oldWakeup为true,也即之前有过wakeup的动作;⑶当前需要唤醒,可能是用户主动调用wakeup方法唤醒的;⑷队列里有任务了,可能是外部线程添加的;⑸有定时任务到期了
- 若线程被打断,设置空轮询次数为1,结束此次循环
- 根据当前时间与进入方法时计算的时间判断阻塞式select是否超时,若time - TimeUnit.MILLISECONDS.toNanos(timeoutMillis) >= currentTimeNanos成立,则有time-currentTimeNanos>=timeoutMillis,说明这次select执行的时间不够,可能触发了空轮询,将空轮询次数为1,计算累计空轮询次数是否大于阈值(阈值SELECTOR_AUTO_REBUILD_THRESHOLD默认为512),当大于阈值时,重建selector,以规避JDK空轮询bug。反之,则进行了一次有效的select,将累计空轮询次数置为1,结束本次循环。
规避空轮询bug
其实netty规避空轮询bug的方式也很巧妙,就是通过新建selector,并将旧selector上的key和attchment复制过去
private Selector selectRebuildSelector(int selectCnt) throws IOException {
rebuildSelector();
Selector selector = this.select
// Select again to populate selectedKeys.
selector.selectNow();
return selector;
}
private void rebuildSelector0() {
final Selector oldSelector = selector;
final SelectorTuple newSelectorTuple
newSelectorTuple = openSelector();
// 将老selector的key和attchment传递给新selector
for (SelectionKey key : oldSelector.keys()) {
Object a = key.attachment();
int interestOps = key.interestOps();
key.cancel();
SelectionKey newKey = key.channel().register(newSelectorTuple.unwrappedSelector, interestOps, a);
if (a instanceof AbstractNioChannel) {
// Update SelectionKey
((AbstractNioChannel) a).selectionKey = newKey;
}
selector = newSelectorTuple.selector;
unwrappedSelector = newSelectorTuple.unwrappedSelector;
// 关闭老selector
oldSelector.close();
}
}
代码足够详细,就不多加解释了
select(wakeup.getAndSet(false))执行完后,还有这样几行代码①
if (wakenUp.get()) {
selector.wakeup();
}
之前提到wakeup的作用是控制将阻塞的selector唤醒。这里先详细说下。
回顾上文,SingleThreadEventExecutor对象的execute方法有一个添加任务后调用wakeup的动作,nioEventLoop重写了wakeup方法如下
protected void wakeup(boolean inEventLoop) {
if (!inEventLoop && wakenUp.compareAndSet(false, true)) {
selector.wakeup();
}
}
这里进行了2个判断,!inEventLoop表明这是外部线程,selector.wakeup()使阻塞的select操作立即唤醒,以便及时处理此时添加的这个任务。
这个方法让外部线程在加入任务时,能及时唤醒selector处理任务
根据netty的解释,wakeup.compareAndSet(false, true)总是在selector.wakeup之前调用,以便在同时多个任务时减少selector.wakeup的性能消耗。
代码①的注释进一步提到存在两种竞态条件使wakeup太早被设置为true。
- 如果Selector在wakeup.set(false)和selector.select(timeout)之间被唤醒。这里发生在步骤4之前。
- 如果Selector在selector.select()和if(wakeup.get())之间被唤醒。这里发生在步骤4之后。
在第一种情况,接下来的一次selector.select(timeout)(注:称为select1)将立即唤醒。之后由于wakeup为true,wakeup.compareAndSet(false, true)将失败,从而导致无法调用selector.wakeup,
假如这期间(从步骤4到下一次selector.select(timeout)(注:称为select2))加入一个任务,那么得等到下一次select超时,任务才能得到处理。
所以查询完任务后,如果发现wakeup为true,再调用一次selector.wakup()。
不过细心的读者会留意到,在步骤3的几个条件里,netty会调用hasTask查看任务队列是否有任务,且在进入select方法前,会把wakeup设置为false,所以wakenUp.compareAndSet(false, true)会成功,因此会调用selectNow,而不必等到select2超时才处理任务。
第二种情况下,select2会立即返回,没有问题。
那这段代码有何意义?
实际上笔者个人认为这段代码属于遗留代码,理由是笔者在52im找到了netty3的代码,在netty3中的AbstractNioSelector类中,wakeup设置为false后,直接调用了selector.select(timeout)。在当时看来,这不失为一种解决方案。
到了这里,NioEventLoop完成了启动,并查询出了selectionKey,下一步就是处理selectionKey。
so····未完待续