僅為個人理解.請指正
Hibernate Session, 其作用無需多言.
在運用中為避免資源消耗,一般都會手動封裝一個HibernateUtil類(未使用Spring管理的前提下).
該類的作用使Hibernate加載配置文件config, 創建sessionFactory等只運行一次.
實際運用中,經常需要將當前線程和session綁定.一般的用法為使用ThreadLocal: 在HibernateUtil類中封裝hibernate的管理.通過openSession取得
session,并將其放入ThreadLocal變量中. 這樣業務邏輯中僅需通過工具類取得當前線程對應的session.使用完畢后,調用工具類closeSession方法將
session關閉,當前線程的ThreadLocal變量置為NULL. 保證線程歸還線程池復用后,ThreadLocal為空,以免出現導致其他線程訪問到本線程變量.
而后,Hibernate的SessionFactory提供獲取session的新方法getCurrentSession (獲得與當前線程綁定的session). 內部通過代理封裝,此方式得到的session
不僅和當前線程綁定,也無需手動開關. 默認在事務提交之后,session自動關閉. 需注意的是,必須在事務開啟的前提之下才可使用此種方式獲得的session.
此外hibernate.cfg.xml配置文件中也許配置


------------------------------以下內容為工地資料-------------------------------------------------------------------------------
1  OpenSession : 手動打開,需手動關閉.[所以代碼中充斥著try catch --sf.openSession --打開事務,提交-回滾 finall關閉session的代碼]

http://space.itpub.net/9252210/viewspace-594453

今天在做數據導出的時候，由于用戶名的密碼使用的是特殊字符，所以遇到了錯誤代碼：“EXP-00056: 遇到 ORACLE 錯誤 12154”，網上查找原因，需要用引號擴起來，但是os不同，方式也不同:

    windows os: exp username/"""password"""@devdb --3個雙引號擴密碼

    linux/unix os: exp 'username/"password"@devdb' --1個雙引號擴密碼，1個單引號擴全部

    實驗結果如下：
1.創建帶有特殊字符密碼的用戶
C:\Documents and Settings\Home>sqlplus /nolog
SQL*Plus: Release 10.2.0.1.0 - Production on 星期四 5月 7 17:37:36 2009
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
SQL> connsys/oracle@devdbas sysdba
已連接。
SQL> create user exp identified by "12345!@#$%";
用戶已創建。
SQL> grant connect, resource to exp;
授權成功。
SQL> conn exp/"12345!@#$%"@devdb2
已連接。
SQL> create table table1 as select * from dual;
表已創建。
SQL> exit
2.windows os導出測試
C:\Documents and Settings\Home>expexp/12345!@#$%@devdbfile=c:\exp.dmp wner=exp
Export: Release 9.2.0.1.0 - Production on 星期四 5月 7 17:39:42 2009
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
EXP-00056: 遇到 ORACLE 錯誤 12154
ORA-12154: TNS: 無法處理服務名
EXP-00000: 導出終止失敗
C:\Documents and Settings\Home>exp exp/"12345!@#$%"@devdb2file=c:\exp.dmp wner=exp
Export: Release 9.2.0.1.0 - Production on 星期四 5月 7 17:39:57 2009
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
EXP-00056: 遇到 ORACLE 錯誤 12154
ORA-12154: TNS: 無法處理服務名
EXP-00000: 導出終止失敗
C:\Documents and Settings\Home>exp exp/"""12345!@#$%"""@devdb2file=c:\exp.dmp wner=exp
Export: Release 9.2.0.1.0 - Production on 星期四 5月 7 17:41:54 2009
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
連接到: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
已導出 ZHS16GBK 字符集和 AL16UTF16 NCHAR 字符集
. 正在導出 pre-schema 過程對象和操作
. 正在導出用戶 EXP 的外部函數庫名稱
. 導出 PUBLIC 類型同義詞
. 導出私有類型同義詞
. 正在導出用戶 EXP 的對象類型定義
即將導出 EXP 的對象 ...
. 正在導出數據庫鏈接
. 正在導出序號
. 正在導出群集定義
. 即將導出 EXP 的表通過常規路徑 ...
. . 正在導出表                          TABLE1          1 行被導出
. 正在導出同義詞
. 正在導出視圖
. 正在導出存儲的過程
. 正在導出運算符
. 正在導出引用完整性約束條件
. 正在導出觸發器
. 正在導出索引類型
. 正在導出位圖, 功能性索引和可擴展索引
. 正在導出后期表活動
. 正在導出實體化視圖
. 正在導出快照日志
. 正在導出作業隊列
. 正在導出刷新組和子組
. 正在導出維
. 正在導出 post-schema 過程對象和操作
. 正在導出統計
在沒有警告的情況下成功終止導出。

