關鍵代碼如下所示：

ContainerBase.java(省略了異常處理代碼)

protected synchronized void startInternal() throws LifecycleException {
// other code......
// 開啟ContainerBackgroundProcessor線程用於處理子容器，默認情況下backgroundProcessorDelay=-1，不會啟用該線程
threadStart();
}

protected class ContainerBackgroundProcessor implements Runnable {
public void run() {
// threadDone 是 volatile 變數，由外面的容器控制
while (!threadDone) {
try {
Thread.sleep(backgroundProcessorDelay * 1000L);
} catch (InterruptedException e) {
// Ignore
}
if (!threadDone) {
processChildren(ContainerBase.this);
}
}
}

protected void processChildren(Container container) {
container.backgroundProcess();
Container[] children = container.findChildren();
for (int i = 0; i < children.length; i++) {
// 如果子容器的 backgroundProcessorDelay 參數小於0，則遞歸處理子容器
// 因為如果該值大於0，說明子容器自己開啟了線程處理，因此父容器不需要再做處理
if (children[i].getBackgroundProcessorDelay() <= 0) {
processChildren(children[i]);
}
}
}
}

Session 檢查

backgroundProcessorDelay 參數默認值為 -1，單位為秒，即默認不啟用後臺線程，而 tomcat 的 Container 容器需要開啟線程處理一些後臺任務，比如監聽 jsp 變更、tomcat 配置變動、Session 過期等等，因此 StandardEngine 在構造方法中便將 backgroundProcessorDelay 參數設為 10（當然可以在 server.xml 中指定該參數），即每隔 10s 執行一次。那麼這個線程怎麼控制生命週期呢？我們注意到 ContainerBase 有個 threadDone 變數，用 volatile 修飾，如果調用 Container 容器的 stop 方法該值便會賦值為 false，那麼該後臺線程也會退出循環，從而結束生命週期。另外，有個地方需要注意下，父容器在處理子容器的後臺任務時，需要判斷子容器的 backgroundProcessorDelay 值，只有當其小於等於 0 才進行處理，因為如果該值大於0，子容器自己會開啟線程自行處理，這時候父容器就不需要再做處理了

前面分析了容器的後臺線程是如何調度的，下面我們重點來看看 webapp 這一層，以及 StandardManager 是如何清理過期會話的。StandardContext 重寫了 backgroundProcess 方法，除了對子容器進行處理之外，還會對一些緩存信息進行清理，關鍵代碼如下所示：

StandardContext.java

@Override
public void backgroundProcess() {
if (!getState().isAvailable())
return;
// 熱載入 class，或者 jsp
Loader loader = getLoader();
if (loader != null) {
loader.backgroundProcess();
}
// 清理過期Session
Manager manager = getManager();
if (manager != null) {
manager.backgroundProcess();
}
// 清理資源文件的緩存
WebResourceRoot resources = getResources();
if (resources != null) {
resources.backgroundProcess();
}
// 清理對象或class信息緩存
InstanceManager instanceManager = getInstanceManager();
if (instanceManager instanceof DefaultInstanceManager) {
((DefaultInstanceManager)instanceManager).backgroundProcess();
}
// 調用子容器的 backgroundProcess 任務
super.backgroundProcess();
}

StandardContext 重寫了 backgroundProcess 方法，在調用子容器的後臺任務之前，還會調用 Loader、Manager、WebResourceRoot、InstanceManager 的後臺任務，這裡我們只關心 Manager 的後臺任務。弄清楚了 StandardManager 的來龍去脈之後，我們接下來分析下具體的邏輯。

StandardManager 繼承至 ManagerBase，它實現了主要的邏輯，關於 Session 清理的代碼如下所示。backgroundProcess 默認是每隔10s調用一次，但是在 ManagerBase 做了取模處理，默認情況下是 60s 進行一次 Session 清理。tomcat 對 Session 的清理並沒有引入時間輪，因為對 Session 的時效性要求沒有那麼精確，而且除了通知 SessionListener。

ManagerBase.java

public void backgroundProcess() {
// processExpiresFrequency 默認值為 6，而backgroundProcess默認每隔10s調用一次，也就是說除了任務執行的耗時，每隔 60s 執行一次
count = (count + 1) % processExpiresFrequency;
if (count == 0) // 默認每隔 60s 執行一次 Session 清理
processExpires();
}

/**
* 單線程處理，不存在線程安全問題
*/
public void processExpires() {
long timeNow = System.currentTimeMillis();
Session sessions[] = findSessions(); // 獲取所有的 Session
int expireHere = 0 ;
for (int i = 0; i < sessions.length; i++) {
// Session 的過期是在 isValid() 裡面處理的
if (sessions[i]!=null && !sessions[i].isValid()) {
expireHere++;
}
}
long timeEnd = System.currentTimeMillis();
// 記錄下處理時間
processingTime += ( timeEnd - timeNow );
}

清理過期 Session

在上面的代碼，我們並沒有看到太多的過期處理，只是調用了 sessions[i].isValid()，原來清理動作都在這個方法裡面處理的，相當的隱晦。在 StandardSession#isValid() 方法中，如果 now - thisAccessedTime >= maxInactiveInterval則判定當前 Session 過期了，而這個 thisAccessedTime 參數在每次訪問都會進行更新

public boolean isValid() {
// other code......
// 如果指定了最大不活躍時間，才會進行清理，這個時間是 Context.getSessionTimeout()，默認是30分鐘
if (maxInactiveInterval > 0) {
int timeIdle = (int) (getIdleTimeInternal() / 1000L);
if (timeIdle >= maxInactiveInterval) {
expire(true);
}
}
return this.isValid;
}

