spring-- 事务--9

一、Mina中的线程池模型

前面介绍了Mina总体的层次结构，那么在Mina里面是怎么使用Java NIO和进行线程调度的呢？这是提高IO处理性能的关键所在。Mina的线程调度原理主要如下图所示：

Acceptor与Connector线程

在服务器端，bind一个端口后，会创建一个Acceptor线程来负责监听工作。这个线程的工作只有一个，调用Java NIO接口在该端口上select connect事件，获取新建的连接后，封装成IoSession，交由后面的Processor线程处理。在客户端，也有一个类似的，叫Connector的线程与之相对应。这两类线程的数量只有1个，外界无法控制这两类线程的数量。

TCP实现的代码可以参考org.apache.mina.core.polling.AbstractPollingIoAcceptor的内部类Acceptor和org.apache.mina.core.polling.AbstractPollingIoConnector的内部类Connector。

Processor线程

Processor线程主要负责具体的IO读写操作和执行后面的IoFilterChain和IoHandler逻辑。Processor线程的数量N默认是CPU数量+1，可以通过配置参数来控制其数量。前面进来的IoSession会被分配到这N个Processor线程中。默认的SimpleIoProcessorPool的策略是session id绝对值对N取模来分配。

每个Porcessor线程中都维护着一个selector，对它维护的IoSession集合进行select，然后对select的结果进行遍历，逐一处理。像前面提到的，读取数据，以事件的形式通知后面IoFilterChain；以及对写请求队列的flush操作，都是在这类线程中来做的。

通过将session均分到多个Processor线程里进行处理，可以充分利用多核的处理能力，减轻select操作的压力。默认的Processor的线程数量设置可以满足大部分情况下的需求，但进一步的优化则需要根据实际环境进行测试。

线程模型

线程模型原理

从单一的Processor线程内部来看，IO请求的处理流程是单线程顺序处理的。前面也提到过，当Process线程select了一批就绪的IO请求后，会在线程内部逐一对这些IO请求进行处理。处理的流程包括IoFilter和IoHandler里的逻辑。当前面的IO请求处理完毕后，才会取下一个IO请求进行处理。也就是说，如果IoFilter或IoHandler中有比较耗时的操作的话（如：读取数据库等），Processor线程将会被阻塞住，后续的请求将得不到处理。这样的情况在高并发的服务器下显然是不能容忍的。于是，Mina通过在处理流程中引入线程池来解决这个问题。

那么线程池应该加在什么地方呢？正如前面所提到过的：IoFilterChain是Mina的扩展点。没错，Mina里是通过IoFilter的形式来为处理流程添加线程池的。Mina的线程模型主要有一下这几种形式：

第一种模型是单线程模型，也是Mina默认线程模型。也就是Processor包办了从底层IO到上层的IoHandler逻辑的所有执行工作。这种模型比较适合于处理逻辑简单，能快速返回的情况。

第二种模型则是在IoFilterChain中加入了Thread Pool Filter。此时的处理流程变为Processor线程读取完数据后，执行IoFilterChain的逻辑。当执行到Thread Pool Filter的时候，该Filter会将后续的处理流程封装到一个Runnable对象中，并交由Filter自身的线程池来执行，而Processor线程则能立即返回来处理下一个IO请求。这样如果后面的IoFilter或IoHandler中有阻塞操作，只会引起Filter线程池里的线程阻塞，而不会阻塞住Processor线程，从而提高了服务器的处理能力。Mina提供了Thread Pool Filter的一个实现：ExecutorFilter。

当然，也没有限制说chain中只能添加一个ExecutorFilter，开发者也可以在chain中加入多个ExecutorFilter来构成第三种情况，但一般情况下可能没有这个必要。

请求的处理顺序

在处理流程中加入线程池，可以较好的提高服务器的吞吐量，但也带来了新的问题：请求的处理顺序问题。在单线程的模型下，可以保证IO请求是挨个顺序地处理的。加入线程池之后，同一个IoSession的多个IO请求可能被ExecutorFilter并行的处理，这对于一些对请求处理顺序有要求的程序来说是不希望看到的。比如：数据库服务器处理同一个会话里的prepare，execute，commit请求希望是能按顺序逐一执行的。

