摘要：如果有處理耗時任務的應該怎么辦可以專門開一個線程池，來專門處理耗時業務。如果是在線程，如果想處理耗時任務邏輯，那么就需要新建一個并調用他的相關方法其本質是一個用來處理事件的線程，其本質是一個線程池。

netty 處理耗時的任務邏輯，是不能在IO線程處理，因為這會造成堵塞，將會嚴重影響性能。那怎么區分IO線程呢?
答案就是EventLoop，EventLoop用來處理IO線程，因此耗時任務的handler不要在EventLoop里面處理。
以下面代碼為例：

 bossGroup = new NioEventLoopGroup();
 workerGroup = new NioEventLoopGroup();

 try {
    ServerBootstrap bootstrap = new ServerBootstrap();
    bootstrap.group(bossGroup, workerGroup).channel(NioServerSocketChannel.class)
 ....

其中workerGroup就是專門用來處理IO線程業務邏輯的，例如執行一些 編碼、解碼 等不耗時的業務處理。

如果有處理耗時任務的handler應該怎么辦？
可以專門開一個線程池，來專門處理耗時業務。Netty Api 已經提供了一些說明，http://netty.io/4.1/api/index...，ChannelPipeline中 可以找到如下描述：

A user is supposed to have one or more ChannelHandlers in a pipeline to receive I/O events (e.g. read) and to request I/O operations (e.g. write and close). For example, a typical server will have the following handlers in each channel"s pipeline, but your mileage may vary depending on the complexity and characteristics of the protocol and business logic:

Protocol Decoder - translates binary data (e.g. ByteBuf) into a Java object.
Protocol Encoder - translates a Java object into binary data.
Business Logic Handler - performs the actual business logic (e.g. database access).
and it could be represented as shown in the following example:
static final EventExecutorGroup group = new DefaultEventExecutorGroup(16);
...

ChannelPipeline pipeline = ch.pipeline();

 pipeline.addLast("decoder", new MyProtocolDecoder());

 pipeline.addLast("encoder", new MyProtocolEncoder());

 // Tell the pipeline to run MyBusinessLogicHandler"s event handler methods
 // in a different thread than an I/O thread so that the I/O thread is not blocked by
 // a time-consuming task.
 // If your business logic is fully asynchronous or finished very quickly, you don"t
 // need to specify a group.
 pipeline.addLast(group, "handler", new MyBusinessLogicHandler());

其中EventExecutorGroup 就是專門來處理耗時業務的線程池。

在實際生產環境中，我們可能會碰到 需要臨時執行也行計劃任務，，這些任務如果不耗時，我們可以通過channel提供的計劃任務方法處理：

future =  channel.eventLoop.scheduleAtFixedRate(new Runnable() {

            @Override
            public void run() {
                            //邏輯代碼，非耗時任務
               }
        }, 6, 6, TimeUnit.HOURS);
       ....

如果計劃任務里面的邏輯比較耗時，那么就不能再用eventLoop，因為這會阻塞IO線程。如果是通過pipeline.addLast(group, "handler", new MyBusinessLogicHandler()); 這種方式添加的業務線程我們可以使用下面的方式添加計劃任務方法實現：

***future = ctx.executor().scheduleAtFixedRate(new Runnable() {
            @Override
            public void run() {
            }
        }, 6, 6, TimeUnit.HOURS);***

...

netty 源碼

public EventExecutor executor() {
        return (EventExecutor)(this.executor == null？this.channel().eventLoop():this.executor);
    }

如果this.executor為null，就返回channel().eventLoop()，這個是io讀寫線程,肯定是不能執行耗時任務的。
如果不為空，那么是怎么傳進來的呢?

DefaultChannelPipeline

public final ChannelPipeline addLast(EventExecutorGroup group, String name, ChannelHandler handler) {
        final AbstractChannelHandlerContext newCtx;
        synchronized(this) {
            checkMultiplicity(handler);
            newCtx = this.newContext(group, this.filterName(name, handler), handler);

DefaultChannelPipeline 的addLast(EventExecutorGroup group, String name, ChannelHandler handler)為例，該方法部分源碼如下

    @Override
    public final ChannelPipeline addLast(EventExecutorGroup group, String name, ChannelHandler handler) {
        final AbstractChannelHandlerContext newCtx;
        synchronized (this) {
            checkMultiplicity(handler);

            newCtx = newContext(group, filterName(name, handler), handler);

            addLast0(newCtx);
   ...代碼略去...

private AbstractChannelHandlerContext newContext(EventExecutorGroup group, String name, ChannelHandler handler) {
        return new DefaultChannelHandlerContext(this, this.childExecutor(group), name, handler);
    }

通過源碼發現：其實就是我們在添加handler時指定的DefaultEventExecutorGroup。
、所以結論是：如果在處理耗時任務的Handler添加時用到了DefaultEventExecutorGroup是可以 ctx.executor().scheduleAtFixedRate這么用的，但是如果你再添加handler時沒有沒有指定特殊的EventExecutorGroup，是不能執行耗時任務的。

如果是在IO線程，如果想處理耗時任務邏輯，那么就需要新建一個EventExecutorGroup,并調用他的相關方法

EventLoop:其本質是一個用來處理IO事件的線程，EventLoopGroup 其本質是一個線程池。一個EventLoop可以和多個Channel綁定，處理多個Channel的IO事件；但是一個Channel在整個生命周期內只會被一個EventLoop處理，這就也就保證了線程安全。