而 expire 方法處理的邏輯較繁鎖，下面我用偽代碼簡單地描述下核心的邏輯，由於這個步驟可能會有多線程進行操作，因此使用 synchronized 對當前 Session 對象加鎖，還做了雙重校驗，避免重複處理過期 Session。它還會向 Container 容器發出事件通知，還會調用 HttpSessionListener 進行事件通知，這個也就是我們 web 應用開發的 HttpSessionListener 了。由於 Manager 中維護了 Session 對象，因此還要將其從 Manager 移除。Session 最重要的功能就是存儲數據了，可能存在強引用，而導致 Session 無法被 gc 回收，因此還要移除內部的 key/value 數據。由此可見，tomcat 編碼的嚴謹性了，稍有不慎將可能出現並發問題，以及出現內存泄露

public void expire(boolean notify) {
1、校驗 isValid 值，如果為 false 直接返回，說明已經被銷毀了
synchronized (this) { // 加鎖
2、雙重校驗 isValid 值，避免並發問題
Context context = manager.getContext();
if (notify) {
Object listeners[] = context.getApplicationLifecycleListeners();
HttpSessionEvent event = new HttpSessionEvent(getSession());
for (int i = 0; i < listeners.length; i++) {
3、判斷是否為 HttpSessionListener，不是則繼續循環
4、向容器發出Destory事件，並調用 HttpSessionListener.sessionDestroyed() 進行通知
context.fireContainerEvent("beforeSessionDestroyed", listener);
listener.sessionDestroyed(event);
context.fireContainerEvent("afterSessionDestroyed", listener);
}
5、從 manager 中移除該 session
6、向 tomcat 的 SessionListener 發出事件通知，非 HttpSessionListener
7、清除內部的 key/value，避免因為強引用而導致無法回收 Session 對象
}
}

由前面的分析可知，tomcat 會根據時間戳清理過期 Session，那麼 tomcat 又是如何更新這個時間戳呢？我們在 StandardSession#thisAccessedTime 的屬性上面打個斷點，看下調用棧。原來 tomcat 在處理完請求之後，會對 Request 對象進行回收，並且會對 Session 信息進行清理，而這個時候會更新 thisAccessedTime、lastAccessedTime 時間戳。此外，我們通過調用 request.getSession() 這個 API 時，在返回 Session 時會調用 Session#access() 方法，也會更新 thisAccessedTime 時間戳。這樣一來，每次請求都會更新時間戳，可以保證 Session 的鮮活時間

方法調用棧如下所示：

關鍵代碼如下所示：

org.apache.catalina.connector.Request.java

protected void recycleSessionInfo() {
if (session != null) {
session.endAccess(); // 更新時間戳
}
// 回收 Request 對象的內部信息
session = null;
requestedSessionCookie = false;
requestedSessionId = null;
requestedSessionURL = false;
requestedSessionSSL = false;
}

org.apache.catalina.session.StandardSession.java

public void endAccess() {
isNew = false;
if (LAST_ACCESS_AT_START) { // 可以通過系統參數改變該值，默認為false
this.lastAccessedTime = this.thisAccessedTime;
this.thisAccessedTime = System.currentTimeMillis();
} else {
this.thisAccessedTime = System.currentTimeMillis();
this.lastAccessedTime = this.thisAccessedTime;
}
}

public void access() {
this.thisAccessedTime = System.currentTimeMillis();
}

HttpSessionListener

創建通知

前面我們分析了 Session 的創建過程，但是在整個創建流程中，似乎沒有看到關於 HttpSessionListener 的創建通知。原來，在給 Session 設置 id 的時候會進行事件通知，和 Session 的銷毀一樣，也是非常的隱晦，個人感覺這一塊設計得不是很合理。

創建通知這塊的邏輯很簡單，首先創建 HttpSessionEvent 對象，然後遍歷 Context 內部的 LifecycleListener，並且判斷是否為 HttpSessionListener 實例，如果是的話則調用 HttpSessionListener#sessionCreated() 方法進行事件通知。

public void setId(String id, boolean notify) {
// 省略部分代碼
if (notify) {
tellNew();
}
}

public void tellNew() {

// 通知 org.apache.catalina.SessionListener
fireSessionEvent(Session.SESSION_CREATED_EVENT, null);

// 獲取 Context 內部的 LifecycleListener，並判斷是否為 HttpSessionListener
Context context = manager.getContext();
Object listeners[] = context.getApplicationLifecycleListeners();
if (listeners != null && listeners.length > 0) {
HttpSessionEvent event = new HttpSessionEvent(getSession());
for (int i = 0; i < listeners.length; i++) {
if (!(listeners[i] instanceof HttpSessionListener))
continue;
HttpSessionListener listener = (HttpSessionListener) listeners[i];
context.fireContainerEvent("beforeSessionCreated", listener); // 通知 Container 容器
listener.sessionCreated(event);
context.fireContainerEvent("afterSessionCreated", listener);
}
}
}

銷毀通知

我們在前面分析清理過期 Session時大致分析了 Session 銷毀時會觸發 HttpSessionListener 的銷毀通知，這裡不再重複了。

更多關於Java的技術和資訊可以關注我的專欄：

Java架構築基?

zhuanlan.zhihu.com

專欄免費給大家分享Java架構的學習資料和視頻

推薦閱讀：