Mina里默认的实现是有保证同一个IoSession中IO请求的顺序的。具体的实现是，ExecutorFilter默认采用了Mina提供的OrderedThreadPoolExecutor作为内置线程池。后者并不会立即执行加入进来的Runnable对象，而是会先从Runnable对象里获取关联的IoSession(这里有个down cast成IoEvent的操作)，并将Runnable对象加入到session的任务列表中。OrderedThreadPoolExecutor会按session里任务列表的顺序来处理请求，从而保证了请求的执行顺序。

对于没有顺序要请求的情况，可以为ExecutorFilter指定一个Executor来替换掉默认的OrderedThreadPoolExecutor，让同一个session的多个请求能被并行地处理，来进一步提高吞吐量。

read  in  data： 
IO读入（IoProcessor）---日志记录、解码、threadPool（IoFilter）---业务逻辑处理（IoHandler） 
write  out  data： 
业务逻辑处理（IoHandler）---日志记录、编码、threadPool（IoFilter）---IO写出（IoProcessor） 
由以上可以看出，IO读入和IO写出的过程是相反的。

二、mina框架中的线程池

Mina中的线程池使用主要有四个地方：

1、IoAcceptor线程池。（一个端口一个线程）不可配置

2、IoConnector线程池。（一个端口一个线程）不可配置

3、IoProcessor线程池。可配置

4、过滤器类ExecutorFilter线程池。可配置（可以配置线程，也可以不配置，如果不配置则业务逻辑处理将共用IoProcessor线程）

2.1、IoAcceptor/IoConnector线程

2.1.1、线程类型及配置：

　　线程类型newCachedThreadPool。

　　 IoAcceptor用于监听客户端的连接，每监听一个端口建立一个线程。IoConnector用于与服务端建立连接，每连接一个服务端就建立一个线程。这两种线程都是通过线程池建立的，我们可以在构建对象的时候就指定线程池类型：

public NioSocketAcceptor(Executor executor, IoProcessor<NioSession> processor) {}
public NioSocketConnector(Executor executor, IoProcessor<NioSession> processor) {}  

2.1.2、线程创建：

此类线程池的构造在源代码中为（AbstractIoService第168行）：

由此可见默认的线程池类型为newCachedThreadPool，这是一个可根据需要创建新线程的线程池，在以前构造的线程可用时可以重用它们。

2.1.3、提交任务作业方法：

对于IoAcceptor提交任务的方法链：AbstractIoAccepter.bind(Iterable<? extends SocketAddress> localAddresses)-->AbstractPollingAccepter.bindInternal(List<? extends SocketAddress> localAddresses)-->AbstractPollingAccepter.startupAcceptor()-->AbstractIoService.executeWorker()

AbstractIoService.executeWorker()：

protected final void executeWorker(Runnable worker, String suffix) {
    String actualThreadName = threadName;
    if (suffix != null) {
        actualThreadName = actualThreadName + '-' + suffix;
    }
    // 向线程池中提交任务。
    executor.execute(new NamePreservingRunnable(worker, actualThreadName));
}

对于IoAcceptor的任务提交调用是在bind和unbind方法实现中的，看下bind最终调用，在类AbstractPollingIoAcceptor的startupAcceptor方法中：

AbstractPollingIoAcceptor

private void startupAcceptor() throws InterruptedException {
        // If the acceptor is not ready, clear the queues
        // TODO : they should already be clean : do we have to do that ?
        if (!selectable) {
            registerQueue.clear();
            cancelQueue.clear();
        }
 
        // start the acceptor if not already started
        Acceptor acceptor = acceptorRef.get();
 
        if (acceptor == null) {
            lock.acquire();
            acceptor = new Acceptor();
 
            if (acceptorRef.compareAndSet(null, acceptor)) {
                executeWorker(acceptor);
            } else {
                lock.release();
            }
        }
    }

AbstractPollingIoAcceptor.bindInternal()和

