Mina源码分析

这边遇到一个mina底层的问题，直接调用 session.close(true) session并没有关闭，因为关闭是个异步的过程，在高版本的mina中已经不推荐直接用session.close  推荐用session.closeNow 等方法，不过都是异步的方法

官网说的方法：

 IoSession session = ...; CloseFuture future = session.close(true);  // Wait until the connection is closed future.awaitUninterruptibly();  // Now connection should be closed. assert future.isClosed();

测试的方法是  在服务端messageReceived 里增加debug断点，客户端发送10来条消息，如果第一条消息超时了 调用session.close（true）方法  ，这时候后续的9条消息还是继续处理了，猜测是跟 粘包处理有关系，那10条消息是一起发过来的，从日志上看是同一个线程处理的，应该是这个线程处理完毕所有消息，才能去处理session.close的消息

这里查阅些资料 结合 mina的源码得知

mina的线程处理模型是使用

这个类默认使用的是 OrderedThreadPoolExecutor

根据mina的文档这么描述的

https://mina.apache.org/mina-project/apidocs/org/apache/mina/filter/executor/ExecutorFilter.html

大意就是 mina默认使用的是绑定策略，一个IoSession 会由线程池中的唯一一个线程去处理，保证不会出现乱序的情况。

从 OrderedThreadPoolExecutor 的代码中我们可以看到

保存task的队列是放在session的 attribute里。

大概逻辑是这样的：

1.通过事件机制去往队列里添加任务

2.线程接受任务不停循环去处理任务

回到刚才debug的情况

1.先连发4条消息(mina通过事件机制将4条消息放入队列  worker去循环处理队列，最后调用handle里的方法，发现某条消息异常，调用session.close(true),session.close抛出事件)

2.这时候客户端在发送多个消息，根据测试还是有可能被加入队列

3.session.close抛出事件，sessionClose 事件会被加入队列，后发的消息如果被offer在前面还有可能被执行，应该是代码拦截了sessionClose之后的消息（猜测）

4.当队列里执行到sessionClose消息时候，才会调用handle里的sessionClosed方法。