Jetty 9 源码分析 Connector及Server类（一）

半只蚂蚁

　　本文的源码基于Jetty9，主要分析了Jetty 的Connector与Server类间在Jetty启动过程中的一些细节。
Jetty9 对以前的Connector体系进行了重构， 结构与6和7都不同，原有的一些BIO类已经被抛弃。
　　
先看Server 构造函数



public Server(@Name("port")int port)
{
this((ThreadPool)null);
ServerConnector connector=new ServerConnector(this);
connector.setPort(port);
setConnectors(new Connector[]{connector});
}
　　将本身传入ServerConnector构造， 设置connector的port， 并将ServerConnector传入自身的
Connector数组，保持引用。
　　Server自身的Connectors数组变量，采用CopyOnWriteArrayList，保证可能的线程操作的安全。



private final List<Connector> _connectors = new CopyOnWriteArrayList<>();
　　Server启动类在Jetty.xml中定义，并设置线程池，Handler



<Configure id="Server" class="org.eclipse.jetty.server.Server">
　　ThreadPool是共享的， Connector与dispatch类都会用到。
　　Server继承自HandlerWrapper， HandlerWrapper将handle代理给其装饰的类，即实际的Handler类，实现Decorator模式。
继承关系如下：

AbstractHandler
|-AbstractHandlerContainer
  |-HandlerWrapper
    |-Server
Server的启动方法是doStart(),该方法先调用上层doStart()方法，然后调用自身Connector数组的中的Connector类的start()方法。

try
{
super.doStart();
}
for (Connector _connector : _connectors)
{
try
{
_connector.start();
}
catch (Throwable e)
{
mex.add(e);
}
}
　　ServerConnector是Jetty9中主要的Connector实现，负责主要接入处理，此类主要的操作还有Java对接入连接的抽象Connection，
Connection由Connector中设置的工厂类产生，如果没设置过，默认的工厂类是HttpConnectionFactory。
Connector中还会与另一抽象Selector交互。

　　描述了ServerConnector继承关系的类图：

　　
ServerConnector的继承层次如下：

　　下面看一些具体点的代码：
　　
  AbstractLifeCycle         start() -> doStart();  预留了doStart()方法供子类重写。
   |-ContainerLifeCycle    doStart()
  |-AbstractConnector   
    |-AbstractNetworkConnector   doStart() ->open(); 设置了一个open方法供子类重写
      |-ServerConnectoropen()；  实现了open方法，打开ServerSocketChannel
　　
AbstractLifeCycle中start()的内容：



try
{
if (_state == __STARTED || _state == __STARTING)
return;
setStarting();
doStart();
setStarted();
}
　　可看到此方法作为一个模板方法，将doStart()的实现留给子类重写，其自身的doStart()是一个空方法，这种用法在Jetty跟生命周期有关的类很多。
Open方法的内容，隐藏部分不太重要的细节：



if (serverChannel == null)
{
serverChannel = ServerSocketChannel.open();
InetSocketAddress bindAddress = getHost() == null ? new InetSocketAddress(getPort()) : new InetSocketAddress(getHost(), getPort());
serverChannel.socket().bind(bindAddress, getAcceptQueueSize());
serverChannel.socket().setReuseAddress(getReuseAddress());
_localPort = serverChannel.socket().getLocalPort();
if (_localPort <= 0)
throw new IOException("Server channel not bound");
addBean(serverChannel);
}
serverChannel.configureBlocking(true);
addBean(serverChannel);
_acceptChannel = serverChannel;
　　这里的ServerSocketChannel使用的是阻塞模式，
回到 AbstractNetworkConnector 的doStart中：



protected void doStart() throws Exception
{
open();
super.doStart();
}
　　方法继续调用了父类的doStart(), 那么再看父类AbstractConnector的doStart():



protected void doStart() throws Exception
{
_defaultConnectionFactory = getConnectionFactory(_defaultProtocol);
super.doStart();
_stopping=new CountDownLatch(_acceptors.length);
for (int i = 0; i < _acceptors.length; i++)
getExecutor().execute(new Acceptor(i));
}
　　此方法设置的默认的ConnectionFactory， 另一个重要概念Acceptor类也是这里出现的。
Acceptor是AbstractConnector的私有内部类，这里用的CountDownLatch是给doStop用的， stop中会计算这个CountDownLatch是否为空，
不为空则会调用CountDownLatch.await等待， 知道Acceptor的线程都停掉才继续做stop的其他事情。
Acceptor的数量在该类的构造方法中进行初始化，下面是片段：



if (acceptors<=0)
acceptors=Math.max(1,(Runtime.getRuntime().availableProcessors()) / 2);
　　主要计算方式就是最少是1个，是否大于一个要根据CPU数量来，按CPU核心数量/2来计算Acceptor的数量。