protected final Set<SocketAddress> bindInternal(List<? extends SocketAddress> localAddresses) throws Exception {
        // Create a bind request as a Future operation. When the selector
        // have handled the registration, it will signal this future.
        AcceptorOperationFuture request = new AcceptorOperationFuture(localAddresses);
 
        // adds the Registration request to the queue for the Workers
        // to handle
        registerQueue.add(request);
 
        // creates the Acceptor instance and has the local
        // executor kick it off.
        startupAcceptor();
 
        // As we just started the acceptor, we have to unblock the select()
        // in order to process the bind request we just have added to the
        // registerQueue.
        try {
            lock.acquire();
 
            // Wait a bit to give a chance to the Acceptor thread to do the select()
            Thread.sleep(10);
            wakeup();
        } finally {
            lock.release();
        }
 
        // Now, we wait until this request is completed.
        request.awaitUninterruptibly();
 
        if (request.getException() != null) {
            throw request.getException();
        }
 
        // Update the local addresses.
        // setLocalAddresses() shouldn't be called from the worker thread
        // because of deadlock.
        Set<SocketAddress> newLocalAddresses = new HashSet<SocketAddress>();
 
        for (H handle : boundHandles.values()) {
            newLocalAddresses.add(localAddress(handle));
        }
 
        return newLocalAddresses;
    }

AbstractPollingIoAcceptor.unbind0(List<? extends SocketAddress> localAddresses)

    protected final void unbind0(List<? extends SocketAddress> localAddresses) throws Exception {
        AcceptorOperationFuture future = new AcceptorOperationFuture(localAddresses);
 
        cancelQueue.add(future);
        startupAcceptor();
        wakeup();
 
        future.awaitUninterruptibly();
        if (future.getException() != null) {
            throw future.getException();
        }

AbstractIoAccepter.bind()和AbstractIoAccepter.unbind()

public final void bind(Iterable<? extends SocketAddress> localAddresses) throws IOException {
        if (isDisposing()) {
            throw new IllegalStateException("Already disposed.");
        }
 
        if (localAddresses == null) {
            throw new IllegalArgumentException("localAddresses");
        }
 
        List<SocketAddress> localAddressesCopy = new ArrayList<SocketAddress>();
 
        for (SocketAddress a : localAddresses) {
            checkAddressType(a);
            localAddressesCopy.add(a);
        }
 
        if (localAddressesCopy.isEmpty()) {
            throw new IllegalArgumentException("localAddresses is empty.");
        }
 
        boolean activate = false;
        synchronized (bindLock) {
            synchronized (boundAddresses) {
                if (boundAddresses.isEmpty()) {
                    activate = true;
                }
            }
 
            if (getHandler() == null) {
                throw new IllegalStateException("handler is not set.");
            }
 
            try {
                Set<SocketAddress> addresses = bindInternal(localAddressesCopy);
 
                synchronized (boundAddresses) {
                    boundAddresses.addAll(addresses);
                }
            } catch (IOException e) {
                throw e;
            } catch (RuntimeException e) {
                throw e;
            } catch (Throwable e) {
                throw new RuntimeIoException("Failed to bind to: " + getLocalAddresses(), e);
            }
        }
 
        if (activate) {
            getListeners().fireServiceActivated();
        }
    }

再看下IoConnector，它最终是在方法connect时会提交任务，看下AbstractPollingIoConnector类的startupWorker方法：

if (connector == null) {
    connector = new Connector();  
 
    if (connectorRef.compareAndSet(null, connector)) {
        //提交执行任务
        executeWorker(connector);
    }
}  

对于IoAcceptor和IoConnector线程池的线程池大小，一般来说一个对象里面只有一个线程池，一个线程池里面一般有一个线程，当然如果你的连接或者监听比较多时可能会自动增加线程，这个就看线程池自己分配了。

2.2、IoProcessor线程

2.2.1、线程类型及配置：

　　对于一个IoAcceptor或IoConnector线程对应一个IoProcessor线程用于IO的处理，这个IoProcessor线程从IoProcessor线程池中取出。IoProcessor线程池的大小默认为机器的CPU核数+1，例如双核机器的IoProcessor的线程池大小默认为3，我们可以更改线程池的大小：

看下面的构造方法，可知使用的是newCachedThreadPool。

2.2.2、线程创建：

如上就把IoProcessor线程池的大小改为9个。 
IoProcessor线程池的默认大小在源代码中的定义（SimpleIoProcessorPool第82行）：

IoProcessor线程池的构造在源代码中为（SimpleIoProcessorPool第144行）：

public SimpleIoProcessorPool(Class<? extends IoProcessor<S>> processorType,
            Executor executor, int size) {
        //省略部分代码
        if (createdExecutor) {
            this.executor = Executors.newCachedThreadPool();
        } else {
            this.executor = executor;
        }
} 

2.2.3、提交任务作业方法：

提交任务的方法链：SimpleIoProcessorPool.add(S session)-->AbstractPollingIoProcessor.add(S session)/remove(S session)/dispose()-->AbstractPollingIoProcessor.startupProcessor()。x下面是一些关键方法的源码：

AbstractPollingIoProcessor.startupProcessor()

    private void startupProcessor() {
        Processor processor = processorRef.get();
 
        if (processor == null) {
            processor = new Processor();
 
            if (processorRef.compareAndSet(null, processor)) {
                executor.execute(new NamePreservingRunnable(processor, threadName));
            }
        }
 
        // Just stop the select() and start it again, so that the processor
        // can be activated immediately.
        wakeup();
    }

AbstractPollingIoProcessor.add(S session)

public final void add(S session) {
        if (disposed || disposing) {
            throw new IllegalStateException("Already disposed.");
        }
 
        // Adds the session to the newSession queue and starts the worker
        newSessions.add(session);
        startupProcessor();
    }

SimpleIoProcessorPool.add(S session)

    public final void add(S session) {
        getProcessor(session).add(session);
    }

2.3、IoHandler线程

　　ExecutorFilter类中的线程池。这是一个可选的线程池，是加在过滤器当中的。我们一般选择加在过滤器的最后面，这样Handler里面的业务处理就可以在线程池里面进行处理了。它的默认大小是16。

2.3.1、线程类型及配置：

线程类型：默认是OrderedThreadPoolExecutor（OrderedThreadPoolExecutor extends ThreadPoolExecutor的自定义线程池）

2.3.2、线程创建：

　　当我们在过滤器链中没有添加“threadPool”过滤器，则业务逻辑处理和IoProcessor使用同一个线程。如果设置了“threadPool”过滤器，则使用设置的线程池产生线程进行业务逻辑处理，过滤器的配置如下：

    public ExecutorFilter() {
        // Create a new default Executor
        Executor executor = createDefaultExecutor(BASE_THREAD_NUMBER, DEFAULT_MAX_POOL_SIZE, DEFAULT_KEEPALIVE_TIME,
                TimeUnit.SECONDS, Executors.defaultThreadFactory(), null);
 
        // Initialize the filter
        init(executor, MANAGEABLE_EXECUTOR);
    }

默认的池大小是16，默认的Executor的创建方式：

    private Executor createDefaultExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit,
            ThreadFactory threadFactory, IoEventQueueHandler queueHandler) {
        // Create a new Executor
        Executor executor = new OrderedThreadPoolExecutor(corePoolSize, maximumPoolSize, keepAliveTime, unit,
                threadFactory, queueHandler);
 
        return executor;
    }

