session保存在服務器端。為了獲得更高的存取速度，服務器一般把Session放在內存里。每個用戶都會有一個獨立的Session。如果Session內容過于復雜，當大量客戶訪問服務器時可能會導致內存溢出。因此，Session里的信息應該盡量精簡。

Session在用戶第一次訪問服務器的時候自動創建。需要注意只有訪問jsp、Servlet等程序時才會創建Session，只訪問HTML、IMAGE等靜態資源并不會創建Session。如果尚未生成Session，也可以使用request.getSession(true)強制生成Session。

Session生成后，只要用戶繼續訪問，服務器就會更新Session的最后訪問時間，并維護該Session。用戶每訪問服務器一次，無論是否讀寫Session，服務器都認為該用戶的Session"活躍（active）"了一次。

由于會有越來越多的用戶訪問服務器，因此Session也會越來越多。為防止內存溢出，服務器會把長時間內沒有活躍的Session從內存刪除。這個時間就是Session的超時時間。如果超過了超時時間沒訪問過服務器，Session就自動失效了。

具體設置方法有三種：（1）在主頁面或者公共頁面中加入：session.setMaxInactiveInterval(900);可以通過對應的getMaxInactiveInterval()獲取。參數900單位是秒，即在沒有活動15分鐘后，session將失效。這里要注意這個session設置的時間是根據服務器來計算的，而不是客戶端。所以如果是在調試程序，應該是修改服務器端時間來測試，而不是客戶端。（2）也是比較通用的設置session失效時間的方法，就是在項目的web.xml中添加Xml代碼

另外，通過調用Session的invalidate()方法可以使Session失效。

（3）直接在應用服務器中設置，如果是tomcat，可以在tomcat目錄下conf/web.xml中找到<session-config>元素，tomcat默認設置是30分鐘，只要修改這個值就可以了。

需要注意的是如果上述三個地方如果都設置了，有個優先級的問題，從高到低：（1）--（2）---（3）

 在一般系統中，也可能需要在session失效后做一些操作，（1）控制用戶數，當session失效后，系統的用戶數減少一個等，控制用戶數在一定范圍內，確保系統的性能。（2）控制一個用戶多次登錄，當session有效時，如果相同用戶登錄，就提示已經登錄了，當session失效后，就可以不用提示，直接登錄了。 那么如何在session失效后，進行一系列的操作呢？這里就需要用到監聽器了，即當session因為各種原因失效后，監聽器就可以監聽到，然后執行監聽器中定義好的程序就可以了。監聽器類為：HttpSessionListener類，有sessionCreated和sessionDestroyed兩個方法 自己可以繼承這個類，然后分別實現。sessionCreated指在session創建時執行的方法sessionDestroyed指在session失效時執行的方法例子：

1.編寫java類。

2.配置監聽器。在web.xml中添加如下代碼：

Session中包括各種方法，使用起來要比Cookie方便得多。Session的常用方法如表5.2所示。

表5.2 HttpSession的常用方法

方 法 名描    述void setAttribute(String attribute, Object value) 設置Session屬性。value參數可以為任何Java Object。通常為Java Bean。

value信息不宜過大String getAttribute(String attribute) 返回Session屬性Enumeration getAttributeNames() 返回Session中存在的屬性名void removeAttribute(String attribute) 移除Session屬性String getId() 返回Session的ID。該ID由服務器自動創建，不會重復long getCreationTime() 返回Session的創建日期。返回類型為long，常被轉化為Date類型，例如：

Date createTime = new Date(session.getCreationTime())long getLastaccessedTime() 返回Session的最后活躍時間。返回類型為longint getMaxInactiveInterval() 返回Session的超時時間。單位為秒。超過該時間沒有訪問，服務器認為該Session失效void setMaxInactiveInterval(int second) 設置Session的超時時間。單位為秒void putValue(String attribute, Object value)不推薦的方法。已經被setAttribute(String attribute, Object Value)替代Object getValue(String attribute) 不被推薦的方法。已經被getAttribute(String attr)替代boolean isNew() 返回該Session是否是新創建的void invalidate() 使該Session失效

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地址重寫