3.linux/unix os導出測試
[oracle@rac2 ~]$ expexp/12345!@#$%@devdbfile=./exp.dmp wner=exp
-bash:!@#$%@devdb: event not found
[oracle@rac2 ~]$ exp exp/"""12345!@#$%"""@devdbfile=./exp.dmp wner=exp
-bash:!@#$%"""@devdb: event not found
[oracle@rac2 ~]$exp 'exp/"12345!@#$%"@devdb'file=./exp.dmp wner=exp 
Export: Release 10.2.0.4.0 - Production on Thu May 7 19:21:32 2009 
Copyright (c) 1982, 2007, Oracle.  All rights reserved. 
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
Export done in US7ASCII character set and AL16UTF16 NCHAR character set
server uses ZHS16GBK character set (possible charset conversion)
. exporting pre-schema procedural objects and actions
. exporting foreign function library names for user EXP
. exporting PUBLIC type synonyms
. exporting private type synonyms
. exporting object type definitions for user EXP
About to export EXP's objects ...
. exporting database links
. exporting sequence numbers
. exporting cluster definitions
. about to export EXP's tables via Conventional Path ...
. . exporting table                         TABLE1          1 rows exported
. exporting synonyms
. exporting views
. exporting stored procedures
. exporting operators
. exporting referential integrity constraints
. exporting triggers
. exporting indextypes
. exporting bitmap, functional and extensible indexes
. exporting posttables actions
. exporting materialized views
. exporting snapshot logs
. exporting job queues
. exporting refresh groups and children
. exporting dimensions
. exporting post-schema procedural objects and actions
. exporting statistics
Export terminated successfully without warnings.

1，什么是Servlet
2，Servlet有什么作用
3，Servlet的生命周期
4，Servlet怎么處理一個請求
5，Servlet與JSP有什么區別
6，Servlet里的cookie技術
7，Servlet里的過濾器
8，Servlet里的監聽器

 

一，什么是Servlet？

Servlet是一個Java編寫的程序，此程序是基于Http協議的，在服務器端運行的(如tomcat)，

 

是按照Servlet規范編寫的一個Java類。

二，Servlet有什么作用？

主要是處理客戶端的請求并將其結果發送到客戶端。

三，Servlet的生命周期？

Servlet的生命周期是由Servlet的容器來控制的，它可以分為3個階段;初始化，運行，銷毀。

初始化階段：

1，Servlet容器加載servlet類，把servlet類的.class文件中的數據讀到內存中。

2，然后Servlet容器創建一個ServletConfig對象。ServletConfig對象包含了Servlet的初始化配置信息。

3，Servlet容器創建一個servlet對象。

4，Servlet容器調用servlet對象的init方法進行初始化。

運行階段：

當servlet容器接收到一個請求時，servlet容器會針對這個請求創建servletRequest和servletResponse對象。

 

然后調用service方法。并把這兩個參數傳遞給service方法。Service方法通過servletRequest對象獲得請求的

 

信息。并處理該請求。再通過servletResponse對象生成這個請求的響應結果。然后銷毀servletRequest和

 

servletResponse對象。我們不管這個請求是post提交的還是get提交的，最終這個請求都會由service方法來處理。

 

銷毀階段：

當Web應用被終止時，servlet容器會先調用servlet對象的destrory方法，然后再銷毀servlet對象，

 

同時也會銷毀與servlet對象相關聯的servletConfig對象。我們可以在destroy方法的實現中，釋放

 

servlet所占用的資源，如關閉數據庫連接，關閉文件輸入輸出流等。

在這里該注意的地方：

在servlet生命周期中，servlet的初始化和和銷毀階段只會發生一次，而service方法執行的次數則取決于servlet被客戶

 

端訪問的次數

 

 

四，Servlet怎么處理一個請求？

當用戶發送一個請求到某個Servlet的時候，Servlet容器會創建一個ServletRequst和ServletResponse對象。

 

在ServletRequst對象中封裝了用戶的請求信息，然后Servlet容器把ServletRequst和ServletResponse對象

 

傳給用戶所請求的Servlet，Servlet把處理好的結果寫在ServletResponse中，然后Servlet容器把響應結果傳

 

給用戶。

 

五，Servlet與JSP有什么區別？

1，jsp經編譯后就是servlet，也可以說jsp等于servlet。

2，jsp更擅長頁面(表現)。servlet更擅長邏輯編輯。 (最核心的區別)。

3，在實際應用中采用Servlet來控制業務流程,而采用JSP來生成動態網頁.在struts框架中,

 

JSP位于MVC設計模式的視圖層,而Servlet位于控制層。

 

六，Servlet里的cookie技術？

cookies是一種WEB服務器通過瀏覽器在訪問者的硬盤上存儲信息的手段，是由Netscape公司開發出來的。

cookie技術的好處：

    1，Cookie有效期限未到時，Cookie能使用戶在不鍵入密碼和用戶名的情況下進入曾經瀏覽過的一些站點。

    2，Cookie能使站點跟蹤特定訪問者的訪問次數、最后訪問時間和訪問者進入站點的路徑。
   
創建一個cookie

 

使用cookie

 

七，Servlet里的過濾器？

過濾器的主要作用

1，任何系統或網站都要判斷用戶是否登錄。

