Jetty 服务器架构分析(中)
??? 接上一篇,說到XmlConfiguration ,XmlConfiguration 利用自己實現(xiàn)的 IOC 組裝 Server 的全過程如下圖所示:
這里可以看到 3 個關(guān)鍵的配置文件, jetty.xml 、 jetty-deploy.xml 、以及 contexts/xxx.xml
l? Jetty.xml 文件中定義了入口類 Server, 以及其所需要的線程池、 Connector 、 Handler 。
l? Jetty-deploy.xml 中則定義了部署 web 應(yīng)用用到部署工具,在其中指定了部署 web 應(yīng)用的兩種方式,類似于 tomcat, 如果采用 webappProvider ,則表示將 web 應(yīng)用放在 webapp 下即可生效,如果采用 ContextProvider ,則需要定義 Contexts 目錄所在位置,只要在該目錄下放置任何應(yīng)用的 context 配置文件就可以生效。
l? Xxx.xml 這是一個用戶自定義文件,表示采用 ContextProvider 時,在其中定義一個 WebAppContext 的 handler, 它指定了我們應(yīng)用所在的位置,便于加載。
?
XmlConfiguration 解析裝配完畢之后,就開始啟動服務(wù), Jetty 的啟動是從 Server 開始的,我們來看一下服務(wù)器真正的啟動過程。
?
?
?
?
?
?
從上圖中我們能大概看出服務(wù)器啟動過程,先是由用戶設(shè)置好需要的核心組件,然后調(diào)用 Server.start() 開始啟動服務(wù),其中會首先啟動 handler 處理器,之后啟動用戶自定義組件,這個自定義組件需要實現(xiàn) LifeCyle 接口,最后才啟動 Connector 接受請求??梢韵氲?#xff0c;關(guān)閉過程恰好是反過來,首先關(guān)閉接受請求的 connector ,然后再關(guān)閉用戶自定義組件,最后關(guān)閉 handler.
???????? 我們再來詳細看一下 Server 源代碼的核心實現(xiàn)過程,當(dāng)調(diào)用 start 方法時,其實是調(diào)用其祖先類 AbstractLifeCycle 中方法,該方法在這里有一個模板實現(xiàn),如下:
public final void start() throws Exception { synchronized (_lock) { try { if (_state == __STARTED || _state == __STARTING) return; setStarting(); doStart(); setStarted(); } catch (Exception e) { setFailed(e); throw e; } catch (Error e) { setFailed(e); throw e; } } }
?
-
Connector 啟動過程
?
看下 Connector 的詳細啟動過程: ( 以 NIO 為例 )
?
NIOConnector 啟動過程中,先創(chuàng)建了多個 SelectSet 對象,每個 SelectSet 負責(zé)一個 NIO 的 Selector ,專門用于監(jiān)聽 read 事件 ( 這里利用的多線程 Reactor 模式, http://gee.cs.oswego.edu/dl/cpjslides/nio.pdf ) ,當(dāng)然這里僅僅是創(chuàng)建了對象,并沒有啟動,后面會提到。
SelectorManager :
?
?
然后再調(diào)用 open 創(chuàng)建了一個 blocking 的阻塞 channel ,專門用于接受用戶的新連接,我們看下:
?
public void open() throws IOException { synchronized(this) { if (_acceptChannel == null) { // Create a new server socket _acceptChannel = ServerSocketChannel.open(); // Set to blocking mode _acceptChannel.configureBlocking(true); // Bind the server socket to the local host and port _acceptChannel.socket().setReuseAddress(getReuseAddress()); InetSocketAddress addr = getHost()==null?new InetSocketAddress(getPort()):new InetSocketAddress(getHost(),getPort()); _acceptChannel.socket().bind(addr,getAcceptQueueSize()); _localPort=_acceptChannel.socket().getLocalPort(); if (_localPort<=0) throw new IOException("Server channel not bound"); } } }
?
隨后從線程池中分配了 N 個 ( 可以在配置文件中配置 ) 線程用于啟動 SelectSet 監(jiān)聽 read 事件。
?
?
?
?
?
?
?
?
synchronized (this) { _acceptorThread = new Thread[getAcceptors()]; for (int i = 0; i < _acceptorThread.length; i++) _threadPool.dispatch(new Acceptor(i)); if (_threadPool.isLowOnThreads()) Log.warn("insufficient threads configured for {}",this); }
最后再分配 1 個線程用于 accept 用戶的新連接,新連接來之后,會將其設(shè)置為 nonblocking 模式,之后就將其 Register 給某個 SelectSet 去監(jiān)聽 read 事件,然后又返回來繼續(xù)監(jiān)聽新連接:
?
_manager.dispatch(new Runnable() { public void run() { final ServerSocketChannel server=_acceptChannel; while (isRunning() && _acceptChannel==server && server.isOpen()) { try { SocketChannel channel = server.accept(); channel.configureBlocking(false); Socket socket = channel.socket(); configure(socket); _manager.register(channel); } catch(IOException e) { Log.ignore(e); } } } });
?
?
?
-
Handler 啟動過程
?
Jetty 將所有的真正處理請求的動作都抽象成了 Handler ,因此做事情的組件都是實現(xiàn)了這個接口的,包括上圖所示的 WebAppContext 等等,需要做什么樣的工作,那么就添加什么樣的 Handler ,這里 SessionHandler 不是必須的,但是默認是創(chuàng)建好的。 ServletHandler 主要負責(zé)處理 web 應(yīng)用的 Servlet 、 Filter 等工作,最后將請求直接交給 Servlet 、 Filter 都是在這里完成。
?? 這里展示的 Handler 的啟動過程其實是在準(zhǔn)備 web 應(yīng)用環(huán)境,例如解析 web 應(yīng)用的 web.xml 等等工作,做好一切準(zhǔn)備工作。
?
?
?轉(zhuǎn)載于:https://www.cnblogs.com/lovingprince/archive/2011/02/23/2166259.html
總結(jié)
以上是生活随笔為你收集整理的Jetty 服务器架构分析(中)的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 阿里巴巴编码规范(java)考核
- 下一篇: 详解为何在嵌套ESXi环境下要求开启Pr