7.2 源碼分析
7.2.1 ChannelPipeline
首先看ChannelPipeline接口的關鍵方法,相似方法只列出一個:
ChannelPipeline addLast(String name, ChannelHandler handler);
ChannelPipeline remove(ChannelHandler handler);
ChannelHandler first();
ChannelHandlerContext firstContext();
ChannelHandler get(String name);
ChannelHandlerContext context(ChannelHandler handler);
Channel channel();
ChannelPipeline fireChannelRegistered();
ChannelFuture bind(SocketAddress localAddress);
DefaultChannelPipeline是ChannelPipeline的一個子類,回憶ChannelHandler的事件處理順序,與雙向鏈表的正向遍歷和反向遍歷順序相同,可推知DefaultChannelPipeline使用了雙向鏈表。事實上如此,所不同的是:鏈表中的節(jié)點并不是ChannelHandler而是ChannelHandlerContext。明白了這些,先看其中的字段:
final AbstractChannelHandlerContext head; // 雙向鏈表頭
final AbstractChannelHandlerContext tail; // 雙向鏈表尾
private final Channel channel; // 對應Channel
// 線程池中的線程映射,記住這個映射是為了保證執(zhí)行任務時使用同一個線程
private Map<EventExecutorGroup, EventExecutor> childExecutors;
private MessageSizeEstimator.Handle estimatorHandle; // 消息大小估算器,內(nèi)部沒有使用
private boolean firstRegistration = true; // 對應Channel首次注冊到EventLoop
// ChannelHandler添加任務隊列鏈表頭部
private PendingHandlerCallback pendingHandlerCallbackHead;
// 注冊到EventLoop標記,該值一旦設置為true后不再改變
private boolean registered;
此外還需要注意一個static字段:
private static final FastThreadLocal<Map<Class<?>, String>> nameCaches =
initialValue() -> { return new WeakHashMap<Class<?>, String>(); };
這是一個Netty內(nèi)部定義的FastThreadLocal變量,以后會分析它的實現(xiàn),現(xiàn)在先了解這樣的事實:nameCaches是一個線程本地(局部)變量,也就是說每個線程都存有一份該變量,該變量是一個WeakHashMap,其中存放的是ChannelHandler的Class與字符串名稱的映射關系。簡單說就是每個線程都有一份Handler的Class與字符串名稱的映射關系,之所以這樣是為了避免使用復雜的CurrentHashMap也能實現(xiàn)并發(fā)安全。
首先看我們常用的addLast()方法:
public final ChannelPipeline addLast(EventExecutorGroup group, String name,
ChannelHandler handler) {
final AbstractChannelHandlerContext newCtx;
synchronized (this) {
// 檢查Handler是否重復添加
checkMultiplicity(handler);
// 新建一個Context
newCtx = newContext(group, filterName(name, handler), handler);
// 實際的雙向鏈表插入操作
addLast0(newCtx);
if (!registered) {
// 此時Channel還沒注冊的EventLoop中,而Netty的原則是事件在同一個EventLoop執(zhí)行,
// 所以新增一個任務用于注冊后添加
newCtx.setAddPending();
callHandlerCallbackLater(newCtx, true);
return this;
}
EventExecutor executor = newCtx.executor();
if (!executor.inEventLoop()) {
// 當前線程不是EventLoop線程
newCtx.setAddPending();
executor.execute( () -> { callHandlerAdded0(newCtx); } );
return this;
}
}
// 當前線程為EventLoop線程且已注冊則直接觸發(fā)HandlerAdd事件
callHandlerAdded0(newCtx);
return this;
}
public final ChannelPipeline addLast(String name, ChannelHandler handler) {
// 線程池為null則使用channel注冊到的EventLoop
return addLast(null, name, handler);
}
先看其中的checkMultiplicity()方法,功能是保證ChannelPipeline中至多只有一個同一類型的非共享Handler,代碼如下:
private static void checkMultiplicity(ChannelHandler handler) {
if (handler instanceof ChannelHandlerAdapter) { // 為什么只對Adapter?
ChannelHandlerAdapter h = (ChannelHandlerAdapter) handler;
if (!h.isSharable() && h.added) {
// 非共享且已被添加到pipeline中
throw new ChannelPipelineException("...");
}
h.added = true;
}
}
filterName()方法對Handler名稱進行重復檢查,generateName()生成形如:HandlerClassName#0、HandlerClassName#1的Handler字符串名稱,checkDuplicateName()檢查名稱是否已使用,也就是說pipeline中Handler的名稱也要求滿足唯一性。代碼如下:
private String filterName(String name, ChannelHandler handler) {
if (name == null) {
return generateName(handler);
}
checkDuplicateName(name);
return name;
}
checkDuplicateName()代碼如下:
private void checkDuplicateName(String name) {
if (context0(name) != null) {
throw new IllegalArgumentException("Duplicate handler name: " + name);
}
}
// 雙向鏈表中查找是否已有該名稱的context
private AbstractChannelHandlerContext context0(String name) {
AbstractChannelHandlerContext context = head.next;
while (context != tail) {
if (context.name().equals(name)) {
return context;
}
context = context.next;
}
return null;
}
generateName()代碼如下:
private String generateName(ChannelHandler handler) {
Map<Class<?>, String> cache = nameCaches.get(); // 獲得ThreadLocal變量
Class<?> handlerType = handler.getClass();
String name = cache.get(handlerType);
if (name == null) {
name = generateName0(handlerType); // 生成HandlerClassName#0
cache.put(handlerType, name);
}
// HandlerClassName#0已有,則末尾編號加1
if (context0(name) != null) {
String baseName = name.substring(0, name.length() - 1);
for (int i = 1;; i ++) {
String newName = baseName + i;
if (context0(newName) == null) {
name = newName;
break;
}
}
}
return name;
}
// 生成HandlerClassName#0
private static String generateName0(Class<?> handlerType) {
return StringUtil.simpleClassName(handlerType) + "#0";
}
再看newContext()方法,返回一個默認Contenxt,其構造方法需要傳入一個EventExecutor用于執(zhí)行Handler中事件處理代碼。childExecutor()正是用來從線程池中分配這個EventExecutor,代碼如下:
private AbstractChannelHandlerContext newContext(EventExecutorGroup group, String name, ChannelHandler handler) {
return new DefaultChannelHandlerContext(this, childExecutor(group), name, handler);
}
private EventExecutor childExecutor(EventExecutorGroup group) {
if (group == null) {
return null;
}
Boolean pinEventExecutor = channel.config().getOption(ChannelOption.SINGLE_EVENTEXECUTOR_PER_GROUP);
if (pinEventExecutor != null && !pinEventExecutor) {
// Channel參數(shù)配置非同一個線程處理,不建議開啟
return group.next();
}
Map<EventExecutorGroup, EventExecutor> childExecutors = this.childExecutors;
if (childExecutors == null) {
childExecutors = this.childExecutors = new IdentityHashMap<EventExecutorGroup, EventExecutor>(4);
}
// 保證pipeline中的事件為同一個EventExecutor處理,可視為將EventExecutor綁定到pipeline
EventExecutor childExecutor = childExecutors.get(group);
if (childExecutor == null) {
childExecutor = group.next();
childExecutors.put(group, childExecutor);
}
return childExecutor;
}
接著看實際的雙向鏈表插入操作addLast0()操作:
private void addLast0(AbstractChannelHandlerContext newCtx) {
AbstractChannelHandlerContext prev = tail.prev;
newCtx.prev = prev;
newCtx.next = tail;
prev.next = newCtx;
tail.prev = newCtx;
}
DefaultChannelPipeline的雙向鏈表初始化持有頭部和尾部節(jié)點,這兩個節(jié)點對用戶不可見,也就是說,用戶addLast只是將節(jié)點插入尾部節(jié)點之前,addFirst將節(jié)點插入頭部節(jié)點之后。明白了這些,代碼便易于理解。
接著看callHandlerCallbackLater()方法,當我們在Channel注冊到之前添加或刪除Handler時,此時沒有EventExecutor可執(zhí)行HandlerAdd或HandlerRemove事件,所以Netty為此事件生成一個相應任務等注冊完成后在調(diào)用執(zhí)行任務。添加或刪除任務可能有很多個,DefaultChannelPipeline使用一個鏈表存儲,鏈表頭部為先前的字段pendingHandlerCallbackHead
,代碼如下:
// 參數(shù)added為True表示HandlerAdd任務,F(xiàn)alse表示HandlerRemove任務
private void callHandlerCallbackLater(AbstractChannelHandlerContext ctx, boolean added) {
assert !registered; // 必須非注冊
PendingHandlerCallback task = added ? new PendingHandlerAddedTask(ctx) : new PendingHandlerRemovedTask(ctx);
PendingHandlerCallback pending = pendingHandlerCallbackHead;
if (pending == null) {
pendingHandlerCallbackHead = task; // 鏈表頭部
} else { // 插入到鏈表尾部
while (pending.next != null) {
pending = pending.next;
}
pending.next = task;
}
}
以HandlerAdd任務為例分析任務部分的代碼(HandlerRemove可類比):
private abstract static class PendingHandlerCallback implements Runnable {
final AbstractChannelHandlerContext ctx;
PendingHandlerCallback next;
PendingHandlerCallback(AbstractChannelHandlerContext ctx) { this.ctx = ctx;}
abstract void execute();
}
private final class PendingHandlerAddedTask extends PendingHandlerCallback {
PendingHandlerAddedTask(AbstractChannelHandlerContext ctx) { super(ctx);}
@Override
public void run() {
callHandlerAdded0(ctx);
}
@Override
void execute() {
EventExecutor executor = ctx.executor();
if (executor.inEventLoop()) {
// 當前線程為EventLoop線程,調(diào)用HandlerAdd事件
callHandlerAdded0(ctx);
} else {
try {
executor.execute(this); // 否則提交一個任務,任務執(zhí)行run()方法
} catch (RejectedExecutionException e) {
logger.warn("...");
remove0(ctx); // 異常時,將已添加的Handler刪除
ctx.setRemoved();
}
}
}
}
callHandlerAdded0()方法執(zhí)行實際的調(diào)用事件操作,作為addLast()的最后一個方法,代碼如下:
private void callHandlerAdded0(final AbstractChannelHandlerContext ctx) {
try {
ctx.handler().handlerAdded(ctx); // 調(diào)用事件處理
ctx.setAddComplete();
} catch (Throwable t) {
boolean removed = false; // 異常時刪除Context,盡量恢復現(xiàn)場
try {
remove0(ctx); // 實際雙向鏈表刪除操作
try {
ctx.handler().handlerRemoved(ctx); // 調(diào)用事件處理
} finally {
ctx.setRemoved();
}
removed = true;
} catch (Throwable t2) {
logger.warn("Failed to remove a handler: " + ctx.name(), t2);
}
if (removed) {
fireExceptionCaught(new ChannelPipelineException("handlerAdded() has thrown an exception; removed."));
} else {
fireExceptionCaught(new ChannelPipelineException("handlerAdded() has thrown an exception; also failed to remove."));
}
}
}
終于分析完addLast()方法,我們經(jīng)常使用的不起眼一行代碼,背后的流程卻很長。分析完這個方法的代碼,其他方法的代碼,我們可推斷:remove()作為addXXX()的逆方法,其處理過程可推斷為:找到對應Context節(jié)點,執(zhí)行實際的雙向鏈表刪除操作,如果非注冊則新增一個HandlerRemove任務并鏈接到任務鏈表尾部,如果已注冊但Context需求線程非EventLoop,提交一個調(diào)用任務到需求線程,如果已注冊且需求線程為EventLoop直接調(diào)用事件處理。first()返回的是鏈表頭部的下一個Handler即用戶可見的首個Handler,last()返回鏈表尾部的前一個Handler即用戶可見的最后一個Handler,firstContext()和lastContext()同理,只是返回Context。get(handlerName)返回相應名稱的Handler,context(handerlNmae)返回相應名稱的Context,操作都是從雙向鏈表頭部進行遍歷查找。
再看一下fireXXX方法和bind等事件觸發(fā)方法的代碼:
@Override
public final ChannelPipeline fireChannelRegistered() {
// 入站事件從雙向鏈表頭部處理
AbstractChannelHandlerContext.invokeChannelRegistered(head);
return this;
}
@Override
public final ChannelFuture bind(SocketAddress localAddress, ChannelPromise promise) {
// 出站事件從雙向鏈表尾部處理
return tail.bind(localAddress, promise);
}
由于頭部和尾部節(jié)點都是ChannelHandlerContext,具體的事件觸發(fā)處理都委托給head和tail處理,將在之后一節(jié)進行分析。至此,接口中的方法已分析完畢,是不是還差點什么?仔細回想一下,在addXXX()方法中有待執(zhí)行的HandlerAdd和HandlerRemove任務,它們怎么執(zhí)行的呢?DefaultChannelPipeline提供了invokeHandlerAddedIfNeeded()方法:
final void invokeHandlerAddedIfNeeded() {
assert channel.eventLoop().inEventLoop();
if (firstRegistration) {
firstRegistration = false;
// 至此,channel已注冊到EventLoop,可以執(zhí)行任務
callHandlerAddedForAllHandlers();
}
}
private void callHandlerAddedForAllHandlers() {
final PendingHandlerCallback pendingHandlerCallbackHead;
synchronized (this) {
assert !registered; // 必須為非注冊
registered = true; // 至此則說明已注冊
pendingHandlerCallbackHead = this.pendingHandlerCallbackHead;
this.pendingHandlerCallbackHead = null; // 幫助垃圾回收
}
// 用一個局部變量保存任務鏈表頭部是因為以下代碼如果在synchronized塊內(nèi),則當用戶在
// 非EventLoop中執(zhí)行HandlerAdd()方法而該方法中又新增一個handler時不會發(fā)生死鎖
PendingHandlerCallback task = pendingHandlerCallbackHead;
while (task != null) {
task.execute(); // 遍歷鏈表依次執(zhí)行
task = task.next;
}
}
invokeHandlerAddedIfNeeded()方法在以下兩種情況被調(diào)用:(1).AbstractUnsafe的register事件框架,當Channel注冊到EventLoop之前會被調(diào)用,確保異步注冊操作一旦完成就觸發(fā)HandlerAdd事件;(2).雙向鏈表頭部節(jié)點的channelRegistered()方法(為什么此時調(diào)用,雙重保護?)。
DefaultChannelPipeline還有最后一個方法destroy(),將pipeline中的所有節(jié)點銷毀,順序由尾部向頭部并觸發(fā)HandlerRemove事件,代碼如下:
private synchronized void destroy() {
destroyUp(head.next, false);
}
// 參數(shù)inEventLoop應理解為是否直接執(zhí)行本段代碼的for循環(huán)部分,也就是說為true時不需要提交
// 一個destroyUp任務,為False時則需要判斷Handler的執(zhí)行線程是否為EventLoop線程
private void destroyUp(AbstractChannelHandlerContext ctx, boolean inEventLoop) {
final Thread currentThread = Thread.currentThread();
final AbstractChannelHandlerContext tail = this.tail;
for (;;) {
if (ctx == tail) {
destroyDown(currentThread, tail.prev, inEventLoop);
break;
}
final EventExecutor executor = ctx.executor();
if (!inEventLoop && !executor.inEventLoop(currentThread)) {
final AbstractChannelHandlerContext finalCtx = ctx;
// destroyUp()的for循環(huán)部分需在executor內(nèi)執(zhí)行,所以置True
executor.execute( () -> { destroyUp(finalCtx, true); } );
break;
}
ctx = ctx.next;
inEventLoop = false; // 每次都悲觀的認為下一個Handler的處理線程會是另外一個線程
}
}
private void destroyDown(Thread currentThread, AbstractChannelHandlerContext ctx, boolean inEventLoop) {
// 至此,已經(jīng)到達雙向鏈表尾部,可確定入站事件已在刪除操作進行之前傳播完畢
final AbstractChannelHandlerContext head = this.head;
for (;;) {
if (ctx == head) {
break;
}
// 這部分代碼實質(zhì)與up部分一致,采用兩種表現(xiàn)形式容易引起困惑
// 本質(zhì)上 (!a && !b) == (a || b)
final EventExecutor executor = ctx.executor();
if (inEventLoop || executor.inEventLoop(currentThread)) {
synchronized (this) {
remove0(ctx);
}
callHandlerRemoved0(ctx);
} else {
final AbstractChannelHandlerContext finalCtx = ctx;
executor.execute(() -> { destroyDown(Thread.currentThread(), finalCtx, true); });
break;
}
ctx = ctx.prev;
inEventLoop = false;
}
}
這部分代碼晦澀難懂,考慮這樣一種情況,當我們由尾部向頭部刪除節(jié)點時,有一個入站事件正從頭部向尾部傳播,由于從尾部開始刪除了某些節(jié)點,入站事件的處理流程被破壞。這部分代碼正是為了處理這種情況,所以首先從頭部向尾部遍歷,確保沒有入站事件,此時才從尾部向頭部進行刪除銷毀操作。
這部分代碼還為了保證事件在正確的線程中執(zhí)行,假設有如下pipeline:
HEAD --> [E1] H1 --> [E2] H2 --> TAIL
其中E1和E2為兩個線程,則必須保證Handler1中的事件在E1執(zhí)行,Handler2中的事件在E2執(zhí)行,而Head和Tail的事件在Channel注冊到的EventLoop中執(zhí)行。