2，網絡聊天系統或論壇，功能是過濾非法文字

3，統一解決編碼

(2)怎么創建一個過濾器：

 

1，生成一個普通的class類，實現Filter接口(javax.servlet.Filter;)。

2，重寫接口里面的三個方法：init，doFilter，destroy。

3，然后在web.xml配置過濾器。

八，Servlet里的監聽器？

監聽器的作用：自動執行一些操作。

三種servlet監聽器:

 

對request的監聽。對session的監聽。對application的監聽。

怎么創建一個session監聽器：

1，生成一個普通的class類，如果是對session的監聽，則實現HttpSessionListener。

2，然后重寫里面的五個方法:

 

http://www.jdon.com/artichect/state.htm

板橋里人 http://www.jdon.com 2006/1/2（轉載請保留）

　　這是一個實戰中非常重要但是容易被忽視的概念，說它重要，是因為它比數據庫重要；說它容易被忽視也是同樣的原因，它經常被數據庫概念替代。

　　如果你經驗和經歷中沒有狀態這個概念，極端地說：可能你的Java系統經驗還未積累到一定程度，狀態是每個Java程序員深入Java系統后必然碰到的問題。

　　本文我想試圖表達的是：狀態分兩種：活動的狀態對象和持久化的狀態。而數據庫中的數據只是狀態的一種持久化結果，而Java系統 運行時，我們更多的可能是和一種活動的狀態打交道，這種活動的狀態存在內存中，而不是持久化到硬盤上，當然，需要時你可以通過數據庫/文件持久化到硬盤上。

　　但是，如果你以數據庫數據替代狀態，那么就可能導致數據庫的頻繁訪問，而且 你的系統會變成一個非對象化的、緊耦合、到處是分散數據塊的糟糕系統。這樣的系統并不比傳統的兩層結構好到哪里！也不會比Jsp里嵌入Java代碼偽三層系統高明到什么地方。

什么是狀態？

　　只要有對象就可能有狀態，任何一個對象活動時，都有自己的狀態屬性，類的 字段屬性極有可能成為狀態，我們現在經常使用的Domain model其實就是一種 包含狀態的對象，如果你對狀態沒有深入掌握，就不可能真正掌握對象系統特點，或者是Domain Model的執行情況。

　　對于初學者，經常會疑問：我是將數據放在HttpSession中還是Request中，這里 其實已經開始接觸狀態，一旦你接觸狀態，你就要開始小心，因為你可能會將內存泄漏的惡魔導引進來。

　　內存泄漏的惡魔爆發時刻取決于你狀態的生存周期和系統并發訪問量。

　　狀態的生存周期也就是包含這個狀態的對象的生命周期，在簡單系統中，我們只 需要通過new創建對象，然后它的消亡就會依靠JVM垃圾回收機制回收，但是事情會這么簡單嗎？

　　狀態的危險還會發生在多線程環境下，當多個線程對同一個內存中狀態寫操作時，這時怎么辦？如果這個狀 態持久化在數據庫中，我們會依賴數據庫提供的強大事務機制防止這種并發死鎖，但是如果是在內存中，你就很難辦，因此，我們就盡量避免發生這種多線程同時訪 問一個狀態的現象，而Singleton單例模式極容易發生這種現象，因此實踐中，單例模式是J2EE開發中需要避免的，相關帖子討論見：
http://www.jdon.com/jive/article.jsp?forum=91&thread=17578

　　我們接觸的Web容器或Jsp/Servlet本質就是一個多線程，這也是很多初學者不知道的， 因為多線程編程是復雜或困難的，因此才有jsp/Servlet這樣的上層封裝，但是我們使用他們
時，實際在進行多線程編程。

　　生命周期和多線程并發使得我們簡單的面向對象系統變得異常復雜和難以掌握起來。下面我從這個兩個角度，給出兩種模式思維解決之道。

生命周期(Scope)

　　生命周期(Scope)就是指狀態的活動周期，狀態對象是什么時候被創建；然后什么時候被銷毀，很顯然，如果狀態對象還沒有被創建或已經被銷毀，你再 訪問這個狀態對象可能失敗，而狀態的生命周期控制是可能散落在運行程序的各個地方，如果不象狀態模式那樣進行統一控制，有可能整個系統是危機四伏的。

　　狀態的生命周期其實就是對象生命周期，更加細化地說：是Domain Model這個對象的生命周期。這在一個以領域模型為驅動的設計概念中不可回避的課題，而領域模型實戰的復雜性就復雜在此。

　　狀態的生命周期在J2EE中目前有三種：Request/Session和 Application，Request是每個客戶端發出的一次請求，這是J2EE系統中最基本的事件激活單元， 當服務器端推出一個頁面到客戶端時，意味著這個Request的結束。那么如果我們的狀態保存在Request中，意味著在request結束之前，這個 請求經歷的任何一個環節都可以對這個狀態（對象）進行操作。（掌握這個原理，對于你學習Struts和JSF很有幫助）

