鎖（locking）
業(yè)務邏輯的實現(xiàn)過程中，往往需要保證數(shù)據(jù)訪問的排他性。如在金融系統(tǒng)的日終結算 處理中，我們希望針對某個cut-off時間點的數(shù)據(jù)進行處理，而不希望在結算進行過程中 （可能是幾秒種，也可能是幾個小時），數(shù)據(jù)再發(fā)生變化。此時，我們就需要通過一些機制來保證這些數(shù)據(jù)在某個操作過程中不會被外界修改，這樣的機制，在這里，也就是所謂 的“鎖”，即給我們選定的目標數(shù)據(jù)上鎖，使其無法被其他程序修改。 Hibernate支持兩種鎖機制：即通常所說的“悲觀鎖（Pessimistic Locking）” 和“樂觀鎖（Optimistic Locking）”。

一 ：悲觀鎖（Pessimistic Locking）
悲觀鎖，正如其名，它指的是對數(shù)據(jù)被外界（包括本系統(tǒng)當前的其他事務，以及來自外部系統(tǒng)的事務處理）修改持保守態(tài)度，因此，在整個數(shù)據(jù)處理過程中，將數(shù)據(jù)處于鎖定 狀態(tài)。悲觀鎖的實現(xiàn)，往往依靠數(shù)據(jù)庫提供的鎖機制（也只有數(shù)據(jù)庫層提供的鎖機制才能 真正保證數(shù)據(jù)訪問的排他性，否則，即使在本系統(tǒng)中實現(xiàn)了加鎖機制，也無法保證外部系 統(tǒng)不會修改數(shù)據(jù)）。 一個典型的倚賴數(shù)據(jù)庫的悲觀鎖調用： select * from account where name=”Erica” for update 這條sql 語句鎖定了account 表中所有符合檢索條件（name=”Erica”）的記錄。 本次事務提交之前（事務提交時會釋放事務過程中的鎖），外界無法修改這些記錄。 Hibernate的悲觀鎖，也是基于數(shù)據(jù)庫的鎖機制實現(xiàn)。 下面的代碼實現(xiàn)了對查詢記錄的加鎖：

1 String?hqlStr? = ? " from?TUser?as?user?where?user.name=’Erica’ " ;?
2 Query?query? = ?session.createQuery(hqlStr);?
3 query.setLockMode( " user " ,LockMode.UPGRADE);? // 加鎖?
4 List?userList? = ?query.list(); // 執(zhí)行查詢，

獲取數(shù)據(jù) query.setLockMode 對查詢語句中特定別名所對應的記錄進行加鎖（我們?yōu)?TUser類指定了一個別名“user”），這里也就是對返回的所有user記錄進行加鎖。 觀察運行期Hibernate生成的SQL語句：?

1 select?tuser0_.id?as?id,?tuser0_.name?as?name,?tuser0_.group_id?as?group_id,?tuser0_.user_type?as?user_type,?tuser0_.sex?as?sex?from?t_user?tuser0_?where?(tuser0_.name = ’Erica’?)? for ?update

?這里Hibernate通過使用數(shù)據(jù)庫的for update子句實現(xiàn)了悲觀鎖機制。 Hibernate的加鎖模式有：
? LockMode.NONE ： 無鎖機制。
? LockMode.WRITE ：Hibernate在Insert和Update記錄的時候會自動 獲取。
? LockMode.READ ： Hibernate在讀取記錄的時候會自動獲取。

以上這三種鎖機制一般由Hibernate內部使用，如Hibernate為了保證Update 過程中對象不會被外界修改，會在save方法實現(xiàn)中自動為目標對象加上WRITE鎖。
?
? LockMode.UPGRADE ：利用數(shù)據(jù)庫的for update子句加鎖。
? LockMode. UPGRADE_NOWAIT ：Oracle的特定實現(xiàn)，利用Oracle的for update nowait子句實現(xiàn)加鎖。

上面這兩種鎖機制是我們在應用層較為常用的，加鎖一般通過以下方法實現(xiàn)：
Criteria.setLockMode
Query.setLockMode
Session.lock
注意，只有在查詢開始之前（也就是Hiberate 生成SQL 之前）設定加鎖，才會 真正通過數(shù)據(jù)庫的鎖機制進行加鎖處理，否則，數(shù)據(jù)已經通過不包含for update 子句的Select SQL加載進來，所謂數(shù)據(jù)庫加鎖也就無從談起。

二 ：樂觀鎖（Optimistic Locking）
相對悲觀鎖而言，樂觀鎖機制采取了更加寬松的加鎖機制。悲觀鎖大多數(shù)情況下依 靠數(shù)據(jù)庫的鎖機制實現(xiàn)，以保證操作最大程度的獨占性。但隨之而來的就是數(shù)據(jù)庫 性能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。 如一個金融系統(tǒng)，當某個操作員讀取用戶的數(shù)據(jù)，并在讀出的用戶數(shù)據(jù)的基礎上進 行修改時（如更改用戶帳戶余額），如果采用悲觀鎖機制，也就意味著整個操作過 程中（從操作員讀出數(shù)據(jù)、開始修改直至提交修改結果的全過程，甚至還包括操作 員中途去煮咖啡的時間），數(shù)據(jù)庫記錄始終處于加鎖狀態(tài)，可以想見，如果面對幾 百上千個并發(fā)，這樣的情況將導致怎樣的后果。 樂觀鎖機制在一定程度上解決了這個問題。樂觀鎖 大多是基于數(shù)據(jù)版本 （Version）記錄機制實現(xiàn)。何謂數(shù)據(jù)版本？即為數(shù)據(jù)增加一個版本標識，在基于 數(shù)據(jù)庫表的版本解決方案中，一般是通過為數(shù)據(jù)庫表增加一個“version”字段來 實現(xiàn)。 讀取出數(shù)據(jù)時，將此版本號一同讀出，之后更新時，對此版本號加一。此時，將提 交數(shù)據(jù)的版本數(shù)據(jù)與數(shù)據(jù)庫表對應記錄的當前版本信息進行比對，如果提交的數(shù)據(jù) 版本號大于數(shù)據(jù)庫表當前版本號，則予以更新，否則認為是過期數(shù)據(jù)。 對于上面修改用戶帳戶信息的例子而言，假設 ：

