1. 請求過程中的session操作：
簡述：在請求過程中首先要解析請求中的sessionId信息，然后將sessionId存儲到request的參數列表中。然后再從 request獲取session的時候，如果存在sessionId那么就根據Id從session池中獲取session，如果sessionId不 存在或者session失效，那么則新建session并且將session信息放入session池，供下次使用。
(1) SessionId解析過程時序圖：
概述：首先用戶發送一個http請求傳遞給Http11Processor,經由Http11Processor解析封裝在 org.apache.coyote.Request然后傳遞給CoyoteAdapter，coyoteAdapter是一個適配器，將coyote框 架封裝的org.apache.coyote.Request適配給org.apache.catalina.connector.Request（這個 流程不多說，之前都有總結過），轉換完之后會調用parsePathParameters方法去解析路徑參數中的cookie信息（因為當cookie被 瀏覽器禁用時，會將cookie信息重寫進url），先嘗試從url中嘗試解析出sessionId. 然后會調用parseSessionCookiesId,這個就是從cookie中解析sessionId存到 request（parsePathParameters和parseSessionCookiesId方法，在調用過程中，沒有看到明顯的異或邏輯，即 兩者都執行了，但這樣不是就有問題了嗎？想想其實沒有問題的，URL重寫設置sessionId或者放到cookie中傳遞過來，兩者方式只會用一個，想 到這點就知道沒有問題了）解析到sessionId就放到了request里面。解析SessionId的邏輯就ok了。下面貼出關鍵代碼：
ParsePathParameters方法（從重寫URL中解析）：
Ps： 標記出來的部分分別是從URL解析出變量，然后放到request參數列表里面。
parseSessionCookiesId方法（從cookie中解析出sessionId）:
Ps: 上面的標記就是從cookie中獲取sessionId.看第一個標記有個 SessionConfig.getSessionCookieName（context）的調用，這里會獲取到一個默認的sessionId的key， 這個key是定義在SessionConfig中的，其值為jsessionId：
(2) 從請求中獲取session的流程基本就是上文描述的這樣。那么再看一下Servlet獲取session的流程：
概述：appServlet是我們自己定義的一個Servlet，在通過Reqest獲取session的時候，其實調用的這個 HttpServletRequest（是一個接口）其實是RequestFacade（封裝了 org.apache.catalina.connector.Request的一個門面），然后RequestFacade會調用真實的Request 的getSession方法。Request具體的邏輯是調用Context容器的getManger方法獲取Session管理器（session管理 器詳情下文介紹），然后如果SessionId如果已經被解析出來了，那么則會調用findSession方法從session對象池中獲取對應的 session，反之如果sessionId不存在，則需要重新創建一個Session，并放入session對象池中。
下面貼出關鍵代碼：
類RequestFacade的getSession方法：
類Request的getSession方法：
類Request的doGetSession方法：
Ps：第一個標記就是根據SessionId從session對象池中獲取session信息，第二標記就是在沒有解析到sessionId的情況下創建一個新的Session對象。
這個創建一個新的session這里點涉及到新的sessionId的生成，生成sessionId的邏輯關鍵代碼是在類SessionIdGenerator中的generateSessionId方法中定義：
以上即是Servlet獲取session的流程，下文具體總結一下tomcat是怎么來管理Session的，即session管理器的知識。
2. Session的管理機制
Session管理器定義：Session管理器組件負責管理Session對象，例如，創建和銷毀Session對象。
首先看一張Session管理器的類繼承結構圖（這個是tocmat7.x的圖，tomcat5的類繼承機構和這個有很大不同）：
簡述：下面依次總結下每個類（參考官網信息）：
(1) Manager：定義了關聯到某一個容器的用來管理session池的基本接口。
(2) ManagerBase：實現了Manager接口，該類提供了Session管理器的常見功能的實現。
(3) StandardManager：繼承自ManagerBase,tomcat的默認Session管理器（不指定配置，默認使用這 個），是tomcat處理session的非集群實現（也就說是單機版的），tomcat關閉時，內存session信息會持久化到磁盤保存為 SESSION.ser,再次啟動時恢復。
(4) PersistentManagerBase：繼承自ManagerBase，實現了和定義了session管理器持久化的基礎功能。
(5) PersistentManager：繼承自PersistentManagerBase，主要實現的功能是會把空閑的會話對象（通過設定超時時間）交換到磁盤上。
(6) ClusterManager：實現了Manager接口，通過類名應該能猜到，這個就是管理集群session的管理器和上面那個 StandardManager單機版的session管理器是相對的概念。這個類定義類集群間session的復制共享接口。
(7) ClusterManagerBase：實現了ClusterManager接口，繼承自ManagerBase。該類實現了session復制的基本操作。
(8) BackupManager：繼承自ClusterManagerBase， 集群間session復制策略的一種實現，會話數據只有一個備份節點，這個備份節點的位置集群中所有節點都可見。這種設計使它有個優勢就是支持異構部署。
(9) DeltaManager：繼承自ClusterManagerBase,集群建session復制策略的一種實現，和BackupManager不同的是，會話數據會復制到集群中所有的成員節點，這也就要求集群中所有節點必須同構，必須部署相同的應用。
補充：下面再具體總結一點就是在PersistentManagerBase類中有個成員變量Store：
持久化session管理器的存儲策略就是有這個Store對象定義的，這個Store的類繼承結構如下：
簡述：接口Store及其實例是為session管理器提供了一套存儲策略，store定義了基本的接口，而StoreBase提供了基本的實現。 其中FileStore類實現的策略是將session存儲在以setDirectory（）指定目錄并以.session結尾的文件中的。 JDBCStore類是將Session通過JDBC存入數據庫中，因此需要使用JDBCStore，需要分別調用setDriverName()方法和 setConnectionURL()方法來設置驅動程序名稱和連接URL。
3. Tomcat session相關的配置
從兩個層面總結一下session相關的配置和設置。首先是從配置文件層面，session是有過期時間的，這個默認的過期時間是 在$catalina_home/conf/web.xml有定義的。具體的默認配置如下（默認的過期時間是30min，即30min沒有訪 問，session就過期了）：
還有一點就是session管理如果不配置就默認使用StandardManager，但如果要配置的話可以 在$catalina_home/conf/context.xml當中指定（其中從這個配置當中可以看到session管理器是和context容器關 聯的，也就說每個web應用都會有一個session管理器）具體的配置如下：
Tomcat7.x默認這個manager的配置是注釋掉的。如果要指定的PersistentManager為默認管理器的話可以這么指定：
其實看到這也就發現了，其實session管理器或者Store存儲策略，只要實現了相關的接口，都是可以自定義的。自己寫一個配置在這里就ok了。
另外在從代碼層面總結一下：session的一些配置信息是寫死在代碼里的，比如SessionConfig這個類就定義了一些session的設 置信息。Session在cookie中的名字是JSESSION. Session通過URL重寫的方式放在path里時，鍵值的名字是jsessionids,具體的代碼如下：
還有一點就是sessionId默認指定的長度是16個字節,這個在SessionIdGenerator當中指定：
好了，有關默認配置的就先總結這么多。
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持服務器之家。