　　如果是Session，則一直和該客戶端有關，只要是該客戶端發出的每次request的任何環節都可以對這個狀態（對象）進行操作。

　　如果是Application，則意味著這個狀態是當前Web項目的全局狀態。

　　這三種狀態形式都是以將狀態保存在內存中形式存在的，是和持久化狀態相對的。是一種內存活動狀態。

　　生命周期的選取當然是越短越好，這樣，這個狀態對象就可以被自動銷毀，從而避免了
大訪問量下的內存泄漏，但是在大訪問量下，對象頻繁創建和銷毀是耗費性能的。

　　那么，我們可能經常使用HttpSession來保存狀態，這時你極有可能造成內存泄漏，我經常在 Jdon論壇上看到將很多數據庫數據暫時保存在HttpSession中想法，這是相當危險的，因為一旦并發用戶很多，相當多的HttpSession包 含了狀態，而狀態中有可能有更多其他引用，因此內存很快會爆滿，或者垃圾回收機制頻繁啟動，造成應用系統運行暫?；蚓徛?。

　　當你將狀態放入HttpSession時，難道沒有考慮將其手工消除嗎？你要知道所有Web容器 （Tomcat/Weblogic等）都不會自動替你清除那些你可能不用的狀態對象啊。如果每個人只管新增元素，不管重整或管理，這個系統能不變得混亂 嗎？代碼上這種現象我們是通過Refactoring等結構/行為模式來解決，那么在運行時的狀態管理呢？

　　狀態管理模式或者說對象管理模式正是解決這種問題的。

　　 按照該模式，你必須手工自己管理放在HttpSession的狀態，比如你為每個HttpSession
設立一個狀態容器最大尺寸，當超過這個尺寸時，你需要將不用的狀態從容器去除， 但是如果這個客戶端在Session失效期內又來訪問這個狀態怎么辦？那么你可能需要先臨時將狀態序列化保存到硬盤上，等Session失效期到達后再真正刪除。

　　是不是覺得很麻煩？
　　捷徑是有：
　　1. 盡量少使用HttpSession保存狀態，這對集群環境也是有利的，見該貼討論：
http://www.jdon.com/jive/article.jsp?forum=121&thread=22282
那么這些狀態放在哪里？使用Application的緩存中，

　　2. 使用狀態管理中間件，目前有幾個選擇：EJB的有態Bean；NanoContainer之類狀態相關的微容器。那么Spring可以嗎？目前沒有發現有 該功能，甚至在Spring容器內無法直接使用Session性質的狀態，只能通過線程級別的ThreadLocal來實現(對不起，你又要開始回到遠古 的匯編線程時代了)；而Jdon框架則可以。

　　下面我們談談Application的狀態，在這個范圍內，一個對象狀態可以被多個用戶反復訪問，在這個級別，狀態類似數據庫中數據，因為可以使用數據庫來替代這個級別的狀態，所以將狀態放入緩存這個深層次技術被大多數初學者忽視了，甚至產生了對數據庫依賴心理。

緩存中的狀態

　　雖然我們將狀態保存在Application中，但是我們不可避免還是遇到Session同樣的狀態管理問題，這個問題所幸的是有專門緩存中間件解決 了，當然，在一個多服務器集群系統，如果一個客戶端在一個服務器中存放了狀態，那么能否在另外一個服務器的內存中訪問到呢？回答是肯定的，前提是你必須使 用分布式緩存系統。

　　目前分布式緩存系統是靠EJB服務器完成，當JBoss 5在2006變成完全解耦、可肢解時，
我們就可以使用原本只支持EJB的JBoss分布式緩存系統來支持我們的普通JavaBeans了(POJO)。這其中目前可能會花費一些力氣，因為還沒有一個統一的POJO構件接口標準，我相信以后
可能會有。

　　如果你不想花費力氣，而且可能就只是一臺服務器，可以通過雙核芯片提升性能，那么單態緩存如果實現？很簡單，使用一個緩存產品如OsCache等，將其設定保存在 Application中，或者在web.xml中進行一下簡單的配置即可。

　　但是，這時你可能碰到另外一個問題：狀態的唯一標識，如何通過唯一標識從緩存中那么
多對象狀態中取出你要的那一個呢？比較瑣碎。

　　有沒有一個框架幫助你省卻這些麻煩，當然推薦Jdon Framework，只要將包含狀態的類（主要是Domain Model）繼承特定的類或接口（接口在1.4版本實現）即可，這個類的對象運行時就會被緩存或從緩存中讀取，再也無需你照料緩存了，就這么簡單。

　　當然，Jdon Framework的底層緩存器是可以被替代，使用你喜歡的緩存產品，因為jdon
Framework是基于Ioc設計，構件之間是完全解耦、可徹底肢解，能夠通過配置替代和更換的。
如果你不明白這個道理，需要好好研究一下Ioc模式帶給我們革命性的新變化。

　　從以上也可以看出：java復雜性還在于我們需要在編碼時，卻要想象其運行時的情形。而這種翻譯聯想沒有深厚的實踐功底，是很難順利完成的。

