一、session機制

　　session機制是一種伺服器端的機制，伺服器使用一種類似於散列表的結構(也可能就是使用散列表)來儲存資訊。
但程式需要為某個客戶端的請求建立一個session的時候，伺服器首先檢查這個客戶端的請求裡是否包含了一個session標識－稱為session id,如果已經包含一個session id則說明以前已經為此客戶建立過session，伺服器就按照session id把這個session檢索出來使用(如果檢索不到，可能會新建一個，這種情況可能出現在服務端已經刪除了該使用者對應的session物件，但使用者人為地在請求的URL後面附加上一個JSESSION的引數)。
如果客戶請求不包含session id，則為此客戶建立一個session並且生成一個與此session相關聯的session id，這個session id將在本次響應中返回給客戶端儲存。

二、儲存session id的幾種方式

1．儲存session id的方式可以採用cookie，這樣在互動過程中瀏覽器可以自動的按照規則把這個標識傳送給伺服器。
2．由於cookie可以被人為的禁止，必須有其它的機制以便在cookie被禁止時仍然能夠把session id傳遞迴伺服器，經常採用的一種技術叫做URL重寫，就是把session id附加在URL路徑的後面，附加的方式也有兩種，一種是作為URL路徑的附加資訊，另一種是作為查詢字串附加在URL後面。網路在整個互動過程中始終保持狀態，就必須在每個客戶端可能請求的路徑後面都包含這個session id。
3．另一種技術叫做表單隱藏欄位。就是伺服器會自動修改表單，新增一個隱藏欄位，以便在表單提交時能夠把session id傳遞迴伺服器。

三、session建立的時間

一個常見的錯誤是以為session在有客戶端訪問時就被建立，然而事實是直到某server端程式(如Servlet)呼叫HttpServletRequest.getSession(true)這樣的語句時才會被建立。

四、session的刪除時間
1．程式呼叫HttpSession.invalidate()
2．距離上一次收到客戶端傳送的session id時間間隔超過了session的最大有效時間
3．伺服器程序被停止

再次注意關閉瀏覽器只會使儲存在客戶端瀏覽器記憶體中的session cookie失效，不會使伺服器端的session物件失效。

五、URL重寫的缺點

　　　對所有的URL使用URL重寫，包括超連結，form的action，和重定向的URL。每個引用你的站點的URL，以及那些返回給使用者的URL(即使通過間接手段，比如伺服器重定向中的Location欄位)都要新增額外的資訊。
　　　這意味著在你的站點上不能有任何靜態的HTML頁面(至少靜態頁面中不能有任何連結到站點動態頁面的連結)。因此，每個頁面都必須使用servlet或JSP動態生成。即使所有的頁面都動態生成，如果使用者離開了會話並通過書籤或連結再次回來，會話的資訊都會丟失，因為儲存下來的連結含有錯誤的標識資訊－該URL後面的SESSION ID已經過期了。　　

六、使用隱藏的表單域有的缺點

    僅當每個頁面都是有表單提交而動態生成時，才能使用這種方法。單擊常規的<A HREF..>超文字連結並不產生表單提交，因此隱藏的表單域不能支援通常的會話跟蹤，只能用於一系列特定的操作中，比如線上商店的結賬過程

七、getSession()/getSession(true)、getSession(false)的區別

getSession()/getSession(true)：當session存在時返回該session，否則新建一個session並返回該物件
getSession(false)：當session存在時返回該session，否則不會新建session，返回null

八、Cookie的過期和Session的超時有什麼區別

會話的超時由伺服器來維護，它不同於Cookie的失效日期。首先，會話一般基於駐留記憶體的cookie
不是持續性的cookie，因而也就沒有截至日期。即使擷取到JSESSIONID cookie，併為它設定一個失效日期傳送出去。瀏覽器會話和伺服器會話也會截然不同。

九、session cookie和session物件的生命週期問題

當用戶關閉了瀏覽器雖然session cookie已經消失，但session物件仍然儲存在伺服器端

十、session當瀏覽器退出時不會刪除

 程式一般都是在使用者做log off的時候發個指令去刪除session，然而瀏覽器從來不會主動在關閉之前通知伺服器它將要被關閉，因此伺服器根本不會有機會知道瀏覽器已經關閉。伺服器會一直保留這個會話物件直到它處於非活動狀態超過設定的間隔為止。
之所以會有這種錯誤的認識，是因為大部分session機制都使用會話cookie來儲存session id，而關閉瀏覽器後這個session id就消失了，再次連線到伺服器時也就無法找到原來的session。
如果伺服器設定的cookie被儲存到硬碟上，或者使用某種手段改寫瀏覽器發出的HTTP請求報頭，把原來的session id傳送到伺服器，則再次開啟瀏覽器仍然能夠找到原來的session。
恰恰是由於關閉瀏覽器不會導致session被刪除，迫使伺服器為session設定了一個失效時間，當距離客戶上一次使用session的時間超過了這個失效時間時，伺服器就可以認為客戶端已經停止了活動，才會把session刪除以節省儲存空間。
　　由此我們可以得出如下結論：
　　關閉瀏覽器，只會是瀏覽器端記憶體裡的session cookie消失，但不會使儲存在伺服器端的session物件消失，同樣也不會使已經儲存到硬碟上的持久化cookie消失。

十一、開啟兩個瀏覽器視窗訪問應用程式會使用同一個session還是不同的session

     IE6下不同的session，其他的瀏覽器都支援相同的session

      通常session cookie是不能跨視窗使用的，當你新開了一個瀏覽器視窗進入相同頁面時，系統會賦予你一個新的session id，這樣我們資訊共享的目的就達不到了。
此時我們可以先把session id儲存在persistent cookie中(通過設定session的最大有效時間)，然後在新視窗中讀出來，就可以得到上一個視窗的session id了，這樣通過session cookie和persistent cookie的結合我們就可以實現了跨視窗的會話跟蹤。

學習總結：session的出現使得不允許被瀏覽器端修改的關鍵狀態資訊得以儲存，並且可以儲存大容量的資訊，但session不能替代cookie，畢竟在伺服器端new出了session物件，當訪問量很大時，伺服器的壓力是很大的。所以在不必要的場所，儘量使用cookie來儲存資訊。