URL地址重寫是對客戶端不支持Cookie的解決方案。URL地址重寫的原理是將該用戶Session的id信息重寫到URL地址中。服務器能夠解析重寫后的URL獲取Session的id。這樣即使客戶端不支持Cookie，也可以使用Session來記錄用戶狀態。HttpServletResponse類提供了encodeURL(String url)實現URL地址重寫，例如：

<td>      <a href="<%= response.encodeURL("index.jsp?c=1&wd=Java") %>">       Homepage</a> </td> 該方法會自動判斷客戶端是否支持Cookie。如果客戶端支持Cookie，會將URL原封不動地輸出來。如果客戶端不支持Cookie，則會將用戶Session的id重寫到URL中。重寫后的輸出可能是這樣的：

<td>      <a href="index.jsp;jsessionid=0CCD096E7F8D97B0BE608AFDC3E1931E?c=       1&wd=Java">Homepage</a> </td> 即在文件名的后面，在URL參數的前面添加了字符串";jsessionid=XXX"。其中XXX為Session的id。分析一下可以知道，增添的jsessionid字符串既不會影響請求的文件名，也不會影響提交的地址欄參數。用戶單擊這個鏈接的時候會把Session的id通過URL提交到服務器上，服務器通過解析URL地址獲得Session的id。

如果是頁面重定向（Redirection），URL地址重寫可以這樣寫：

<%      if("administrator".equals(userName)){          response.sendRedirect(response.encodeRedirectURL("administrator.jsp"));          return;      } %> 效果跟response.encodeURL(String url)是一樣的：如果客戶端支持Cookie，生成原URL地址，如果不支持Cookie，傳回重寫后的帶有jsessionid字符串的地址。

對于WAP程序，由于大部分的手機瀏覽器都不支持Cookie，WAP程序都會采用URL地址重寫來跟蹤用戶會話。比如用友集團的移動商街等。

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

Session中禁止使用Cookie

既然WAP上大部分的客戶瀏覽器都不支持Cookie，索性禁止Session使用Cookie，統一使用URL地址重寫會更好一些。Java Web規范支持通過配置的方式禁用Cookie。下面舉例說一下怎樣通過配置禁止使用Cookie。

打開項目sessionWeb的WebRoot目錄下的META-INF文件夾（跟WEB-INF文件夾同級，如果沒有則創建），打開context.xml（如果沒有則創建），編輯內容如下：

代碼5.11 /META-INF/context.xml

<?xml version='1.0' encoding='UTF-8'?> <Context path="/sessionWeb" cookies="false"> </Context> 或者修改Tomcat全局的conf/context.xml，修改內容如下：

代碼5.12 context.xml

<!-- The contents of this file will be loadedfor each web application --> <Context cookies="false">      <!-- ... 中間代碼略 --> </Context> 部署后TOMCAT便不會自動生成名JSESSIONID的Cookie，Session也不會以Cookie為識別標志，而僅僅以重寫后的URL地址為識別標志了。

注意：該配置只是禁止Session使用Cookie作為識別標志，并不能阻止其他的Cookie讀寫。也就是說服務器不會自動維護名為JSESSIONID的Cookie了，但是程序中仍然可以讀寫其他的Cookie。

Session與Cookie的比較

Cookie與Session都可以進行會話跟蹤，但是實現的原理不太一樣。一般情況下二者均可以滿足需求，但有時候不可以使用Cookie，有時候不可以使用Session。下面通過比較說明二者的特點以及適用的場合。

5.3.1 從存取方式上比較

Cookie中只能保存ASCII字符串，如果需要存取Unicode字符或者二進制數據，需要進行UTF-8，GBK或者BASE64等方式的編碼。Cookie中也不能直接存取Java對象。若要存儲稍微復雜的信息，使用Cookie是比較困難的。

而Session中可以存取任何類型的數據，包括而不限于String、Integer、List、Map等。Session中也可以直接保存Java Bean乃至任何Java類，對象等，使用起來非常方便。可以把Session看做是一個Java容器類。

從隱私安全上比較