數(shù)據(jù)庫中帳戶信息表中有一個 version字段，當前值為1；而當前帳戶余額字段（balance）為$100。
1 ：操作員A 此時將其讀出（version=1），并從其帳戶余額中扣除$50 （$100-$50）。
2?：?在操作員A操作的過程中，操作員B也讀入此用戶信息（version=1），并 從其帳戶余額中扣除$20（$100-$20）。
3： 操作員A完成了修改工作，將數(shù)據(jù)版本號加一（version=2），連同帳戶扣 除后余額（balance=$50），提交至數(shù)據(jù)庫更新，此時由于提交數(shù)據(jù)版本大 于數(shù)據(jù)庫記錄當前版本，數(shù)據(jù)被更新，數(shù)據(jù)庫記錄version更新為2。
4： 操作員B完成了操作，也將版本號加一（version=2）試圖向數(shù)據(jù)庫提交數(shù) 據(jù)（balance=$80），但此時比對數(shù)據(jù)庫記錄版本時發(fā)現(xiàn)，操作員B提交的 數(shù)據(jù)版本號為2，數(shù)據(jù)庫記錄當前版本也為2，不滿足“提交版本必須大于記 錄當前版本才能執(zhí)行更新“的樂觀鎖策略，因此，操作員B 的提交被駁回。 這樣，就避免了操作員B 用基于version=1 的舊數(shù)據(jù)修改的結果覆蓋操作 員A的操作結果的可能。

從上面的例子可以看出，樂觀鎖機制避免了長事務中的數(shù)據(jù)庫加鎖開銷（操作員A 和操作員B操作過程中，都沒有對數(shù)據(jù)庫數(shù)據(jù)加鎖），大大提升了大并發(fā)量下的系 統(tǒng)整體性能表現(xiàn)。 需要注意的是，樂觀鎖機制往往基于系統(tǒng)中的數(shù)據(jù)存儲邏輯，因此也具備一定的局 限性，如在上例中，由于樂觀鎖機制是在我們的系統(tǒng)中實現(xiàn)，來自外部系統(tǒng)的用戶 余額更新操作不受我們系統(tǒng)的控制，因此可能會造成臟數(shù)據(jù)被更新到數(shù)據(jù)庫中。在 系統(tǒng)設計階段，我們應該充分考慮到這些情況出現(xiàn)的可能性，并進行相應調整（如 將樂觀鎖策略在數(shù)據(jù)庫存儲過程中實現(xiàn)，對外只開放基于此存儲過程的數(shù)據(jù)更新途 徑，而不是將數(shù)據(jù)庫表直接對外公開）。 Hibernate 在其數(shù)據(jù)訪問引擎中內置了樂觀鎖實現(xiàn)。如果不用考慮外部系統(tǒng)對數(shù) 據(jù)庫的更新操作，利用Hibernate提供的透明化樂觀鎖實現(xiàn)，將大大提升我們的 生產力。 Hibernate中可以通過class描述符的optimistic-lock屬性結合version 描述符指定。
現(xiàn)在，我們?yōu)橹笆纠械腡User加上樂觀鎖機制。
?
1． 首先為TUser的class描述符添加optimistic-lock屬性：

< hibernate - mapping > ?
< class ?
name = " org.hibernate.sample.TUser " ?
table = " t_user " ?
dynamic - update = " true " ?
dynamic - insert = " true " ?
optimistic - lock = " version " ?
> ?
……?
</ class > ?
</ hibernate - mapping > ?

optimistic-lock屬性有如下可選取值：
? none 無樂觀鎖
? version 通過版本機制實現(xiàn)樂觀鎖
? dirty 通過檢查發(fā)生變動過的屬性實現(xiàn)樂觀鎖
? all 通過檢查所有屬性實現(xiàn)樂觀鎖

其中通過version實現(xiàn)的樂觀鎖機制是Hibernate官方推薦的樂觀鎖實現(xiàn)，同時也 是Hibernate中，目前唯一在數(shù)據(jù)對象脫離Session發(fā)生修改的情況下依然有效的鎖機 制。因此，一般情況下，我們都選擇version方式作為Hibernate樂觀鎖實現(xiàn)機制。

2． 添加一個Version屬性描述符
代碼內容

?1 < hibernate - mapping > ??
?2 < class ??
?3 name = " org.hibernate.sample.TUser " ??
?4 table = " t_user " ??
?5 dynamic - update = " true " ??
?6 dynamic - insert = " true " ??
?7 optimistic - lock = " version " ??
?8 > ??
?9 < id??
10 name = " id " ??
11 column = " id " ??
12 type = " java.lang.Integer " ??
13 > ??
14 < generator? class = " native " > ??
15 </ generator > ??
16 </ id > ??
17 < version??
18 column = " version " ??
19 name = " version " ??
20 type = " java.lang.Integer " ??
21 /> ??
22 ……??
23 </ class > ??
24 </ hibernate - mapping > ??
25

注意version 節(jié)點必須出現(xiàn)在ID 節(jié)點之后。 這里我們聲明了一個version屬性，用于存放用戶的版本信息，保存在TUser表的 version字段中。 此時如果我們嘗試編寫一段代碼，更新TUser表中記錄數(shù)據(jù)，如：
代碼內容

1 Criteria?criteria? = ?session.createCriteria(TUser. class );??
2 criteria.add(Expression.eq( " name " , " Erica " ));??
3 List?userList? = ?criteria.list();??
4 TUser?user? = (TUser)userList.get( 0 );??
5 Transaction?tx? = ?session.beginTransaction();??
6 user.setUserType( 1 );? // 更新UserType字段??
7 tx.commit();??
8

每次對TUser進行更新的時候，我們可以發(fā)現(xiàn)，數(shù)據(jù)庫中的version都在遞增。 而如果我們嘗試在tx.commit 之前，啟動另外一個Session，對名為Erica 的用 戶進行操作，以模擬并發(fā)更新時的情形：
代碼內容

?1 Session?session = ?getSession();??
?2 Criteria?criteria? = ?session.createCriteria(TUser. class );??
?3 criteria.add(Expression.eq( " name " , " Erica " ));??
?4 Session?session2? = ?getSession();??
?5 Criteria?criteria2? = ?session2.createCriteria(TUser. class );??
?6 criteria2.add(Expression.eq( " name " , " Erica " ));??
?7 List?userList? = ?criteria.list();??
?8 List?userList2? = ?criteria2.list();TUser?user? = (TUser)userList.get( 0 );??
?9 TUser?user2? = (TUser)userList2.get( 0 );??
10 Transaction?tx? = ?session.beginTransaction();??
11 Transaction?tx2? = ?session2.beginTransaction();??
12 user2.setUserType( 99 );??
13 tx2.commit();??
14 user.setUserType( 1 );??
15 tx.commit();??
16

執(zhí)行以上代碼，代碼將在tx.commit()處拋出StaleObjectStateException異 常，并指出版本檢查失敗，當前事務正在試圖提交一個過期數(shù)據(jù)。通過捕捉這個異常，我 們就可以在樂觀鎖校驗失敗時進行相應處理。

說明一下,這一篇文章的用到的lucene,是用2.0版本的,主要在查詢的時候2.0版本的lucene與以前的版本有了一些區(qū)別.
其實這一些代碼都是早幾個月寫的,自己很懶,所以到今天才寫到自己的博客上,高深的文章自己寫不了，只能記錄下一些簡單的記錄與點滴，其中的代碼算是自娛自樂的，希望高手不要把重構之類的砸下來...