也可以自定义不同类型的线程池及池大小，如下：

如上配置之后，IO处理和业务逻辑处理将会使用各自的线程池产生线程使用。如果你的应用每次处理请求的时间较长而又希望应用能够有较好的响应性，那么最好是把处理业务逻辑的任务放到一个新的线程中去执行，而不是在 mina 框架创建的线程中去执行。

2.3.3、提交任务作业方法：

提交任务的方法链：DefaultIoFilterChain.callNextMessageReceived(Entry entry, IoSession session, Object message)

-->ExecutorFilter.messageReceived(NextFilter nextFilter, IoSession session, Object message)

-->ExecutorFilter.fireEvent(IoFilterEvent event)

    protected void fireEvent(IoFilterEvent event) {
        executor.execute(event);
    }

ExecutorFilter.messageReceived(NextFilter nextFilter, IoSession session, Object message)

    public final void messageReceived(NextFilter nextFilter, IoSession session, Object message) {
        if (eventTypes.contains(IoEventType.MESSAGE_RECEIVED)) {
            IoFilterEvent event = new IoFilterEvent(nextFilter, IoEventType.MESSAGE_RECEIVED, session, message);
            fireEvent(event);
        } else {
            nextFilter.messageReceived(session, message);
        }
    }

DefaultIoFilterChain.callNextMessageReceived(Entry entry, IoSession session, Object message)

    private void callNextMessageReceived(Entry entry, IoSession session, Object message) {
        try {
            IoFilter filter = entry.getFilter();
            NextFilter nextFilter = entry.getNextFilter();
            filter.messageReceived(nextFilter, session, message);
        } catch (Throwable e) {
            fireExceptionCaught(e);
        }
    }

