host, port))// 创建连接
future.awaitUninterruptibly()// 等待连接创建完成
MINA,Grizzly[grizzly-nio-framework],xSocket都是基于javanio的serverframework.这里的性能缺陷的焦点是指当一条channel上的SelectionKey.OP_READready时,1.是由selectthread读完数据之后再分发给应用程序的handler,2.还是直接就分发,由handlerthread来负责读数据和handle.mina,xsocket是1.grizzly-nio-framework是2.尽管读channelbuffer中bytes是很快的,但是如果我们放大,当连接channel达到上万数量级,甚至,这种延迟响应的效果将会愈加明显.MINA:forallselectedKeys{readdatathenfireMessageReceived.}xSocket:forallselectedKeys{readdata,appendittoreadQueuethenperformOnData.}其中mina在fireMessageReceived时没有使用threadpool来分发,所以需要应用程序在handler.messageReceived中再分发.而xsocket的performOnData默认是分发给threadpool[WorkerPool],WorkerPool虽然解决了线程池中的线程不能充到最大的问题[跟tomcat6的做法一样],但是它的调度机制依然缺乏灵活性.Grizzly:forallselectedKeys{[NIOContext---filterChain.execute--->ourfilter.execute]bindInternal--->startupAcceptor:启动AbstractPollingIoAcceptor.Acceptor.run使用executor[Executor]的线程,注册[interestOps:SelectionKey.OP_ACCEPT],然后wakeupselector.一旦有连接进来就构建NioSocketSession--对应--channal,然后session.getProcessor().add(session)将当前的channal加入到NioProcessor的selector中去[interestOps:SelectionKey.OP_READ],这样每个连接中有请求过来就由相应的NioProcessor来处理.这里有几点要说明的是:1.一个NioSocketAcceptor对应了多个NioProcessor,比如NioSocketAcceptor就使用了SimpleIoProcessorPoolDEFAULT_SIZE=Runtime.getRuntime().availableProcessors()+1.当然这个size在newNioSocketAcceptor的时候可以设定.2.一个NioSocketAcceptor对应一个javanioselector[OP_ACCEPT],一个NioProcessor也对应一个javanioselector[OP_READ].3.一个NioSocketAcceptor对应一个内部的AbstractPollingIoAcceptor.Acceptor---thread.4.一个NioProcessor也对应一个内部的AbstractPollingIoProcessor.Processor---thread.5.在newNioSocketAcceptor的时候如果你不提供Executor(线程池)的话,那么默认使用Executors.newCachedThreadPool().这个Executor将被NioSocketAcceptor和NioProcessor公用,也就是说上面的Acceptor---thread(一条)和Processor---thread(多条)都是源于这个Executor.当一个连接javaniochannal--NioSession被加到ProcessorPool[i]--NioProcessor中去后就转入了AbstractPollingIoProcessor.Processor.run,AbstractPollingIoProcessor.Processor.run方法是运行在上面的Executor中的一条线程中的,当前的NioProcessor将处理注册在它的selector上的所有连接的请求[interestOps:SelectionKey.OP_READ].AbstractPollingIoProcessor.Processor.run的主要执行流程:for(){intselected=selector(finalSELECT_TIMEOUT=1000L).if(selected>0){process()}}process()-->forallsession-channal:OP_READ-->read(session):这个read方法是AbstractPollingIoProcessor.privatevoidread(Tsession)方法.read(session)的主要执行流程是readchannal-datatobuf,ifreadBytes>0thenIoFilterChain.fireMessageReceived(buf)/*我们的IoHandler.messageReceived将在其中被调用*/到此minaNio处理请求的流程已经明了.mina处理请求的线程模型也出来了,性能问题也来了,那就是在AbstractPollingIoProcessor.Processor.run-->process-->read(persession)中,在process的时候mina是forallselected-channals逐次readdata再fireMessageReceived到我们的IoHandler.messageReceived中,而不是并发处理,这样一来很明显后来的请求将被延迟处理.我们假设:如果NioProcessorPool'ssize=2现在有200个客户端同时连接过来,假设每个NioProcessor都注册了100个连接,对于每个NioProcessor将依次顺序处理这100个请求,那么这其中的第100个请求要得到处理,那它只有等到前面的99个被处理完了.有人提出了改进方案,那就是在我们自己的IoHandler.messageReceived中利用线程池再进行分发dispatching,这个当然是个好主意.但是请求还是被延迟处理了,因为还有readdata所消耗的时间,这样第100个请求它的数据要被读,就要等前面的99个都被读完才行,即便是增加ProcessorPool的尺寸也不能解决这个问题.此外mina的陷阱(这个词较时髦)也出来了,就是在read(session)中,在说这个陷阱之前先说明一下,我们的client端向server端发送一个消息体的时候不一定是完整的只发送一次,可能分多次发送,特别是在client端忙或要发送的消息体的长度较长的时候.而mina在这种情况下就会call我们的IoHandler.messageReceived多次,结果就是消息体被分割了若干份,等于我们在IoHandler.messageReceived中每次处理的数据都是不完整的,这会导致数据丢失,无效.下面是read(session)的源码:privatevoidread(Tsession){IoSessionConfigconfig=session.getConfig()IoBufferbuf=IoBuffer.allocate(config.getReadBufferSize())finalbooleanhasFragmentation=session.getTransportMetadata().hasFragmentation()try{intreadBytes=0intrettry{if(hasFragmentation/*hasFragmentation一定为ture,也许mina的开发人员也意识到了传输数据的碎片问题,但是靠下面的处理是远远不够的,因为client一旦间隔发送,ret就可能为0,退出while,不完整的readBytes将被fire*/){while((ret=read(session,buf))>0){readBytes+=retif(!buf.hasRemaining()){break}}}else{ret=read(session,buf)if(ret>0){readBytes=ret}}}finally{buf.flip()}if(readBytes>0){IoFilterChainfilterChain=session.getFilterChain()filterChain.fireMessageReceived(buf)buf=nullif(hasFragmentation){if(readBytesIoAcceptor.accept()在port上阻塞,一旦有channel就从IoSocketDispatcherPool中获取一个IoSocketDispatcher,同时构建一个IoSocketHandler和NonBlockingConnection,调用Server.LifeCycleHandler.onConnectionAccepted(ioHandler)initializetheIoSocketHandler.注意:IoSocketDispatcherPool.size默认为2,也就是说只有2条doselect的线程和相应的2个IoSocketDispatcher.这个和MINA的NioProcessor数是一样的.说明2.IoSocketDispatcher[javanioSelector]:IoSocketHandler:NonBlockingConnection------1:1:1在IoSocketDispatcher[对应一个Selector].run中--->IoSocketDispatcher.handleReadWriteKeys:forallselectedKeys{IoSocketHandler.onReadableEvent/onWriteableEvent.}IoSocketHandler.onReadableEvent的处理过程如下:1.readSocket()2.NonBlockingConnection.IoHandlerCallback.onDataNonBlockingConnection.onData--->appendDataToReadBuffer:readQueueappenddata3.NonBlockingConnection.IoHandlerCallback.onPostDataNonBlockingConnection.onPostData--->HandlerAdapter.onData[ourdataHandler]performOnDatainWorkerPool[threadpool].因为是把channel中的数据读到readQueue中,应用程序的dataHandler.onData会被多次调用直到readQueue中的数据读完为止.所以依然存在类似mina的陷阱.解决的方法依然类似,因为这里有NonBlockingConnection.----------------------------------------------------------------------------------------------再下面以grizzly-nio-frameworkv1.9.18源码为例:tcpusagee.g:Controllersel=newController()sel.setProtocolChainInstanceHandler(newDefaultProtocolChainInstanceHandler(){publicProtocolChainpoll(){ProtocolChainprotocolChain=protocolChains.poll()if(protocolChain==null){protocolChain=newDefaultProtocolChain()//protocolChain.addFilter(ourapp'sfilter/*应用程序的处理从filter开始,类似mina.ioHandler,xSocket.dataHandler*/)//protocolChain.addFilter(newReadFilter())}returnprotocolChain}})//如果你不增加自己的SelectorHandler,Controller就默认使用TCPSelectorHandlerport:18888sel.addSelectorHandler(ourapp'sselectorHandleronspecialport)sel.start()------------------------------------------------------------------------------------------------------------说明1.Controller:ProtocolChain:Filter------1:1:n,Controller:SelectorHandler------1:n,SelectorHandler[对应一个Selector]:SelectorHandlerRunner------1:1,Controller.start()--->forperSelectorHandlerstartSelectorHandlerRunnertorun.SelectorHandlerRunner.run()--->selectorHandler.select()thenhandleSelectedKeys:forallselectedKeys{NIOContext.execute:dispatchingtothreadpoolforProtocolChain.execute--->ourfilter.execute.}你会发现这里没有readdatafromchannel的动作,因为这将由你的filter来完成.所以自然没有mina,xsocket它们的陷阱问题,分发提前了.但是你要注意SelectorHandler:Selector:SelectorHandlerRunner:Thread[SelectorHandlerRunner.run]都是1:1:1:1,也就是说只有一条线程在doSelectthenhandleSelectedKeys.相比之下虽然grizzly在并发性能上更优,但是在易用性方面却不如mina,xsocket,比如类似mina,xsocket中表示当前连接或会话的IoSession,INonBlockingConnection对象在grizzly中由NIOContext来负责,但是NIOContext并没有提供session/connectionlifecycleevent,以及常规的read/write操作,这些都需要你自己去扩展SelectorHandler和ProtocolFilter,从另一个方面也可以说明grizzly的可扩展性,灵活性更胜一筹.转载Java NIO框架MINA用netty性能和链接数、并发等压力测试参数好于mina。\x0d\x0a\x0d\x0a特点：\x0d\x0a1。NIO弥补了原来的I/O的不足，它再标准java代码中提供了高速和面向块的I/O\x0d\x0a原力的I/O库与NIO最重要的区别是数据打包和传输方式的不同，原来的I/O以流的方式处理数据，而NIO以块的方式处理数据；\x0d\x0a\x0d\x0a2.NIO以通道channel和缓冲区Buffer为基础来实现面向块的IO数据处理，MINA是开源的。\x0d\x0a\x0d\x0aJavaNIO非堵塞应用通常适用用在I/O读写等方面，我们知道，系统运行的性能瓶颈通常在I/O读写，包括对端口和文件的操作上，过去，在打开一个I/O通道后，read()将一直等待在端口一边读取字节内容，如果没有内容进来，read()也是傻傻的等，这会影响我们程序继续做其他事情，那么改进做法就是开设线程，让线程去等待，但是这样做也是相当耗费资源的。\x0d\x0a\x0d\x0aJava NIO非堵塞技术实际是采取Reactor模式，或者说是Observer模式为我们监察I/O端口，如果有内容进来，会自动通知我们，这样，我们就不必开启多个线程死等，从外界看，实现了流畅的I/O读写，不堵塞了。\x0d\x0a\x0d\x0aJava NIO出现不只是一个技术性能的提高，会发现网络上到处在介绍它，因为它具有里程碑意义，从JDK1.4开始，Java开始提高性能相关的功能，从而使得Java在底层或者并行分布式计算等操作上已经可以和C或Perl等语言并驾齐驱。\x0d\x0a\x0d\x0a如果至今还是在怀疑Java的性能，说明思想和观念已经完全落伍了，Java一两年就应该用新的名词来定义。从JDK1.5开始又要提供关于线程、并发等新性能的支持，Java应用在游戏等适时领域方面的机会已经成熟，Java在稳定自己中间件地位后，开始蚕食传统C的领域。\x0d\x0a\x0d\x0a原理：\x0d\x0aNIO 有一个主要的类Selector,这个类似一个观察者，只要我们把需要探知socketchannel告诉Selector,我们接着做别的事情，当有事件发生时，他会通知我们，传回一组SelectionKey,我们读取这些Key,就会获得我们刚刚注册过的socketchannel,然后，我们从这个Channel中读取数据，放心，包准能够读到，接着我们可以处理这些数据。Selector内部原理实际是在做一个对所注册的channel的轮询访问，不断的轮询(目前就这一个算法)，一旦轮询到一个channel有所注册的事情发生。比如数据来了，他就会站起来报告，交出一把钥匙，让我们通过这把钥匙来读取这个channel的内容。在使用上，也在分两个方向，一个是线程处理，一个是用非线程，后者比较简单。