1、在windows系統(tǒng)下的的C盤，建一個名叫s的文件夾,在該文件夾里面隨便建三個txt文件，隨便起名啦，就叫"1.txt","2.txt"和"3.txt"啦
其中1.txt的內容如下：

2、下載lucene包，放在classpath路徑中
建立索引:

索引的結果：

3、建立了索引之后，查詢啦....

其運行結果：

這是lucene1.4.3版的API

Lucene 其實很簡單的,它最主要就是做兩件事:建立索引和進行搜索
來看一些在lucene中使用的術語,這里并不打算作詳細的介紹,只是點一下而已----因為這一個世界有一種好東西，叫搜索。

IndexWriter:lucene中最重要的的類之一，它主要是用來將文檔加入索引，同時控制索引過程中的一些參數(shù)使用。

Analyzer:分析器,主要用于分析搜索引擎遇到的各種文本。常用的有StandardAnalyzer分析器,StopAnalyzer分析器,WhitespaceAnalyzer分析器等。

Directory:索引存放的位置;lucene提供了兩種索引存放的位置，一種是磁盤，一種是內存。一般情況將索引放在磁盤上；相應地lucene提供了FSDirectory和RAMDirectory兩個類。

Document:文檔;Document相當于一個要進行索引的單元，任何可以想要被索引的文件都必須轉化為Document對象才能進行索引。

Field：字段。

IndexSearcher:是lucene中最基本的檢索工具，所有的檢索都會用到IndexSearcher工具;

Query:查詢，lucene中支持模糊查詢，語義查詢，短語查詢，組合查詢等等,如有TermQuery,BooleanQuery,RangeQuery,WildcardQuery等一些類。

QueryParser: 是一個解析用戶輸入的工具，可以通過掃描用戶輸入的字符串，生成Query對象。

Hits:在搜索完成之后，需要把搜索結果返回并顯示給用戶，只有這樣才算是完成搜索的目的。在lucene中，搜索的結果的集合是用Hits類的實例來表示的。

上面作了一大堆名詞解釋，下面就看幾個簡單的實例吧:
1、簡單的的StandardAnalyzer測試例子

2、看另一個實例,簡單地建立索引，進行搜索

很久沒有看lucene了，這兩三天又復習了一下,上一些代碼都是前幾個月寫的，只是改動了一些字符串和包名顯示。轉載時請說明，文章來自:http://lighter.javaeye.com。
如有什么錯誤的地方，懇請指出，謝謝。

StandardAnalyzer是lucene中內置的"標準分析器",可以做如下功能:
1、對原有句子按照空格進行了分詞
2、所有的大寫字母都可以能轉換為小寫的字母
3、可以去掉一些沒有用處的單詞，例如"is","the","are"等單詞，也刪除了所有的標點
同時也可以對中文進行分詞(效果不好),現(xiàn)在有很多的中文分詞包可以采用

昨天，由于程序中需要用到一個WEB TABS樣式的頁面，GOOGLE之，才發(fā)現(xiàn)這東西真不好找。
displaytag 這個東西計劃要支持TABS，為啥只是計劃，雖然它的表格樣式看起來不錯。
webtabs 這個嘛，樣子太丑了，拿不出手。
prizetags 這個可控制的屬性太少了，不爽。
Ditchnet JSP Tabs Taglib 就是它，為什么沒有地方能下載到，哪位好心人能告訴我？

下面的這個站收錄的比較全，收藏之。
東西還真不少，慢慢學啦，可惜沒有我想要的
【Java開源 Jsp標簽庫】
Posted by E_wsq 2006-3-29 9:32:00
displytag

與Struts結合使用最出名的一個tag主要是顯示表格數(shù)據(jù)很漂亮、完善。
500)this.style.width=500;” border=0> http://displaytag.sourceforge.net/
cewolf tag

用來在web上顯示復雜圖形報表的一個jsp tag。
500)this.style.width=500;” border=0> http://cewolf.sourceforge.net/
Loading Tab

當一個復雜的操作可以加載比較長的時間時，用這個tag。
500)this.style.width=500;” border=0> http://www.mycgiserver.com/~eboudrant/#taglibs
DbForms

DbForms!它是一個基于 Java (Servlet,JSP/Taglib)的快速應用程序開發(fā)環(huán)境，可以幫助開發(fā)人員快速建造基于Web的數(shù)據(jù)庫應用程序。
500)this.style.width=500;” border=0> http://jdbforms.sourceforge.net/
Jakarta Taglibs

Jakarta Taglibs 是為JSP定制標簽庫和相關的項目提供的一個開源倉庫，如 TagLibraryValidator類，和對頁面生成工具的擴展來支持標簽庫。Jakarta Taglibs 也包括了對JSP Standard Tag Library (JSTL)的參考實現(xiàn)。這個實現(xiàn)基于項目標準。目前，在Jakarta Taglibs 中沒有其它標簽庫代表了Java Community Process (JCP) 標準。
500)this.style.width=500;” border=0> http://jakarta.apache.org/taglibs/index.html
EasyLDAP

關鍵字 J2EE Spring Acegi

[簡介]

對于一個典型的Web應用，完善的認證和授權機制是必不可少的，在SpringFramework中，Juergen Hoeller提供的范例JPetStore給了一些這方面的介紹，但還遠遠不夠，Acegi是一個專門為SpringFramework提供安全機制的 項目，全稱為Acegi Security System for Spring，當前版本為0.5.1，就其目前提供的功能，應該可以滿足絕大多數(shù)應用的需求。

本文的主要目的是希望能夠說明如何在基于Spring構架的Web應用中使用Acegi，而不是詳細介紹其中的每個接口、每個類。注意，即使對已經存在的Spring應用，通過下面介紹的步驟，也可以馬上享受到Acegi提供的認證和授權。

[基礎工作]
在你的Web應用的lib中添加Acegi下載包中的acegi-security.jar

[web.xml]
實現(xiàn)認證和授權的最常用的方法是通過filter，Acegi亦是如此，通常Acegi需要在web.xml添加以下5個filter:

<filter>
<filter-name>Acegi Channel Processing Filter</filter-name>
<filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
<init-param>
<param-name>targetClass</param-name>
<param-value>net.sf.acegisecurity.securechannel.ChannelProcessingFilter</param-value>
</init-param>
</filter>
<filter>
<filter-name>Acegi Authentication Processing Filter</filter-name>
<filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
<init-param>
<param-name>targetClass</param-name>
<param-value>net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilter</param-value>
</init-param>
</filter>
<filter>
<filter-name>Acegi HTTP BASIC Authorization Filter</filter-name>
<filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
<init-param>
<param-name>targetClass</param-name>
<param-value>net.sf.acegisecurity.ui.basicauth.BasicProcessingFilter</param-value>
</init-param>
</filter>
<filter>
<filter-name>Acegi Security System for Spring Auto Integration Filter</filter-name>
<filter-class>net.sf.acegisecurity.ui.AutoIntegrationFilter</filter-class>
</filter>
<filter>
<filter-name>Acegi HTTP Request Security Filter</filter-name>
<filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
<init-param>
<param-name>targetClass</param-name>
<param-value>net.sf.acegisecurity.intercept.web.SecurityEnforcementFilter</param-value>
</init-param>
</filter>