Cookie存儲在客戶端瀏覽器中，對客戶端是可見的，客戶端的一些程序可能會窺探、復制甚至修改Cookie中的內容。而Session存儲在服務器上，對客戶端是透明的，不存在敏感信息泄露的危險。

如果選用Cookie，比較好的辦法是，敏感的信息如賬號密碼等盡量不要寫到Cookie中。最好是像Google、Baidu那樣將Cookie信息加密，提交到服務器后再進行解密，保證Cookie中的信息只有自己能讀得懂。而如果選擇Session就省事多了，反正是放在服務器上，Session里任何隱私都可以。

從有效期上比較

使用過Google的人都知道，如果登錄過Google，則Google的登錄消息長期有效。用戶不必每次訪問都重新登錄，Google會長久地記錄該用戶的登錄信息。要達到這種效果，使用Cookie會是比較好的選擇。只需要設置Cookie的maxAge屬性為一個很大很大的數字或者Integer.MAX_VALUE就可以了。Cookie的maxAge屬性支持這樣的效果。

使用Session理論上也能實現這種效果。只要調用方法setMaxInactiveInterval(Integer. MAX_VALUE)不就可以了么。但是由于Session依賴于名為JSESSIONID的Cookie，而Cookie JSESSIONID的maxAge默認為-1，只要關閉了瀏覽器該Session就會失效，因此Session不能實現信息永久有效的效果。使用URL地址重寫也不能實現。

而且如果設置Session的超時時間過長，服務器累計的Session就會越多，越容易導致內存溢出。

從對服務器的負擔上比較

Session是保存在服務器端的，每個用戶都會產生一個Session。如果并發訪問的用戶非常多，會產生非常多的Session，消耗大量的內存。因此像Google、Baidu、Sina這樣并發訪問量極高的網站，是不太可能使用Session來追蹤客戶會話的。

而Cookie保存在客戶端，不占用服務器資源。如果并發瀏覽的用戶非常多，Cookie是很好的選擇。對于Google、Baidu、Sina來說，Cookie也許是唯一的選擇。

從瀏覽器支持上比較

Cookie是需要客戶端瀏覽器支持的。如果客戶端禁用了Cookie，或者不支持Cookie，則會話跟蹤會失效。對于WAP上的應用，常規的Cookie就派不上用場了。

如果客戶端瀏覽器不支持Cookie，需要使用Session以及URL地址重寫。需要注意的是所有的用到Session程序的URL都要使用response.encodeURL(String URL)或者response.encodeRedirectURL(String URL)進行URL地址重寫，否則導致Session會話跟蹤失敗。對于WAP應用來說，Session+URL地址重寫也許是它唯一的選擇。

如果客戶端支持Cookie，則Cookie既可以設為本瀏覽器窗口以及子窗口內有效（把maxAge設為-1），也可以設為所有瀏覽器窗口內有效（把maxAge設為某個大于0的整數）。但Session只能在本瀏覽器窗口以及其子窗口內有效。如果兩個瀏覽器窗口互不相干，它們將使用兩個不同的Session。

從跨域名上比較

Cookie支持跨域名訪問，例如將domain屬性設置為".helloweenvsfei.com"，則以".helloweenvsfei.com"為后綴的所有域名均可以訪問該Cookie。跨域名Cookie現在被廣泛用在網絡中，例如Google、Baidu、Sina等。而Session則不會支持跨域名訪問。Session僅在他所在的域名內有效。

注意：僅使用Cookie或者僅使用Session可能實現不了理想的效果。這時應該嘗試一下同時使用Cookie與Session。Cookie與Session的搭配使用在實際項目中會實現絢爛多姿的效果。

本章小結

Cookie是早期的會話跟蹤技術，它將信息保存到客戶端瀏覽器中。瀏覽器訪問網站時會攜帶這些Cookie信息，達到鑒別身份的目的。

Session是在Cookie基礎上建立的會話跟蹤技術，它將信息保存在服務器端，Session中能夠存儲負責的Java對象，因此使用更加方便。Session依賴于名為JSESSIONID的Cookie。

如果客戶端瀏覽器不支持Cookie，或者禁用了Cookie，仍然可以通過使用URL地址重寫來使用Session。