论文部分内容阅读
[摘要]随着J2EE技术在企业级平台系统中的广泛应用,用户对基于JAVA的网络服务器程序的性能与扩展性提出更高的要求。围绕服务器模型中高效NIO实现与高扩展性架构两方面介绍一个网络应用服务器模型,结合实际应用环境对这种模型的特点及优越性进行说明,并指出进一步的研究方向。
[关键词]JAVA NIO 业务扩展
中图分类号:TP3文献标识码:A文章编号:1671-7597(2009)0910012-02
一、引言
J2EE是一种利用Java2平台来简化企业解决方案的开发、部署和管理相关的复杂问题的体系结构。在保留现存的IT资产,快速开发以及支持异构环境等因素的考虑下,众多大型企业的企业级应用均采用J2EE技术。在大型的企业架构中,基于客户/服务器模式所设计的服务器程序由于能为客户提供一些特定的服务而得到了普遍的应用,这种服务器程序的核心技术是并发技术,服务器需要同时对多个客户请求提供服务[1],为每个连接的客户都分配一个线程来处理输入输出,其线程与客户机之比几乎为1:1,因此,应用服务器易受到大量线程开销的影响,导致了性能低下又缺乏可伸缩性。为了解决这个问题,java平台的开发者引入了非阻塞I/O机制(NIO)[2]。NIO与IO包提供的阻塞模型不同,NIO在对一个非阻塞的连接进行操作时,调用会立即返回,而不是挂起等待,这就使得一个线程管理多个连接成为可能,从而使资源使用率得到很大的提升[3]。
在满足高性能需求同时,企业还要求服务器端平台能提供可伸缩性来满足大量的新客户,为了解决当前企业应用的迫切需求,我们需要一种基于NIO技术的兼顾高效并发与业务扩展两方面的服务器模型。
二、研究现状
JDK1.4提供的无阻塞I/O(NIO)有效解决了多线程服务器存在的线程开销问题,在NIO中使用多线程,主要目的已不是为了应对每个客户端请求而分配独立的服务线程,而是通过多线程充分利用多个CPU的处理能力,减少处理时间,达到提高服务能力的目的。许多基于NIO的多线程服务器程序往往直接用基于选择器(Selector)的Reactor模式实现,这种简单的事件机制对于较复杂的服务器应用,显然缺乏扩展性和可维护性,而且缺乏直观清晰的结构层次[4]。
文献[4]针对上述问题提出了基于事件回调思想下的NIO多线程服务器,但该服务器设计的运行时Socket分发机制无法正常的对SocketChannel
(套接字通道)进行处理。文献[4]设计将新接收的客户端通道放在连接接收线程中进行select,当客户端有数据到达时,socket被分配给了处理线程。在任意给定时刻最多只能有一个线程对SocketChannel进行读取和写入操作[5],而客户端数据到达时连接接收线程仍然在对SocketChannel进行select,导致了连接接收线程与处理线程对客户端SocketChannel的访问发生冲突。本文提出的使用多线程套接字分发机制的改良NIO模型很好地解决上述诸多问题。
在具备清晰的层次与高效的性能的同时,服务器的运算逻辑组织方式是决定服务器扩展性的主要因素。例如一个网络服务器需要向手持PDA终端提供采集数据处理服务,当出现不同接口协议的PDA终端时,服务器必须对新协议进行支持。在服务器开发设计过程中往往只重视服务器的性能而忽视了服务器的再编程能力,这导致某一种特殊应用的网络服务器扩展性较低或是扩展难度较大。本文使用改良NIO模型的事件回调机制为接口,以NIO模型的线程池业务数据扩展框架的运行载体,构建了一个网络应用服务器模型,提供了一个具备高效性与扩展性的服务器开发模型解决方案。
三、多线程套接字分发NIO模型
多线程套接字分发NIO模型是本文网络服务器架构中的通信层与事件接口层模型,也是数据处理层的基础,向数据层提供了事件回调接口以及TCP数据发送接口。
(一)模型结构
如图1所示,NIO模型基本可分为以下模块:
1.通讯层
客户端代理(TcpClient/TcpClientPool):Tcp客户端在服务器端的镜像,包含了该客户端链路的所有信息,并提供了数据发送的方法。客户端代理主要包括套接字通道与输入缓冲区,缓冲区大小是应用需求而定。
连接接收器(TcpAcceptor):负责启动服务器的端口监听,并且对生成的监听套接字进行select,接收新连接。
链路处理器(TcpProcessor/TcpProessorPool):负责处理已分配的链路事件,驱动事件接口进行业务运算。服务器将根据链路处理器数量均匀分配客户端代理,通过实现定义的链路处理器池(TcpProessorPool)实现线程池的功能。由于该模型下的高并发服务器所服务的客户端通讯流量相对比较均匀,因此每一个链路处理器将会对该处理器内部的socket套接字通道进行select,处理器之间并不交换客户端代理。
2.事件层
事件通知器(EventNotifier):向上层应用提供了事件注册方法,并向底层通讯提供事件驱动的方法,即register/notify模式。事件通知器将保存进行了事件注册的业务对象,并在事件触发时以轮询的方式对事件注册者的运算进行驱动。
事件适配器接口(EventAdapter):定义了通讯事件触发接口,包括OnAccepted(连接建立)、OnRead(数据到达)、OnClose(连接关闭)。
(二)数据处理流程
数据的处理流程如图2所示,客户端A、B、C向服务器发起连接,详细步骤如下:
如图2所示NIO模型数据处理流程分为以下几个步骤:
1.客户端向服务器发起连接请求:TcpAcceptor通过select阻塞等待连接到来,当selectedKeys为OP_ACCEPT时进入建立连接的处理流程。
2.在该模型中对于所有新建立的连接都必须给其分配一个客户端代理以做到端到端的对应。因为连接的关闭与建立是一个相对比较频繁的操作,因此TcpAcceptor通过向TcpClientPool请求TcpClient以增加对象的再利用率。
3.在获得了TcpClient后,模块需要将TcpClient分配给空闲的TcpPr
ocessor,此处采用平均分配的方式,向TcpProcessorPool申请,选择其管理TcpClient数最少的TcpProcessor。
4.在空闲TcpProcessor注册TcpClient并指定需要监视事件。
5.TcpProcessor对已注册的TcpClient进行处理,在数据到达时通过EventNotifer驱动事件的业务处理。
(三)设计原理对比分析
该NIO模型相对于其他基于NIO技术的服务器模型主要优势在三个方面:
1.在NIO的反射模型[3]中,通过Dispatch的中心事件分发方式,使数据处理必须包含对SocketChannel的处理,这样的层次将降低扩展性,因为对于一个便于进行二次开发通讯架构应该是让开发人员无需关心数据是怎么来的。本文中的NIO模型将数据的接收和发送通过事件封装起来,使数据处理代码与数据获取/发送代码分离,从而提高了系统的扩展性。
2.基于事件回调思想下的NIO多线程[5]中将SocketChannel放置在接收线程中select,这样的作法使得SocketChannel的select与read在不同线程操作时发生冲突,而导致读取数据的失败。因此,本文采用均分的机制将客户端的SocketChannel的select与read放在同一处理线程中,避免了冲突的发生。
3.文献[5]中数据的发送采用事件接口onWrite实现,而本文的NIO模型则直接采用又TcpClient提供Send方法的方式,这使得程序设计便于理解。因为数据发送动作是由上层发起的,因此使用事件回调的方式将使操作数增多,层次将更为复杂。
四、数据处理层架构
在有了高效且易于扩展的NIO通讯层框架后,服务器同时需要基于NIO模型之上,便于扩展的数据处理层的架构。在企业应用中存在各式各样的网关服务器程序,例如游戏服务器,Web服务器,终端服务器等,它们都面向连接的数据处理服务程序,对于一个企业来说程序的可扩展性和维护性是非常重要的,若它们的数据处理层架构均采用统一模式,这将大大增加服务器代码的可阅读性,维护性以及扩展性。
基于NIO的面向服务对象的扩展业务模型的基本概念是将业务对象的数据处理独立化,即每一个业务处理单元的数据处理运算相互独立,在数据处理过程中具有上下文信息。业务处理单元采用挂载的方式,一个业务处理对象下可以挂载多业务处理单元。业务处理对象通过对消息类型的判断将接口的消息分发给不同的业务处理单元进行处理。与通讯层不相同的是,业务扩展模型主要提供标准的基础类或是接口以供扩展,本身并不带有复杂的处理逻辑。下面从核心业务模块接口和模块结构两方面详细描述。
(一)核心业务模块接口定义
命令上下文(CmdContext):在整个单个业务处理过程中记录具体业务的历史信息与当前状态。通过了加入上下文机制可以使同一业务中的不同操作在不同的时间区间完成,实现了业务的异步化。
命令处理单元(CmdHandler/CmdHandlerGather):所有业务处理单元都继承命令处理单元,CmdHandler包含了标准的上下行数据接口,让业务处理单元以标准的方式挂载在业务对象上。其中,向上接口表现为指令的处理,而向下接口则是网络数据的处理。CmdHandler的定时器处理接口(disposeTimeOut)接口还完成了统一的定时器处理,通过该接口实现所有的服务器单元共享定时器时间片与定时器处理线程池。CmdHandlerGather的作用是将服务对象将不同类型的指令或消息路由至指定的CmdHandler。
命令发起者接口(CmdSponsor):主要完成了对指令的路由工作。由于模型采用了Request/Response请求响应模式,因此该模式下的业务处理必然会以响应的方式向通知上层模块。通过CmdSponsor接口去描述指令发起者使得业务处理可以不再局限于模块对模块层面,对于已经编写好的业务单元可以通过以其他的业务单元为发起者完成整个业务链,从而大大增强了代码的复用性。
(二)核心业务模块整合
在整合了核心业务模块后,服务器模型大致可分为:
1.接口模块:向上层应用平台提供标准的指令接口,并提供接口消息的发送与接收方法。
2.核心服务管理模块:业务数据的处理核心。通过继承统一的接口标准,完成不同业务运算,且服务对象相互独立。
3.事件接口:包含了事件通知接口与事件驱动接口。
4.通讯服务模块:基于TCP/IP协议的通讯平台,向上提供了数据发送接口以及通过事件驱动处理单元。
从图3中可以看出,事件接口与通讯服务模块构成了整个基于事件驱动的NIO实现模型,通过线程池驱动核心服务管理模块中的处理单元。定时器线程也是处理单元的运行载体,因此在不考虑具体接口形式时,处理单元将会出现两个驱动者。为了保证每一个服务对象的上下文保持一致,服务对象的资源方式是需要进行同步处理的。
五、应用实例
GPS车辆监控是在依托于移动网络下通过GPS车载终端与服务端建立通讯连接,进而实现车辆的GPS监控。对于一些物流型行业,如邮政,烟草配送等,均是具备了数以万计的车辆资源,这给GPS系统中的网络通讯服务器的功能和性能又提出了更高的要求。本文介绍的模型已经成功应用于GPS监控系统的业务领域,在NIO技术高性能的基础上通过以GPS车载终端为服务对象,向GPS车载提供指令解析以及其他的业务服务功能。
性能方面,基于该模型所开发的网络通信服务平台通过了2万台GPS终端并发的压力测试。GPS终端作为GPS数据的通讯器,其数据是以相当稳定的速度向平台发送,不会因为外界因素产生大的波动,连接处理器的均匀分配管理模式与GPS终端通信流量稳定的性质极其吻合。
业务扩展性方面,在实际GPS产品的通讯协议解析业务的开发过程中,该模型所提供的接口标准使开发人员无需关心平台除数据处理逻辑以外的其他部分。包括通讯服务模块,核心服务处理模块在内的架构模块都已经达到了完全的通用,对于不同的GPS产品(如珠海天琴、上海飞田、深圳龙翰、苏州宏原等),GPS业界并没有一个统一的标准协议,统一的数据处理层框架使程序编写人员只需要编写实现业务处理单元中的诸如上行、下行以及定时器等标准接口的具体业务。
六、结束与展望
本文提出了基于NIO技术的多线程套接字分发服务器模型,并在此基础上构建了一套具有高扩展性的数据处理层架构,从而提供了一个高并发网络应用服务器开发模型的解决方案。通过实际应用的检验该模型在性能以及扩展性方面都有着良好的表现,但该模型在复杂的网络环境下仍存在一定问题。均匀的连接调度机制并不能很好的适应多变的应用环境,因此根据实际应用环境的其它性能指标对连接调度机制进行自适应调整是该模型的下一步的研究方向。
基金项目:国家自然科学基金(60673164)
参考文献:
[1]刘仕筠、盛志伟、黄健,Linux环境并发服务器设计技术研究[J].成都信息工程学院学报,2006,21(5):630-634.
[2]王洁,JAVA NIO在Socket通讯中的应用[J].成都信息工程学院学报,2003,18(3):258-261.
[3]姜力,基于Java NIO反应器模式设计与实现[J].大庆师范学院报,2008,28(2):27-30.
[4]黄林榕,基于事件的NIO多线程服务器[DB/OL].http://www.ibm.com/
developer works/cn/java/l-niosvr/.2004.4.1.
[5]Sun Microsystems.Java 2 Platform Standard Edition5.0的API规范[Z].2004.
作者简介:
王伟平(1969-),女,副教授,主要从事计算机网络研究。
[关键词]JAVA NIO 业务扩展
中图分类号:TP3文献标识码:A文章编号:1671-7597(2009)0910012-02
一、引言
J2EE是一种利用Java2平台来简化企业解决方案的开发、部署和管理相关的复杂问题的体系结构。在保留现存的IT资产,快速开发以及支持异构环境等因素的考虑下,众多大型企业的企业级应用均采用J2EE技术。在大型的企业架构中,基于客户/服务器模式所设计的服务器程序由于能为客户提供一些特定的服务而得到了普遍的应用,这种服务器程序的核心技术是并发技术,服务器需要同时对多个客户请求提供服务[1],为每个连接的客户都分配一个线程来处理输入输出,其线程与客户机之比几乎为1:1,因此,应用服务器易受到大量线程开销的影响,导致了性能低下又缺乏可伸缩性。为了解决这个问题,java平台的开发者引入了非阻塞I/O机制(NIO)[2]。NIO与IO包提供的阻塞模型不同,NIO在对一个非阻塞的连接进行操作时,调用会立即返回,而不是挂起等待,这就使得一个线程管理多个连接成为可能,从而使资源使用率得到很大的提升[3]。
在满足高性能需求同时,企业还要求服务器端平台能提供可伸缩性来满足大量的新客户,为了解决当前企业应用的迫切需求,我们需要一种基于NIO技术的兼顾高效并发与业务扩展两方面的服务器模型。
二、研究现状
JDK1.4提供的无阻塞I/O(NIO)有效解决了多线程服务器存在的线程开销问题,在NIO中使用多线程,主要目的已不是为了应对每个客户端请求而分配独立的服务线程,而是通过多线程充分利用多个CPU的处理能力,减少处理时间,达到提高服务能力的目的。许多基于NIO的多线程服务器程序往往直接用基于选择器(Selector)的Reactor模式实现,这种简单的事件机制对于较复杂的服务器应用,显然缺乏扩展性和可维护性,而且缺乏直观清晰的结构层次[4]。
文献[4]针对上述问题提出了基于事件回调思想下的NIO多线程服务器,但该服务器设计的运行时Socket分发机制无法正常的对SocketChannel
(套接字通道)进行处理。文献[4]设计将新接收的客户端通道放在连接接收线程中进行select,当客户端有数据到达时,socket被分配给了处理线程。在任意给定时刻最多只能有一个线程对SocketChannel进行读取和写入操作[5],而客户端数据到达时连接接收线程仍然在对SocketChannel进行select,导致了连接接收线程与处理线程对客户端SocketChannel的访问发生冲突。本文提出的使用多线程套接字分发机制的改良NIO模型很好地解决上述诸多问题。
在具备清晰的层次与高效的性能的同时,服务器的运算逻辑组织方式是决定服务器扩展性的主要因素。例如一个网络服务器需要向手持PDA终端提供采集数据处理服务,当出现不同接口协议的PDA终端时,服务器必须对新协议进行支持。在服务器开发设计过程中往往只重视服务器的性能而忽视了服务器的再编程能力,这导致某一种特殊应用的网络服务器扩展性较低或是扩展难度较大。本文使用改良NIO模型的事件回调机制为接口,以NIO模型的线程池业务数据扩展框架的运行载体,构建了一个网络应用服务器模型,提供了一个具备高效性与扩展性的服务器开发模型解决方案。
三、多线程套接字分发NIO模型
多线程套接字分发NIO模型是本文网络服务器架构中的通信层与事件接口层模型,也是数据处理层的基础,向数据层提供了事件回调接口以及TCP数据发送接口。
(一)模型结构
如图1所示,NIO模型基本可分为以下模块:
1.通讯层
客户端代理(TcpClient/TcpClientPool):Tcp客户端在服务器端的镜像,包含了该客户端链路的所有信息,并提供了数据发送的方法。客户端代理主要包括套接字通道与输入缓冲区,缓冲区大小是应用需求而定。
连接接收器(TcpAcceptor):负责启动服务器的端口监听,并且对生成的监听套接字进行select,接收新连接。
链路处理器(TcpProcessor/TcpProessorPool):负责处理已分配的链路事件,驱动事件接口进行业务运算。服务器将根据链路处理器数量均匀分配客户端代理,通过实现定义的链路处理器池(TcpProessorPool)实现线程池的功能。由于该模型下的高并发服务器所服务的客户端通讯流量相对比较均匀,因此每一个链路处理器将会对该处理器内部的socket套接字通道进行select,处理器之间并不交换客户端代理。
2.事件层
事件通知器(EventNotifier):向上层应用提供了事件注册方法,并向底层通讯提供事件驱动的方法,即register/notify模式。事件通知器将保存进行了事件注册的业务对象,并在事件触发时以轮询的方式对事件注册者的运算进行驱动。
事件适配器接口(EventAdapter):定义了通讯事件触发接口,包括OnAccepted(连接建立)、OnRead(数据到达)、OnClose(连接关闭)。
(二)数据处理流程
数据的处理流程如图2所示,客户端A、B、C向服务器发起连接,详细步骤如下:
如图2所示NIO模型数据处理流程分为以下几个步骤:
1.客户端向服务器发起连接请求:TcpAcceptor通过select阻塞等待连接到来,当selectedKeys为OP_ACCEPT时进入建立连接的处理流程。
2.在该模型中对于所有新建立的连接都必须给其分配一个客户端代理以做到端到端的对应。因为连接的关闭与建立是一个相对比较频繁的操作,因此TcpAcceptor通过向TcpClientPool请求TcpClient以增加对象的再利用率。
3.在获得了TcpClient后,模块需要将TcpClient分配给空闲的TcpPr
ocessor,此处采用平均分配的方式,向TcpProcessorPool申请,选择其管理TcpClient数最少的TcpProcessor。
4.在空闲TcpProcessor注册TcpClient并指定需要监视事件。
5.TcpProcessor对已注册的TcpClient进行处理,在数据到达时通过EventNotifer驱动事件的业务处理。
(三)设计原理对比分析
该NIO模型相对于其他基于NIO技术的服务器模型主要优势在三个方面:
1.在NIO的反射模型[3]中,通过Dispatch的中心事件分发方式,使数据处理必须包含对SocketChannel的处理,这样的层次将降低扩展性,因为对于一个便于进行二次开发通讯架构应该是让开发人员无需关心数据是怎么来的。本文中的NIO模型将数据的接收和发送通过事件封装起来,使数据处理代码与数据获取/发送代码分离,从而提高了系统的扩展性。
2.基于事件回调思想下的NIO多线程[5]中将SocketChannel放置在接收线程中select,这样的作法使得SocketChannel的select与read在不同线程操作时发生冲突,而导致读取数据的失败。因此,本文采用均分的机制将客户端的SocketChannel的select与read放在同一处理线程中,避免了冲突的发生。
3.文献[5]中数据的发送采用事件接口onWrite实现,而本文的NIO模型则直接采用又TcpClient提供Send方法的方式,这使得程序设计便于理解。因为数据发送动作是由上层发起的,因此使用事件回调的方式将使操作数增多,层次将更为复杂。
四、数据处理层架构
在有了高效且易于扩展的NIO通讯层框架后,服务器同时需要基于NIO模型之上,便于扩展的数据处理层的架构。在企业应用中存在各式各样的网关服务器程序,例如游戏服务器,Web服务器,终端服务器等,它们都面向连接的数据处理服务程序,对于一个企业来说程序的可扩展性和维护性是非常重要的,若它们的数据处理层架构均采用统一模式,这将大大增加服务器代码的可阅读性,维护性以及扩展性。
基于NIO的面向服务对象的扩展业务模型的基本概念是将业务对象的数据处理独立化,即每一个业务处理单元的数据处理运算相互独立,在数据处理过程中具有上下文信息。业务处理单元采用挂载的方式,一个业务处理对象下可以挂载多业务处理单元。业务处理对象通过对消息类型的判断将接口的消息分发给不同的业务处理单元进行处理。与通讯层不相同的是,业务扩展模型主要提供标准的基础类或是接口以供扩展,本身并不带有复杂的处理逻辑。下面从核心业务模块接口和模块结构两方面详细描述。
(一)核心业务模块接口定义
命令上下文(CmdContext):在整个单个业务处理过程中记录具体业务的历史信息与当前状态。通过了加入上下文机制可以使同一业务中的不同操作在不同的时间区间完成,实现了业务的异步化。
命令处理单元(CmdHandler/CmdHandlerGather):所有业务处理单元都继承命令处理单元,CmdHandler包含了标准的上下行数据接口,让业务处理单元以标准的方式挂载在业务对象上。其中,向上接口表现为指令的处理,而向下接口则是网络数据的处理。CmdHandler的定时器处理接口(disposeTimeOut)接口还完成了统一的定时器处理,通过该接口实现所有的服务器单元共享定时器时间片与定时器处理线程池。CmdHandlerGather的作用是将服务对象将不同类型的指令或消息路由至指定的CmdHandler。
命令发起者接口(CmdSponsor):主要完成了对指令的路由工作。由于模型采用了Request/Response请求响应模式,因此该模式下的业务处理必然会以响应的方式向通知上层模块。通过CmdSponsor接口去描述指令发起者使得业务处理可以不再局限于模块对模块层面,对于已经编写好的业务单元可以通过以其他的业务单元为发起者完成整个业务链,从而大大增强了代码的复用性。
(二)核心业务模块整合
在整合了核心业务模块后,服务器模型大致可分为:
1.接口模块:向上层应用平台提供标准的指令接口,并提供接口消息的发送与接收方法。
2.核心服务管理模块:业务数据的处理核心。通过继承统一的接口标准,完成不同业务运算,且服务对象相互独立。
3.事件接口:包含了事件通知接口与事件驱动接口。
4.通讯服务模块:基于TCP/IP协议的通讯平台,向上提供了数据发送接口以及通过事件驱动处理单元。
从图3中可以看出,事件接口与通讯服务模块构成了整个基于事件驱动的NIO实现模型,通过线程池驱动核心服务管理模块中的处理单元。定时器线程也是处理单元的运行载体,因此在不考虑具体接口形式时,处理单元将会出现两个驱动者。为了保证每一个服务对象的上下文保持一致,服务对象的资源方式是需要进行同步处理的。
五、应用实例
GPS车辆监控是在依托于移动网络下通过GPS车载终端与服务端建立通讯连接,进而实现车辆的GPS监控。对于一些物流型行业,如邮政,烟草配送等,均是具备了数以万计的车辆资源,这给GPS系统中的网络通讯服务器的功能和性能又提出了更高的要求。本文介绍的模型已经成功应用于GPS监控系统的业务领域,在NIO技术高性能的基础上通过以GPS车载终端为服务对象,向GPS车载提供指令解析以及其他的业务服务功能。
性能方面,基于该模型所开发的网络通信服务平台通过了2万台GPS终端并发的压力测试。GPS终端作为GPS数据的通讯器,其数据是以相当稳定的速度向平台发送,不会因为外界因素产生大的波动,连接处理器的均匀分配管理模式与GPS终端通信流量稳定的性质极其吻合。
业务扩展性方面,在实际GPS产品的通讯协议解析业务的开发过程中,该模型所提供的接口标准使开发人员无需关心平台除数据处理逻辑以外的其他部分。包括通讯服务模块,核心服务处理模块在内的架构模块都已经达到了完全的通用,对于不同的GPS产品(如珠海天琴、上海飞田、深圳龙翰、苏州宏原等),GPS业界并没有一个统一的标准协议,统一的数据处理层框架使程序编写人员只需要编写实现业务处理单元中的诸如上行、下行以及定时器等标准接口的具体业务。
六、结束与展望
本文提出了基于NIO技术的多线程套接字分发服务器模型,并在此基础上构建了一套具有高扩展性的数据处理层架构,从而提供了一个高并发网络应用服务器开发模型的解决方案。通过实际应用的检验该模型在性能以及扩展性方面都有着良好的表现,但该模型在复杂的网络环境下仍存在一定问题。均匀的连接调度机制并不能很好的适应多变的应用环境,因此根据实际应用环境的其它性能指标对连接调度机制进行自适应调整是该模型的下一步的研究方向。
基金项目:国家自然科学基金(60673164)
参考文献:
[1]刘仕筠、盛志伟、黄健,Linux环境并发服务器设计技术研究[J].成都信息工程学院学报,2006,21(5):630-634.
[2]王洁,JAVA NIO在Socket通讯中的应用[J].成都信息工程学院学报,2003,18(3):258-261.
[3]姜力,基于Java NIO反应器模式设计与实现[J].大庆师范学院报,2008,28(2):27-30.
[4]黄林榕,基于事件的NIO多线程服务器[DB/OL].http://www.ibm.com/
developer works/cn/java/l-niosvr/.2004.4.1.
[5]Sun Microsystems.Java 2 Platform Standard Edition5.0的API规范[Z].2004.
作者简介:
王伟平(1969-),女,副教授,主要从事计算机网络研究。