最先引起迷惑的是net.sf.acegisecurity.util.FilterToBeanProxy，Acegi自己的文檔上解釋是： “What FilterToBeanProxy does is delegate the Filter’s methods through to a bean which is obtained from the
Spring application context. This enables the bean to benefit from the Spring application context lifecycle support and configuration flexibility.”，如希望深究的話，去看看源代碼應該不難理解。

再下來就是添加filter-mapping了：
<filter-mapping>
<filter-name>Acegi Channel Processing Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>Acegi Authentication Processing Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>Acegi HTTP BASIC Authorization Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>Acegi Security System for Spring Auto Integration Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>Acegi HTTP Request Security Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

這里，需要注意以下兩點：
1) 這幾個filter的順序是不能更改的，順序不對將無法正常工作；
2) 如果你的應用不需要安全傳輸，如https，則將”Acegi Channel Processing Filter”相關內容注釋掉即可；
3) 如果你的應用不需要Spring提供的遠程訪問機制，如Hessian and Burlap，將”Acegi HTTP BASIC Authorization
Filter”相關內容注釋掉即可。

[applicationContext.xml]
接下來就是要添加applicationContext.xml中的內容了，從剛才FilterToBeanFactory的解釋可以看出，真正的filter都
在Spring的applicationContext中管理：

1) 首先，你的數(shù)據(jù)庫中必須具有保存用戶名和密碼的table，Acegi要求table的schema必須如下：

CREATE TABLE users (
username VARCHAR(50) NOT NULL PRIMARY KEY,
password VARCHAR(50) NOT NULL,
enabled BIT NOT NULL
);
CREATE TABLE authorities (
username VARCHAR(50) NOT NULL,
authority VARCHAR(50) NOT NULL
);
CREATE UNIQUE INDEX ix_auth_username ON authorities ( username, authority );
ALTER TABLE authorities ADD CONSTRAINT fk_authorities_users foreign key (username) REFERENCES users
(username);

2) 添加訪問你的數(shù)據(jù)庫的datasource和Acegi的jdbcDao，如下：

<bean id=”dataSource” class=”org.springframework.jdbc.datasource.DriverManagerDataSource”>
<property name=”driverClassName”><value>${jdbc.driverClassName}</value></property>
<property name=”url”><value>${jdbc.url}</value></property>
<property name=”username”><value>${jdbc.username}</value></property>
<property name=”password”><value>${jdbc.password}</value></property>
</bean>
<bean id=”jdbcDaoImpl” class=”net.sf.acegisecurity.providers.dao.jdbc.JdbcDaoImpl”>
<property name=”dataSource”><ref bean=”dataSource”/></property>
</bean>

3) 添加DaoAuthenticationProvider:

<bean id=”daoAuthenticationProvider” class=”net.sf.acegisecurity.providers.dao.DaoAuthenticationProvider”>
<property name=”authenticationDao”><ref bean=”authenticationDao”/></property>
<property name=”userCache”><ref bean=”userCache”/></property>
</bean>

<bean id=”userCache” class=”net.sf.acegisecurity.providers.dao.cache.EhCacheBasedUserCache”>
<property name=”minutesToIdle”><value>5</value></property>
</bean>

如果你需要對密碼加密，則在daoAuthenticationProvider中加入：<property name=”passwordEncoder”><ref
bean=”passwordEncoder”/></property>，Acegi提供了幾種加密方法，詳細情況可看包
net.sf.acegisecurity.providers.encoding

4) 添加authenticationManager:

<bean id=”authenticationManager” class=”net.sf.acegisecurity.providers.ProviderManager”>
<property name=”providers”>
<list>
<ref bean=”daoAuthenticationProvider”/>
</list>
</property>
</bean>

5) 添加accessDecisionManager:

<bean id=”accessDecisionManager” class=”net.sf.acegisecurity.vote.AffirmativeBased”>
<property name=”allowIfAllAbstainDecisions”>
<value>false</value>
</property>
<property name=”decisionVoters”>
<list><ref bean=”roleVoter”/></list>
</property>
</bean>
<bean id=”roleVoter” class=”net.sf.acegisecurity.vote.RoleVoter”/>

6) 添加authenticationProcessingFilterEntryPoint:

<bean id=”authenticationProcessingFilterEntryPoint”
class=”net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilterEntryPoint”>
<property name=”loginFormUrl”><value>/acegilogin.jsp</value></property>
<property name=”forceHttps”><value>false</value></property>
</bean>

其中acegilogin.jsp是登陸頁面，一個最簡單的登錄頁面如下：

<%@ taglib prefix=’c’ uri=’http://java.sun.com/jstl/core’ %>
<%@ page import=”net.sf.acegisecurity.ui.AbstractProcessingFilter” %>
<%@ page import=”net.sf.acegisecurity.AuthenticationException” %>
<html>
<head>
<title>Login</title>
</head>

<body>
<h1>Login</h1>
<form action=”<c:url value=’j_acegi_security_check’/>” method=”POST”>
<table>
<tr><td>User:</td><td><input type=’text’ name=’j_username’></td></tr>
<tr><td>Password:</td><td><input type=’password’ name=’j_password’></td></tr>
<tr><td colspan=’2′><input name=”submit” type=”submit”></td></tr>
<tr><td colspan=’2′><input name=”reset” type=”reset”></td></tr>
</table>
</form>
</body>
</html>

7) 添加filterInvocationInterceptor:

<bean id=”filterInvocationInterceptor”
class=”net.sf.acegisecurity.intercept.web.FilterSecurityInterceptor”>
<property name=”authenticationManager”>
<ref bean=”authenticationManager”/>
</property>
<property name=”accessDecisionManager”>
<ref bean=”accessDecisionManager”/>
</property>
<property name=”objectDefinitionSource”>
<value>
CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
\A/sec/administrator.*\Z=ROLE_SUPERVISOR
\A/sec/user.*\Z=ROLE_TELLER
</value>
</property>
</bean>

這里請注意，要objectDefinitionSource中定義哪些頁面需要權限訪問，需要根據(jù)自己的應用需求進行修改，我上面給出
的定義的意思是這樣的：
a. CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON意思是在比較請求路徑時全部轉換為小寫
b. \A/sec/administrator.*\Z=ROLE_SUPERVISOR意思是只有權限為ROLE_SUPERVISOR才能訪問/sec/administrator*的頁面
c. \A/sec/user.*\Z=ROLE_TELLER意思是只有權限為ROLE_TELLER的用戶才能訪問/sec/user*的頁面

8) 添加securityEnforcementFilter:

