Netty是一個java的高性能同步/異步通訊框架,基于SEDA模型。最近因為要逐漸接觸java項目,就看了下它的實現(xiàn),順便也練練手。
Netty的概念模型中第一層就是EventLoop,我們也先從EventLoop來了解它的實現(xiàn)。EventLoop是Netty做出的一個事件隊列,無論是網(wǎng)絡(luò)事件(消息發(fā)送/接收)還是Netty內(nèi)部的任務都會丟到EventLoop中然后等待觸發(fā)執(zhí)行??梢哉fEventLoop就是Netty的運行引擎。
本文根據(jù)EpollEventLoop的實現(xiàn),來參考了解下Netty框架的思路。
EpollEventLoop
Epoll是linux下提供的一個高效的異步網(wǎng)絡(luò)通信io接口,具體信息請自行查詢。本文重點關(guān)注Netty是如何包裹Epoll接口并利用它實現(xiàn)事件隊列的。
注意的是,EventLoop不僅僅是執(zhí)行socket事件,還可以用來執(zhí)行自定義的task,他利用了epoll來做底層的觸發(fā),具體方法參見下文。
epollFd和eventFd
在EpollEventLoop的初始化函數(shù)中,新建了兩個fd:
this.epollFd = epollFd = Native.newEpollCreate();
this.eventFd = eventFd = Native.newEventFd();
try {
Native.epollCtlAdd(epollFd.intValue(), eventFd.intValue(), Native.EPOLLIN);
} catch (IOException e) {
throw new IllegalStateException("Unable to add eventFd filedescriptor to epoll", e);
}
success = true;
其中Epollfd對應Epoll API,用來輪詢之后綁定的socket,而它首先綁定的就是eventFd,eventFd就成為用來喚醒事件隊列的內(nèi)部接口了。具體的使用方法繼續(xù)往下看。
epollWait
private int epollWait(boolean oldWakenUp) throws IOException {
int selectCnt = 0;
long currentTimeNanos = System.nanoTime();
long selectDeadLineNanos = currentTimeNanos + delayNanos(currentTimeNanos);
for (;;) {
long timeoutMillis = (selectDeadLineNanos - currentTimeNanos + 500000L) / 1000000L;
if (timeoutMillis <= 0) {
if (selectCnt == 0) {
int ready = Native.epollWait(epollFd.intValue(), events, 0);
if (ready > 0) {
return ready;
}
}
break;
}
// If a task was submitted when wakenUp value was 1, the task didn't get a chance to produce wakeup event.
// So we need to check task queue again before calling epoll_wait. If we don't, the task might be pended
// until epoll_wait was timed out. It might be pended until idle timeout if IdleStateHandler existed
// in pipeline.
if (hasTasks() && WAKEN_UP_UPDATER.compareAndSet(this, 0, 1)) {
return Native.epollWait(epollFd.intValue(), events, 0);
}
int selectedKeys = Native.epollWait(epollFd.intValue(), events, (int) timeoutMillis);
selectCnt ++;
if (selectedKeys != 0 || oldWakenUp || wakenUp == 1 || hasTasks() || hasScheduledTasks()) {
// - Selected something,
// - waken up by user, or
// - the task queue has a pending task.
// - a scheduled task is ready for processing
return selectedKeys;
}
currentTimeNanos = System.nanoTime();
}
return 0;
}
epollWait會通過輪詢的方式不斷的調(diào)用操作系統(tǒng)提供的epollWait API,另外輪詢之前也設(shè)置了timeout,因此當:
- 監(jiān)聽的fd(socket,eventFd)上有事件發(fā)生。
- timeout時
EpollWait都會返回,這個不斷的EpollWait就成為EventLoop底層的事件發(fā)動機了,驅(qū)動著整個Netty不斷執(zhí)行新的任務,可以參見run函數(shù),如下:
run
protected void run() {
for (;;) {
try {
int strategy = selectStrategy.calculateStrategy(selectNowSupplier, hasTasks());
switch (strategy) {
case SelectStrategy.CONTINUE:
continue;
case SelectStrategy.SELECT:
strategy = epollWait(WAKEN_UP_UPDATER.getAndSet(this, 0) == 1);
// 'wakenUp.compareAndSet(false, true)' is always evaluated
// before calling 'selector.wakeup()' to reduce the wake-up
// overhead. (Selector.wakeup() is an expensive operation.)
//
// However, there is a race condition in this approach.
// The race condition is triggered when 'wakenUp' is set to
// true too early.
//
// 'wakenUp' is set to true too early if:
// 1) Selector is waken up between 'wakenUp.set(false)' and
// 'selector.select(...)'. (BAD)
// 2) Selector is waken up between 'selector.select(...)' and
// 'if (wakenUp.get()) { ... }'. (OK)
//
// In the first case, 'wakenUp' is set to true and the
// following 'selector.select(...)' will wake up immediately.
// Until 'wakenUp' is set to false again in the next round,
// 'wakenUp.compareAndSet(false, true)' will fail, and therefore
// any attempt to wake up the Selector will fail, too, causing
// the following 'selector.select(...)' call to block
// unnecessarily.
//
// To fix this problem, we wake up the selector again if wakenUp
// is true immediately after selector.select(...).
// It is inefficient in that it wakes up the selector for both
// the first case (BAD - wake-up required) and the second case
// (OK - no wake-up required).
if (wakenUp == 1) {
Native.eventFdWrite(eventFd.intValue(), 1L);
}
default:
// fallthrough
}
final int ioRatio = this.ioRatio;
if (ioRatio == 100) {
if (strategy > 0) {
processReady(events, strategy);
}
runAllTasks();
} else {
final long ioStartTime = System.nanoTime();
if (strategy > 0) {
processReady(events, strategy);
}
final long ioTime = System.nanoTime() - ioStartTime;
runAllTasks(ioTime * (100 - ioRatio) / ioRatio);
}
if (allowGrowing && strategy == events.length()) {
//increase the size of the array as we needed the whole space for the events
events.increase();
}
if (isShuttingDown()) {
closeAll();
if (confirmShutdown()) {
break;
}
}
} catch (Throwable t) {
logger.warn("Unexpected exception in the selector loop.", t);
// Prevent possible consecutive immediate failures that lead to
// excessive CPU consumption.
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
// Ignore.
}
}
}
}
run函數(shù)會不斷的調(diào)用epollWait,每次epollWait返回的時候,就先執(zhí)行監(jiān)聽的fd中的事件處理,然后再另外執(zhí)行所有的tasks,這個tasks就是用戶直接通過schedule等方法安排的任務。
可以看到ioRatio還會影響每次執(zhí)行的任務數(shù)量的百分比。
wakeup
protected void wakeup(boolean inEventLoop) {
if (!inEventLoop && WAKEN_UP_UPDATER.compareAndSet(this, 0, 1)) {
// write to the evfd which will then wake-up epoll_wait(...)
Native.eventFdWrite(eventFd.intValue(), 1L);
}
}
這是wakeup函數(shù),其實現(xiàn)就是往eventFd里寫一個1,因為在epollWait里綁定了eventFd,所以wakeup函數(shù)會迅速喚醒Eventloop來執(zhí)行tasks。否則的話,如果沒有IO事件的情況下,eventloop就退化成一個定時的task執(zhí)行隊列,這個時延在有些高事件敏感性的任務里是不可接受的。
EventLoopGroup
EventLoopGroup是一個EventLoop的容器??梢钥匆幌鲁S玫膔egister函數(shù)
register
register函數(shù)是Netty中最常用的,將一個Channel(背后代表了一個socket)注冊到EventLoopGroup中。
@Override
public ChannelFuture register(Channel channel) {
return next().register(channel);
}
而next函數(shù)總是用來選擇一個eventloop。因此eventLoopGroup會選出其下的某一個eventLoop供channel注冊。
channel注冊其實就是將其背后的socket交給EventLoop去監(jiān)聽,當socket上有事件發(fā)生時,調(diào)用channel中對應的handler來執(zhí)行。
研究了EpollEventLoop后,我們可以再研究下其它的幾個EventLoop的實現(xiàn)。
DefaultEventLoop
DefaultEventLoop就是維護一個tasks列表,不斷的取tasks run就可以了。
protected void run() {
for (;;) {
Runnable task = takeTask();
if (task != null) {
task.run();
updateLastExecutionTime();
}
if (confirmShutdown()) {
break;
}
}
}
綜述
EventLoop是Netty的執(zhí)行引擎,就像心跳一樣提供了Netty程序執(zhí)行的動力。它的核心是一個不斷的輪詢,而epollEventLoop在輪詢時一部分CPU時間會因為epoll系統(tǒng)調(diào)用的原因讓出給其它線程,因此EpollEventLoop的超時時長對最后Netty的工作有重大影響,調(diào)高時長會降低Netty的CPU占用,但是會影響系統(tǒng)實時性。降低時長會提高系統(tǒng)響應時間,但是相對的會耗費更多的CPU。