狀態管理中間件

　　自從J2EE開辟中間件時代以來，就有相當多的高級中間件提供與具體應用無關的通用功能，狀態管理中間件很早就有之，EJB的有態Session Bean是一個代表。

　　一個中間件不但要有良好的松耦合設計，我們暫時稱為靜態設計；更要有優秀的動態設計，例如狀態管理就屬于一種動態設計。

　　當然，如果你比較謙虛，不但要選擇一些靜態設計很好的框架或中間件；而且還要依賴一些擁有良好的動態運行管理的中間件。

　　EJB無論是EJB1.X/EJB2.X/EJB3.X.在狀態管理上要更加優秀，當然EJB3.X又吸收了優秀的靜態設計概念，但是因為需要有一個具體服務器實現過程，這個過程中存在一些陷阱，如In-Box問題等。

　　Spring無疑是一個靜態設計非常優秀框架，它一直在AOP上孜孜不倦，力圖探索一條從AOP角度進行動態運行管理干預捷徑，相信會有驚人結果，當然，這種細粒度的AOP需要實踐檢驗，當然如果整入JDK 6.0就更好。

　　而Jdon Framework則試圖在目前兩者之間尋求了一個平衡，既有Ioc/AOP優秀的靜態設計，雖然在AOP上不及Spring前衛；但提供了切實Session和Cache狀態管理；

　　如果你不需要EJB的分布式多服務器集群功能；又不是AOP的超級粉絲，無疑使用Jdon Framework之類的框架無疑是簡化方便的。

狀態設計的難點

　　最后，我不得不重申，并不是有了良好的狀態管理框架就可以高枕無憂了，狀態的設計其實是我們每個項目必須面臨的可變課題，如果狀態復雜了可以使用狀態模式對付，可惜往往狀態不夠復雜。

　　一個對象本身屬性和狀態是應該耦合在一起，還是進行分離，屬性和狀態沒有明顯的涇渭分明的界限，我們舉一個例子：

　　論壇Forum這個對象，它有一些字段屬性，如論壇名稱、論壇描述，還有其他一些相關屬性：如該論壇 的最新發帖；該論壇的發貼量，后兩者好像也是論壇字段，但是他們可能經常變化的，應該屬于狀態，那么狀態和Forum這個主體對象是什么關系？是將該論壇 的最新發帖和該論壇的發貼量兩個字段并入Forum這個Domain Model中，還是應該單獨建立一個狀態對象？如果進行分離，分離的依據是什么？

　　當然，這里分離的依據是因為對象的生存周期不同。對于我們熟悉的課題，我們能夠馬上分辨出其中的生存周期，如果是不熟悉領域的建模呢？

　　所以，大家已經明白：狀態設計的難點是：如何粒度細化地創建模型對象；然后分辨出其中動態的狀態性質。這是域建模實戰中一個難點。

　　很多人問我：你提倡的域建模、設計模式和框架是什么意思？為什么說他們是Java開發設計的三件寶呢？或者說三個典型知識點呢？我想通過本篇我已經通過狀態這個概念稍微解釋了域建模的一些特點。

　　當前，MDA中的四色原型模式Archetype將幫助我們更好地分辨出類的屬性、狀態和行為，這是一場帶來以后十年的軟件革命，

(1) 訪問流程:

(1.1) 系統運行在某web容器,如Tomcat(其運行和weblogic不同,Tomcat只有一個進程).

      其預設有初始的線程數.

(1.2) 瀏覽器打開某網站,網站及給其分配一個sessionID(頁面隱式的發起request, 由Tomcat

      某個特定的監聽線程給予response一個sessionid). 該sessionid用以識別本次訪問.

(1.3) 用戶點擊登錄/注冊, 瀏覽器發起一個新的request, 由Tomcat線程池中空閑的線程進行

       處理. 反饋結果于前臺展現.如線程池中線程不足,則Tomcat每次按照一定規則創建出更多的空閑線程(其初始值,增加值,及最大值依據配置文件/JDK/硬件).

最近在做登錄和權限控制模塊，用到了session，發現session的好多方法都不熟悉，而且以前也聽說過JsessionId 之類session竊取的事，

對這些一直都是一知半解。今天索性google了很多資料，先上sun的官網去看session的文檔了解一些方法，又找了別人關于session的看法。

總結如下：

      1，session是什么？  what

          session經常譯為會話，以打電話為例，從開始撥號到掛斷電話就是你會話的生存周期。

      2，session 做什么用的  why？

          首先舉個例子：

                咖啡店舉行 消費滿5杯咖啡贈送一杯的活動，可每個人一次消費5杯的時候非常少。這時候有3種辦法：

                1，店員看到每個顧客時都能記住其消費了多少杯，從而給其優惠，這是協議本身具有狀態

                2，給每個顧客一個卡片，上面記錄顧客的每次消費，這是客戶端保存狀態

                3，給每個顧客一個卡片，卡片上只有一個編號，顧客每次的消費記錄在店里，這就是 服務端有狀態

          而http本身是無狀態的，所以我們只能使用2，3中方法，來保存一些信息。

          實際采用的是第3種方法，服務器段保存一次會話所有的信息，并生成一個唯一的id，這個id沒有規律而且不會重復，將這個id傳回到客戶段，