<bean id=”securityEnforcementFilter” class=”net.sf.acegisecurity.intercept.web.SecurityEnforcementFilter”>
<property name=”filterSecurityInterceptor”>
<ref bean=”filterInvocationInterceptor”/>
</property>
<property name=”authenticationEntryPoint”>
<ref bean=”authenticationProcessingFilterEntryPoint”/>
</property>
</bean>

9) 添加authenticationProcessingFilter:

<bean id=”authenticationProcessingFilter”
class=”net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilter”>
<property name=”authenticationManager”>
<ref bean=”authenticationManager”/>
</property>
<property name=”authenticationFailureUrl”>
<value>/loginerror.jsp</value>
</property>
<property name=”defaultTargetUrl”>
<value>/</value>
</property>
<property name=”filterProcessesUrl”>
<value>/j_acegi_security_check</value>
</property>
</bean>
其中authenticationFailureUrl是認證失敗的頁面。

10) 如果需要一些頁面通過安全通道的話，添加下面的配置:

<bean id=”channelProcessingFilter” class=”net.sf.acegisecurity.securechannel.ChannelProcessingFilter”>
<property name=”channelDecisionManager”>
<ref bean=”channelDecisionManager”/>
</property>
<property name=”filterInvocationDefinitionSource”>
<value>
CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
\A/sec/administrator.*\Z=REQUIRES_SECURE_CHANNEL
\A/acegilogin.jsp.*\Z=REQUIRES_SECURE_CHANNEL
\A/j_acegi_security_check.*\Z=REQUIRES_SECURE_CHANNEL
\A.*\Z=REQUIRES_INSECURE_CHANNEL
</value>
</property>
</bean>

<bean id=”channelDecisionManager” class=”net.sf.acegisecurity.securechannel.ChannelDecisionManagerImpl”>
<property name=”channelProcessors”>
<list>
<ref bean=”secureChannelProcessor”/>
<ref bean=”insecureChannelProcessor”/>
</list>
</property>
</bean>
<bean id=”secureChannelProcessor” class=”net.sf.acegisecurity.securechannel.SecureChannelProcessor”/>
<bean id=”insecureChannelProcessor” class=”net.sf.acegisecurity.securechannel.InsecureChannelProcessor”/>

[缺少了什么？]
Acegi目前提供了兩種”secure object”，分別對頁面和方法進行安全認證管理，我這里介紹的只是利用
FilterSecurityInterceptor對訪問頁面的權限控制，除此之外，Acegi還提供了另外一個Interceptor–
MethodSecurityInterceptor，它結合runAsManager可實現(xiàn)對對象中的方法的權限控制，使用方法可參看Acegi自帶的文檔
和contact范例。

[最后要說的]
本來以為只是說明如何使用Acegi而已，應該非常簡單，但真正寫起來才發(fā)現(xiàn)想要條理清楚的理順所有需要的bean還是很
困難的，但愿我沒有遺漏太多東西，如果我的文章有什么遺漏或錯誤的話，還請參看Acegi自帶的quick-start范例，但請
注意，這個范例是不能直接拿來用的。

原文在這里：

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=54881

<property name="dialect">org.hibernate.dialect.Oracle9Dialect</property>
<property name="show_sql">true</property>
<property name="current_session_context_class">thread</property>
<!--Fetch Size 是設定JDBC的Statement讀取數(shù)據(jù)的時候每次從數(shù)據(jù)庫中取出的記錄條數(shù)-->
<property name="jdbc.fetch_size">20</property>
<!--Batch Size是設定對數(shù)據(jù)庫進行批量刪除，批量更新和批量插入的時候的批次大小，有點相當于設置Buffer緩沖區(qū)大小的意思-->
<property name="jdbc.batch_size ">20</property>
<property name="connection.username">HNMC</property>
<property name="connection.password">sundy</property>
<property name="connection.url">jdbc:oracle:thin:@192.168.0.20:1521:ora9</property>
<property name="connection.driver_class">oracle.jdbc.driver.OracleDriver</property>

<!--??在這種情況下，沒問題啊 -->
<property name="c3p0.timeout">60</property>
<property name="c3p0.idle_test_period">600</property>


<!--????

<!--<property name="c3p0.idle_test_period">120</property>-->
如改以下倆值，或他們差距很大：

<property name="c3p0.timeout">600</property>

<!--<property name="c3p0.idle_test_period">60</property>-->

當我啟動tomcat，運行程序后，空閑600后出現(xiàn)下列異常,但程序還照常運行

-->

<!--?

Hibernate里可以設置的屬性不多：
#c3p0-native property name hibernate configuration key
#c3p0.acquireIncrement hibernate.c3p0.acquire_increment
#c3p0.idleConnectionTestPeriod hibernate.c3p0.idle_test_period
#c3p0.initialPoolSize not available -- uses minimum size
#c3p0.maxIdleTime hibernate.c3p0.timeout
#c3p0.maxPoolSize hibernate.c3p0.max_size
#c3p0.maxStatements hibernate.c3p0.max_statements
#c3p0.minPoolSize hibernate.c3p0.min_size
#c3p0.testConnectionsOnCheckout hibernate.c3p0.validate hibernate 2.x only!

另外的屬性你需要配置c3p0.properties
比如：
c3p0.acquireRetryDelay=111
c3p0.acquireRetryAttempts=22
c3p0.breakAfterAcquireFailure=true

-->



<property name="hibernate.connection.provider_class">org.hibernate.connection.C3P0ConnectionProvider</property>
<property name="hibernate.c3p0.max_size">2</property>
<property name="hibernate.c3p0.min_size">2</property>
<property name="hibernate.c3p0.timeout">50000</property>
<property name="hibernate.c3p0.max_statements">100</property>
<property name="hibernate.c3p0.idle_test_period">3000</property>
<property name="hibernate.c3p0.acquire_increment">2</property>

<!-- 另<property name="hibernate.c3p0.validate">false</property>確實在hibernate中不可設置??-->
<property name="hibernate.c3p0.validate">false</property>


<!--C3P0 setting-->

<property name="c3p0.max_size">20</property>
<property name="c3p0.min_size">5</property>
<!--獲取連接的等待時間-->
<property name="c3p0.timeout">3600</property>
<property name="c3p0.max_statements">100</property>
<!--每隔3600毫秒測試連接是否可以正常使用-->
<property name="c3p0.idle_test_period">3600</property>
<property name="c3p0.acquire_increment">2</property>

<mapping resource="com/sundy/hnmc/beans/AccountBean.hbm.xml"/>
</session-factory>
</hibernate-configuration>



