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í)行。