2.4各种线程的产生

• 当 IoAcceptor/IoConnector实例创建的时候，同时一个关联在IoAcceptor/IoConnector上的IoProcessor线程池也被创建。
• 当IoAcceptor/IoConnector建立套接字（IoAcceptor 的bind()或者是IoConnector 的connect()方法被调用）时，从线程池中取出一个线程，监听套接字端口。
• 当 IoAcceptor/IoConnector监听到套接字上有连接请求时，建立IoSession 对象，从IoProcessor池中取出一个IoProcessor线程执行IO处理。
• 如若过滤器中配置了“threadPool”过滤器，则使用此线程池建立线程执行业务逻辑（IoHandler）处理，否则使用IoProcessor线程处理业务逻辑。

3线程查看 
举个例子通过jdk自带工具jvisualvm来查看线程：

1. public class MinaTest {
2. protected static Logger logger = LoggerFactory.getLogger(MinaTest.class);
3. private static int PORT = 9999;
4. public static void main(String[] args) {
5. try {
6. // 创建一个非阻塞的server端的Socket
7. IoAcceptor acceptor = new NioSocketAcceptor();
8. // 设置过滤器
9. acceptor.getFilterChain().addLast("logger", new LoggingFilter());
10. acceptor.getFilterChain().addLast("codec",
11. new ProtocolCodecFilter(new TextLineCodecFactory(Charset.forName("UTF-8"))));
12. acceptor.getFilterChain().addLast("threadPool", new ExecutorFilter(Executors.newCachedThreadPool()));
13. // 设置读取数据的缓冲区大小
14. acceptor.getSessionConfig().setReadBufferSize(2048);
15. // 读写通道10秒内无操作进入空闲状态
16. acceptor.getSessionConfig().setIdleTime(IdleStatus.BOTH_IDLE, 10);
17. // 绑定逻辑处理器
18. acceptor.setHandler(new MinaServerHandler());
19. // 绑定端口
20. acceptor.bind(new InetSocketAddress(PORT));
21. logger.info("服务端启动成功... 端口号为：" + PORT);
22. } catch (Exception e) {
23. logger.error("服务端启动异常....", e);
24. e.printStackTrace();
25. }
26. }
27. }

1. public class MinaServerHandler extends IoHandlerAdapter {
2. protected static Logger logger = LoggerFactory.getLogger(MinaServerHandler.class);
3. public void exceptionCaught(IoSession session, Throwable cause) throws Exception {
4. logger.error("服务端发送异常...", cause);
5. }
6. public void messageReceived(IoSession session, Object message) throws Exception {
7. String msg = message.toString();
8. //如果是quit就关闭session退出
9. if ("quit".equals(msg)) {
10. session.close();
11. }
12. Date date = new Date();
13. session.write(date.toString());
14. }
15. public void sessionCreated(IoSession session) throws Exception {
16. logger.info("服务端与客户端创建连接...");
17. }
18. }

• 运行MinaTest类，启动服务器端。
• 开始->运行->cmd进入控制台 窗口。
• 输入：telnet 127.0.0.1 9999
• 再重复2、3步骤2次。
• 对jvisualvm的线程视图截图如下：

• 通过以上步骤我们可以看出我们打开了一个服务器端口，并用3个客户端进行连接，下面我们通过以上总结的知识来分析一下服务端产生的线程：
• NioSccketAcceptor为服务器端监听端口9999通过线程池创建的一个线程。
• NioProcessor-1、NioProcessor-2、NioProcessor-3为IoProcessor线程池创建的线程，用来IO处理。
• pool-3-thread-1、pool-3-thread-2、pool-3-thread-3为过滤器配置的线程池创建的线程，用来业务逻辑处理。

 

参考：

http://www.iteye.com/topic/1124736

http://www.iteye.com/topic/1112123