另一個設置
?<!--?數(shù)據(jù)源配置?-->
????<bean?id="dataSource"?class="com.mchange.v2.c3p0.ComboPooledDataSource"?destroy-method="close">
??????<property?name="driverClass">
????????<value>org.gjt.mm.mysql.Driver</value>
??????</property>
??????<property?name="jdbcUrl">
????????<value>jdbc:mysql://localhost/tycho?useUnicode=true&amp;characterEncoding=utf-8</value>
??????</property>
??????<property?name="properties">
????????<props>
????????????<prop?key="hibernate.hbm2ddl.auto">update</prop>?
????????????<prop?key="c3p0.minPoolSize">1</prop>?
????????????<prop?key="hc3p0.maxPoolSize">10</prop>?
????????????<prop?key="hc3p0.timeout">60</prop>?
????????????<prop?key="c3p0.max_statement">50</prop>?
????????????<prop?key="c3p0.testConnectionOnCheckout">true</prop>?
????????????<prop?key="hibernate.c3p0.testConnectionOnCheckout">false</prop>
????????????<prop?key="user">root</prop>?
????????????<prop?key="password">root</prop>
????????</props>
??????</property>
????</bean>



<property name="hibernate.connection.provider_class">org.hibernate.connection.C3P0ConnectionProvider</property>
<property name="hibernate.c3p0.max_size">20</property>
<property name="hibernate.c3p0.min_size">5</property>
<property name="hibernate.c3p0.timeout">120</property>
<property name="hibernate.c3p0.max_statements">100</property>
<property name="hibernate.c3p0.idle_test_period">120</property>
<property name="hibernate.c3p0.acquire_increment">2</property>

?

?

?

?

1. LoadModule?proxy_module?modules/mod_proxy.so ??
2. LoadModule?proxy_ajp_module?modules/mod_proxy_ajp.so ??
3. LoadModule?proxy_balancer_module?modules/mod_proxy_balancer.so ??
4. ??
5. ProxyPass?/admin?balancer://tomcatcluster/admin? lbmethod = byrequests ? stickysession = JSESSIONID ? nofailover = Off ? timeout = 5 ? maxattempts = 3 ??
6. ProxyPassReverse?/admin?balancer://tomcatcluster/admin ??
7. ??
8. < Proxy ?balancer://tomcatcluster > ??
9. BalancerMember?ajp://localhost:8009? route = web1 ??
10. BalancerMember?ajp://localhost:10009? smax = 10 ? route = web2 ??
11. BalancerMember?ajp://localhost:11009? route = web3 ??
12. BalancerMember?ajp://localhost:12009? smax = 10 ? route = web4 ??
13. </ Proxy > ??

類的初始化和對象初始化是 JVM 管理的類型生命周期中非常重要的兩個環(huán)節(jié)，Google 了一遍網絡，有關類裝載機制的文章倒是不少，然而類初始化和對象初始化的文章并不多，特別是從字節(jié)碼和 JVM 層次來分析的文章更是鮮有所見。

本文主要對類和對象初始化全過程進行分析，通過一個實際問題引入，將源代碼轉換成 JVM 字節(jié)碼后，對 JVM 執(zhí)行過程的關鍵點進行全面解析，并在文中穿插入了相關 JVM 規(guī)范和 JVM 的部分內部理論知識，以理論與實際結合的方式介紹對象初始化和類初始化之間的協(xié)作以及可能存在的沖突問題。

問題引入

近日我在調試一個枚舉類型的解析器程序，該解析器是將數(shù)據(jù)庫內一萬多條枚舉代碼裝載到緩存中，為了實現(xiàn)快速定位枚舉代碼和具體枚舉類別的所有枚舉元素，該類在裝載枚舉代碼的同時對其采取兩種策略建立內存索引。由于該類是一個公共服務類，在程序各個層面都會使用到它，因此我將它實現(xiàn)為一個單例類。這個類在我調整類實例化語句位置之前運行正常，但當我把該類實例化語句調整到靜態(tài)初始化語句之前時，我的程序不再為我工作了。

下面是經過我簡化后的示例代碼：

package com.ccb.framework.enums;

import java.util.Collections;
import java.util.HashMap;
import java.util.Map;

public class CachingEnumResolver {
	//單態(tài)實例　一切問題皆由此行引起
	private static final CachingEnumResolver SINGLE_ENUM_RESOLVER = new
	CachingEnumResolver();
	/*MSGCODE->Category內存索引*/
	private static Map CODE_MAP_CACHE;
	static {
		CODE_MAP_CACHE = new HashMap();
		//為了說明問題,我在這里初始化一條數(shù)據(jù)
		CODE_MAP_CACHE.put("0","北京市");
	}
	
	//private, for single instance
	private CachingEnumResolver() {
		//初始化加載數(shù)據(jù)  引起問題，該方法也要負點責任
		initEnums();
	}
	
	/**
	 * 初始化所有的枚舉類型
	 */
	public static void initEnums() {		
		// ~~~~~~~~~問題從這里開始暴露 ~~~~~~~~~~~//
		if (null == CODE_MAP_CACHE) {
			System.out.println("CODE_MAP_CACHE為空,問題在這里開始暴露.");
			CODE_MAP_CACHE = new HashMap();
		}
		CODE_MAP_CACHE.put("1", "北京市");
		CODE_MAP_CACHE.put("2", "云南省");
		
		//..... other code...
	}
	
	public Map getCache() {
		return Collections.unmodifiableMap(CODE_MAP_CACHE);
	}
	
	/**
	 * 獲取單態(tài)實例
	 * 
	 * @return
	 */
	public static CachingEnumResolver getInstance() {
		return SINGLE_ENUM_RESOLVER;
	}
	
	public static void main(String[] args) {
		System.out.println(CachingEnumResolver.getInstance().getCache());
	}
}

想必大家看了上面的代碼后會感覺有些茫然，這個類看起來沒有問題啊，這的確屬于典型的餓漢式單態(tài)模式啊，怎么會有問題呢？

是的，他看起來的確沒有問題，可是如果將他 run 起來時，其結果是他不會為你正確 work。運行該類，它的執(zhí)行結果是：

CODE_MAP_CACHE為空,問題在這里開始暴露.
{0=北京市}

我的程序怎么會這樣？為什么在 initEnum() 方法里 CODE_MAP_CACHE 為空？為什么我輸出的 CODE_MAP_CACHE 內容只有一個元素，其它兩個元素呢？？？？！！

看到這里，如果是你在調試該程序，你此刻一定覺得很奇怪，難道是我的 Jvm 有問題嗎？非也！如果不是，那我的程序是怎么了？這絕對不是我想要的結果。可事實上無論怎么修改 initEnum() 方法都無濟于事，起碼我最初是一定不會懷疑到問題可能出在創(chuàng)建 CachingEnumResolver 實例這一環(huán)節(jié)上。正是因為我太相信我創(chuàng)建 CachingEnumResolver 實例的方法，加之對 Java 類初始化與對象實例化底層原理理解有所偏差，使我為此付出了三、四個小時--約半個工作日的大好青春。

那么問題究竟出在哪里呢？為什么會出現(xiàn)這樣的怪事呢？在解決這個問題之前，先讓我們來了解一下JVM的類和對象初始化的底層機制。

回頁首

類的生命周期

上圖展示的是類生命周期流向；在本文里，我只打算談談類的"初始化"以及"對象實例化"兩個階段。

