《Apache Mina原理及典型例子分析》由会员分享，可在线阅读，更多相关《Apache Mina原理及典型例子分析（8页珍藏版）》请在金锄头文库上搜索。
1、Apache Mina ，一个高性能 Java 异步并发网络通讯框架。利用 Mina 可以高效地完成以 下任务： TCP/IP 和 UDP/IP 通讯 串口通讯 VM 间的管道通讯 SSL/TLS JXM 集成 IoC 容器集成（ Spring 、 Pico 等） 状态机 Mina 的 API 当前主要有三个分支，分别是： 2.0.x 目前处于 SVN trunk 上的版本， Mina 社区对该版本的 API 进行了全新的设计 1.1.x 为当前用于产品开发的版本，适用于 5.0 以上的 JDK ，最新版本为 1.1.5 1.0.x 是 1.1.x 的 JDK 1.4 的兼容版本，最新版本为
2、1.0.8 这里将要介绍的是 2.0.x 版。虽然当前的稳定版本还是 1.1.x ，但是按照 Mina 团队之前 的开发计划， 2.0.x 即将在 08 年夏季正式发布，并且在 2.0.x 中对 Spring 等 IoC 的集 成进行了简化，添加了基于 OGNL 的 JMX 远程管理支持，使用基于 Java Annotation 的 全新 API 大大简化了状态机编程，新的基于 Apache APR 的基础 I/O 组件促进了进一步 的效率提升（据官方评测， APR 的效率较之 Sun NIO 要高出约 10%） 。由于这一系列的 重大改进，使得 2.0.x 成为十分令人期待的一个版本，无论是
3、 Mina 新手还是老用户，如 果你对这个项目抱有兴趣，便很有必要提前对这个版本进行一些了解。 首先让我们对异步 I/O 做一些基本的了解。异步 I/O 模型大体上可以分为两种，反应式 （ Reactive ）模型和前摄式（ Proactive ）模型： 传 统的 select / epoll / kqueue 模型，以及 Java NIO 模型，都是典型的反应式模型，即应 用代码对 I/O 描述符进行注册，然后等待 I/O 事件。当某个或某些 I/O 描述符所对应的 I/O 设备上产生 I/O 事件（可读、可写、异常等）时，系统将发出通知，于是应用便有机 会进行 I/O 操作并避免阻塞。由于
4、在反应式模型中应用代码需要根据相应的事件类型采取 不同的动作，最常见的结构便是嵌套的 if else 或 switch ，并常常需要结合状态 机来完成复杂的逻辑。 前摄式模型则恰恰相反。在前摄式模型中，应用代码主动地投递异步操作而不管 I/O 设备 当前是否可读或可写。投递的异步 I/O 操作被系统接管，应用代码也并不阻塞在该操作上， 而是指定一个回调函数并继续自己的应用逻辑。当该异步操作完成时，系统将发起通知并 调用应用代码指定的回 调函数。在前摄式模型中，程序逻辑由各个回调函数串联起来：异 步操作 A 的回调发起异步操作 B ，B 的回调再发起异步操作 C ，以此往复。 Mina 便 是一
5、个前摄式的异步 I/O 框架。 注意贴主修正: Reactor 和 Proactor 同为事件驱动 I/O 模型，其本质区别在于事件触发时机： Reactor 在 I/O 设备就绪，即可以立即执行 I/O 调用而无需阻塞时触发，只有这时才可以放心大胆的 执行 I/O 调用；而 Proactor 则允许在任意时刻发起 I/O 调用请求，并在 I/O 调用完成时 触发事件。 Proactor 可以直接利用系统提供的 aio 、 IOCP 等异步 I/O 机制实现。不过鉴于一时之 间各种平台上 aio 接口实现的兼容性、功能、性能等方面的表现都还比较不靠谱，常见平 台里还是 Win32 IOCP 对
6、 Proactor 的原生支持最好。当系统不提供原生的异步 I/O 机制 时，也可以使用 Reactor 模拟实现。相关内容可参见这篇文章。 MINA 正是借由 Java NIO 的 Reactor 实现的模拟 Proactor 模型。 Boost.Asio 的 Proactor 内核在非 NT Win32 平台上也是利用 select() / kqueue() / epoll 等 Reactor 模拟实现的。 Reactor 按照事件触发方式又可分为 level-triggered (LT) 和 edge-triggered (ET) 两种，其 区别详见 epoll 的 man page 。
7、传统的 select() / poll() 都属于 LT Reactor ； kqueue() 则 是 ET Reactor ； epoll 是个两面派， LT/ET 语义通吃。 前摄式模型相较于反射式模型往 往更加难以编程。然而在具有原生异步 I/O 支持的操作 系统中（例如支持 IO Completion Port 的 Win32 系统） ，采用前摄式模型往往可以取得比 反应式模型更佳的效率。在没有原生异步 I/O 支持的系统中，也可以使用传统的反应式 API 对前摄式模型予以模拟。在现代的软硬件系统中，使用 epoll 和 kqueue 的前摄式模 型实现同样可以轻松解决 C10K 问题
8、。前摄式模型的一个显著优势是在实现复杂逻辑的时 候不需要借助于状态机。因为状态机已经隐含在由回调串联起来的异步操作链当中了。如 果上述内容难以理解，可以参考 Boost.Asio ，这是一个相当优秀的跨平台 C+ 前摄式 I/O 模型实现。 当然，对于程序员来说，还是直接看代码来得最为直接： Show me the code! 好，以下我 们以官方文档上的一个简单的 TCP Time Server 为示例对 Mina 的基本服务器编程予以剖 析。该服务器的功能是监听本地所有接口的 8150 端口，当有客户端连接建立时便向客户 端以文本方式发送当前时间，并关闭连接。使用 Time Server
9、的目的在于 逻辑简单（更甚于 Unix Network Programming 中的 Echo Server ） ，易于实现 只需实现服务器端代码，客户端可有普通 telnet 程序代替 使用文本协议，可利用 Mina 内置的 TextLineCodecFactory 来作为协议解析器 Time Server 源码分析 以下便是完整的服务端代码，稍后再逐行进行分析：1 package test.mina.time.server;23 import java.io.IOException;4 import .InetSocketAddress;5 import java.util.Date;67
10、 import mons.logging.Log;8 import mons.logging.LogFactory;9 import mon.IoAcceptor; 10 import mon.IoHandlerAdapter; 11 import mon.IoSession; 12 import org.apache.mina.filter.codec.ProtocolCodecFilter; 13 import org.apache.mina.filter.codec.textline.TextLineCodecFactory; 14 import org.apache.mina.filt
11、er.logging.LoggingFilter; 15 import org.apache.mina.transport.socket.nio.NioSocketAcceptor; 16 17 public class TimeServer 18 19 static Log log = LogFactory.getLog( TimeServer.class ); 20 21 public static void main( final String args ) 22 final IoAcceptor acceptor = new NioSocketAcceptor();23 24 acce
12、ptor.setHandler( new IoHandlerAdapter() 25 26 Override 27 public void messageSent( final IoSession session, 28 final Object message ) 29 throws Exception 30 session.close(); 31 32 33 Override 34 public void sessionOpened( final IoSession session ) 35 throws Exception 36 session.write( new Date() );
13、37 38 39 ); 40 41 acceptor.getFilterChain().addLast( “codec“, 42 new ProtocolCodecFilter( new TextLineCodecFactory() ) ); 43 acceptor.getFilterChain().addLast( “logging“, new LoggingFilter() ); 44 45 try 46 acceptor.bind( new InetSocketAddress( 8150 ) ); 47 48 catch( final IOException e ) 49 log.err
14、or( “Bind error: “, e ); 50 51 52 53 建立监听器 22 final IoAcceptor acceptor = new NioSocketAcceptor();在传统服务端编程中，对于 一个 TCP 服务器，我们需要先建立一个监听套接字。在 Mina 中，我们创建的并不是一 个监听套接字，而是一个监听套接字工厂，或者称之为“监听器（ acceptor ） ” 。该概念映 射到 Mina API 中，就是 IoAcceptor 接口及其各个实现类。 传统的 BSD Socket API 中的监听套接字以及其在 Java 中的对等物 .ServerSocket
15、都是套接字工厂，其任务是在某个本地地址上进行监听，并在有客户端连接到来时产生一 个与客户端进行通信的套接字。而 Mina 的 IoAcceptor 作为监听套接字的工厂可以接受 一个包含多个本地地址的集合， IoAcceptor 会自行针对这个集合中的每个本地地址分别创 建监听套接字并进行监听，并且在监听器销毁时进行适当的资源清理。这样便省去了我们 建立自行维护多个监听套接字的麻烦。 监听套接字由 IoAcceptor 来接管，那么服务端接受客户端连接后产生的套接字又由谁接管 呢？在 Mina 的术语中，一个 TCP 连接被称作一个“会话（ session ） ” ，对应的 Mina API 是 IoSession 接口。每当服务端接受一个客户端连接，便会创建出一个新的 IoSession 对象，通过该对象就可以对新