保存到cookie中。每次訪問服務器時，客戶端都會偷偷將這個id傳到服務器，服務器根據id查到這次會話保存的內容。就能實現會話中共享一些數據。

     3，session怎樣創建和銷毀 ？ how

         session是保存在內存中的，所以會有一些性能上的影響。因此本著這個原則，session是只有在使用到的時候才會被創建，如果始終沒有用到

session，這個session是永遠不會被創建的。

        比如： 訪問servlet ，只要你代碼中沒有 request.getSession()或request.getSession(true);這兩行是等價的，那session是不會創建。

又 當你訪問靜態頁面時，根本不會生成servlet，所以也不會創建session。

       下面解釋一些疑惑： session是第一次請求時創建的？

  大家都知道 jsp是被編譯成servlet才執行的，問題就在jsp編譯的過程。

 jsp中有個<%@ page session="true/false"%> 這個開關表示是否創建session，當你不寫這行時，它會默認給你加上這句。所以會造成上面的疑惑。

當然還有一些標簽中可能有getSession()操作，會產生一些不必要的session。

       session只能在服務端銷毀，有三種途徑： 1，到達session的最大請求間隔時間時，2，session。invalidate()

 3,服務器進程當掉。

       這里也有一些疑惑： 瀏覽器關閉時，session就會注銷。

       首先瀏覽器關閉時，瀏覽器并沒有給服務器發送任何消息，所以服務器不會知道瀏覽器何時關閉了。

 上面我們知道取得session 是因為瀏覽器cookie中有sessionid，而普通cookie通常會是會話cookie，也就是說瀏覽器關閉時，這個cookie會被注銷，

所以當你再訪問服務器時就沒有sessionid了，所以造成session關閉了的假象，如果昵稱通過特殊方法將sessionid傳遞給服務器，你會發現session還在。

如果想讓cookie保存時間長一些，就需要手動指定cookie的過期時間

 

4，實際項目中的難點：

     1，瀏覽器禁用cookie

      這就沒辦法保存sessionid了，可以采用url重寫，轉發，加隱藏字段等方法來將sessionid傳給服務器。

     如：  baidu.com:jsessionid=adfasdfasdfasdfasdfafdadf?asdfasdf

             baidu.com?jsessionid=asdfasdfasdfadsfad&&adfdf

 這根據服務器的不同實現，第一種可以將普通參數區分開。

 

     2，多人共用session的問題

        例： a 訪問 baidu.com ,但他沒有帳號，于是他將連接 baidu.com/login.jsp?jsessionid=adsfasdfad（這個a的sessionid） 發給B, B登錄

后，a就相當于用b的帳號登錄了。你們可以在在本地試試。

        解決方法： 當發現通過sessionid從url指定時， 創建一個新的session，將舊session的信息復制到 新sessoin中，然后將新session注銷。

就能防止上面那種情況了。

    3，一個帳號多地方登錄

       比如： 你用abc帳號登錄了baidu.com,有打開了一個瀏覽器，又用abc帳號登錄了一次。當不設計敏感操作時，這無所謂，而當你做一些敏感操

作時就必須禁止這樣情況，防止同時操作，造成重復操作，或者數據損壞。

     解決方法： 監聽session，將username和sessionid對應起來，當username再次登錄時，注銷掉以前的session，保存現在的session，這也是

一種比較不錯的方案。

 

 

http://www.iteye.com/topic/257191

今天下午研究了半天hashcode()和equals()方法，終于有了一點點的明白，寫下來與大家分享（zhaoxudong 2008.10.23晚21.36）。
1. 首先equals()和hashcode()這兩個方法都是從object類中繼承過來的。
equals()方法在object類中定義如下：
  public boolean equals(Object obj) {
return (this == obj);
}
很明顯是對兩個對象的地址值進行的比較（即比較引用是否相同）。但是我們必需清楚，當String 、Math、還有Integer、Double。。。。等這些封裝類在使用equals()方法時，已經覆蓋了object類的equals（）方法。比 如在String類中如下：
  public boolean equals(Object anObject) {
if (this == anObject) {
    return true;
}
if (anObject instanceof String) {
    String anotherString = (String)anObject;
    int n = count;
    if (n == anotherString.count) {
char v1[] = value;
char v2[] = anotherString.value;
int i = offset;
int j = anotherString.offset;
while (n-- != 0) {
    if (v1[i++] != v2[j++])
return false;
}
return true;
    }
}
return false;
}
很明顯，這是進行的內容比較，而已經不再是地址的比較。依次類推Double、Integer、Math。。。。等等這些類都是重寫了equals()方法的，從而進行的是內容的比較。當然了基本類型是進行值的比較，這個沒有什么好說的。
我們還應該注意，Java語言對equals()的要求如下，這些要求是必須遵循的：
• 對稱性：如果x.equals(y)返回是“true”，那么y.equals(x)也應該返回是“true”。
• 反射性：x.equals(x)必須返回是“true”。
• 類推性：如果x.equals(y)返回是“true”，而且y.equals(z)返回是“true”，那么z.equals(x)也應該返回是“true”。
• 還有一致性：如果x.equals(y)返回是“true”，只要x和y內容一直不變，不管你重復x.equals(y)多少次，返回都是“true”。
• 任何情況下，x.equals(null)，永遠返回是“false”；x.equals(和x不同類型的對象)永遠返回是“false”。
以上這五點是重寫equals()方法時，必須遵守的準則，如果違反會出現意想不到的結果，請大家一定要遵守。
2. 其次是hashcode() 方法，在object類中定義如下：
  public native int hashCode();
