MINA2的多线程模型问题探讨
最近和一友人沟通，他在一个项目中使用MINA2，他反馈在启动了服务端之后，发现IO阻塞和堆内存一直上升；





JCONSOLE面板中的解释：
阻塞总数

Blocked count is the total number of times that the thread blocked to enter or reenter a monitor. I.e. the number of times a thread has been in the java.lang.Thread.State.BLOCKED state.
当线程试图获取一个内部的对象锁(不是java.util.concurrent库中的锁)，而锁被其它线程占有，则该线程进入阻塞状态。

等待总数
Waited count is the total number of times that the thread waited for notification. i.e. the number of times that a thread has been in the ava.lang.Thread.State.WAITING or java.lang.Thread.State.TIMED_WAITING state.
当线程等待另外一个线程通知调度器的一个条件的时候，它自己进入等待状态。在调用Object.wait()或Thread.join()方法，或者等待java.util.concurrent库中的Lock或Condition时，会出现等待状况。

后这两天我自己本地拿一个简单案例测试了下，
采用JAVA原生的newCachedThreadPool，以及MINA2自带的 OrderedThreadPoolExecutor 线程池，在性能上没有太大的区别；
本身他原来的代码中就是使用了一种线程池，将IO线程和工作线程（业务线程）区分开的，所以这个处理的堆内存升高和IO堵塞是正常现象，我本地代码实测，暂用的堆内存并不多，而且是快速回收了，并不影响后续业务；
下图中大量的thread就是由于使用了ExecutorFilter之后，MINA2服务器端产生的大量线程。


在服务端启动的代码中有一段如下：

  根据图里面的信息，发现在NioProcessor.java中
    @Override
    protected int select(long timeout) throws Exception {
        return selector.select(timeout);
    }
 然后继续跟踪，在AbstractPollingIoProcessor.java类中
filterChainBuilder.addLast("threadPool", new ExecutorFilter(Executors.newCachedThreadPool()); 



 然    1 楼    qrong    2012-07-13              经测试，new ExecutorFilter(Executors.newCachedThreadPool())会导致在codec层收到的数据错乱，好大个坑。。。。。改回默认的orderThreadPool后无此问题。