以后端发动一次申请，我想理解tomcat是如何解决的。这里写一些文章做一些简短的记录，不便后续温习。
Connector的创立：当实例化一个Connector，结构器函数会通过反射的形式创立一个ProtocolHandler。这里的protocolHandlerClassName实际上是：”org.apache.coyote.http11.Http11NioProtocol”;
public Connector(String protocol) {
setProtocol(protocol);
// Instantiate protocol handler
ProtocolHandler p = null;
try {
Class<?> clazz = Class.forName(protocolHandlerClassName);
p = (ProtocolHandler) clazz.getConstructor().newInstance();
} catch (Exception e) {
log.error(sm.getString("coyoteConnector.protocolHandlerInstantiationFailed"), e);
} finally {
this.protocolHandler = p;
}
...
}
为什么要在创立Connector的时候绑定一个ProtocolHandler呢？其实情理很简略，当客户端和服务器发送网络申请时，必须约定协定，tomcat经常作为web端服务器，因而默认提供解决http协定的ProtocolHandler。
而在创立Http11NioProtocol过程中，又创立了上面的内容：
public Http11NioProtocol() {
// 创立一个Nio模型的端点
super(new NioEndpoint());
}
public AbstractHttp11Protocol(AbstractEndpoint<S,?> endpoint) {
super(endpoint);
setConnectionTimeout(Constants.DEFAULT_CONNECTION_TIMEOUT);
// 创立一个ConnectionHandler来解决链接
ConnectionHandler<S> cHandler = new ConnectionHandler<>(this);
setHandler(cHandler);
getEndpoint().setHandler(cHandler);
}
Connector的初始化：
Tomcat外围的组件都实现了Lifecycle接口，被治理的接口，大略都是经验
init()->start()->stop()的生命周期。
tomcat为了对立治理Lifecycle的组件，提供了抽象类LifecycleBase(实现了Lifecycle接口办法)，每一个继承LifecycleBase的组件都会有一个状态，它的默认值是：
private volatile LifecycleState state = LifecycleState.NEW;上面是LifecycleBase提供init()的模板办法：
@Override
public final synchronized void init() throws LifecycleException {
// 对于任何一个组件来说，肯定是在新生状态才可能被初始化，如果不是则抛出异样
if (!state.equals(LifecycleState.NEW)) {
invalidTransition(Lifecycle.BEFORE_INIT_EVENT);
}
try {
// init前的状态
setStateInternal(LifecycleState.INITIALIZING, null, false);
// 真正的初始化办法，每个子类必须实现它
initInternal();
// init后的状态
setStateInternal(LifecycleState.INITIALIZED, null, false);
} catch (Throwable t) {
handleSubClassException(t, "lifecycleBase.initFail", toString());
}
}
这个办法有两个要学习的中央：
第一在办法上应用了synchronized+状态判断，比较简单的形式就保障一个了组件，只能初始化。而状态的应用也是很有用的，当咱们有一堆组件，组合成某种性能时，只有当所有组件都处于某种失常的状态时，才可能提供服务的。
第二是利用了抽象类，对立标准了初始化的流程。这里也能够看出接口和抽象类的区别，接口更像是定义了一些系列协定。而抽象类表白的是，你想要实现某种性能，你的规范流程是什么？
因而Connector继承了LifecycleBase，所以要看Connector在初始化，都干了什么事，就找到对应的initInternal():
@Override
protected void initInternal() throws LifecycleException {
super.initInternal();
// 指定了适配器
adapter = new CoyoteAdapter(this);
protocolHandler.setAdapter(adapter);
....
try {
// Http11NioProtocol init
protocolHandler.init();
} catch (Exception e) {
throw new LifecycleException(
sm.getString("coyoteConnector.protocolHandlerInitializationFailed"), e);
}
}上面看下protocolHandler.init()，它实际上要调用AbstractProtocol的init(),最初调用NioEndpoint的init()-> bindWithCleanup()->bind()：
public void init() throws Exception {
if (bindOnInit) {
// 初始化服务器
bindWithCleanup();
bindState = BindState.BOUND_ON_INIT;
}
....
}
@Override
public void bind() throws Exception {
// 重点!
initServerSocket();
setStopLatch(new CountDownLatch(1));
// Initialize SSL if needed
initialiseSsl();
}
protected void initServerSocket() throws Exception {
if (getUseInheritedChannel()) {
// Retrieve the channel provided by the OS
Channel ic = System.inheritedChannel();
if (ic instanceof ServerSocketChannel) {
serverSock = (ServerSocketChannel) ic;
}
if (serverSock == null) {
throw new IllegalArgumentException(sm.getString("endpoint.init.bind.inherited"));
}
} else {
serverSock = ServerSocketChannel.open();
socketProperties.setProperties(serverSock.socket());
// 获取地址，绑定服务器端口
InetSocketAddress addr = new InetSocketAddress(getAddress(), getPortWithOffset());
serverSock.socket().bind(addr,getAcceptCount());
}
// 服务主线程，次要负责链接的申请，为了管制申请的大小
// 所以这里采纳了阻塞模式
serverSock.configureBlocking(true); //mimic(模拟) APR behavior
}其中getAcceptCount()默认值为：100
在这里咱们能够看到，咱们平时配置的端口时如何失效的，就在addr中
tomcat中的NIO并不全部都是NIO,对于每个客户端的申请，任然应用的时阻塞模式。
到了这里Connector实现了它的初始化工作，留神并没有启动！
Connector开始运行：这里依照Lifecycle的思维，间接看Connector的startInternal()
@Override
public void startInternal() throws Exception {
if (!running) {
running = true;
paused = false;
if (socketProperties.getProcessorCache() != 0) {
processorCache = new SynchronizedStack<>(SynchronizedStack.DEFAULT_SIZE,
socketProperties.getProcessorCache());
}
if (socketProperties.getEventCache() != 0) {
eventCache = new SynchronizedStack<>(SynchronizedStack.DEFAULT_SIZE,
socketProperties.getEventCache());
}
if (socketProperties.getBufferPool() != 0) {
nioChannels = new SynchronizedStack<>(SynchronizedStack.DEFAULT_SIZE,
socketProperties.getBufferPool());
}
// Create worker collection
// endpoint获取申请后，会交给worker去执行，主线程仅仅是获取申请
// 另外这里采纳了非阻塞io,期待链接是阻塞式的，解决其余读写事件是用了非阻塞IO
if (getExecutor() == null) {
createExecutor();
}
// 设置最大的链接数：8192。这里须要留神，这里是如何工作的，
// 因为应用了Latch，因而每来一个链接，maxConnection就缩小1.直到为0
// 当为0的时候，不能再承受多的链接申请了
initializeConnectionLatch();
// Start poller thread
poller = new Poller();// 关上选择器，Poller其实是一个Runnable
Thread pollerThread = new Thread(poller, getName() + "-Poller");
pollerThread.setPriority(threadPriority);
pollerThread.setDaemon(true);
pollerThread.start();// poller 开始工作。Poller 那么这里去看一下run()
// 开启Acceptor Thread专门负责接管socket链接，留神它并不进行socket解决
startAcceptorThread();
}
}wokers和Poller在前面说
接着咱们看下startAcceptorThread()
protected void startAcceptorThread() {
acceptor = new Acceptor<>(this);
String threadName = getName() + "-Acceptor";
acceptor.setThreadName(threadName);
Thread t = new Thread(acceptor, threadName);
t.setPriority(getAcceptorThreadPriority());
t.setDaemon(getDaemon());
t.start();
}Poller和Acceptor都是线程，因而想要明确它们工作内容，之间看对应的run();
首先是Acceptor：
@Override
public void run() {
int errorDelay = 0;
long pauseStart = 0;
try {
// Loop until we receive a shutdown command
while (!stopCalled) {
// Loop if endpoint is paused.
// There are two likely scenarios here.
// The first scenario is that Tomcat is shutting down. In this
// case - and particularly for the unit tests - we want to exit
// this loop as quickly as possible. The second scenario is a
// genuine pause of the connector. In this case we want to avoid
// excessive CPU usage.
// Therefore, we start with a tight loop but if there isn't a
// rapid transition to stop then sleeps are introduced.
// < 1ms - tight loop
// 1ms to 10ms - 1ms sleep
// > 10ms - 10ms sleep
while (endpoint.isPaused() && !stopCalled) {
if (state != AcceptorState.PAUSED) {
pauseStart = System.nanoTime();
// Entered pause state
state = AcceptorState.PAUSED;
}
if ((System.nanoTime() - pauseStart) > 1_000_000) {
// Paused for more than 1ms
try {
if ((System.nanoTime() - pauseStart) > 10_000_000) {
Thread.sleep(10);
} else {
Thread.sleep(1);
}
} catch (InterruptedException e) {
// Ignore
}
}
}
if (stopCalled) {
break;
}
state = AcceptorState.RUNNING;
try {
// if we have reached max connections, wait
// 限度了最大的申请数。
endpoint.countUpOrAwaitConnection();
// Endpoint might have been paused while waiting for latch
// If that is the case, don't accept new connections
if (endpoint.isPaused()) {
continue;
}
U socket = null;
try {
// Accept the next incoming connection from the server socket
socket = endpoint.serverSocketAccept();
} catch (Exception ioe) {
// We didn't get a socket
endpoint.countDownConnection();
if (endpoint.isRunning()) {
// Introduce delay if necessary
errorDelay = handleExceptionWithDelay(errorDelay);
// re-throw
throw ioe;
} else {
break;
}
}
// Successful accept, reset the error delay
errorDelay = 0;
// Configure the socket
if (!stopCalled && !endpoint.isPaused()) {
// setSocketOptions() will hand the socket off to
// an appropriate processor if successful
// 解决的socket
if (!endpoint.processSocket(socket)) {
endpoint.closeSocket(socket);
}
} else {
endpoint.destroySocket(socket);
}
} catch (Throwable t) {
ExceptionUtils.handleThrowable(t);
String msg = sm.getString("endpoint.accept.fail");
// APR specific.
// Could push this down but not sure it is worth the trouble.
if (t instanceof org.apache.tomcat.jni.Error) {
org.apache.tomcat.jni.Error e = (org.apache.tomcat.jni.Error) t;
if (e.getError() == 233) {
// Not an error on HP-UX so log as a warning
// so it can be filtered out on that platform
// See bug 50273
log.warn(msg, t);
} else {
log.error(msg, t);
}
} else {
log.error(msg, t);
}
}
}
} finally {
stopLatch.countDown();
}
state = AcceptorState.ENDED;
}Acceptor作为一个线程始终while循环，直到stop。通过代码也大略看得出
，它的次要工作就是负责承受申请。
在申请到来后，Acceptor会分派给Poller去解决。那么有一个问题是，如果不限度申请量大小，服务器会解体，那么接着就会产生一个疑难，既然tomcat有并发限度，为什么咱们还要对接口做性能调优？
在这个办法中，有一行很重要的代码endpoint.processSocket(socket)。最后源代码叫endpoint.setSocketOptions(socket)，我为了浏览不便，调整成processSocket，前面整体了解了下processSocket的确不太好，因为Acceptor仅仅负责承受申请，它并不解决申请。
因为当初仅仅是start，并没有申请到来，因而线程被阻塞在socket = endpoint.serverSocketAccept();这个办法实际上是：
protected SocketChannel serverSocketAccept() throws Exception {
// 因为是阻塞模式，因而没有新的申请到来时，线程被阻塞在这里了
SocketChannel result = serverSock.accept();
return result;
}好了，到了这里，Connector曾经启动好了，能够承受客户端的申请了
Poller呢？因为它和链接的解决，十分严密，在后续申请到来时说。
Connector的启动次要目标就是提供好服务端的serverSocket，指定好当有socket申请时，要依照协定去解决申请（Http11NioProtocol）
发表回复