承受申请：
当客户端发来新的申请后，Acceptor线程不再阻塞，会获取到socket，持续运行调用setSocketOptions():
@Override
protected boolean setSocketOptions(SocketChannel socket) {
NioSocketWrapper socketWrapper = null;
try {
// Allocate channel and wrapper
NioChannel channel = null;
if (nioChannels != null) {
channel = nioChannels.pop();
}
if (channel == null) {
SocketBufferHandler bufhandler = new SocketBufferHandler(
socketProperties.getAppReadBufSize(),
socketProperties.getAppWriteBufSize(),
socketProperties.getDirectBuffer());
if (isSSLEnabled()) {
channel = new SecureNioChannel(bufhandler, this);
} else {
channel = new NioChannel(bufhandler);
}
}
NioSocketWrapper newWrapper = new NioSocketWrapper(channel, this);
channel.reset(socket, newWrapper);
connections.put(socket, newWrapper);
socketWrapper = newWrapper;
// Set socket properties
// Disable blocking, polling will be used
socket.configureBlocking(false);// todo 每个socket是非阻塞式的
socketProperties.setProperties(socket.socket());
socketWrapper.setReadTimeout(getConnectionTimeout());
socketWrapper.setWriteTimeout(getConnectionTimeout());
socketWrapper.setKeepAliveLeft(NioEndpoint.this.getMaxKeepAliveRequests());
// 将一个链接socket申请注册到poller中，而后应用异步io，解决读写事件
poller.register(socketWrapper);// 将申请的socket放在poller中开始轮询解决
return true;
} catch (Throwable t) {
ExceptionUtils.handleThrowable(t);
try {
log.error(sm.getString("endpoint.socketOptionsError"), t);
} catch (Throwable tt) {
ExceptionUtils.handleThrowable(tt);
}
if (socketWrapper == null) {
destroySocket(socket);
}
}
// Tell to close the socket if needed
return false;
}
setSocketOptions正如办法名字，包装了一下此次客户端与服务端socket，
设置了socket的IO模式为非阻塞，我猜想这样的益处是，一旦建设好链接好，客户端能够发送多个读写事件，而不会阻塞。
在办法完结的中央，有一行很重要的办法poller.register(socketWrapper);
它负责利用NIO的形式，注册服务端感情趣味的可读事件(SelectionKey.OP_READ)，不过这里并没有真正的进行注册，仅仅是封装成了Event，而后放在Poller的SynchronizedQueue队列中。
private final SynchronizedQueue<PollerEvent> events = new SynchronizedQueue<>();
public void register(final NioSocketWrapper socketWrapper) {
socketWrapper.interestOps(SelectionKey.OP_READ);//this is what OP_REGISTER turns into.
PollerEvent pollerEvent = createPollerEvent(socketWrapper, OP_REGISTER);
addEvent(pollerEvent);
}
private void addEvent(PollerEvent event) {
events.offer(event);
if (wakeupCounter.incrementAndGet() == 0) {
// 重点！！！事件注册好后，唤醒一次selector，进行解决，否则selector会阻塞
selector.wakeup();
}
}
当初是时候看看Poller这个线程在干什么事件了，间接看他的run();
@Override
public void run() {
// Loop until destroy() is called
while (true) {
boolean hasEvents = false;
try {
if (!close) {
// 这里次要是解决register，每当有一个socket链接申请到来的时候
// 每个socket须要注册本人感兴趣的工夫
// 这里的socket申请起源是在Acceptor中
// 也就是说Acceptor不停的往events队列中投放事件
// poller不停的处理事件
// 因而这里最重要的就是了解 每一个事件是什么
// todo 要对这一块了解透彻，必须对非阻塞IO有十分深刻的理解
// todo 再次加深了解
hasEvents = events();
// 每当有一个新的链接申请来的时候，都必须当初selector中注册本人感兴趣的事件
// 这样当客户端发送事件后，才可能处理事件。
// 然而，上面的select()只有当有事件来的时候，才会唤醒持续向下执行
if (wakeupCounter.getAndSet(-1) > 0) {
// If we are here, means we have other stuff to do
// Do a non blocking select
keyCount = selector.selectNow();
} else {
keyCount = selector.select(selectorTimeout);
}
wakeupCounter.set(0);
}
if (close) {
events();
timeout(0, false);
try {
selector.close();
} catch (IOException ioe) {
log.error(sm.getString("endpoint.nio.selectorCloseFail"), ioe);
}
break;
}
// Either we timed out or we woke up, process events first
if (keyCount == 0) {
hasEvents = (hasEvents | events());
}
} catch (Throwable x) {
ExceptionUtils.handleThrowable(x);
log.error(sm.getString("endpoint.nio.selectorLoopError"), x);
continue;
}
Iterator<SelectionKey> iterator = keyCount > 0 ? selector.selectedKeys().iterator() : null;
// 重点了解 Walk through the collection of ready keys and dispatch any active event.
while (iterator != null && iterator.hasNext()) {
SelectionKey sk = iterator.next();
iterator.remove();
// attachment 怎么来的，是在注册的时候失去的。
// todo 了解一下attachment工作原理
NioSocketWrapper socketWrapper = (NioSocketWrapper) sk.attachment();
// Attachment may be null if another thread has called
// cancelledKey()
if (socketWrapper != null) {
// sk次要用来判断事件的类型，事件的内容在附件中
processKey(sk, socketWrapper);
}
}
// Process timeouts
timeout(keyCount,hasEvents);
}
getStopLatch().countDown();
}在每次循环中，先看看是否有新的申请链接利用NIO注册感兴趣的事件，如果有，那么就进行解决。如果没有就看看是否有IO事件，如果有则调用processKey（）进行解决。
这里有一个疑难，为什么有了Acceptor还要有Poller呢？为什么不能在Acceptor中做这些事件。
Acceptor次要是负责链接的建设，那么谁来负责解决链接，另外，当链接好后，产生了读写事件了，该有谁来对立治理呢？Poller表演了这个角色。
第二个疑难是，为什么要在Poller中来实现真正的注册，而不是在Acceptor，要了解这一点必须要对NIO有肯定理解。在NIO中Selector的register()和select()都是阻塞式的，对于一个socke来说，必定式要register()再select()。先当初假如第一个客户端A发来链接申请，Poller因为在启动阶段线程就始终在运行了，然而因为没有事件产生，因而被阻塞在select()办法，此时尽管A客户端发来了申请，然而因为阻塞的起因，并不能注册胜利，没有注册胜利，天然也就没有读写事件，就这样始终期待着，那这样岂不死锁了？为了解决这个问题，才有addEvent()结尾处有一个唤醒的办法。
Poller循环中不仅负责老板交给的工作，还要分派任务，上面看下Poller如何解决Socket？Poller会通过NIO模型，当有IO事件到来时候，调用processKey()->processSocket()解决申请。而在processSocket()中，会把每个IO事件封装成SocketProcessorBase工作，交给wokers线程池执行。
public boolean processSocket(SocketWrapperBase<S> socketWrapper,
SocketEvent event, boolean dispatch) {
try {
if (socketWrapper == null) {
return false;
}
SocketProcessorBase<S> sc = null;
if (processorCache != null) {
sc = processorCache.pop();
}
if (sc == null) {
sc = createSocketProcessor(socketWrapper, event);
} else {
sc.reset(socketWrapper, event);
}
// 留神这里的Executor，其实就是真正干活的workers
// workers的大小和一些信息，曾经在初始化的办法中对立做了，须要留神的是，应用linkQ作为阻塞队列。
// 那么这样的话，大量的申请如果不能及时处理，阻塞队列可能爆满，不能再执行新的工作，
// 因而tomcat会勾销此次读事件！！并且敞开socket链接
// 这里大略是这样的，每个socket链接建设好后，会有大量的读事件进行解决
// 因而这里委派给了workers线程池来解决
// 而咱们的具体的工作是后面的SocketProcessorBase 他是一个Runnable实现的对象
// 因而要看
Executor workers = getExecutor();
if (dispatch && workers != null) {
workers.execute(sc);
} else {
sc.run();
}
} catch (RejectedExecutionException ree) {
getLog().warn(sm.getString("endpoint.executor.fail", socketWrapper) , ree);
return false;
} catch (Throwable t) {
ExceptionUtils.handleThrowable(t);
// This means we got an OOM or similar creating a thread, or that
// the pool and its queue are full
getLog().error(sm.getString("endpoint.process.fail"), t);
return false;
}
return true;
}这里咱们能够把Acceptor了解咱们的老板，咱们TL就是那个接老板活的人（Poller），而后指定谁来干。嗯。。。。这里的”咱们”，就是真正干活的workers。tomcat利用这三个组件，把相干的职责离开了，零碎更加清晰，也更加高效(两个线程)，值得学习。另外也能够看到，Acceptor和Poller都是单线程，因为他们只分派任务，所以不存在性能瓶颈，而workers则必须以线程池的形式来运行了。所以在做零碎设计的时候，也要留神哪里才是最须要资源的中央。
woker工作内容：在后面，每个IO事件，被封装成SocketProcessorBase工作，交给线程池运行，因而咱们关注下SocketProcessorBase的run(),它会调用doRun()
@Override
protected void doRun() {
...
if (handshake == 0) {
SocketState state = SocketState.OPEN;
// Process the request from this socket
if (event == null) {
state = getHandler().process(socketWrapper, SocketEvent.OPEN_READ);
} else {
state = getHandler().process(socketWrapper, event);
}
if (state == SocketState.CLOSED) {
poller.cancelledKey(getSelectionKey(), socketWrapper);
}
} else if (handshake == -1 ) {
getHandler().process(socketWrapper, SocketEvent.CONNECT_FAIL);
poller.cancelledKey(getSelectionKey(), socketWrapper);
} else if (handshake == SelectionKey.OP_READ){
socketWrapper.registerReadInterest();
} else if (handshake == SelectionKey.OP_WRITE){
socketWrapper.registerWriteInterest();
}
} catch (CancelledKeyException cx) {
poller.cancelledKey(getSelectionKey(), socketWrapper);
} catch (VirtualMachineError vme) {
ExceptionUtils.handleThrowable(vme);
} catch (Throwable t) {
log.error(sm.getString("endpoint.processing.fail"), t);
poller.cancelledKey(getSelectionKey(), socketWrapper);
} finally {
socketWrapper = null;
event = null;
//return to cache
if (running && processorCache != null) {
processorCache.push(this);
}
}办法省略了很多内容，外围看下getHandler().process(socketWrapper, event);这里获取到的Handler，就是在后面启动Connector创立的ConnectionHandler。ConnectionHandler解决的次要内容，依据具体协定
找到对应的Processor去解决这个socket。
Processor processor = (Processor) wrapper.takeCurrentProcessor();
if (processor == null) {
// 依据咱们指定的协定，去创立对应的处理器
processor = getProtocol().createProcessor();
register(processor);
if (getLog().isDebugEnabled()) {
getLog().debug(sm.getString("abstractConnectionHandler.processorCreate", processor));
}
}
// 依据具体协定去解决申请事件了
state = processor.process(wrapper, status);后面我在Connector启动的时候，创立了一个默认协定Http11NioProtocol，
因而getProtocol()返回Http11NioProtocol，而后通过它创立一个Processor，它会生成以Http11Processor。
Http11Processor继承自AbstractProcessor
public AbstractProcessor(AbstractEndpoint<?,?> endpoint) {
this(endpoint, new Request(), new Response());
}上面看下Http11Processor是如何进行解决的，这里又用到了模板办法（Http11Processor继承自AbstractProcessorLight，实现了Processor接口)：process->service();
@Override
public SocketState service(SocketWrapperBase<?> socketWrapper)
throws IOException {
getAdapter().service(request, response);这里能够看到service的入参是SocketWrapperBase，数据被解析进了request,和response两个对象中。另外后面Connector启动的时候，也指定了适配器是，CoyoteAdapter,因而最终是调用在CoyoteAdapter.service(request, response).
到了这里咱们能够看到客户端发送数据后，服务端利用NIO收到可读事件，获取数据后，把内容转换成了request和response，而后利用适配器去解决。
发表回复