在進行WEB Application開發的時候，很多程式設計師在理解Session的時候，常常會被誤導，錯誤的認為：一個瀏覽器只有一個Session， 瀏覽器關閉Session就消失了。其實這是不正確的。（很多程式設計師是去baidu，或者google一下，只解決了當下的問題，但是對於更深次的問題沒有仔細思考！）

要了解Session首先要知道一個概念：Session的銷燬只有兩種情況：

第一：成功地呼叫了 session.invalidate()方法。

第二：前後兩次請求超出了session指定的生命週期時間。其中Session的生命週期時間可以在web.xml配置，預設30分鐘。

在web.xml檔案中可以做如下配置：
<session-config>
      <session-timeout>5</session-timeout>
</session-config>

上述配置表示：session的有效時間為 5分鐘。注意：單位是分鐘。

如何來證明關閉瀏覽器的時候Session沒有銷燬呢？我們可以建立一個SessionListener 此監聽器專門用來監聽Session的生命週期的。

此處插入樣例程式碼：

package com.mrbean.commons.utils;

import java.util.Date;

import javax.servlet.http.HttpSessionEvent;
import javax.servlet.http.HttpSessionListener;
import org.hibernate.HibernateException;
import org.hibernate.Session;

public class SessionListener implements HttpSessionListener{

//監聽Session的建立
public void sessionCreated(HttpSessionEvent event) {
System.out.println("session已建立,時間："+new Date().toLocaleString());

                System.out.println(event.getSession().getId());
//此處省略一些程式碼
}

//監聽Session的銷燬
public void sessionDestroyed(HttpSessionEvent event) {
System.out.println("session已銷燬,時間："+new Date().toLocaleString());

                System.out.println(event.getSession().getId());
//此處省略一些程式碼
}

/**更新*/
public void updateObject(Object entity)
{
Session session=HibernateUtils.getSession();
try {
session.getTransaction().begin();
session.update(entity);
session.getTransaction().commit();
} catch (HibernateException e) {
session.getTransaction().rollback();
e.printStackTrace();
} finally {
HibernateUtils.closeConnection(session);
}
}
}

web.xml中的配置Session監聽的程式碼：

<listener>
<listener-class>com.mrbean.commons.utilsSessionListener</listener-class>
</listener>

關於Session失效時間的配置：

<session-config>
    <session-timeout>5</session-timeout>
</session-config>

 配置完畢後，可以做個測試。 當瀏覽器關閉後此監聽器的 sessionDestroyed方法並沒有執行，而是在5分鐘左右才會觸發sessionDestroyed，當然 再開啟瀏覽器的時候

ssessionCreated 會自動呼叫。 關閉5分鐘後sessionDestroyed 又會自動呼叫，通過getID方法大家可以判斷是否為同一個Session。

控制檯監控，獲得輸出資訊：

session已建立,時間：2014-11-30 17:04:04
D5AB6933ABFFFC6F65736C188CF562CE

session已銷燬,時間：2014-11-30 17:10:35
D5AB6933ABFFFC6F65736C188CF562CE

（個人筆記本上做的測試，時間上存在一些誤差），存在一些時間誤差。

這個時候通過瀏覽器的關閉按鈕，強制關閉瀏覽器。

然後開啟一個新的瀏覽器，直接輸入需要訪問的頁面地址，我們發現不用登陸系統，可以直接開啟你想訪問的頁面。（而第一次訪問該頁面時，需要首先登陸系統，才可以訪問。）

注意：如果沒有任何配置的情況下，關閉瀏覽器30分鐘後Session才會消失的。

我們可以利用這個Session監聽做什麼呢？ 最典型的就是利用 SessionListener  的sessionDestroyed方法來記錄使用者非正常退出的時間。使用者在訪問某個網站的時候(目前很多網站都應用了這種方式) 顯示了使用者的最後登入時間。 此時間如何獲取？

在這裡分兩種情況：

        Case 1：如果使用者按"退出" 按鈕那就好說了，跳轉到action中，記錄下使用者退出的時間。 儲存到持久層中。
        Case2： 如果使用者非正常退出， 在沒有配置Session的情況下，預設會在30分鐘後呼叫sessionDestroyed。那麼我們同樣可以在此獲取使用者退出的時間，在