說明是一個本地方法，它的實現是根據本地機器相關的。當然我們可以在自己寫的類中覆蓋hashcode()方法，比如String、 Integer、Double。。。。等等這些類都是覆蓋了hashcode()方法的。例如在String類中定義的hashcode()方法如下：
    public int hashCode() {
int h = hash;
if (h == 0) {
    int off = offset;
    char val[] = value;
    int len = count;

            for (int i = 0; i < len; i++) {
                h = 31*h + val[off++];
            }
            hash = h;
        }
        return h;
}
解釋一下這個程序（String的API中寫到）：
s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]
使用 int 算法，這里 s[i] 是字符串的第 i 個字符，n 是字符串的長度，^ 表示求冪。（空字符串的哈希碼為 0。）

3.這里我們首先要明白一個問題：
equals()相等的兩個對象，hashcode()一定相等；
equals（）不相等的兩個對象，卻并不能證明他們的hashcode()不相等。換句話說，equals()方法不相等的兩個對象，hashcode()有可能相等。（我的理解是由于哈希碼在生成的時候產生沖突造成的）。
反過來：hashcode()不等，一定能推出equals()也不等；hashcode()相等，equals()可能相等，也可能不等。解釋 下第3點的使用范圍，我的理解是在object、String等類中都能使用。在object類中，hashcode()方法是本地方法，返回的是對象的 地址值，而object類中的equals()方法比較的也是兩個對象的地址值，如果equals()相等，說明兩個對象地址值也相等，當然 hashcode()也就相等了；在String類中，equals()返回的是兩個對象內容的比較，當兩個對象內容相等時，
Hashcode()方法根據String類的重寫（第2點里面已經分析了）代碼的分析，也可知道hashcode()返回結果也會相等。以此類 推，可以知道Integer、Double等封裝類中經過重寫的equals()和hashcode()方法也同樣適合于這個原則。當然沒有經過重寫的 類，在繼承了object類的equals()和hashcode()方法后，也會遵守這個原則。

4.談到hashcode()和equals()就不能不說到hashset,hashmap,hashtable中的使用，具體是怎樣呢，請看如下分析：
Hashset是繼承Set接口，Set接口又實現Collection接口，這是層次關系。那么hashset是根據什么原理來存取對象的呢？
在hashset中不允許出現重復對象，元素的位置也是不確定的。在hashset中又是怎樣判定元素是否重復的呢？這就是問題的關鍵所在，經過一下午的查詢求證終于獲得了一點啟示，和大家分享一下，在java的集合中，判斷兩個對象是否相等的規則是：
1)，判斷兩個對象的hashCode是否相等
      如果不相等，認為兩個對象也不相等，完畢
      如果相等，轉入2)
（這一點只是為了提高存儲效率而要求的，其實理論上沒有也可以，但如果沒有，實際使用時效率會大大降低，所以我們這里將其做為必需的。后面會重點講到這個問題。）
2)，判斷兩個對象用equals運算是否相等
      如果不相等，認為兩個對象也不相等
      如果相等，認為兩個對象相等（equals()是判斷兩個對象是否相等的關鍵）
為什么是兩條準則，難道用第一條不行嗎？不行，因為前面已經說了，hashcode()相等時，equals()方法也可能不等，所以必須用第2條準則進行限制，才能保證加入的為非重復元素。
比如下面的代碼：