回頁首

類初始化

類"初始化"階段，它是一個類或接口被首次使用的前階段中的最后一項工作，本階段負責為類變量賦予正確的初始值。

Java 編譯器把所有的類變量初始化語句和類型的靜態(tài)初始化器通通收集到 <clinit> 方法內，該方法只能被 Jvm 調用，專門承擔初始化工作。

除接口以外，初始化一個類之前必須保證其直接超類已被初始化，并且該初始化過程是由 Jvm 保證線程安全的。另外，并非所有的類都會擁有一個 <clinit>() 方法，在以下條件中該類不會擁有 <clinit>() 方法：

• 該類既沒有聲明任何類變量，也沒有靜態(tài)初始化語句；
• 該類聲明了類變量，但沒有明確使用類變量初始化語句或靜態(tài)初始化語句初始化；
• 該類僅包含靜態(tài) final 變量的類變量初始化語句，并且類變量初始化語句是編譯時常量表達式。

回頁首

對象初始化

在類被裝載、連接和初始化，這個類就隨時都可能使用了。對象實例化和初始化是就是對象生命的起始階段的活動，在這里我們主要討論對象的初始化工作的相關特點。

Java 編譯器在編譯每個類時都會為該類至少生成一個實例初始化方法--即 "<init>()" 方法。此方法與源代碼中的每個構造方法相對應，如果類沒有明確地聲明任何構造方法，編譯器則為該類生成一個默認的無參構造方法，這個默認的構造器僅僅調用父類的無參構造器，與此同時也會生成一個與默認構造方法對應的 "<init>()" 方法.

通常來說，<init>() 方法內包括的代碼內容大概為：調用另一個 <init>() 方法；對實例變量初始化；與其對應的構造方法內的代碼。

如果構造方法是明確地從調用同一個類中的另一個構造方法開始，那它對應的 <init>() 方法體內包括的內容為：一個對本類的 <init>() 方法的調用；對應用構造方法內的所有字節(jié)碼。

如果構造方法不是通過調用自身類的其它構造方法開始，并且該對象不是 Object 對象，那 <init>() 法內則包括的內容為：一個對父類 <init>() 方法的調用；對實例變量初始化方法的字節(jié)碼；最后是對應構造子的方法體字節(jié)碼。

如果這個類是 Object，那么它的 <init>() 方法則不包括對父類 <init>() 方法的調用。

回頁首

類的初始化時機

本文到目前為止，我們已經大概有了解到了類生命周期中都經歷了哪些階段，但這個類的生命周期的開始階段--類裝載又是在什么時候被觸發(fā)呢？類又是何時被初始化的呢？讓我們帶著這三個疑問繼續(xù)去尋找答案。

Java 虛擬機規(guī)范為類的初始化時機做了嚴格定義："initialize on first active use"--" 在首次主動使用時初始化"。這個規(guī)則直接影響著類裝載、連接和初始化類的機制--因為在類型被初始化之前它必須已經被連接，然而在連接之前又必須保證它已經被裝載了。

在與初始化時機相關的類裝載時機問題上，Java 虛擬機規(guī)范并沒有對其做嚴格的定義，這就使得 JVM 在實現(xiàn)上可以根據(jù)自己的特點提供采用不同的裝載策略。我們可以思考一下 Jboss AOP 框架的實現(xiàn)原理，它就是在對你的 class 文件裝載環(huán)節(jié)做了手腳--插入了 AOP 的相關攔截字節(jié)碼，這使得它可以對程序員做到完全透明化，哪怕你用 new 操作符創(chuàng)建出的對象實例也一樣能被 AOP 框架攔截--與之相對應的 Spring AOP，你必須通過他的 BeanFactory 獲得被 AOP 代理過的受管對象，當然 Jboss AOP 的缺點也很明顯--他是和 JBOSS 服務器綁定很緊密的，你不能很輕松的移植到其它服務器上。嗯~……，說到這里有些跑題了，要知道 AOP 實現(xiàn)策略足可以寫一本厚厚的書了，嘿嘿，就此打住。

說了這么多，類的初始化時機就是在"在首次主動使用時"，那么，哪些情形下才符合首次主動使用的要求呢？

首次主動使用的情形：

• 創(chuàng)建某個類的新實例時--new、反射、克隆或反序列化；
• 調用某個類的靜態(tài)方法時；
• 使用某個類或接口的靜態(tài)字段或對該字段賦值時（final字段除外）；
• 調用Java的某些反射方法時
• 初始化某個類的子類時
• 在虛擬機啟動時某個含有main()方法的那個啟動類。

除了以上幾種情形以外，所有其它使用JAVA類型的方式都是被動使用的，他們不會導致類的初始化。

回頁首

我的問題究竟出在哪里

好了，了解了JVM的類初始化與對象初始化機制后，我們就有了理論基礎，也就可以理性的去分析問題了。

下面讓我們來看看前面[清單一]的JAVA源代碼反組譯出的字節(jié)碼：

public class com.ccb.framework.enums.CachingEnumResolver extends
java.lang.Object{
static {};
  Code:
   0:	new	#2; //class CachingEnumResolver
   3:	dup
   4:	invokespecial	#14; //Method "<init>":()V  ①
   7:	putstatic	#16; //Field
   SINGLE_ENUM_RESOLVER:Lcom/ccb/framework/enums/CachingEnumResolver;
   10:	new	#18; //class HashMap              ②
   13:	dup
   14:	invokespecial	#19; //Method java/util/HashMap."<init>":()V
   17:	putstatic	#21; //Field CODE_MAP_CACHE:Ljava/util/Map;  
   20:	getstatic	#21; //Field CODE_MAP_CACHE:Ljava/util/Map;  
   23:	ldc	#23; //String 0
   25:	ldc	#25; //String 北京市
   27:	invokeinterface	#31,  3; //InterfaceMethod
   java/util/Map.put:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;   ③
   32:	pop
   33:	return

private com.ccb.framework.enums.CachingEnumResolver();
  Code:
   0:	aload_0
   1:	invokespecial	#34; //Method java/lang/Object."<init>":()V
   4:	invokestatic	#37; //Method initEnums:()V                  ④
   7:	return

public static void initEnums();
  Code:
   0:	getstatic	#21; //Field CODE_MAP_CACHE:Ljava/util/Map;    ⑤
   3:	ifnonnull	24
   6:	getstatic	#44; //Field java/lang/System.out:Ljava/io/PrintStream;
   9:	ldc	#46; //String CODE_MAP_CACHE為空,問題在這里開始暴露.
   11:	invokevirtual	#52; //Method
   java/io/PrintStream.println:(Ljava/lang/String;)V
   14:	new	#18; //class HashMap
   17:	dup
   18:	invokespecial	#19; //Method java/util/HashMap."<init>":()V      ⑥
   21:	putstatic	#21; //Field CODE_MAP_CACHE:Ljava/util/Map;
   24:	getstatic	#21; //Field CODE_MAP_CACHE:Ljava/util/Map;
   27:	ldc	#54; //String 1
   29:	ldc	#25; //String 北京市
   31:	invokeinterface	#31,  3; //InterfaceMethod
   java/util/Map.put:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;   ⑦
   36:	pop
   37:	getstatic	#21; //Field CODE_MAP_CACHE:Ljava/util/Map;
   40:	ldc	#56; //String 2
   42:	ldc	#58; //String 云南省
   44:	invokeinterface	#31,  3; //InterfaceMethod
   java/util/Map.put:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;    ⑧
   49:	pop
   50:	return

public java.util.Map getCache();
  Code:
   0:	getstatic	#21; //Field CODE_MAP_CACHE:Ljava/util/Map;
   3:	invokestatic	#66; //Method
   java/util/Collections.unmodifiableMap:(Ljava/util/Map;)Ljava/util/Map;
   6:	areturn

public static com.ccb.framework.enums.CachingEnumResolver getInstance();
  Code:
   0:	getstatic	#16; 
   //Field SINGLE_ENUM_RESOLVER:Lcom/ccb/framework/enums/CachingEnumResolver;   ⑨
   3:	areturn
}