sessionDestroyed 呼叫業務邏輯完成我們想要實現的功能。

        有關Session第2個典型的應用就是Session中儲存了使用者的登入資訊， 那麼就可以訪問使用者許可權的一些頁面。

        有關這個應用要注意一個問題：儲存到session中的 User物件一定要實現Serializable介面。 Serializable的作用可以參考相關資料。正常情況下當我們做測試的時候關閉Tomcat 大家會在Tomcat安裝目錄\work\Catalina\localhost\專案名 資料夾下面看到有一個SESSIONS.ser 的檔案。

        此檔案就是Session在Tomcat停止的時候 持久化到硬碟中的檔案。 所有當前訪問的使用者Session都儲存到此檔案中。 Tomcat啟動成功後.SESSIONS.ser  又會反序列化到記憶體中，所以啟動成功後此檔案就消失了。 所以正常情況下從啟Tomcat使用者是不需要登入的。 注意有個前提就是儲存到Session裡面的user物件所對應的User類必須要序列化才可以。

另外補充：

Session儲存在伺服器端，一般為了防止在伺服器的記憶體中（為了高速存取），Sessinon在使用者訪問第一次訪問伺服器時建立，需要注意只有訪問JSP、Servlet等程式時才會建立Session，只訪問HTML、IMAGE等靜態資源並不會建立Session，可呼叫request.getSession(true)強制生成Session。

　　Session什麼時候失效？
　　1. 伺服器會把長時間沒有活動的Session從伺服器記憶體中清除，此時Session便失效。Tomcat中Session的預設失效時間為20分鐘。
　　2. 呼叫Session的invalidate方法。

　　Session對瀏覽器的要求：
　　雖然Session儲存在伺服器，對客戶端是透明的，它的正常執行仍然需要客戶端瀏覽器的支援。這是因為Session需要使用Cookie作為識別標誌。HTTP協議是無狀態的，Session不能依據HTTP連線來判斷是否為同一客戶，因此伺服器向客戶端瀏覽器傳送一個名為JSESSIONID的Cookie，它的值為該Session的id（也就是HttpSession.getId()的返回值）。Session依據該Cookie來識別是否為同一使用者。


　　該Cookie為伺服器自動生成的，它的maxAge屬性一般為-1，表示僅當前瀏覽器內有效，並且各瀏覽器視窗間不共享，關閉瀏覽器就會失效。因此同一機器的兩個瀏覽器視窗訪問伺服器時，會生成兩個不同的Session。但是由瀏覽器視窗內的連結、指令碼等開啟的新視窗（也就是說不是雙擊桌面瀏覽器圖示等開啟的視窗）除外。這類子視窗會共享父視窗的Cookie，因此會共享一個Session。

    　注意：新開的瀏覽器視窗會生成新的Session，但子視窗除外。子視窗會共用父視窗的Session。例如，在連結上右擊，在彈出的快捷選單中選擇"在新視窗中開啟"時，子視窗便可以訪問父視窗的Session。

        如果客戶端瀏覽器將Cookie功能禁用，或者不支援Cookie怎麼辦？例如，絕大多數的手機瀏覽器都不支援Cookie。Java Web提供了另一種解決方案：URL地址重寫。

　　URL地址重寫是對客戶端不支援Cookie的解決方案。URL地址重寫的原理是將該使用者Session的id資訊重寫到URL地址中。伺服器能夠解析重寫後的URL獲取Session的id。這樣即使客戶端不支援Cookie，也可以使用Session來記錄使用者狀態。HttpServletResponse類提供了encodeURL(String url)實現URL地址重寫，該方法會自動判斷客戶端是否支援Cookie。如果客戶端支援Cookie，會將URL原封不動地輸出來。如果客戶端不支援Cookie，則會將使用者Session的id重寫到URL中。

　　注意：TOMCAT判斷客戶端瀏覽器是否支援Cookie的依據是請求中是否含有Cookie。儘管客戶端可能會支援Cookie，但是由於第一次請求時不會攜帶任何Cookie（因為並無任何Cookie可以攜帶），URL地址重寫後的地址中仍然會帶有jsessionid。當第二次訪問時伺服器已經在瀏覽器中寫入Cookie了，因此URL地址重寫後的地址中就不會帶有jsessionid了。