tomcat处理网络的时有 JIoEndpoint,NioEndpoint,AprEndpoint 分别对应了三种传统IO模式，BIO用线程池处理连接创建后的业务，NIO用到了channel处理，AIO使用了回调处理，本篇主要将jio
1）JIoEndpoint的创建与初始化
ConnectorCreateRule在解析server.xml时，获取对应connector中的protocol标签（使用digester解析）
在Http11Protocol创建了JIO
public Http11Protocol() {
endpoint = new JIoEndpoint();
cHandler = new Http11ConnectionHandler(this);
((JIoEndpoint) endpoint).setHandler(cHandler);
setSoLinger(Constants.DEFAULT_CONNECTION_LINGER);
setSoTimeout(Constants.DEFAULT_CONNECTION_TIMEOUT);
setTcpNoDelay(Constants.DEFAULT_TCP_NO_DELAY);
}
随着Connector的启动，在Http11Protocol中启动了endpoint
2）JIoEndpoint启动时
启动方法：
public final void start() throws Exception {
if (bindState == BindState.UNBOUND) {
bind();
bindState = BindState.BOUND_ON_START;
}
startInternal();
}
//在bind中设置了一些参数
acceptorThreadCount = 1;//接收IO请求线程数量为1
setMaxConnections(getMaxThreadsWithExecutor());//将xml中配置的Executor线程数设置到maxConnections中
serverSocketFactory = new DefaultServerSocketFactory(this);//创建网络连接工厂类，this是endpoint没有作用不用关心
serverSocket = serverSocketFactory.createSocket(getPort(), getBacklog());//初始化连接端口，默认8080
startInternal方法调用到了org.apache.tomcat.util.net.JIoEndpoint.startInternal()
创建了一个任务处理的线程池，并且开启了org.apache.tomcat.util.net.JIoEndpoint.Acceptor
3）Acceptor socket监听器
其功能就是一个socketServer,控制着请求的连接数,然后不断监听请求
public void run() {
int errorDelay = 0;
// Loop until we receive a shutdown command
while (running) {//protected volatile boolean running 声明是一个volatile类型，降低状态的延迟
// Loop if endpoint is paused
...
state = AcceptorState.RUNNING;
try {
//if we have reached max connections, wait 查看当前处理队列是不是满了，满了就会等待
countUpOrAwaitConnection();
Socket socket = null;//创建一个新的Socket
try {
// Accept the next incoming connection from the server
// socket
socket = serverSocketFactory.acceptSocket(serverSocket);
//这里是开启监听，假如有另一个连接连上了这个serverSocket，那么就会返回一个socket
} catch (IOException ioe) {
countDownConnection();//异常时减一
...
}
// Successful accept, reset the error delay
errorDelay = 0;
// Configure the socket
if (running && !paused && setSocketOptions(socket)) {
// Hand this socket off to an appropriate processor
if (!processSocket(socket)) {//processSocket调用线程池处理socket
countDownConnection();
// Close socket right away
closeSocket(socket);
}
...
}
其中最关键的方法
socket = serverSocketFactory.acceptSocket(serverSocket);
serverSocket作为socket的服务端，在endpoint最开始的bind中就创建并且开始监听了,监听后在系统中就有了linsten端口的动作，再然后有其他请求到达主机后才会确认端口有监听，请求能够被接收，可以通过操作系统的netstat -ano看到
socket的代码比较枯燥，可以总出来这样的东西，我们的tomcat将创建一个serverSocket其实现是SocksSocketImpl,进一步SocksSocketImpl是继承自PlainSocketImpl，Plain的功能是由TwoStacksPlainSocketImpl调用本地库执行,本地方法调用系统后就正真开启了一个端口监听
native void socketCreate(boolean isServer) throws IOException;
native void socketAccept(SocketImpl s) throws IOException;
本地方法是系统与java的桥梁，其调用了系统的sock函数
fd = accept(fd, (struct sockaddr *)&him, &len);//这个就是调用系统的函数获取连接返回文件描述符
对linux不熟悉，向同学咨询了，在linux中socket的accept指令会监听客户端的请求，请求成功后将会创建新的连接，然后将系统新生成的socket文件描述符fd返回，这个fd是系统存放所有文件索引的地方
继续往下看，在本地方法中将远程客户的地址以及新建连接的fd写入我们的空壳子java socket中，就等于返回了一个新的客户端连接，其记录了请求连接的地址端口信息还有服务端的地址信息
（底层涉及系统的代码不好看，可以手动创建一个服务端将返回的sock存入一个list进行对比观察，多次请求过来的sock是有不同的fd和sockimpl的）
当有请求connect后，socketAccept就会返回一个socket，sock里面是有输入输出流的
4）处理器
processSocket方法中
SocketWrapper wrapper = new SocketWrapper(socket);
getExecutor().execute(new SocketProcessor(wrapper));
由于交给了线程池处理，方法会很快返回，接收器就能继续下一个socket的连接了
假如说在processSocket中阻塞，我们的接收器就不会接受后面新的请求，这就是bio
5）请求处理过程
SocketWrapper将sock封装成了一个SocketProcessor放入线程池执行
if ((state != SocketState.CLOSED)) {
if (status == null) {
state = handler.process(socket, SocketStatus.OPEN_READ);
} else {
state = handler.process(socket,status);
}
}
Http11Processor在process方法中将socketWrapper中的sock输入输出流获取出来，将sock连接的数据转换成了一个coyote的request
再然后将请求提交给connector的adapter进行业务处理，处理的结果在response中存放
最后在commit的时候，将response调用socket的write方法发送给请求方
6）关闭socket
体现出来的BIO，就是accept方法是一个阻塞方法，但是正真影响使用的并不是这里，阻塞在处理sock的时候，假如有连接连上了没有传数据或者数据很大，那么处理线程会一直等待，而线程是有数量限制的，所以连接占满了就处理不了了，这里才是阻塞关键的地方
连接建立后等待数据的过程是阻塞的才是BIO