如果上面［清單一］顯示，清單內容是在 JDK1.4 環(huán)境下的字節(jié)碼內容，可能這份清單對于很大部分兄弟來說確實沒有多少吸引力，因為這些 JVM 指令確實不像源代碼那樣漂亮易懂。但它的的確確是查找和定位問題最直接的辦法，我們想要的答案就在這份 JVM 指令清單里。

現(xiàn)在，讓我們對該類從類初始化到對象實例初始化全過程分析[清單一]中的代碼執(zhí)行軌跡。

如前面所述，類初始化是在類真正可用時的最后一項前階工作，該階段負責對所有類正確的初始化值，此項工作是線程安全的，JVM會保證多線程同步。

第１步：調用類初始化方法 CachingEnumResolver.<clinit>()，該方法對外界是不可見的，換句話說是 JVM 內部專用方法，<clinit>() 內包括了 CachingEnumResolver 內所有的具有指定初始值的類變量的初始化語句。要注意的是并非每個類都具有該方法，具體的內容在前面已有敘述。

第２步：進入 <clinit>() 方法內，讓我們看字節(jié)碼中的 "①" 行，該行與其上面兩行組合起來代表 new 一個 CachingEnumResolver 對象實例，而該代碼行本身是指調用 CachingEnumResolver 類的 <init>（）方法。每一個 Java 類都具有一個 <init>() 方法，該方法是 Java 編譯器在編譯時生成的，對外界不可見，<init>() 方法內包括了所有具有指定初始化值的實例變量初始化語句和java類的構造方法內的所有語句。對象在實例化時，均通過該方法進行初始化。然而到此步，一個潛在的問題已經在此埋伏好，就等著你來犯了。

第３步：讓我們順著執(zhí)行順序向下看，"④" 行，該行所在方法就是該類的構造器，該方法先調用父類的構造器 <init>() 對父對象進行初始化，然后調用 CachingEnumResolver.initEnum() 方法加載數(shù)據(jù)。

第４步："⑤" 行，該行獲取 "CODE_MAP_CACHE" 字段值，其運行時該字段值為 null。注意，問題已經開始顯現(xiàn)了。（作為程序員的你一定是希望該字段已經被初始化過了，而事實上它還沒有被初始化）。通過判斷，由于該字段為 NULL，因此程序將繼續(xù)執(zhí)行到 "⑥" 行，將該字段實例化為 HashMap()。

第５步：在 "⑦"、"⑧" 行，其功能就是為 "CODE_MAP_CACHE" 字段填入兩條數(shù)據(jù)。

第６步：退出對象初始化方法 <init>()，將生成的對象實例初始化給類字段 "SINGLE_ENUM_RESOLVER"。（注意，此刻該對象實例內的類變量還未初始化完全，剛才由 <init>() 調用 initEnum() 方法賦值的類變量 "CODE_MAP_CACHE" 是 <clinit>() 方法還未初始化字段，它還將在后面的類初始化過程再次被覆蓋）。

第７步：繼續(xù)執(zhí)行 <clinit>（）方法內的后繼代碼，"②" 行，該行對 "CODE_MAP_CACHE" 字段實例化為 HashMap 實例（注意：在對象實例化時已經對該字段賦值過了，現(xiàn)在又重新賦值為另一個實例，此刻，"CODE_MAP_CACHE"變量所引用的實例的類變量值被覆蓋，到此我們的疑問已經有了答案）。

第8步：類初始化完畢，同時該單態(tài)類的實例化工作也完成。

通過對上面的字節(jié)碼執(zhí)行過程分析，或許你已經清楚了解到導致錯誤的深層原因了，也或許你可能早已被上面的分析過程給弄得暈頭轉向了，不過也沒折，雖然我也可以從源代碼的角度來闡述問題，但這樣不夠深度，同時也會有僅為個人觀點、不足可信之嫌。

回頁首

如何解決

要解決上面代碼所存在的問題很簡單，那就是將 "SINGLE_ENUM_RESOLVER" 變量的初始化賦值語句轉移到 getInstance() 方法中去即可。換句話說就是要避免在類還未初始化完成時從內部實例化該類或在初始化過程中引用還未初始化的字段。

回頁首

寫在最后

靜下浮燥之心，仔細思量自己是否真的掌握了本文主題所引出的知識，如果您覺得您已經完全或基本掌握了，那么很好，在最后，我將前面的代碼稍做下修改，請思考下面兩組程序是否同樣會存在問題呢？

	public class CachingEnumResolver {
	public  static Map CODE_MAP_CACHE;
	static {
		CODE_MAP_CACHE = new HashMap();
		//為了說明問題,我在這里初始化一條數(shù)據(jù)
		CODE_MAP_CACHE.put("0","北京市");
		initEnums();
	}
	

	public class CachingEnumResolver {
		private static final CachingEnumResolver SINGLE_ENUM_RESOLVER;
		public  static Map CODE_MAP_CACHE;
		static {
			CODE_MAP_CACHE = new HashMap();
			//為了說明問題,我在這里初始化一條數(shù)據(jù)
			CODE_MAP_CACHE.put("0","北京市");
			SINGLE_ENUM_RESOLVER = new CachingEnumResolver();
			initEnums();
		}
	

最后，一點關于 JAVA 群體的感言：時下正是各種開源框架盛行時期，Spring 更是大行其道，吸引著一大批 JEE 開發(fā)者的眼球（我也是 fans 中的一員）。然而，讓我們仔細觀察一下--以 Spring 群體為例，在那么多的 Spring fans 當中，有多少人去研究過 Spring 源代碼？又有多少人對 Spring 設計思想有真正深入了解呢？當然，我是沒有資格以這樣的口吻來說事的，我只是想表明一個觀點--學東西一定要"正本清源"。

獻上此文，謹以共勉。