tomcat架构分析 (connector NIO 实现)【转】

原文地址：https://www.iteye.com/blog/gearever-1844203

ller线程中维护的这个Selector标为主Selector。
Poller是NIO实现的主要线程。首先作为events queue的消费者，从queue中取出PollerEvent对象，然后将此对象中的channel以OP_READ事件注册到主Selector中，然后主Selector执行select操作，遍历出可以读数据的socket，并从Worker线程池中拿到可用的Worker线程，然后将socket传递给Worker。整个过程是典型的NIO实现。

Worker
Worker线程拿到Poller传过来的socket后，将socket封装在SocketProcessor对象中。然后从Http11ConnectionHandler中取出Http11NioProcessor对象，从Http11NioProcessor中调用CoyoteAdapter的逻辑，跟BIO实现一样。在Worker线程中，会完成从socket中读取http request，解析成HttpServletRequest对象，分派到相应的servlet并完成逻辑，然后将response通过socket发回client。在从socket中读数据和往socket中写数据的过程，并没有像典型的非阻塞的NIO的那样，注册OP_READ或OP_WRITE事件到主Selector，而是直接通过socket完成读写，这时是阻塞完成的，但是在timeout控制上，使用了NIO的Selector机制，但是这个Selector并不是Poller线程维护的主Selector，而是BlockPoller线程中维护的Selector，称之为辅Selector。

NioSelectorPool
NioEndpoint对象中维护了一个NioSelecPool对象，这个NioSelectorPool中又维护了一个BlockPoller线程，这个线程就是基于辅Selector进行NIO的逻辑。以执行servlet后，得到response，往socket中写数据为例，最终写的过程调用NioBlockingSelector的write方法。

Java代码

public int write(ByteBuffer buf, NioChannel socket, long writeTimeout,MutableInteger lastWrite) throws IOException {
SelectionKey key = socket.getIOChannel().keyFor(socket.getPoller().getSelector());
if ( key == null ) throw new IOException("Key no longer registered");
KeyAttachment att = (KeyAttachment) key.attachment();
int written = 0;
boolean timedout = false;
int keycount = 1; //assume we can write
long time = System.currentTimeMillis(); //start the timeout timer
try {
while ( (!timedout) && buf.hasRemaining()) {
if (keycount > 0) { //only write if we were registered for a write
//直接往socket中写数据
int cnt = socket.write(buf); //write the data
lastWrite.set(cnt);
if (cnt == -1)
throw new EOFException();
written += cnt;
//写数据成功，直接进入下一次循环，继续写
if (cnt > 0) {
time = System.currentTimeMillis(); //reset our timeout timer
continue; //we successfully wrote, try again without a selector
}
}
//如果写数据返回值cnt等于0，通常是网络不稳定造成的写数据失败
try {
//开始一个倒数计数器
if ( att.getWriteLatch()==null || att.getWriteLatch().getCount()==0) att.startWriteLatch(1);
//将socket注册到辅Selector，这里poller就是BlockSelector线程
poller.add(att,SelectionKey.OP_WRITE);
//阻塞，直至超时时间唤醒，或者在还没有达到超时时间，在BlockSelector中唤醒
att.awaitWriteLatch(writeTimeout,TimeUnit.MILLISECONDS);
}catch (InterruptedException ignore) {
Thread.interrupted();
}
if ( att.getWriteLatch()!=null && att.getWriteLatch().getCount()> 0) {
keycount = 0;
}else {
//还没超时就唤醒，说明网络状态恢复，继续下一次循环，完成写socket
keycount = 1;
att.resetWriteLatch();
}
if (writeTimeout > 0 && (keycount == 0))
timedout = (System.currentTimeMillis() - time) >= writeTimeout;
} //while
if (timedout)
throw new SocketTimeoutException();
} finally {
poller.remove(att,SelectionKey.OP_WRITE);
if (timedout && key != null) {
poller.cancelKey(socket, key);
}
}
return written;
}

也就是说当socket.write()返回0时，说明网络状态不稳定，这时将socket注册OP_WRITE事件到辅Selector，由BlockPoller线程不断轮询这个辅Selector，直到发现这个socket的写状态恢复了，通过那个倒数计数器，通知Worker线程继续写socket动作。看一下BlockSelector线程的逻辑；

Java代码