public static void main(String args[]){
String s1=new String("zhaoxudong");
String s2=new String("zhaoxudong");
System.out.println(s1==s2);//false
System.out.println(s1.equals(s2));//true
System.out.println(s1.hashCode());//s1.hashcode()等于s2.hashcode()
System.out.println(s2.hashCode());
Set hashset=new HashSet();
hashset.add(s1);
hashset.add(s2);
/*實質上在添加s1,s2時，運用上面說到的兩點準則，可以知道hashset認為s1和s2是相等的，是在添加重復元素，所以讓s2覆蓋了s1;*/
Iterator it=hashset.iterator();
            while(it.hasNext())
            {
             System.out.println(it.next());
            }
最后在while循環的時候只打印出了一個”zhaoxudong”。
輸出結果為：false
            true
            -967303459
            -967303459
這是因為String類已經重寫了equals()方法和hashcode()方法，所以在根據上面的第1.2條原則判定時，hashset認為它們是相等的對象，進行了重復添加。
但是看下面的程序：
import java.util.*;
public class HashSetTest
{
   public static void main(String[] args)
    {
                 HashSet hs=new HashSet();
                 hs.add(new Student(1,"zhangsan"));
                 hs.add(new Student(2,"lisi"));
                 hs.add(new Student(3,"wangwu"));
                 hs.add(new Student(1,"zhangsan"));
 
                 Iterator it=hs.iterator();
                 while(it.hasNext())
                 {
                        System.out.println(it.next());
                 }
     }
}
class Student
   {
     int num;
     String name;
     Student(int num,String name)
                {
                this.num=num;
                 this.name=name;
                 }
              public String toString()
                {
                    return num+":"+name;
                 }
           }     
輸出結果為：
                      1:zhangsan
                   1:zhangsan
                   3:wangwu
                   2:lisi
問題出現了，為什么hashset添加了相等的元素呢，這是不是和hashset的原則違背了呢？回答是：沒有
因為在根據hashcode()對兩次建立的new Student(1,"zhangsan")對象進行比較時，生成的是不同的哈希碼值，所以hashset把他當作不同的對象對待了，當然此時的 equals()方法返回的值也不等（這個不用解釋了吧）。那么為什么會生成不同的哈希碼值呢？上面我們在比較s1和s2的時候不是生成了同樣的哈希碼 嗎？原因就在于我們自己寫的Student類并沒有重新自己的hashcode()和equals()方法，所以在比較時，是繼承的object類中的 hashcode()方法，呵呵，各位還記得object類中的hashcode()方法比較的是什么吧??！
它是一個本地方法，比較的是對象的地址（引用地址），使用new方法創建對象，兩次生成的當然是不同的對象了（這個大家都能理解吧。。。），造成 的結果就是兩個對象的hashcode()返回的值不一樣。所以根據第一個準則，hashset會把它們當作不同的對象對待，自然也用不著第二個準則進行 判定了。那么怎么解決這個問題呢？？
答案是：在Student類中重新hashcode()和equals()方法。
例如：
  class Student
{
int num;
String name;
Student(int num,String name)
{
            this.num=num;
            this.name=name;
}
public int hashCode()
{
            return num*name.hashCode();
}
public boolean equals(Object o)
{
            Student s=(Student)o;
            return num==s.num && name.equals(s.name);
}
public String toString()
{
            return num+":"+name;
}
}
根據重寫的方法，即便兩次調用了new Student(1,"zhangsan")，我們在獲得對象的哈希碼時，根據重寫的方法hashcode()，獲得的哈希碼肯定是一樣的（這一點應該沒有疑問吧）。
當然根據equals()方法我們也可判斷是相同的。所以在向hashset集合中添加時把它們當作重復元素看待了。所以運行修改后的程序時，我們會發現運行結果是：
                      1:zhangsan
                   3:wangwu
                   2:lisi
可以看到重復元素的問題已經消除。
關于在hibernate的pojo類中，重新equals()和hashcode()的問題：
1)，重點是equals，重寫hashCode只是技術要求（為了提高效率）
2)，為什么要重寫equals呢，因為在java的集合框架中，是通過equals來判斷兩個對象是否相等的
3)，在hibernate中，經常使用set集合來保存相關對象，而set集合是不允許重復的。我們再來談談前面提到在向hashset集合中添加元素時,怎樣判斷對象是否相同的準則，前面說了兩條，其實只要重寫equals()這一條也可以。
但當hashset中元素比較多時，或者是重寫的equals()方法比較復雜時，我們只用equals()方法進行比較判斷，效率也會非常低， 所以引入了hashcode()這個方法，只是為了提高效率，但是我覺得這是非常有必要的（所以我們在前面以兩條準則來進行hashset的元素是否重復 的判斷）。
比如可以這樣寫：
public int hashCode(){
   return  1;}//等價于hashcode無效
這樣做的效果就是在比較哈希碼的時候不能進行判斷，因為每個對象返回的哈希碼都是1，每次都必須要經過比較equals()方法后才能進行判斷是否重復，這當然會引起效率的大大降低。
我有一個問題，如果像前面提到的在hashset中判斷元素是否重復的必要方法是equals()方法（根據網上找到的觀點），但是這里并沒有涉及到關于哈希表的問題，可是這個集合卻叫hashset，這是為什么？？
我想，在hashmap,hashtable中的存儲操作，依然遵守上面的準則。所以這里不再多說。這些是今天看書，網上查詢資料，自己總結出來 的，部分代碼和語言是引述，但是千真萬確是自己總結出來的。有錯誤之處和不詳細不清楚的地方還請大家指出，我也是初學者，所以難免會有錯誤的地方，希望大 家共同討論。