背景
最近跟著前輩學(xué)習(xí)了Tomcat源碼。記錄一下分析過程和tomcat的架構(gòu)設(shè)計思想。
環(huán)境準備
idea
java sdk
tomcat源碼下載：https://github.com/apache/tomcat.git
git下載失敗可以換碼云:https://gitee.com/mirrors/tomcat
源碼目錄結(jié)構(gòu)
├── bin 啟動和關(guān)閉tomcat的腳本
├── conf 服務(wù)器的各種配置文件
├── java 源碼目錄
├── modules jdbc包
├── res ？
├── test 單元測試
└── webapps 應(yīng)用程序目錄
idea配置源碼調(diào)試環(huán)境
1 idea配置
- 下載源碼后用idea打開，設(shè)置源碼目錄為java
- image.png
- 配置啟動類，jre我用的13，大家選擇自己安裝的版本即可
- image.png
-
idea項目根目錄添加pom.xml，工程設(shè)置添加maven依賴
主要是依賴的一些第三方庫，我這里給一個我的pom.xml的依賴配置供參考
如果不知道m(xù)aven的pom文件怎么寫，建議去參考一下其他教程，這里不擴展了。<dependencies> <dependency> <groupId>ant</groupId> <artifactId>ant</artifactId> <version>1.7.0</version> </dependency> <dependency> <groupId>ant</groupId> <artifactId>ant-apache-log4j</artifactId> <version>1.6.5</version> </dependency> <dependency> <groupId>ant</groupId> <artifactId>ant-commons-logging</artifactId> <version>1.6.5</version> </dependency> <dependency> <groupId>wsdl4j</groupId> <artifactId>wsdl4j</artifactId> <version>1.6.2</version> </dependency> <dependency> <groupId>javax.xml.rpc</groupId> <artifactId>javax.xml.rpc-api</artifactId> <version>1.1</version> </dependency> <dependency> <groupId>org.eclipse.jdt.core.compiler</groupId> <artifactId>ecj</artifactId> <version>4.6.1</version> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> <scope>test</scope> </dependency> <dependency> <groupId>org.easymock</groupId> <artifactId>easymock</artifactId> <version>RELEASE</version> <scope>test</scope> </dependency> </dependencies> 現(xiàn)在開始運行，發(fā)現(xiàn)還有一些錯誤
是一些源碼無關(guān)的測試，example代碼引起的，繼續(xù)解決錯誤提示: trailers.ResponseTrailers不存在
解決方式： webapps/examples/WEB_INF/classes/trailers 目錄下找到該類，復(fù)制一份到test。錯誤提示：CookieFilter不存在
解決方式和上面類似，全局搜索到CookieFilter，拷貝到test/util,報錯找不到的位置錯誤提示：java.lang.ClassNotFoundException: listeners.ContextListener
解決方法，暴力一點，直接刪除， 刪除 webapps 下的 examples 文件夾！程序再次運行不報此錯誤，對的，就是整個目錄刪掉。這個時候已經(jīng)可以運行了，但是啟動后，瀏覽器輸入127.0.0.1:8080，會報服務(wù)器錯誤500
解決方式： org.apache.catalina.startup.ContextConfig 文件的 configureStart() 方法，添加初始化 JSP 解析器的代碼
context.addServletContainerInitializer(new JasperInitializer(), null);
添加位置：
- image.png
至此，源碼調(diào)試環(huán)境配置完成
2 為什么啟動類是org.apache.catalina.startup.Bootstrap
前面應(yīng)該看到我們配置啟動類位置：org.apache.catalina.startup.Bootstrap，找到入口這個很關(guān)鍵，后續(xù)看源碼也是從這個入口出發(fā)。如何找到這個入口呢？
- 工程下找到 /bin/start.sh
--> 可以發(fā)現(xiàn)最終執(zhí)行的 catalina.sh start
找到 catalina.sh start 邏輯
eval $_NOHUP "\"$_RUNJAVA\"" "\"$LOGGING_CONFIG\"" $LOGGING_MANAGER $JAVA_OPTS $CATALINA_OPTS \
-D$ENDORSED_PROP="\"$JAVA_ENDORSED_DIRS\"" \
-classpath "\"$CLASSPATH\"" \
-Dcatalina.base="\"$CATALINA_BASE\"" \
-Dcatalina.home="\"$CATALINA_HOME\"" \
-Djava.io.tmpdir="\"$CATALINA_TMPDIR\"" \
org.apache.catalina.startup.Bootstrap "$@" start \
>> "$CATALINA_OUT" 2>&1 "&"
核心是：org.apache.catalina.startup.Bootstrap
源碼找到：Bootstrap 其中的main方法，就是啟動入口。這里有個入?yún)?start"，其實沒有這個參數(shù)，tomcat啟動也會設(shè)置默認入?yún)?shù) start
Tomcat 架構(gòu)
tomcat是一個web應(yīng)用服務(wù)器，核心是兩部分：
-
Http服務(wù)，其實是一個Connector（Coyote）
image.png Servlet容器（Catalina）
源碼中設(shè)計的Coyote和Catalina兩個關(guān)鍵字分別對應(yīng)這里的兩個模塊，后續(xù)不再解釋了。
核心代碼解讀
下面進入核心代碼的閱讀
LifeCycle
為了統(tǒng)一管理，抽象出LifeCycle接口
源碼中作者自己用字符畫了一張生命周期的示意圖，牛逼?。?！
- image.png
-
LifeCycle主要的構(gòu)成
- 生命周期接口：init()，start()，stop()， destroy()
- 事件名：BEFORE_INIT_EVENT等等
- 其他接口：
- public void addLifecycleListener(LifecycleListener listener);
-
public LifecycleState getState();
通過idea的Structure工具，能比較清晰的看出類結(jié)構(gòu)
image.png
如果需要查看類層級圖，mac idea下的快捷鍵是
ctrl + h
網(wǎng)上有教程說在 idea->navigate->call hierachy中，奈何我這個idea版本上一直灰顯，還好找到了快捷鍵。層級圖基本和項目的架構(gòu)對應(yīng)，容器啊，service這些，這里不深究了，只要知道基本整個容器和服務(wù)都繼承了LifeCycle即可，繼續(xù)往下。
啟動流程分析：初始化init()
- 前面已經(jīng)分析過了，啟動入口在Bootstrap的main方法中
main方法中有個默認的啟動參數(shù)是“start”
順著這個邏輯我們先直接到關(guān)鍵代碼行
else if (command.equals("start")) {
daemon.setAwait(true);
daemon.load(args);
daemon.start();
if (null == daemon.getServer()) {
System.exit(1);
}
- 其中daemon.load(args);就是我們要關(guān)心的核心代碼
- 跳轉(zhuǎn)到load
private void load(String[] arguments)
throws Exception {
// Call the load() method
String methodName = "load";
Object param[];
Class<?> paramTypes[];
if (arguments==null || arguments.length==0) {
paramTypes = null;
param = null;
} else {
paramTypes = new Class[1];
paramTypes[0] = arguments.getClass();
param = new Object[1];
param[0] = arguments;
}
// 通過反射獲取方法并且執(zhí)行
// catalinaDaemon的config file來自 conf/server.xml
Method method =
catalinaDaemon.getClass().getMethod(methodName, paramTypes);
if (log.isDebugEnabled())
log.debug("Calling startup class " + method);
method.invoke(catalinaDaemon, param);
}
然后進入Catalina.java找到這個load()方法
其中初始化的核心代碼是：
getServer().init();
這里的getServer用debug模式看到是StandardServer，其繼承關(guān)系如下：
其init()方法的邏輯在LifecycleBase中
@Override
public final synchronized void init() throws LifecycleException {
if (!state.equals(LifecycleState.NEW)) {
invalidTransition(Lifecycle.BEFORE_INIT_EVENT);
}
try {
setStateInternal(LifecycleState.INITIALIZING, null, false);
initInternal();
setStateInternal(LifecycleState.INITIALIZED, null, false);
} catch (Throwable t) {
handleSubClassException(t, "lifecycleBase.initFail", toString());
}
}
其中initInternal();用的是設(shè)計模式的“模版模式”，即基類中定義流程，然后具體的實現(xiàn)類中實現(xiàn)initInternal()；從StanderServer的initInternal中出發(fā)，我們大致可以看到如下圖所示的實例化過程。
就是依次調(diào)用子類的initInternal()，完成初始化。
初始化完成之后是start()流程
-
方式方法大致同init()，這里就不一步步debug了。注意幾個核心點即可
- 找到入口
還是前前面的Bootstrap的main方法，load之后就是
同樣是通過反射執(zhí)行StandardServer的start方法，也就是Catalina.java中的start方法daemon.start();
其核心是：
后續(xù)就和init很類似了getServer().start();
- 找到入口
容器啟動過程大致就是init()，start()，啟動之后如何處理http請求呢。接下倆看servlet請求處理的過程。
Servlet請求鏈路源碼
前置知識：
- 前面start過程中，默認啟動的是nio，selector多路復(fù)用channel
- acceptor線程用來注冊selector，poller線程檢查selector線程中哪些channel中有數(shù)據(jù)
-
所以核心處理的入口在Poller這個線程中。關(guān)聯(lián)的類是NioEndpoint.java就從這個類開始分析。
前面已經(jīng)配置好了調(diào)試環(huán)境，點擊頁面這個按鈕，可以出發(fā)一條請求，但是因為前面刪掉了一些文件，所以雖然可以構(gòu)建請求，但是最后的返回有錯誤，只是不影響我們閱讀源碼流程
image.png
NioEndpoint
- start()過程模版方法調(diào)用的執(zhí)行方法是startInternal() ,其核心代碼在最后
注冊Poller和啟動Acceptor
// Start poller threads
pollers = new Poller[getPollerThreadCount()];
for (int i=0; i<pollers.length; i++) {
pollers[i] = new Poller();
Thread pollerThread = new Thread(pollers[i], getName() + "-ClientPoller-"+i);
pollerThread.setPriority(threadPriority);
pollerThread.setDaemon(true);
pollerThread.start();
}
startAcceptorThreads();
- 其中Poller繼承自Runnable，說明是一個線程程序，實現(xiàn)邏輯在run方法
Poller初始化：注冊一個nioselector
public Poller() throws IOException {
this.selector = Selector.open();
}
run中 while（True）的大循環(huán)中等待selector中事件就緒，然后開始處理
while (true) {
boolean hasEvents = false;
try {
if (!close) {
hasEvents = events();
if (wakeupCounter.getAndSet(-1) > 0) {
//if we are here, means we have other stuff to do
//有請求需要處理了
keyCount = selector.selectNow();
} else {
keyCount = selector.select(selectorTimeout);
}
wakeupCounter.set(0);
}
// ***省略若干
// keyCount>0 開始處理
Iterator<SelectionKey> iterator =
keyCount > 0 ? selector.selectedKeys().iterator() : null;
}
while (iterator != null && iterator.hasNext()) {
SelectionKey sk = iterator.next();
NioSocketWrapper attachment = (NioSocketWrapper)sk.attachment();
// Attachment may be null if another thread has called
// cancelledKey()
if (attachment == null) {
iterator.remove();
} else {
// 先刪除后處理
iterator.remove();
processKey(sk, attachment); // 處理的核心
}
}//while
然后看processKey(),其中兩個邏輯分支，分別是讀和寫,
if (sk.isReadable() || sk.isWritable() )
處理邏輯是processSocket()
其核心是
SocketProcessorBase<S> sc = processorCache.pop();
if (sc == null) {
// 創(chuàng)建線程，處理socketWrapper
sc = createSocketProcessor(socketWrapper, event);
} else {
sc.reset(socketWrapper, event);
}
// *** 省略若干
executor.execute(sc);
可以知道sc是一個線程，交給線程池executor去執(zhí)行
既然sc是線程，那么找到核心的run方法。
@Override
public final void run() {
synchronized (socketWrapper) {
if (socketWrapper.isClosed()) {
return;
}
doRun();
}
}
這里和前面一樣，是模版方法，debug發(fā)現(xiàn)真實執(zhí)行的是
Endpoint中的doRun方法。
@Override
protected void doRun() {
NioChannel socket = socketWrapper.getSocket();
SelectionKey key = socket.getIOChannel().keyFor(socket.getPoller().getSelector());
try {
// *** 省略若干，判斷握手狀態(tài)，handshake == 0就是握手沒有問題
if (handshake == 0) {
SocketState state = SocketState.OPEN;
// Process the request from this socket
if (event == null) {
state = getHandler().process(socketWrapper, SocketEvent.OPEN_READ);
} else {
// process執(zhí)行處理
state = getHandler().process(socketWrapper, event);
}
// *** 省略若干代碼
}
}
}
走進process方法在AbstractProtocol.java，其中的process方法
其中核心是找到一個能處理的processor
// ** 省略若干
Processor processor = connections.get(socket);
// *** 省略若干，創(chuàng)建過還沒有被銷毀的
if (processor == null) {
processor = recycledProcessors.pop();
}
// ** 省略若干，還為空，就創(chuàng)建新的
if (processor == null) {
processor = getProtocol().createProcessor();
register(processor);
}
// ** 省略若干代碼
do {
// 找到了之后開始處理，processor默認是Http11Processor
state = processor.process(wrapper, status);
// ** 省略若干代碼
}while ( state == SocketState.UPGRADING);
找到process方法,核心代碼如下，這里又是模版模式
if (state == SocketState.OPEN) {
state = service(socketWrapper);
}
在具體的Http11Processor中，又service方法的實現(xiàn)。
這里是一個核心方法，代碼很多，這里不貼了，描述一下這里的功能：
- 解析http報文
- 封裝request和response
- response是初始化結(jié)構(gòu)，還沒有response數(shù)據(jù)
- getAdapter將數(shù)據(jù)轉(zhuǎn)換成servlet容器可用的數(shù)據(jù)格式（這里獲取的Adapter是CoyoteAdapter）
getAdapter().service(request, response);
然后進入CoyoteAdapter的service方法
public void service(org.apache.coyote.Request req, org.apache.coyote.Response res)
throws Exception {
// *** 省略若干
}
可以看到入?yún)⑹莾蓚€coyote包下的Request和Response，就是原生request，response適配后的request和response
其中核心處理方法是：
// 找到能夠處理請求的servlet
postParseSuccess = postParseRequest(req, request, res, response)；
if (postParseSuccess) {
//check valves if we support async
request.setAsyncSupported(
connector.getService().getContainer().getPipeline().isAsyncSupported());
// Calling the container
connector.getService().getContainer().getPipeline().getFirst().invoke(
request, response);
}
這里用到了Mapper機制，封裝了Host，Context，wrapper(servlet)之前的數(shù)據(jù)和關(guān)系
上述方法進入之后
上述的invoke方法debug模式下跳轉(zhuǎn)到
StandardEngineValue中的invoke方法。
然后跳轉(zhuǎn)到
AbstractAccessLogValve的invoke方法
然后跳轉(zhuǎn)到
ErrorReportValue中的invoke方法
然后跳轉(zhuǎn)到
StanderHostValve的invoke方法
這里是 找到一個合適的Context處理request 如果沒有找到合適的Context就會報錯
（這里吐槽一下，找到這個真實的處理方法跳轉(zhuǎn)次數(shù)也太多了，以目前的境界還不能理解這種設(shè)計的好處）
找到context之后
if (!response.isErrorReportRequired()) {
context.getPipeline().getFirst().invoke(request, response);
}
又是一組context，有種預(yù)感，又要一層層往下?lián)荛_，找到真正的invoke
在StandardContextValve中
接下來又是一個invoke嵌套的過程，
StandardWrapperValve找到的invoke中，才真正初始化一個
// ** 省略若干代碼
servlet = wrapper.allocate()；
// ** 省略若干代碼
// 創(chuàng)建一個鏈
ApplicationFilterChain filterChain =
ApplicationFilterFactory.createFilterChain(request, wrapper, servlet);
// ** 省略若干代碼
filterChain.doFilter(request.getRequest(),
response.getResponse());
跳轉(zhuǎn)進入之后找到執(zhí)行方法internalDoFilter()
其中核心執(zhí)行邏輯 servlet.service(request, response);
這里就是servlet請求真實被執(zhí)行的地方。
我們調(diào)試的這個例子，就會進入：
JspServlet.java中的service方法，繼續(xù)往下看，還有很多servlet的執(zhí)行細節(jié)，這里不繼續(xù)往下了。