public void run() {
while (run) {
try {
......
Iterator iterator = keyCount > 0 ? selector.selectedKeys().iterator() : null;
while (run && iterator != null && iterator.hasNext()) {
SelectionKey sk = (SelectionKey) iterator.next();
KeyAttachment attachment = (KeyAttachment)sk.attachment();
try {
attachment.access();
iterator.remove(); ;
sk.interestOps(sk.interestOps() & (~sk.readyOps()));
if ( sk.isReadable() ) {
countDown(attachment.getReadLatch());
}
//发现socket可写状态恢复，将倒数计数器置位，通知Worker线程继续
if (sk.isWritable()) {
countDown(attachment.getWriteLatch());
}
}catch (CancelledKeyException ckx) {
if (sk!=null) sk.cancel();
countDown(attachment.getReadLatch());
countDown(attachment.getWriteLatch());
}
}//while
}catch ( Throwable t ) {
log.error("",t);
}
}
events.clear();
try {
selector.selectNow();//cancel all remaining keys
}catch( Exception ignore ) {
if (log.isDebugEnabled())log.debug("",ignore);
}
}

使用这个辅Selector主要是减少线程间的切换，同时还可减轻主Selector的负担。以上描述了NIO connector工作的主要逻辑，可以看到在设计上还是比较精巧的。NIO connector还有一块就是Comet，有时间再说吧。需要注意的是，上面从Acceptor开始，有很多对象的封装，NioChannel及其KeyAttachment，PollerEvent和SocketProcessor对象，这些不是每次都重新生成一个新的，都是NioEndpoint分别维护了它们的对象池；

Java代码

ConcurrentLinkedQueue<SocketProcessor> processorCache = new ConcurrentLinkedQueue<SocketProcessor>()
ConcurrentLinkedQueue<KeyAttachment> keyCache = new ConcurrentLinkedQueue<KeyAttachment>()
ConcurrentLinkedQueue<PollerEvent> eventCache = new ConcurrentLinkedQueue<PollerEvent>()
ConcurrentLinkedQueue<NioChannel> nioChannels = new ConcurrentLinkedQueue<NioChannel>()

当需要这些对象时，分别从它们的对象池获取，当用完后返回给相应的对象池，这样可以减少因为创建及GC对象时的性能消耗。

转载于:https://www.cnblogs.com/davidwang456/articles/11452705.html

tomcat架构分析 (connector NIO 实现)【转】相关推荐

tomcat架构分析(connector BIO 实现)【转】
原文地址:https://www.iteye.com/blog/gearever-1841586 在tomcat架构分析(概览)中已经介绍过,connector组件是service容器中的一部分.它主 ...
tomcat架构分析 (Session管理)【转】
原文地址:https://www.iteye.com/blog/gearever-1546423 Session管理是JavaEE容器比较重要的一部分,在app中也经常会用到.在开发app时,我们只是 ...
tomcat架构分析(valve源码导读)【转】
原文地址:https://www.iteye.com/blog/gearever-1540028 源码面前,了无秘密 ----侯捷在to ...
tomcat架构分析(概览)【转】
原文地址: https://www.iteye.com/blog/gearever-1532822 Tomcat是目前应用比较多的servlet容器.关于tomcat本身的特点及介绍,网上已经有很多描 ...
tomcat架构分析(容器类)【转】
原文地址:https://www.iteye.com/blog/gearever-1533678 Tomcat提供了engine,host,context及wrapper四种容器.在总体结构中已经阐述 ...
tomcat架构分析(容器类)
Tomcat提供了engine,host,context及wrapper四种容器.在总体结构中已经阐述了他们之间的包含关系.这四种容器继承了一个容器基类,因此可以定制化.当然,tomcat也提供了标准 ...
tomcat架构分析(valve机制)
出处:http://gearever.iteye.com 关于tomcat的内部逻辑单元的存储空间已经在相关容器类的blog里阐述了.在每个容器对象里面都有一个pipeline及valve模块.它们是 ...
tomcat架构分析(valve机制)【转】
原文地址:https://www.iteye.com/blog/gearever-1536022 关于tomcat的内部逻辑单元的存储空间已经在相关容器类的blog里阐述了.在每个容器对象里面都有一个 ...
应用服务器——tomcat架构分析
先mark,后续补充 https://blog.csdn.net/qq_38245537/article/details/79009448

tomcat架构分析 (connector NIO 实现)【转】

tomcat架构分析 (connector NIO 实现)【转】相关推荐

最新文章

热门文章