要了解Session的底層工作原理。我們還是先看在一個會話過程中，同一個瀏覽器在訪問多個web資源的情況好了，大致分為以下幾個步驟：

1，瀏覽器訪問某個Servlet，這時如果服務(wù)器要從請求對象中獲取Session對象（第一次獲取也是創(chuàng)建），那么服務(wù)器會為這個Session對象創(chuàng)建一個id：JSESSIONID

2，同時在對瀏覽器的響應(yīng)過程中，這個Session會將JSESSIONID這個id以Cookie形式回送給客戶端瀏覽器，記住，這時候Cookie服務(wù)器沒有設(shè)置有效時間，因此是存在瀏覽器的緩存中，而不是在硬盤文件。

3，當(dāng)用戶繼續(xù)在這個會話過程中訪問其他Servlet，這時候這個Servlet再從請求對象中獲取Session對象，注意這時候獲取Session對象是從瀏覽器發(fā)來的請求中查詢是否有名為JSESSIONID的這個Cookie，如果有，那么這個Session就不用再創(chuàng)建，而是直接根據(jù)查詢服務(wù)器中這個相同JSESSIONID值的Session，換句話說就可以取得之前存在這個Session中的數(shù)據(jù)。

總結(jié)來說，Session是基于Cookie的。

（注：cookie并不是萬能的，Session首先是依據(jù)cookie，但是有時候cookie不能用，這時候Session會查詢發(fā)來請求的URL地址是否有JSESSIONID。）

Session的隱藏Cookie，我們可以做個小實驗來驗證下，在【myservlet】這個web工程下創(chuàng)建兩個Servlet，分別命名為SessionDemo1和SessionDemo2：

在SessionDemo1代碼為：

   HttpSession session = request.getSession();
   String data = "Message from SessionDemo";
   session.setAttribute("data", data);

在SessionDemo2代碼為：

   HttpSession session = request.getSession();
   System.out.println((String)session.getAttribute("data"));

我們在瀏覽器中打開HttpWatch，來訪問SessionDemo1，因為是首次訪問Servlet，查看SessionDemo1給瀏覽器的響應(yīng):

確確實實服務(wù)器發(fā)送回瀏覽器有這個JSESSIONID名稱的Cookie，這時候如果我們再在打開的瀏覽器去訪問SessionDemo2，那么在HttpWatch中觀察請求包的內(nèi)容發(fā)現(xiàn)：

再次訪問服務(wù)器時，瀏覽器就會帶著這個名為JSESSIONID的Cookie給服務(wù)器，服務(wù)器正是通過這個cookie中的JSESSIONID值去服務(wù)器中查找之前為該瀏覽器創(chuàng)建的Session。

如果我們將瀏覽器關(guān)閉，由于這個cookie沒有設(shè)置“setMaxAge”，因此這個cookie只存在于瀏覽器的緩沖，瀏覽器關(guān)閉即被銷毀。如果想使關(guān)閉瀏覽器之后，Session還能存在，我們就要人為的覆蓋這個Session的cookie，并設(shè)置覆蓋cookie的有效時間和有效路徑。而這個cookie的值，也就是JSESSIONID的值，可以通過Session的getId()方法得到。

1，覆蓋有效時間：

注意，服務(wù)器在為瀏覽器創(chuàng)建Session后，在用戶沒有操作的情況下(或者瀏覽器關(guān)閉后)默認(rèn)為其維護30分鐘。這點可以從Tomcat的【web.xml】文件中可以看出：

當(dāng)然我們從這里也可以修改服務(wù)器默認(rèn)的銷毀無操作的Session時間。

當(dāng)然如果我們不要全局設(shè)置所有服務(wù)器中Session的銷毀時間，就在每個web應(yīng)用中的web.xml文件中自定義添加<session-config>和<session-timeout>進行設(shè)置。

注：我們還可以通過Session對象的invalidate()方法，將某個Session進行立刻銷毀。

對此，如果我們要覆蓋一個Session的cookie并保存在硬盤文件中，我們設(shè)置的cookie有效時間就不要超過服務(wù)器默認(rèn)的session-timeout時間。

2，覆蓋有效路徑：

如果我們創(chuàng)建一個Cookie對象，沒有設(shè)置“setPath”，那么Cookie的有效路徑為創(chuàng)建該Cookie的程序（通常為某個Servlet），即只有訪問了這個程序時瀏覽器才會帶著Cookie過去，那實在是“人脈不通”，訪問這個web應(yīng)用的其他資源就無法再使用Session了。

我們看看剛才的第一次訪問Servlet時，服務(wù)器為瀏覽器創(chuàng)建的Session中的cookie的有效路徑：

可以看到這個服務(wù)器默認(rèn)將JSESSIONID這個cookie的有效路徑設(shè)置為創(chuàng)建這個Session的web工程根目錄。所以我們要覆蓋Session中的cookie時也應(yīng)該設(shè)置路徑為該web工程根目錄。

好，接下來對上面那個Servlet的例子進行改造，我們只需要在SessionDemo1中修改就行，因為這個首次將Session的cookie返回給客戶端，修改后代碼如下：

   HttpSession session = request.getSession();
   String data = "Message from SessionDemo";
   session.setAttribute("data", data);
     
   Cookie cookie = new Cookie("JSESSIONID", session.getId());
   cookie.setMaxAge(30*60);
   cookie.setPath("/myservlet");
   response.addCookie(cookie);

這樣，當(dāng)我們打開瀏覽器訪問了SessionDemo1之后，就能在存放cookie的目錄中找到該cookie，如果我們通過HttpWatch來查看可以看到重名的這個cookie：

雖然JSEESIONID這個cookie重名了，沒有關(guān)系，因為其值都是一樣的，并且如果我們將瀏覽器關(guān)閉后，沒有設(shè)置cookie有效時間的（也是原先Session發(fā)來的）cookie將不復(fù)存在(存在瀏覽器緩存中，瀏覽器關(guān)閉就被銷毀)，這時重新打開一個瀏覽器，再去訪問SessionDemo2依然能獲取到原來Session中保存的內(nèi)容：

注意，這是另外打開瀏覽器窗口訪問的SessionDemo2?。×砀剑?br />

通過這里我們可以看到，我們?nèi)藶榈貙⒃萐ession定義的cookie給替換了，而Session并不知道，只要能獲得“JSESSIONID”這個cookie，它就認(rèn)為cookie是存在的，可以從這個cookie中id值獲取以前保存的信息，因此我們實現(xiàn)了一臺主機共享一個Session，此時，當(dāng)瀏覽器關(guān)閉，或者說結(jié)束一個會話后，依然能獲取Session來獲取之前保存的數(shù)據(jù)。