1、test.html 測試頁
<html>
<head>
<title>測試頁面</title>
<style>
.list {
border-top:1 solid #8A2BE2;
border-left:1 solid #8A2BE2;
border-right:1 solid #8A2BE2;
}
.list td {
border-bottom: 1 solid #8A2BE2;
}
</style>
<script>
function $(el) {
return document.getElementById(el);
}
function showWin(param) {
window.showModalDialog("dailog.htm", param, "dialogWidth:" +param.width +"px;dialogHeight:"+param.height+"px;center:yes;help:no;scroll:no;status:no;resizable:no");
}
function TB(tbid) {
this.tb = typeof(tbid) == "string"? $(tbid): tbid;
this.getValue = function(rowIndex, cellIndex){
var trs = this.tb.rows[rowIndex];
var _td = trs.cells[cellIndex];
return _td.innerText;
}
this.setValue = function(rowIndex, cellIndex, value) {
var _tr = this.tb.rows[rowIndex];
var _td = _tr.cells[cellIndex];
_td.innerText = value;
}
/********獲取行索引********/
this.findRowIndex = function(eventSrc) {
var _tr = eventSrc; //eventSrc事件源,必須在TD里獲事件源是TD或TR本身
while(_tr.tagName != "TR") {
_tr = _tr.parentNode;
}
var trs = this.tb.rows;
for(var i = 0; i < trs.length; i++){
if(_tr == trs[i]) return i;
}
}
}
function edit() {
var tb = new TB("data");
rIndex = tb.findRowIndex(event.srcElement);
$("updateRowIndex").value = rIndex;
$("userName").value = tb.getValue(rIndex, 1); //獲得姓名
$("sex").value = tb.getValue(rIndex, 2); //獲得性別
$("age").value = tb.getValue(rIndex, 3); //獲得年齡
showWin({title:"修改用戶信息", width:390, height:230, _div:"openWin",parent:window});
}
function saveAndUpdateView(){
var updateRowIndex = $("updateRowIndex").value;
var tb = new TB($f("data")); //$f()在dailog.html定義,獲到的table是父窗口中的table
tb.setValue(updateRowIndex, 1, $("userName").value);
tb.setValue(updateRowIndex, 2, $("sex").value);
tb.setValue(updateRowIndex, 3, $("age").value);
close();
}
</script>
</head>
<body>
<p style="margin-top:60px">
<center>
<table id="data" class="list" width="460px">
<tr>
<td>編號</td>
<td>用戶名</td>
<td>性別</td>
<td>年齡</td>
<td>操作</td>
</tr>
<tr>
<td>1</td>
<td>李永勝</td>
<td>男</td>
<td>27</td>
<td><span style="background:#FAEBD7;cursor:hand" onclick="edit();"> 修改 </span></td>
</tr>
<tr>
<td>2</td>
<td>林兄</td>
<td>男</td>
<td>27</td>
<td><span style="background:#FAEBD7;cursor:hand" onclick="edit();"> 修改 </span></td>
</tr>
<tr>
<td>3</td>
<td>葉兄</td>
<td>男</td>
<td>23</td>
<td><span style="background:#FAEBD7;cursor:hand" onclick="edit();"> 修改 </span></td>
</tr>
</table>
</center>
</p>
<!---彈出窗口顯示的內容---->
<div id="openWin" style="display:none;">
<form>
<fieldSet>
<legend>修改用戶</legend>
<table>
<tr>
<td>用戶名</td><td><input type="text" id="userName"/></td>
</tr>
<tr>
<td>性別</td><td><input type="text" id="sex"/></td>
</tr>
<tr>
<td>年齡</td><td><input type="text" id="age"/></td>
</tr>
</table>
</fieldSet>
<input type="hidden" id="updateRowIndex"/>
</form>
<span style="background:#FAEBD7;cursor:hand" onclick="saveAndUpdateView();"> 修改 </span>
</div>
</body>
</html>
2、dailog.html 窗口原型
<html>
<head>
<script>
var param = window.dialogArguments; //傳過來的模式對話框窗口參數
document.title = param.title; //窗口標題,必須在窗口創建前實現s
/********將父窗口的js加載進來********/
var scripts = param.parent.document.scripts;
var _head = document.getElementsByTagName("head")[0];
for(var n = 0; n < scripts.length; n++) {
if(scripts[n].src) {
var _script = newEl("script");
_script.src = scripts[n].src;
bind(_head, _script);
}else{//加載直接在html文檔中寫的script
var _script = newEl("script");
_script.text = scripts[n].text;
bind(_head, _script);
}
}
/*******根據ID獲得父窗口的元素*********/
function $f(el) {
return param.parent.document.getElementById(el);
}
/***********創建一個HTML元素*******/
function newEl(tagName) {
return document.createElement(tagName);
}
/***********追加元素***************/
function bind(ower, child) {
ower.appendChild(child);
}
/*******在瀏覽器完成對象的裝載后立即觸發*********/
window.onload = function() {
var winDiv;
if(typeof(param._div) == "string") {
winDiv = param.parent.document.getElementById(param._div); //父窗口window對象,因為param._div對象在父窗口
}else{//直接傳對象過來
winDiv = param._div;
}
$("mainDiv").innerHTML = winDiv.innerHTML; //將DIV內容在彈出窗口中渲染
}
</script>
</head>
<body>
<center>
<div id="mainDiv" style="margin-top:20px;width:90%"></div>
</center>
</body>
</html>
轉自http://www.aygfsteel.com/flyffa/archive/2006/12/14/87722.html
基本方法:
基本的方法,網上到處都是,在 java 中就是在 web.xml 注冊一個 Listener ,如下:
<listener>
<listener-class>xp.web.SessionCounter</listener-class>
</listener>
SessionCounter.java 實現 javax.servlet.http.HttpSessionListener 接口,分別在 sessionCreated 方法和 sessionDestroyed 方法中處理 session 數目。
這樣的方法有一定的問題:
1 、對于真正從網頁訪問的和搜索引擎的 spider 無法區分。
2 、當 Tomcat 重啟時,加載了上次持久化的 session 時,無法準確計算在線數。
第二個問題我們可以不予考慮,這是 tomcat 容器實現不標準的問題,我們要解決的是的第一個問題,如何知道你的訪問的是真實的。
用 js 繞過搜索引擎 :
做過 pv 統計的都知道,可以用 script 的方式得到你真實的 pageView 數目,我們現在要做的就是這樣的一件事情,我們在所有的頁面都加入一段話:
<script type="text/javascript">
document.write ("<iframe src='/sessionCountServlet' width=0 height=0 frameborder=no border=0 MARGINWIDTH=0 MARGINHEIGHT=0 SCROLLING=no></iframe>");
</script>
然后我們寫上一個 servlet 來記錄這些真正的訪問者。
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class SessionCounterServlet extends HttpServlet {
public SessionCounterServlet() {
super();
}
public void doGet(HttpServletRequest request,
HttpServletResponse response) throws IOException,
ServletException {
process(request, response);
}
public void doPost(HttpServletRequest request,
HttpServletResponse response) throws IOException,
ServletException {
process(request, response);
}
public void process(HttpServletRequest request,
HttpServletResponse response) throws IOException,
ServletException {
SessionCounter.put(request.getSession().getId());
}
}
我們可以看到這個 servlet 只是做了一件事情,在 process 里面做了 SessionCounter.put(request.getSession().getId()); 這個動作。
我們來看看我們的 SessionCounter 做了些什么:
import javax.servlet.http.*;
import java.util.Hashtable;
public class SessionCounter implements HttpSessionListener {
public SessionCounter() {
}
public static Hashtable m_real = new Hashtable();
private static long count = 0;
public void sessionCreated(HttpSessionEvent e) {
count++;
}
public void sessionDestroyed(HttpSessionEvent e) {
if (count > 0) {
count--;
}
m_real.remove(e.getSession().getId());
}
public static long getSessionCount() {
return count;
}
public static void put(String sessionId){
m_real.put(sessionId,"1");
}
public static int getRealCount(){
return m_real.size();
}
}
我們記錄了一個靜態的 hash 表來記錄激活狀態的 sessionid ,并在 session 銷毀的時候將這個 sessionid 置為空。
怎么把 servlet 配置到 web 應用中我就不羅唆了。
這部分的內容基本與Hibernate一致.JPA同樣支持3種類型的繼承形式:
1.Single Table Strategy ,單表策略,一張表包含基類與子類的所有數據,很多情況下都是采用這樣的冗余設計,通過一個discriminator來區分
2.Table Per Class Strategy ,每個子類對應一張表,每張表都擁有基類的屬性
3.Join Strategy ,仍然是每個子類對應一張表,但此表中不包含基類的屬性,僅僅是此子類的擴展屬性,共享基類的屬性
以一個例子來說明3種情況:
一.單表策略
比如Pet作為基類,Cat和Dog繼承此類并擁有自己的擴展屬性,如:
package com.denny_blue.ejb3.inheritance;
import java.io.Serializable;
import javax.persistence.DiscriminatorColumn;
import javax.persistence.DiscriminatorType;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Inheritance;
import javax.persistence.InheritanceType;
@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "animal_type", discriminatorType = DiscriminatorType.STRING)
public class Pet implements Serializable {
private int id;
private String name;
private double weight;
public Pet() {
}
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public double getWeight() {
return weight;
}
public void setWeight(double weight) {
this.weight = weight;
}
}
Pet類值的注意的就是通過@Inheritance(strategy = InheritanceType.SINGLE_TABLE)確定采用單表策略,通過@DiscriminatorColumn確定了標志值的字段和類型,我想熟悉hibernate的朋友對這些都應該很熟悉.然后是兩個子類:
//Cat.java
package com.denny_blue.ejb3.inheritance;
import javax.persistence.DiscriminatorColumn;
import javax.persistence.DiscriminatorType;
import javax.persistence.DiscriminatorValue;
import javax.persistence.Entity;
import javax.persistence.Inheritance;
import javax.persistence.InheritanceType;
@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(discriminatorType = DiscriminatorType.STRING)
@DiscriminatorValue("cat")
public class Cat extends Pet {
private String HairBall;
public String getHairBall() {
return HairBall;
}
public void setHairBall(String hairBall) {
HairBall = hairBall;
}
}
//Dog.java
package com.denny_blue.ejb3.inheritance;
import javax.persistence.DiscriminatorColumn;
import javax.persistence.DiscriminatorType;
import javax.persistence.DiscriminatorValue;
import javax.persistence.Entity;
import javax.persistence.Inheritance;
import javax.persistence.InheritanceType;
@Entity
@Inheritance(strategy=InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(discriminatorType=DiscriminatorType.STRING)
@DiscriminatorValue("dog")
public class Dog extends Pet {
private String trick;
public String getTrick() {
return trick;
}
public void setTrick(String trick) {
this.trick = trick;
}
}
兩個子類最值的關注的就是@DiscriminatorValue注釋,比如Cat的此值為cat,意味著當Cat類型的Entity存入數據庫時,JPA將自動把cat的值賦給animal_type字段,Dog的值則為dog,由此就可以在同一張表中區分開兩個不同的子類.
二.Table per Class
采用Table Per Class策略的話,每個子類都將單獨建表,并且都獨立擁有基類中的所有屬性,互相之間不共享,在我們的例子中所要進行的修改很小,像這樣:
//基類
@Entity
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
public class Pet implements Serializable {
private int id;
private String name;
private double weight;
........
//子類:不需要任何設置
@Entity
public class Dog extends Pet {
private String trick;
.......
.......
三.Join策略
每個子類同樣獨立建表,基類也獨立建表,只不過所有的子類的表中只有擴展屬性,他們共享基類的表,在我們的例子中修改下即可:
//基類
@Entity
@Inheritance(strategy = InheritanceType.JOINED)
public class Pet implements Serializable {
private int id;
private String name;
private double weight;
........
//子類
@Entity
@Inheritance(strategy = InheritanceType.JOINED)
public class Dog extends Pet {
private String trick;
.......
.......
這部分的內容實在沒什么新意,與hibernate完全一致.JAVA EE5向spring和hibernate借鑒了太多東西.
{}
Oracle sql 性能優化調整
1. 選用適合的ORACLE優化器
ORACLE的優化器共有3種:
a. RULE (基于規則)
b. COST (基于成本)
c. CHOOSE (選擇性)
設置缺省的優化器,可以通過對init.ora文件中OPTIMIZER_MODE參數的各種聲明,如RULE,COST,CHOOSE,ALL_ROWS,FIRST_ROWS . 你當然也在SQL句級或是會話(session)級對其進行覆蓋。
為了使用基于成本的優化器(CBO, Cost-Based Optimizer) , 你必須經常運行analyze 命令,以增加數據庫中的對象統計信息(object statistics)的準確性。
如果數據庫的優化器模式設置為選擇性(CHOOSE),那么實際的優化器模式將和是否運行過analyze命令有關。 如果table已經被analyze過, 優化器模式將自動成為CBO , 反之,數據庫將采用RULE形式的優化器。
在缺省情況下,ORACLE采用CHOOSE優化器,為了避免那些不必要的全表掃描(full table scan) , 你必須盡量避免使用CHOOSE優化器,而直接采用基于規則或者基于成本的優化器。
2. 訪問Table的方式ORACLE 采用兩種訪問表中記錄的方式
a. 全表掃描
全表掃描就是順序地訪問表中每條記錄。 ORACLE采用一次讀入多個數據塊(database block)的方式優化全表掃描。
b. 通過ROWID訪問表
你可以采用基于ROWID的訪問方式情況,提高訪問表的效率, ROWID包含了表中記錄的物理位置信息……ORACLE采用索引(INDEX)實現了數據和存放數據的物理位置(ROWID)之間的聯系。 通常索引提供了快速訪問ROWID的方法,因此那些基于索引列的查詢就可以得到性能上的提高。
3. 共享SQL語句
為了不重復解析相同的SQL語句,在第一次解析之后, ORACLE將SQL語句存放在內存中。這塊位于系統全局區域SGA(system global area)的共享池(shared buffer pool)中的內存可以被所有的數據庫用戶共享。 因此,當你執行一個SQL語句(有時被稱為一個游標)時,如果它和之前的執行過的語句完全相同, ORACLE就能很快獲得已經被解析的語句以及最好的執行路徑。 ORACLE的這個功能大大地提高了SQL的執行性能并節省了內存的使用。
可惜的是ORACLE只對簡單的表提供高速緩沖(cache buffering) ,這個功能并不適用于多表連接查詢。數據庫管理員必須在init.ora中為這個區域設置合適的參數,當這個內存區域越大,就可以保留更多的語句,當然被共享的可能性也就越大了。當你向ORACLE 提交一個SQL語句,ORACLE會首先在這塊內存中查找相同的語句。
這里需要注明的是,ORACLE對兩者采取的是一種嚴格匹配,要達成共享,SQL語句必須完全相同(包括空格,換行等)。
共享的語句必須滿足三個條件:
A. 字符級的比較:
當前被執行的語句和共享池中的語句必須完全相同。
例如:
SELECT * FROM EMP;
和下列每一個都不同
SELECT * from EMP;
Select * From Emp;
SELECT * FROM EMP;
B. 兩個語句所指的對象必須完全相同:
例如:
用戶 對象名 如何訪問
Jack sal_limit private synonym
Work_city public synonym
Plant_detail public synonym
Jill sal_limit private synonym
Work_city public synonym
Plant_detail table owner
考慮一下下列SQL語句能否在這兩個用戶之間共享。
C. 兩個SQL語句中必須使用相同的名字的綁定變量(bind variables)
例如:第一組的兩個SQL語句是相同的(可以共享),而第二組中的兩個語句是不同的(即使在運行時,賦于不同的綁定變量相同的值)
a.
selectpin,namefrompeoplewherepin=:blk1.pin;
selectpin,namefrompeoplewherepin=:blk1.pin;
b.
selectpin,namefrompeoplewherepin=:blk1.ot_ind;
selectpin,namefrompeoplewherepin=:blk1.ov_ind;
4. 選擇最有效率的表名順序(只在基于規則的優化器中有效)
ORACLE的解析器按照從右到左的順序處理FROM子句中的表名,因此FROM子句中寫在最后的表(基礎表 driving table)將被最先處理。 在FROM子句中包含多個表的情況下,你必須選擇記錄條數最少的表作為基礎表。當ORACLE處理多個表時, 會運用排序及合并的方式連接它們。首先,掃描第一個表(FROM子句中最后的那個表)并對記錄進行派序,然后掃描第二個表(FROM子句中最后第二個表),最后將所有從第二個表中檢索出的記錄與第一個表中合適記錄進行合并。
例如:
表 TAB1 16,384 條記錄
表 TAB2 1 條記錄
選擇TAB2作為基礎表 (最好的方法)
select count(*) from tab1,tab2 執行時間0.96秒
選擇TAB2作為基礎表 (不佳的方法)
select count(*) from tab2,tab1 執行時間26.09秒
如果有3個以上的表連接查詢, 那就需要選擇交叉表(intersection table)作為基礎表, 交叉表是指那個被其他表所引用的表。
例如: EMP表描述了LOCATION表和CATEGORY表的交集。
SELECT *
FROM LOCATION L ,
CATEGORY C,
EMP E
WHERE E.EMP_NO BETWEEN 1000 AND 2000
AND E.CAT_NO = C.CAT_NO
AND E.LOCN = L.LOCN
將比下列SQL更有效率
SELECT *
FROM EMP E ,
LOCATION L ,
CATEGORY C
WHERE E.CAT_NO = C.CAT_NO
AND E.LOCN = L.LOCN
AND E.EMP_NO BETWEEN 1000 AND 2000
1. WHERE子句中的連接順序。
ORACLE采用自下而上的順序解析WHERE子句,根據這個原理,表之間的連接必須寫在其他WHERE條件之前, 那些可以過濾掉最大數量記錄的條件必須寫在WHERE子句的末尾。
例如:
(低效,執行時間156.3秒)
SELECT…
FROMEMPE
WHERESAL>50000
ANDJOB=‘MANAGER’
AND25<(SELECTCOUNT(*)FROMEMP
WHEREMGR=E.EMPNO);
(高效,執行時間10.6秒)
SELECT…
FROMEMPE
WHERE25<(SELECTCOUNT(*)FROMEMP
WHEREMGR=E.EMPNO)
ANDSAL>50000
ANDJOB=‘MANAGER’;
2. SELECT子句中避免使用 ‘ * ’
當你想在SELECT子句中列出所有的COLUMN時,使用動態SQL列引用 ‘*’ 是一個方便的方法。不幸的是,這是一個非常低效的方法。 實際上,ORACLE在解析的過程中, 會將‘*’ 依次轉換成所有的列名, 這個工作是通過查詢數據字典完成的, 這意味著將耗費更多的時間。
3. 減少訪問數據庫的次數
當執行每條SQL語句時, ORACLE在內部執行了許多工作: 解析SQL語句, 估算索引的利用率, 綁定變量 , 讀數據塊等等。 由此可見, 減少訪問數據庫的次數 , 就能實際上減少ORACLE的工作量。
例如,以下有三種方法可以檢索出雇員號等于0342或0291的職員。
方法1 (最低效)
SELECTEMP_NAME,SALARY,GRADE
FROMEMP
WHEREEMP_NO=342;
SELECTEMP_NAME,SALARY,GRADE
FROMEMP
WHEREEMP_NO=291;
方法2 (次低效)
DECLARE
CURSORC1(E_NONUMBER)IS
SELECTEMP_NAME,SALARY,GRADE
FROMEMP
WHEREEMP_NO=E_NO;
BEGIN
OPENC1(342);
FETCHC1INTO…,..,..;
OPENC1(291);
FETCHC1INTO…,..,..;
CLOSEC1;
END;
方法3 (高效)
以下是引用片段:
SELECTA.EMP_NAME,A.SALARY,A.GRADE,
B.EMP_NAME,B.SALARY,B.GRADE
FROMEMPA,EMPB
WHEREA.EMP_NO=342
ANDB.EMP_NO=291;
注意:
在SQL*Plus , SQL*Forms和Pro*C中重新設置ARRAYSIZE參數, 可以增加每次數據庫訪問的檢索數據量 ,建議值為200.
4. 使用DECODE函數來減少處理時間
使用DECODE函數可以避免重復掃描相同記錄或重復連接相同的表。
例如:
SELECTCOUNT(*),SUM(SAL)
FROM EMP
WHEREDEPT_NO=0020
ANDENAMELIKE ‘SMITH%’;
SELECTCOUNT(*),SUM(SAL)
FROM EMP
WHEREDEPT_NO=0030
ANDENAMELIKE ‘SMITH%’;
你可以用DECODE函數高效地得到相同結果
SELECTCOUNT(DECODE(DEPT_NO,0020,’X’,NULL))D0020_COUNT,
COUNT(DECODE(DEPT_NO,0030,’X’,NULL))D0030_COUNT,
SUM(DECODE(DEPT_NO,0020,SAL,NULL))D0020_SAL,
SUM(DECODE(DEPT_NO,0030,SAL,NULL))D0030_SAL
FROMEMPWHEREENAMELIKE‘SMITH%’;
類似的,DECODE函數也可以運用于GROUP BY 和ORDER BY子句中。
5. 整合簡單,無關聯的數據庫訪問
如果你有幾個簡單的數據庫查詢語句,你可以把它們整合到一個查詢中(即使它們之間沒有關系)
例如:
SELECTNAME
FROMEMP
WHEREEMP_NO=1234;
SELECTNAME
FROMDPT
WHEREDPT_NO=10;
SELECTNAME
FROMCAT
WHERECAT_TYPE=‘RD’;
上面的3個查詢可以被合并成一個:
SELECTE.NAME,D.NAME,C.NAME
FROMCATC,DPTD,EMPE,DUALX
WHERENVL(‘X’,X.DUMMY)=NVL(‘X’,E.ROWID(+))
ANDNVL(‘X’,X.DUMMY)=NVL(‘X’,D.ROWID(+))
ANDNVL(‘X’,X.DUMMY)=NVL(‘X’,C.ROWID(+))
ANDE.EMP_NO(+)=1234
ANDD.DEPT_NO(+)=10
ANDC.CAT_TYPE(+)=‘RD’;
1. 刪除重復記錄
最高效的刪除重復記錄方法 ( 因為使用了ROWID)
DELETE FROM EMP E
WHERE E.ROWID > (SELECT MIN(X.ROWID)
FROM EMP X
WHERE X.EMP_NO = E.EMP_NO);
2. 用TRUNCATE替代DELETE
當刪除表中的記錄時,在通常情況下, 回滾段(rollback segments ) 用來存放可以被恢復的信息。 如果你沒有COMMIT事務,ORACLE會將數據恢復到刪除之前的狀態(準確地說是恢復到執行刪除命令之前的狀況)
而當運用TRUNCATE時, 回滾段不再存放任何可被恢復的信息。當命令運行后,數據不能被恢復。因此很少的資源被調用,執行時間也會很短。
(譯者按: TRUNCATE只在刪除全表適用,TRUNCATE是DDL不是DML)
3. 盡量多使用COMMIT
只要有可能,在程序中盡量多使用COMMIT, 這樣程序的性能得到提高,需求也會因為COMMIT所釋放的資源而減少:COMMIT所釋放的資源:
a. 回滾段上用于恢復數據的信息。
b. 被程序語句獲得的鎖
c. redo log buffer 中的空間
d. ORACLE為管理上述3種資源中的內部花費
(譯者按: 在使用COMMIT時必須要注意到事務的完整性,現實中效率和事務完整性往往是魚和熊掌不可得兼)
4. 計算記錄條數
和一般的觀點相反, count(*) 比count(1)稍快 , 當然如果可以通過索引檢索,對索引列的計數仍舊是最快的。 例如 COUNT(EMPNO)
(譯者按: 在CSDN論壇中,曾經對此有過相當熱烈的討論, 作者的觀點并不十分準確,通過實際的測試,上述三種方法并沒有顯著的性能差別)
5. 用Where子句替換HAVING子句
避免使用HAVING子句, HAVING 只會在檢索出所有記錄之后才對結果集進行過濾。 這個處理需要排序,總計等操作。 如果能通過WHERE子句限制記錄的數目,那就能減少這方面的開銷。
例如:
低效
SELECTREGION,AVG(LOG_SIZE)
FROMLOCATION
GROUPBYREGION
HAVINGREGIONREGION!=‘SYDNEY’
ANDREGION!=‘PERTH’
高效
SELECTREGION,AVG(LOG_SIZE)
FROMLOCATION
WHEREREGIONREGION!=‘SYDNEY’
ANDREGION!=‘PERTH’
GROUPBYREGION
(譯者按: HAVING 中的條件一般用于對一些集合函數的比較,如COUNT() 等等。 除此而外,一般的條件應該寫在WHERE子句中)
6. 減少對表的查詢
在含有子查詢的SQL語句中,要特別注意減少對表的查詢。
例如:
低效
SELECTTAB_NAME
FROMTABLES
WHERETAB_NAME=(SELECTTAB_NAME
FROMTAB_COLUMNS
WHEREVERSION=604)
AND DB_VER=(SELECTDB_VER
FROMTAB_COLUMNS
WHEREVERSION=604)
高效
SELECTTAB_NAME
FROMTABLES
WHERE(TAB_NAME,DB_VER)
=(SELECTTAB_NAME,DB_VER)
FROMTAB_COLUMNS
WHEREVERSION=604)
Update 多個Column 例子:
低效:
UPDATEEMP
SETEMP_CAT=(SELECTMAX(CATEGORY)FROMEMP_CATEGORIES)
1. 使用表的別名(Alias)
當在SQL語句中連接多個表時, 請使用表的別名并把別名前綴于每個Column上。這樣一來,就可以減少解析的時間并減少那些由Column歧義引起的語法錯誤。
(Column歧義指的是由于SQL中不同的表具有相同的Column名,當SQL語句中出現這個Column時,SQL解析器無法判斷這個Column的歸屬)
2. 用EXISTS替代IN
在許多基于基礎表的查詢中,為了滿足一個條件,往往需要對另一個表進行聯接。在這種情況下, 使用EXISTS(或NOT EXISTS)通常將提高查詢的效率。
低效:
SELECT*
FROMEMP(基礎表)
WHEREEMPNO>0
ANDDEPTNOIN(SELECTDEPTNO
FROMDEPT
WHERELOC=‘MELB’)
高效:
SELECT*
FROMEMP(基礎表)
WHEREEMPNO>0
ANDEXISTS(SELECT‘X’
FROMDEPT
WHEREDEPT.DEPTNO=EMP.DEPTNO
ANDLOC=‘MELB’)
(相對來說,用NOT EXISTS替換NOT IN 將更顯著地提高效率,下面將指出)
3. 用NOT EXISTS替代NOT IN
在子查詢中,NOT IN子句將執行一個內部的排序和合并。 無論在哪種情況下,NOT IN都是最低效的 (因為它對子查詢中的表執行了一個全表遍歷)。 為了避免使用NOT IN ,我們可以把它改寫成外連接(Outer Joins)或NOT EXISTS.
例如:
SELECT…
FROMEMP
WHEREDEPT_NONOTIN(SELECTDEPT_NO
FROMDEPT
WHEREDEPT_CAT=’A’);
為了提高效率。改寫為:
(方法一: 高效)
SELECT….
FROMEMPA,DEPTB
WHEREA.DEPT_NO=B.DEPT(+)
ANDB.DEPT_NOISNULL
ANDB.DEPT_CAT(+)=‘A’
1. 用EXPLAIN PLAN 分析SQL語句
EXPLAIN PLAN 是一個很好的分析SQL語句的工具,它甚至可以在不執行SQL的情況下分析語句。 通過分析,我們就可以知道ORACLE是怎么樣連接表,使用什么方式掃描表(索引掃描或全表掃描)以及使用到的索引名稱。
你需要按照從里到外,從上到下的次序解讀分析的結果。 EXPLAIN PLAN分析的結果是用縮進的格式排列的, 最內部的操作將被最先解讀, 如果兩個操作處于同一層中,帶有最小操作號的將被首先執行。
NESTED LOOP是少數不按照上述規則處理的操作, 正確的執行路徑是檢查對NESTED LOOP提供數據的操作,其中操作號最小的將被最先處理。
通過實踐, 感到還是用SQLPLUS中的SET TRACE 功能比較方便。
舉例:
SQL> list
1 SELECT *
2 FROM dept, emp
3* WHERE emp.deptno = dept.deptno
SQL> set autotrace traceonly /*traceonly 可以不顯示執行結果*/
SQL> /
14 rows selected.
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 NESTED LOOPS
2 1 TABLE ACCESS (FULL) OF 'EMP'
3 1 TABLE ACCESS (BY INDEX ROWID) OF 'DEPT'
4 3 INDEX (UNIQUE SCAN) OF 'PK_DEPT' (UNIQUE)
Statistics
----------------------------------------------------------
0 recursive calls
2 db block gets
30 consistent gets
0 physical reads
0 redo size
2598 bytes sent via SQL*Net to client
503 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
14 rows processed
通過以上分析,可以得出實際的執行步驟是:
1. TABLE ACCESS (FULL) OF 'EMP'
2. INDEX (UNIQUE SCAN) OF 'PK_DEPT' (UNIQUE)
3. TABLE ACCESS (BY INDEX ROWID) OF 'DEPT'
4. NESTED LOOPS (JOINING 1 AND 3)
注: 目前許多第三方的工具如TOAD和ORACLE本身提供的工具如OMS的SQL Analyze都提供了極其方便的EXPLAIN PLAN工具。也許喜歡圖形化界面的朋友們可以選用它們。
2. 用索引提高效率
索引是表的一個概念部分,用來提高檢索數據的效率。 實際上,ORACLE使用了一個復雜的自平衡B-tree結構。 通常,通過索引查詢數據比全表掃描要快。 當ORACLE找出執行查詢和Update語句的最佳路徑時, ORACLE優化器將使用索引。 同樣在聯結多個表時使用索引也可以提高效率。 另一個使用索引的好處是,它提供了主鍵(primary key)的唯一性驗證。
除了那些LONG或LONG RAW數據類型, 你可以索引幾乎所有的列。 通常, 在大型表中使用索引特別有效。 當然,你也會發現, 在掃描小表時,使用索引同樣能提高效率。
雖然使用索引能得到查詢效率的提高,但是我們也必須注意到它的代價。 索引需要空間來存儲,也需要定期維護, 每當有記錄在表中增減或索引列被修改時, 索引本身也會被修改。 這意味著每條記錄的INSERT , DELETE , UPDATE將為此多付出4 , 5 次的磁盤I/O . 因為索引需要額外的存儲空間和處理,那些不必要的索引反而會使查詢反應時間變慢。
定期的重構索引是有必要的。
ALTER INDEX REBUILD
3. 索引的操作
ORACLE對索引有兩種訪問模式。
索引唯一掃描 ( INDEX UNIQUE SCAN)
大多數情況下, 優化器通過WHERE子句訪問INDEX.
表LODGING有兩個索引 : 建立在LODGING列上的唯一性索引LODGING_PK和建立在MANAGER列上的非唯一性索引LODGING$MANAGER.
SELECT*
FROMLODGING
WHERELODGING=‘ROSEHILL’;
在內部 , 上述SQL將被分成兩步執行, 首先 , LODGING_PK 索引將通過索引唯一掃描的方式被訪問 , 獲得相對應的ROWID, 通過ROWID訪問表的方式執行下一步檢索。
如果被檢索返回的列包括在INDEX列中,ORACLE將不執行第二步的處理(通過ROWID訪問表)。 因為檢索數據保存在索引中, 單單訪問索引就可以完全滿足查詢結果。
下面SQL只需要INDEX UNIQUE SCAN 操作。
SELECTLODGING
FROMLODGING
WHERELODGING=‘ROSEHILL’;
索引范圍查詢(INDEX RANGE SCAN)
適用于兩種情況:
1. 基于一個范圍的檢索
2. 基于非唯一性索引的檢索
例1:
SELECT LODGING FROM LODGING WHERE LODGING LIKE ‘M%’;
WHERE子句條件包括一系列值, ORACLE將通過索引范圍查詢的方式查詢LODGING_PK . 由于索引范圍查詢將返回一組值, 它的效率就要比索引唯一掃描低一些。
例2:
SELECTLODGING
FROMLODGING
WHEREMANAGER=‘BILLGATES’;
這個SQL的執行分兩步, LODGING$MANAGER的索引范圍查詢(得到所有符合條件記錄的ROWID) 和下一步同過ROWID訪問表得到LODGING列的值。 由于LODGING$MANAGER是一個非唯一性的索引,數據庫不能對它執行索引唯一掃描。
由于SQL返回LODGING列,而它并不存在于LODGING$MANAGER索引中, 所以在索引范圍查詢后會執行一個通過ROWID訪問表的操作。
WHERE子句中, 如果索引列所對應的值的第一個字符由通配符(WILDCARD)開始, 索引將不被采用。在這種情況下,ORACLE將使用全表掃描。
SELECTLODGING
FROMLODGING
WHEREMANAGERLIKE‘%HANMAN’;
1. 基礎表的選擇
基礎表(Driving Table)是指被最先訪問的表(通常以全表掃描的方式被訪問)。 根據優化器的不同, SQL語句中基礎表的選擇是不一樣的。
如果你使用的是CBO (COST BASED OPTIMIZER),優化器會檢查SQL語句中的每個表的物理大小,索引的狀態,然后選用花費最低的執行路徑。
如果你用RBO (RULE BASED OPTIMIZER) , 并且所有的連接條件都有索引對應, 在這種情況下, 基礎表就是FROM 子句中列在最后的那個表。
舉例:
SELECTA.NAME,B.MANAGER
FROM WORKERA,
LODGINGB
WHERE A.LODGING=B.LODING;
由于LODGING表的LODING列上有一個索引, 而且WORKER表中沒有相比較的索引, WORKER表將被作為查詢中的基礎表。
2. 多個平等的索引
當SQL語句的執行路徑可以使用分布在多個表上的多個索引時, ORACLE會同時使用多個索引并在運行時對它們的記錄進行合并, 檢索出僅對全部索引有效的記錄。
在ORACLE選擇執行路徑時,唯一性索引的等級高于非唯一性索引。 然而這個規則只有當WHERE子句中索引列和常量比較才有效。如果索引列和其他表的索引類相比較。 這種子句在優化器中的等級是非常低的。
如果不同表中兩個想同等級的索引將被引用, FROM子句中表的順序將決定哪個會被率先使用。 FROM子句中最后的表的索引將有最高的優先級。
如果相同表中兩個想同等級的索引將被引用, WHERE子句中最先被引用的索引將有最高的優先級。
舉例:
DEPTNO上有一個非唯一性索引,EMP_CAT也有一個非唯一性索引。
SELECTENAME,
FROMEMP
WHEREDEPT_NO=20
ANDEMP_CAT=‘A’;
這里,DEPTNO索引將被最先檢索,然后同EMP_CAT索引檢索出的記錄進行合并。 執行路徑如下:
TABLEACCESSBYROWIDONEMP
AND-EQUAL
INDEXRANGESCANONDEPT_IDX
INDEXRANGESCANONCAT_IDX
3. 等式比較和范圍比較
當WHERE子句中有索引列, ORACLE不能合并它們,ORACLE將用范圍比較。
舉例:
DEPTNO上有一個非唯一性索引,EMP_CAT也有一個非唯一性索引。
SELECTENAME
FROMEMP
WHEREDEPTNO>20
ANDEMP_CAT=‘A’;
這里只有EMP_CAT索引被用到,然后所有的記錄將逐條與DEPTNO條件進行比較。 執行路徑如下:
TABLEACCESSBYROWIDONEMP
INDEXRANGESCANONCAT_IDX
4. 不明確的索引等級
當ORACLE無法判斷索引的等級高低差別,優化器將只使用一個索引,它就是在WHERE子句中被列在最前面的。
舉例:
DEPTNO上有一個非唯一性索引,EMP_CAT也有一個非唯一性索引。
SELECTENAME
FROMEMP
WHEREDEPTNO>20
ANDEMP_CAT>‘A’;
這里, ORACLE只用到了DEPT_NO索引。 執行路徑如下:
TABLEACCESSBYROWIDONEMP
INDEXRANGESCANONDEPT_IDX
譯者按:我們來試一下以下這種情況:
SQL> select index_name, uniqueness from user_indexes where table_name = 'EMP';
INDEX_NAME UNIQUENES
------------------------------ ---------
EMPNO UNIQUE
EMPTYPE NONUNIQUE
SQL> select * from emp where empno >= 2 and emp_type = 'A' ;
no rows selected
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMP'
2 1 INDEX (RANGE SCAN) OF 'EMPTYPE' (NON-UNIQUE
雖然EMPNO是唯一性索引,但是由于它所做的是范圍比較, 等級要比非唯一性索引的等式比較低!
5. 強制索引失效
如果兩個或以上索引具有相同的等級,你可以強制命令ORACLE優化器使用其中的一個(通過它,檢索出的記錄數量少) .
舉例:
SELECTENAME
FROMEMP
WHEREEMPNO=7935
ANDDEPTNO+0=10/*DEPTNO上的索引將失效*/
ANDEMP_TYPE||‘’=‘A’/*EMP_TYPE上的索引將失效*/
這是一種相當直接的提高查詢效率的辦法。 但是你必須謹慎考慮這種策略,一般來說,只有在你希望單獨優化幾個SQL時才能采用它。
這里有一個例子關于何時采用這種策略,
假設在EMP表的EMP_TYPE列上有一個非唯一性的索引而EMP_CLASS上沒有索引。
SELECTENAME
FROMEMP
WHEREEMP_TYPE=‘A’
ANDEMP_CLASS=‘X’;
優化器會注意到EMP_TYPE上的索引并使用它。 這是目前唯一的選擇。 如果,一段時間以后, 另一個非唯一性建立在EMP_CLASS上,優化器必須對兩個索引進行選擇,在通常情況下,優化器將使用兩個索引并在他們的結果集合上執行排序及合并。 然而,如果其中一個索引(EMP_TYPE)接近于唯一性而另一個索引(EMP_CLASS)上有幾千個重復的值。 排序及合并就會成為一種不必要的負擔。 在這種情況下,你希望使優化器屏蔽掉EMP_CLASS索引。
用下面的方案就可以解決問題。
SELECTENAME
FROMEMP
WHEREEMP_TYPE=‘A’
ANDEMP_CLASS||‘’=‘X’;
1. 避免在索引列上使用計算
WHERE子句中,如果索引列是函數的一部分。優化器將不使用索引而使用全表掃描。
舉例:
低效:
SELECT…
FROMDEPT
WHERESAL*12>25000;
高效:
SELECT…
FROMDEPT
WHERESAL>25000/12;
:這是一個非常實用的規則,請務必牢記
2. 自動選擇索引
如果表中有兩個以上(包括兩個)索引,其中有一個唯一性索引,而其他是非唯一性。
在這種情況下,ORACLE將使用唯一性索引而完全忽略非唯一性索引。
舉例:
SELECTENAME
FROMEMP
WHEREEMPNO=2326
ANDDEPTNO=20;
這里,只有EMPNO上的索引是唯一性的,所以EMPNO索引將用來檢索記錄。
TABLEACCESSBYROWIDONEMP
INDEXUNIQUESCANONEMP_NO_IDX
3. 避免在索引列上使用NOT
通常,我們要避免在索引列上使用NOT, NOT會產生在和在索引列上使用函數相同的影響。 當ORACLE“遇到”NOT,他就會停止使用索引轉而執行全表掃描。
舉例:
低效: (這里,不使用索引)
SELECT…
FROMDEPT
WHEREDEPT_CODENOT=0;
高效: (這里,使用了索引)
SELECT…
FROMDEPT
WHEREDEPT_CODE>0;
需要注意的是,在某些時候, ORACLE優化器會自動將NOT轉化成相對應的關系操作符。
NOT > to <=
NOT >= to <
NOT < to >=
NOT <= to >
:在這個例子中,作者犯了一些錯誤。 例子中的低效率SQL是不能被執行的。
我做了一些測試:
SQL> select * from emp where NOT empno > 1;
no rows selected
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMP'
2 1 INDEX (RANGE SCAN) OF 'EMPNO' (UNIQUE)
SQL> select * from emp where empno <= 1;
no rows selected
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMP'
2 1 INDEX (RANGE SCAN) OF 'EMPNO' (UNIQUE)
兩者的效率完全一樣,也許這符合作者關于“ 在某些時候, ORACLE優化器會自動將NOT轉化成相對應的關系操作符” 的觀點。
4. 用>=替代>
如果DEPTNO上有一個索引,
高效:
SELECT*
FROMEMP
WHEREDEPTNO>=4
低效:
SELECT*
FROMEMP
WHEREDEPTNO>3
兩者的區別在于, 前者DBMS將直接跳到第一個DEPT等于4的記錄而后者將首先定位到DEPTNO=3的記錄并且向前掃描到第一個DEPT大于3的記錄。
1. 避免在索引列上使用計算
WHERE子句中,如果索引列是函數的一部分。優化器將不使用索引而使用全表掃描。
舉例:
低效:
SELECT…
FROMDEPT
WHERESAL*12>25000;
高效:
SELECT…
FROMDEPT
WHERESAL>25000/12;
:這是一個非常實用的規則,請務必牢記
2. 自動選擇索引
如果表中有兩個以上(包括兩個)索引,其中有一個唯一性索引,而其他是非唯一性。
在這種情況下,ORACLE將使用唯一性索引而完全忽略非唯一性索引。
舉例:
SELECTENAME
FROMEMP
WHEREEMPNO=2326
ANDDEPTNO=20;
這里,只有EMPNO上的索引是唯一性的,所以EMPNO索引將用來檢索記錄。
TABLEACCESSBYROWIDONEMP
INDEXUNIQUESCANONEMP_NO_IDX
3. 避免在索引列上使用NOT
通常,我們要避免在索引列上使用NOT, NOT會產生在和在索引列上使用函數相同的影響。 當ORACLE“遇到”NOT,他就會停止使用索引轉而執行全表掃描。
舉例:
低效: (這里,不使用索引)
SELECT…
FROMDEPT
WHEREDEPT_CODENOT=0;
高效: (這里,使用了索引)
SELECT…
FROMDEPT
WHEREDEPT_CODE>0;
需要注意的是,在某些時候, ORACLE優化器會自動將NOT轉化成相對應的關系操作符。
NOT > to <=
NOT >= to <
NOT < to >=
NOT <= to >
:在這個例子中,作者犯了一些錯誤。 例子中的低效率SQL是不能被執行的。
我做了一些測試:
SQL> select * from emp where NOT empno > 1;
no rows selected
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMP'
2 1 INDEX (RANGE SCAN) OF 'EMPNO' (UNIQUE)
SQL> select * from emp where empno <= 1;
no rows selected
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMP'
2 1 INDEX (RANGE SCAN) OF 'EMPNO' (UNIQUE)
兩者的效率完全一樣,也許這符合作者關于“ 在某些時候, ORACLE優化器會自動將NOT轉化成相對應的關系操作符” 的觀點。
4. 用>=替代>
如果DEPTNO上有一個索引,
高效:
SELECT*
FROMEMP
WHEREDEPTNO>=4
低效:
SELECT*
FROMEMP
WHEREDEPTNO>3
兩者的區別在于, 前者DBMS將直接跳到第一個DEPT等于4的記錄而后者將首先定位到DEPTNO=3的記錄并且向前掃描到第一個DEPT大于3的記錄。
{http://blog.chinaunix.net/u/20483/showart_546882.html}
http://blog.chinaunix.net/u/21684/showart.php?id=537094 http://www.aygfsteel.com/zhangchao/archive/2008/03/19/187372.html http://www.smellcode.cn/index.php/javascript/jiyuext20dehanyoucheckboxdetree/ http://www.aygfsteel.com/amigoxie/archive/2008/02/20/180779.html http://www.aygfsteel.com/pdw2009/archive/2006/05/10/45461.html ?HashMap是Java新Collection Framework中用來代替HashTable的一個實現,HashMap和HashTable的區別是: HashMap是未經同步的,而且允許null值。HashTable繼承Dictionary,而且使用了Enumeration,所以被建議不要使用。
HashMap的聲明如下:
public class HashMap extends AbstractMap implements Map, Cloneable,Serializable
有關AbstractMap:http://blog.csdn.net/treeroot/archive/2004/09/20/110343.aspx
有關Map:http://blog.csdn.net/treeroot/archive/2004/09/20/110331.aspx
有關Cloneable:http://blog.csdn.net/treeroot/archive/2004/09/07/96936.aspx
這個類比較復雜,這里只是重點分析了幾個方法,特別是后面涉及到很多內部類都沒有解釋
不過都比較簡單。
static final int DEFAULT_INITIAL_CAPACITY = 16; 默認初始化大小
static final int MAXIMUM_CAPACITY = 1 << 30; 最大初始化大小
static final float DEFAULT_LOAD_FACTOR = 0.75f; 默認加載因子
transient Entry[] table; 一個Entry類型的數組,數組的長度為2的指數。
transient int size; 映射的個數
int threshold; 下一次擴容時的值
final float loadFactor; 加載因子
transient volatile int modCount; 修改次數
public HashMap(int initialCapacity, float loadFactor) {
if (initialCapacity < 0)
throw new IllegalArgumentException("Illegal initial capacity: " +initialCapacity);
if (initialCapacity > MAXIMUM_CAPACITY)
initialCapacity = MAXIMUM_CAPACITY;
if (loadFactor <= 0 || Float.isNaN(loadFactor))
throw new IllegalArgumentException("Illegal load factor: " +loadFactor);
int capacity = 1;
while (capacity < initialCapacity)
capacity <<= 1;
this.loadFactor = loadFactor;
threshold = (int)(capacity * loadFactor);
table = new Entry[capacity];
init();
}
public HashMap(int initialCapacity) {
this(initialCapacity, DEFAULT_LOAD_FACTOR);
}
public HashMap() {
this.loadFactor = DEFAULT_LOAD_FACTOR;
threshold = (int)(DEFAULT_INITIAL_CAPACITY);
注意:這里應該是一個失誤! 應該是:threshold =(int)(DEFAULT_INITIAL_CAPACITY * loadFactor);
table = new Entry[DEFAULT_INITIAL_CAPACITY];
init();
}
public HashMap(Map m) {
this(Math.max((int) (m.size() / DEFAULT_LOAD_FACTOR) + 1, DEFAULT_INITIAL_CAPACITY), DEFAULT_LOAD_FACTOR);
putAllForCreate(m);
}
void init() {}
static final Object NULL_KEY = new Object();
static Object maskNull(Object key){
return (key == null ? NULL_KEY : key);
}
static Object unmaskNull(Object key) {
return (key == NULL_KEY ? null : key);
}
static int hash(Object x) {
int h = x.hashCode();
h += ~(h << 9);
h ^= (h >>> 14);
h += (h << 4);
h ^= (h >>> 10);
return h;
}
在HashTable中沒有這個方法,也就是說HashTable中是直接用對象的hashCode值,但是HashMap做了改進 用這個算法來獲得哈希值。
static boolean eq(Object x, Object y) {
return x == y || x.equals(y);
}
static int indexFor(int h, int length) {
return h & (length-1);
}
根據哈希值和數組的長度來返回該hash值在數組中的位置,只是簡單的與關系。
public int size() {
return size;
}
public boolean isEmpty() {
return size == 0;
}
public Object get(Object key) {
Object k = maskNull(key);
int hash = hash(k);
int i = indexFor(hash, table.length);
Entry e = table[i];
while (true) {
if (e == null) return e;
if (e.hash == hash && eq(k, e.key)) return e.value;
e = e.next;
}
}
這個方法是獲取數據的方法,首先獲得哈希值,這里把null值掩飾了,并且hash值經過函數hash()修正。 然后計算該哈希值在數組中的索引值。如果該索引處的引用為null,表示HashMap中不存在這個映射。 否則的話遍歷整個鏈表,這里找到了就返回,如果沒有找到就遍歷到鏈表末尾,返回null。這里的比較是這樣的:e.hash==hash && eq(k,e.key) 也就是說如果hash不同就肯定認為不相等,eq就被短路了,只有在 hash相同的情況下才調用equals方法。現在我們該明白Object中說的如果兩個對象equals返回true,他們的 hashCode應該相同的道理了吧。假如兩個對象調用equals返回true,但是hashCode不一樣,那么在HashMap 里就認為他們不相等。
public boolean containsKey(Object key) {
Object k = maskNull(key);
int hash = hash(k);
int i = indexFor(hash, table.length);
Entry e = table[i];
while (e != null) {
if (e.hash == hash && eq(k, e.key)) return true;
e = e.next;
}
return false;
}
這個方法比上面的簡單,先找到哈希位置,再遍歷整個鏈表,如果找到就返回true。
Object k = maskNull(key);
int hash = hash(k);
int i = indexFor(hash, table.length);
Entry e = table[i];
while (e != null && !(e.hash == hash && eq(k, e.key)))
e = e.next;
return e;
}
這個方法根據key值返回Entry節點,也是先獲得索引位置,再遍歷鏈表,如果沒有找到返回的是null。
public Object put(Object key, Object value) {
Object k = maskNull(key);
int hash = hash(k);
int i = indexFor(hash, table.length);
for (Entry e = table[i]; e != null; e = e.next) {
if (e.hash == hash && eq(k, e.key)) {
Object oldValue = e.value;
e.value = value;
e.recordAccess(this);
return oldValue;
}
}
modCount++;
addEntry(hash, k, value, i);
return null;
}
首先獲得hash索引位置,如果該位置的引用為null,那么直接插入一個映射,返回null。如果此處的引用不是null,必須遍歷鏈表,如果找到一個相同的key,那么就更新該value,同時返回原來的value值。如果遍歷完了沒有找到,說明該key值不存在,還是插入一個映射。如果hash值足夠離散的話,也就是說該索引沒有被使用的話,那么不不用遍歷鏈表了。相反,如果hash值不離散,極端的說如果是常數的話,所有的映射都會在這一個鏈表上,效率會極其低下。這里舉一個最簡單的例子,寫兩
個不同的類作為key插入到HashMap中,效率會遠遠不同。
class Good{
int i;
public Good(int i){
this.i=i;
}
public boolean equals(Object o){
return (o instanceof Good) && (this.i==((Good)o).i)
}
public int hashCode(){
return i;
}
}
class Bad{
int i;
public Good(int i){
this.i=i;
}
public boolean equals(Object o){
return (o instanceof Good) && (this.i==((Good)o).i)
}
public int hashCode(){
return 0;
}
}
執行代碼:
Map m1=new HashMap();
Map m2=new HashMap();
for(int i=0;i<100;i++){
m1.put(new Good(i),new Integer(i)); //這里效率非常高
}
for(int i=0;i<100;i++){
m2.put(new Bad(i),new Integer(i)); //這里幾乎要崩潰
}
上面的是兩個非常極端的例子,執行一下就知道差別有多大。
private void putForCreate(Object key, Object value) {
Object k = maskNull(key);
int hash = hash(k);
int i = indexFor(hash, table.length);
for (Entry e = table[i]; e != null; e = e.next) {
if (e.hash == hash && eq(k, e.key)) {
e.value = value;
return;
}
}
createEntry(hash, k, value, i);
}
void putAllForCreate(Map m) {
for (Iterator i = m.entrySet().iterator(); i.hasNext(); ) {
Map.Entry e = (Map.Entry) i.next();
putForCreate(e.getKey(), e.getValue());
}
}
上面的兩個方法是被構造函數和clone方法調用的。
void resize(int newCapacity) {
Entry[] oldTable = table;
int oldCapacity = oldTable.length;
if (size < threshold || oldCapacity > newCapacity)
return;
Entry[] newTable = new Entry[newCapacity];
transfer(newTable);
table = newTable;
threshold = (int)(newCapacity * loadFactor);
}
這個方法在需要的時候重新分配空間,相當于ArrayList的ensureCapacity方法,不過這個更加復雜。
void transfer(Entry[] newTable) {
Entry[] src = table;
int newCapacity = newTable.length;
for (int j = 0; j < src.length; j++) {
Entry e = src[j];
if (e != null) {
src[j] = null;
do {
Entry next = e.next;
int i = indexFor(e.hash, newCapacity);
e.next = newTable[i];
newTable[i] = e;
e = next;
} while (e != null);
}
}
}
遍歷原來的數組,如果該Entry不是null的話,說明有映射,然后遍歷這個鏈表,把所有的映射插入到新的數組中,注意這里要從新計算索引位置。
public void putAll(Map t) {
int n = t.size();
if (n == 0)
return;
if (n >= threshold) {
n = (int)(n / loadFactor + 1);
if (n > MAXIMUM_CAPACITY)
n = MAXIMUM_CAPACITY;
int capacity = table.length;
while (capacity < n) capacity <<= 1;
resize(capacity);
}
for (Iterator i = t.entrySet().iterator(); i.hasNext(); ) {
Map.Entry e = (Map.Entry) i.next();
put(e.getKey(), e.getValue());
}
}
這個方法先確定是否需要擴大空間,然后循環調用put方法。
public Object remove(Object key) {
Entry e = removeEntryForKey(key);
return (e == null ? e : e.value);
}
Entry removeEntryForKey(Object key) {
Object k = maskNull(key);
int hash = hash(k);
int i = indexFor(hash, table.length);
Entry prev = table[i];
Entry e = prev;
while (e != null) { 如果e==null表示不存在
Entry next = e.next;
if (e.hash == hash && eq(k, e.key)) {
modCount++;
size--;
if (prev == e)
table[i] = next; 鏈表的第一個元素就是要刪除的,這里最好加一句 e.next=null.
else
prev.next = next; 存在擔不是鏈表的第一個元素, 這里最好加一句 e.next=null.
e.recordRemoval(this);
return e;
}
prev = e;
e = next;
}
return e; 這里其實就是return null;
}
這個方法其實也不復雜,也是遍歷鏈表,這里建議加一句e.next=null,可以改為
if(prev==e)
table[i]=next;
else
prev.next=next;
e.next=null; 這一句是多加的,可以提高效率。
這里簡單說明我的看法:
因為e是被刪除的節點,刪除它其實就是指向它的指針指向它的后面一個節點。所以e可以作為GC回收的對象。
可以e還有一個next指針指向我們的數據,如果e沒有被回收。而且此時e.next指向的節點也變為沒用的了,但是
卻有一個它的引用(e.next),所以雖然e的下一個節點沒用了,但是卻不能作為GC回收的對象,除非e先被回收。
雖然不一定會引起很大的問題,但是至少會影響GC的回收效率。就像數據庫中的外鍵引用一樣,刪除起來很麻煩呀。
Entry removeMapping(Object o) {
if (!(o instanceof Map.Entry))
return null;
Map.Entry entry = (Map.Entry)o;
Object k = maskNull(entry.getKey());
int hash = hash(k);
int i = indexFor(hash, table.length);
Entry prev = table[i];
Entry e = prev;
while (e != null) {
Entry next = e.next;
if (e.hash == hash && e.equals(entry)) {
modCount++;
size--;
if (prev == e)
table[i] = next;
else
prev.next = next;
e.recordRemoval(this);
return e;
}
prev = e;
e = next;
}
return e;
}
這個方法和上面的一樣。
public void clear() {
modCount++;
Entry tab[] = table;
for (int i = 0; i < tab.length; i++)
tab[i] = null;
size = 0;
}
同樣可以改進
public boolean containsValue(Object value) {
if (value == null)
return containsNullValue();
Entry tab[] = table;
for (int i = 0; i < tab.length ; i++)
for (Entry e = tab[i] ; e != null ; e = e.next)
if (value.equals(e.value)) return true;
return false;
}
private boolean containsNullValue() {
Entry tab[] = table;
for (int i = 0; i < tab.length ; i++)
for (Entry e = tab[i] ; e != null ; e = e.next)
if (e.value == null) return true;
return false;
}
public Object clone() {
HashMap result = null;
try {
result = (HashMap)super.clone();
}
catch (CloneNotSupportedException e) { // assert false; }
result.table = new Entry[table.length];
result.entrySet = null;
result.modCount = 0;
result.size = 0;
result.init();
result.putAllForCreate(this);
return result;
}
static class Entry implements Map.Entry {
final Object key;
Object value;
final int hash;
Entry next;
Entry(int h, Object k, Object v, Entry n) {
value = v;
next = n;
key = k;
hash = h;
}
public Object getKey() {
return unmaskNull(key);
}
public Object getValue() {
return value;
}
public Object setValue(Object newValue) {
Object oldValue = value;
value = newValue;
return oldValue;
}
public boolean equals(Object o) {
if (!(o instanceof Map.Entry)) return false;
Map.Entry e = (Map.Entry)o;
Object k1 = getKey();
Object k2 = e.getKey();
if (k1 == k2 || (k1 != null && k1.equals(k2))) {
Object v1 = getValue();
Object v2 = e.getValue();
if (v1 == v2 || (v1 != null && v1.equals(v2))) return true;
}
return false;
}
public int hashCode() {
return (key==NULL_KEY ? 0 : key.hashCode()) ^ (value==null ? 0 : value.hashCode());
}
public String toString() {
return getKey() + "=" + getValue();
}
void recordAccess(HashMap m) { }
void recordRemoval(HashMap m) { }
}
一個靜態內部類
void addEntry(int hash, Object key, Object value, int bucketIndex) {
table[bucketIndex] = new Entry(hash, key, value, table[bucketIndex]);
if (size++ >= threshold)
resize(2 * table.length);
}
注意這個方法,插入連表的頭。
可以寫成這樣更好理解:
Entry oldHead=table[bucketIndex];
Entry newHead = new Entry(hash,key,value,oldHead);
table[bucketIndex]=newHead;
void createEntry(int hash, Object key, Object value, int bucketIndex) {
table[bucketIndex] = new Entry(hash, key, value, table[bucketIndex]);
size++;
}
private abstract class HashIterator implements Iterator {
Entry next;
int expectedModCount;
int index;
Entry current;
HashIterator() {
expectedModCount = modCount;
Entry[] t = table;
int i = t.length;
Entry n = null;
if (size != 0) {
while (i > 0 && (n = t[--i]) == null) ;
}
next = n;
index = i;
}
public boolean hasNext() {
return next != null;
}
Entry nextEntry() {
if (modCount != expectedModCount)
throw new ConcurrentModificationException();
Entry e = next;
if (e == null)
throw new NoSuchElementException();
Entry n = e.next;
Entry[] t = table;
int i = index;
while (n == null && i > 0)
n = t[--i]; index = i;
next = n;
return current = e;
}
public void remove() {
if (current == null)
throw new IllegalStateException();
if (modCount != expectedModCount)
throw new ConcurrentModificationException();
Object k = current.key;
current = null;
HashMap.this.removeEntryForKey(k);
expectedModCount = modCount;
}
}
private class ValueIterator extends HashIterator {
public Object next() {
return nextEntry().value;
}
}
private class KeyIterator extends HashIterator {
public Object next() {
return nextEntry().getKey();
}
}
private class EntryIterator extends HashIterator {
public Object next() {
return nextEntry();
}
}
Iterator newKeyIterator() {
return new KeyIterator();
}
Iterator newValueIterator() {
return new ValueIterator();
}
Iterator newEntryIterator() {
return new EntryIterator();
}
private transient Set entrySet = null;
public Set keySet() {
Set ks = keySet;
return (ks != null ? ks : (keySet = new KeySet()));
}
private class KeySet extends AbstractSet {
public Iterator iterator() {
return newKeyIterator();
}
public int size() {
return size;
}
public boolean contains(Object o) {
return containsKey(o);
}
public boolean remove(Object o) {
return HashMap.this.removeEntryForKey(o) != null;
}
public void clear() {
HashMap.this.clear();
}
}
public Collection values() {
Collection vs = values; return (vs != null ? vs : (values = new Values()));
}
private class Values extends AbstractCollection {
public Iterator iterator() {
return newValueIterator();
}
public int size() {
return size;
}
public boolean contains(Object o) {
return containsValue(o);
}
public void clear() {
HashMap.this.clear();
}
}
public Set entrySet() {
Set es = entrySet;
return (es != null ? es : (entrySet = new EntrySet()));
}
private class EntrySet extends AbstractSet {
public Iterator iterator() {
return newEntryIterator();
}
public boolean contains(Object o) {
if (!(o instanceof Map.Entry))
return false;
Map.Entry e = (Map.Entry)o;
Entry candidate = getEntry(e.getKey());
return candidate != null && candidate.equals(e);
}
public boolean remove(Object o) {
return removeMapping(o) != null;
}
public int size() {
return size;
}
public void clear() {
HashMap.this.clear();
}
}
private void writeObject(java.io.ObjectOutputStream s) throws IOException {
s.defaultWriteObject();
s.writeInt(table.length);
s.writeInt(size);
for (Iterator i = entrySet().iterator(); i.hasNext(); ) {
Map.Entry e = (Map.Entry) i.next();
s.writeObject(e.getKey());
s.writeObject(e.getValue());
}
}
private static final long serialVersionUID = 362498820763181265L;
private void readObject(java.io.ObjectInputStream s) throws IOException, ClassNotFoundException {
s.defaultReadObject();
int numBuckets = s.readInt();
table = new Entry[numBuckets];
init();
size = s.readInt(); for (int i=0;
for (int i=0; i<size; i++) {
Object key = s.readObject();
Object value = s.readObject();
putForCreate(key, value);
}
}
int capacity() {
return table.length;
}
float loadFactor() {
return loadFactor;
}
時間:2006-06-08 作者:Dejan Bosanac 瀏覽次數: 701 本文關鍵字:Spring,?configuration,?source control,?CVS,?subversion,?配置,?源代碼控制 |
|

本文將為您提供關于Spring MVC框架的配置技巧,以幫助管理基于Spring的web應用程序的多個實例。本配置管理主題常被學術界所忽略,但是,這對于現實的web開發尤為重要。本主題并不直接關聯任何具體的技術,因此,我們將從最基本的概念開始對這個問題進行說明。下面,我們將根據Spring MVC框架,為基于本技術開發的項目提供一系列的解決方案。
Spring配置
人們經常會在一臺以上的主機上配置一種Web應用程序。例如,在生產中,一個網站可能只有一個實例。除了此實例外,開發人員可以在用于開發的機器上配置其他的(開發)實例。也可以在公司(機構)內部的本地開發服務器上維護其他應用程序裝置,這將讓您受益匪淺。該實例的目的是使Web設計者可以獲得有質量保證的材料,并為需要為應用程序提供文件資料的人提供準入。
大家都知道,即使是最簡單的場景,也需要安裝、配置和維護三個實例。而對于位于不同地理位置的團隊來說,要從事這樣的項目便更加困難。對于任何不是特別簡單的Web應用程序項目,都需要多名開發人員來安裝項目裝置和本地設置以及運行單元測試的裝置等。
很多組織都將自己開發的產品作為Web應用程序。我們可以在很多產品中發現這種情況,例如電子商務系統、內容管理系統(CMS),以及博客發布平臺等。這類產品可在多個服務器中進行部署。對于成功的多用途Web應用程序來說,他們的開發人員必須要保證他們的應用程序便于安裝,并且能夠與其他Web應用程序完美集成。經過上述討論之后,我們應該明了,作為本文主題的應用程序配置是通用Web應用程序項目開發人員所需要解決的重要問題之一。
諸如CVS或Subversion之類的版本控制系統是開發組織使用的一種標準工具。這種工具代表了一些組織的中心源代碼版本庫,它們被用于保持源代碼的有序。用戶可以跟蹤應用程序源代碼的變化,顯示不同版本的區別,并可以確定項目分支。而且,它們使得在應用程序部署中進行部分更新成為可能。
很明顯,版本控制系統軟件是跟蹤源代碼所必需的,它對于解決應用程序配置問題有非常大的幫助。在本文中,我們將不會把重點放在版本控制系統上,因為這方面已經有很多相關的材料了。在此,我們將關注版本控制問題中的一個小話題:如何使Web應用程序的配置更加便捷(尤其是使用Spring MVC框架編寫的Web應用程序)。
問題是:我們在此討論的是一種什么樣的配置?任何Web應用程序都需要一些資源,這些資源通常都是其所運行的服務器所特有的,例如數據庫URL、發送電子郵件的SMTP服務器,以及包含專用軟件文件的文件夾等。這樣的設置應該集中,從而使應用程序配置更加簡單。
但是,這只是這個問題最簡單的一種版本。有時候,在應用程序開發中需要更加復雜的配置。這意味著,必須將各次部署中的不同Bean連接起來,而這會使問題更加復雜。
這些應用程序配置問題的解決方案有諸多優勢,包括:簡化應用程序的安裝和配置過程,使源代碼版本控制更加簡便,減少源代碼版本庫中的沖突現象。下面,我們將通過示例詳細討論這個話題。
問題
我們首先來演示一下上文所提到的最簡單的版本。在這一場景中,我們希望在應用程序部署中改變的是簡單的配置參數,例如鏈接、密碼等。如果您曾經使用Spring MVC框架開發過Web應用程序,那么您應該知道這里將用到的兩個配置文件:
- /WEB-INF/applicationContext.xml,它讓您可以配置Bean,或者顯示應用程序上下文。通過這個文件,您可以定義自己的業務邏輯Bean、資源以及其他可以與Web端口相關聯的所有Bean。
- /WEB-INF/[servlet-name]-servlet.xml,它被用于配置Web層、視圖解析器、控制器、校驗器以及其他所有MVC框架中必需的Bean。[servlet-name]指的是在web.xml部署描述符中定義的Spring dispatcher servlet的名稱。
那么問題在哪兒呢?問題就出在applicationContext.xml中將包括一些特定于主機的Bean定義。其中,最明顯的一個示例就是包含了JDBC連接信息的bean,但是任何一種稍微復雜些的應用程序都有十幾個類似的Bean。看一下下面的示例:
<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource"> <property name="driverClassName"> <value>org.postgresql.Driver</value> </property> <property name="url"> <value>jdbc:postgresql://localhost/test</value> </property> <property name="username"> <value>postgres</value> </property> <property name="password"> <value></value> </property> </bean>
這個解決方案的問題在于對applicationContext.xml文件的維護。對于初學者來說,設想一下,項目放在源代碼版本控制系統中,例如CVS。下面,假設您希望在網站中添加新的功能,那么就需要在應用程序上下文定義中添加額外的Bean定義。問題是如何在生產服務器上體現這些改變。
通常情況下,應用程序的本地實例不會與活動站點使用同樣的數據庫,因此applicationContext.xml文件將包括讓您能夠訪問本地數據庫的設置。當您想提交在源代碼版本庫中的改變時,就需要注意這些特定于主機屬性的同步性。版本庫中的文件最終可能使用本地設置中的配置。如果想在生產服務器上更新配置,就必須手動同步這些屬性的值。這是非常枯燥的任務,而且還非常容易出錯。
對于應用程序的每個實例來說,這個問題更加重要。假如有三位開發人員正在使用代碼段基址,而且他們使用的是本地的數據庫。當您提交更改的時候,他們每個人在本地服務器上更新源代碼的時候都必須非常謹慎。他們會手動同步這些更改,然后提交他們的工作。這樣一來,版本控制系統對于這些配置文件來說已經毫無用處。如果曾經使用過Spring MVC,那么您應該知道applicationContext.xml是應用程序中的關鍵組件,因為是它將所有的東西粘合在一起。所以,我們需要一種機制來幫助使應用程序中各項保持有序,這點非常重要。
正如前面所提到的,這是您可能遇到的較簡單的配置問題。更難的問題出現在當需要在不同服務器中進行不同的Bean連接的時候。這類問題常會出現在日常軟件開發任務中。例如,假如您的產品有一個客戶身份驗證模塊,可以對來自關系數據庫或LDAP服務器中的用戶進行身份驗證。自然,這一身份驗證模塊可以使用抽象了特定版本庫的Bean進行配置。如果您想改變不同應用程序部署中驗證用戶的方式,就需要在applicationContext.xml文件中進行不同的Bean連接。這種配置問題常見于在部署中有可配置特性的所有應用程序。
在下文中,我們將討論這兩種配置問題。首先我們會關注同步的Bean屬性問題及其解決方案,接下來,我們會討論更加復雜的同步Bean連接問題。
解決方案
同步Bean屬性
這個問題的一種可行的解決方案是將所有特定于主機的參數都放到普通的Java屬性文件中,使用Spring的PropertyPlaceHolderConfigurer類,將這些參數寫入Bean屬性中。
使用這一解決方案,我們可以生成如下的屬性文件(/WEB-INF/jdbc.properties):
jdbc.driver=org.postgresql.Driver jdbc.url=jdbc:postgresql://localhost/test jdbc.user=postgres jdbc.password=
我們的Bean配置如下:
<bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> <property name="location"> <value>/WEB-INF/jdbc.properties</value> </property> </bean> <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource"> <property name="driverClassName"> <value>${jdbc.driver}</value> </property> <property name="url"> <value>${jdbc.url}</value> </property> <property name="username"> <value>${jdbc.user}</value> </property> <property name="password"> <value>${jdbc.password}</value> </property> </bean>
如上所述,我們定義了一個PropertyPlaceholderConfigurer類的實例,并將其位置屬性設置為我們的屬性文件。該類被實現為Bean工廠的后處理器,并將使用定義在文件中的屬性來代替所有的占位符(${...}value)。
利用這種技術,我們可以從applicationContext.xml中移除所有特定于主機的配置屬性。通過這種方式,我們可以自由地為該文件添加新的Bean,而不必擔心特定于主機屬性的同步性。這樣可以簡化生產部署和維護。
同步性連接
上面的技術解決了第一個問題,可是如果您計劃修改不同應用程序部署之間的Bean連接,這一技術便不很適合。針對這一問題的一個解決方案便是額外創建一個名為applicationContext-[hostname].xml 的XML定義文件。其中[hostname]是部署應用程序的主機的名稱。例如,在本地的機器上,這個文件通常名為applicationContext-localhost.xml,而在部署時,它可能更名為applicationContext-somehost.com.xml。
可以猜測,這一文件必須包括特定于某一主機的所有配置Bean。在本文中,我們將假設dataSource bean定義將位于這類文件中,而不是通用的applicationContext.xml定義。當然,這種機制與前者并非沖突,但是為了更加簡單明了,我們將只關注這種方法。
既然我們已經有了特定的配置,下面我們就來討論一下如何將其整合到整個Spring MVC配置概念中。要達到這一目的,可以有許多方法,我們將詳細地一一說明。但首先,我們應該注意到,由于有些Bean可能位于獨立的配置文件中,因此在applicationContext.xml中,所有對它們的局部引用都必須更換成全局名稱。
例如,如下引用:
<property name="someProperty"> <ref local="someBean"/> </property>
應更改為:
<property name="someProperty"> <ref bean="someBean"/> </property>
在這之后,我們有很多可以添加額外的資源以用于配置的方式。其中最明顯的就是使用<import>標簽將這一額外資源包含在applicationContext.xml配置文件中。使用時,要將該標簽放在applicationContext.xml文件開頭。例如:
<import resource="applicationContext-somehost.com.xml"/>
現在,在獨立的XML定義文件和普通的應用程序上下文定義文件中的所有通用Bean定義都有了特定于主機的連接。由于大多數的Bean都不是特定于主機的,因此我們可以像處理Web應用程序中的其他資源一樣自由地處理applicationContext.xml文件,并可以通過合適的版本控制系統與其進行同步。
但是,上述方法也有一定的弊端。如果您想保留不同XML文件的不同配置,就仍然必須擔心applicationContext.xml的同步性,因為資源的名稱必須根據不同服務器進行更改。雖然與原有的解決方案相比有了很大提高,只需更改文件名,但是這還是需要開發人員的手動協助。
由于與applicationContext.xml相比,主機配置不需如此頻繁地進行更改,因此下一步便是將主機配置移動到web.xml文件中(如果可能的話)。幸運的是,我們有一個可用的解決方案。看一下下面關于web.xml配置的片斷:
<listener> <listener-class> org.springframework.web.context.ContextLoaderListener </listener-class> </listener> <context-param> <param-name>contextConfigLocation</param-name> <param-value> /WEB-INF/applicationContext.xml /WEB-INF/applicationContext-somehost.com.xml </param-value> </context-param>
正如您所看到的,除了web.xml文件中常有的ContextLoaderListener之外,我們還添加了contextConfigLocation上下文參數配置。這一參數用于指示框架查找這些配置文件的位置。如果這一參數被省略,則Spring就只能到applicationContext.xml中查找。這里我們也定義了特定于主機的配置文件來使用。
利用這種方法,我們將所有特定于主機的配置從applicationContext.xml文件中移除,這樣便減輕了其在不同應用程序部署中的同步性。
如果這種方法成為您的新習慣,您還可以使其更加靈活。通過遵守下列指令,也可以將特定于主機的配置從web.xml文件中移除。
為此,需要創建特定于我們的應用程序上下文的類:
package net.nighttale.spring.util; import java.net.InetAddress; import org.springframework.web.context.support.XmlWebApplicationContext; public class PerHostXmlWebApplicationContext extends XmlWebApplicationContext { protected String[] getDefaultConfigLocations() { String hostname = "localhost"; try { hostname = InetAddress.getLocalHost().getHostName(); } catch (Exception e) { } String perHostConfiguration = DEFAULT_CONFIG_LOCATION_PREFIX + "applicationContext-" + hostname + DEFAULT_CONFIG_LOCATION_SUFFIX ; logger.debug( "Adding per host configuration file: " + perHostConfiguration ); if (getNamespace() != null) { return new String[] { DEFAULT_CONFIG_LOCATION_PREFIX + getNamespace() + DEFAULT_CONFIG_LOCATION_SUFFIX , perHostConfiguration}; } else { return new String[] { DEFAULT_CONFIG_LOCATION , perHostConfiguration}; } } }
這個類拓展了Spring中常被作為默認值使用的XmlWebApplicationContext。XmlWebApplicationContext類將Web應用程序的配置從XML定義文件中復制過來。默認情況下,它可以配置來自applicationContext.xml和[servlet-name]-servlet.xml文件中的應用程序。這個類執行的惟一一項額外任務便是獲取它所在的主機名稱,并將applicationContext-[hostname].xml文件添加到配置文件列表中。
為了使用這個類,我們需要對其進行編譯,將其包含在類途徑中,并指示Spring框架使用它。前兩步非常簡單,我們就不在此贅述。我們可以指示Sping通過contextClass上下文參數來使用它。除了web.xml文件中的原有配置,我們還可以添加下列內容:
<context-param> <param-name>contextClass</param-name> <param-value> net.nighttale.spring.util.PerHostXmlWebApplicationContext </param-value> </context-param>
如果我們使用這一配置片斷,將會有三個文件被用于初始化這個框架:[servlet-name]-servlet.xml、applicationContext-[hostname].xml以及applicationContext.xml。
正如您所看到的,applicationContext.xml和web.xml文件已經完全擺脫了任何特定的配置細節,而且您也不必擔心會在更新應用程序時破壞配置。
但是,這種方法有一個不足之處。因為,不論是否會使用,都需要在應用程序部署中有第三個配置文件。在這種情況下,便不需要特定于主機的配置。例如:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd"> <beans></beans>
最后,需要知道應用程序上下文類需要查找的特定主機名。檢查主機名稱的最簡單的方法是在機器上運行下列代碼:
System.out.println(InetAddress.getLocalHost().getHostName())
可以將其作為Java代碼執行,也可在喜歡使用的腳本語言(如BeanShell或Groovy)中作為一個具有Java風格語法的腳本執行。在獲取了主機的名稱之后,應該創建一個默認的/WEB-INF/applicationContext-[hostname].xml空文件夾(如我們上面所定義的),然后便可以開始了。
結束語
在本文中,我們提供了一系列的配置技巧,讓您在使用Spring MVC框架完成日常工作的時候更加輕松。如果您希望知道如何維護各種Web應用程序部署,可以試著找出最適合您的開發過程的解決方案。您的生活會更為輕松。
???????? 最近,買了本Spring入門書:spring In Action 。大致瀏覽了下感覺還不錯。就是入門了點。Manning的書還是不錯的,我雖然不像哪些只看Manning書的人那樣專注于Manning,但懷著崇敬的心情和激情通覽了一遍。又一次接受了IOC 、DI、AOP等Spring核心概念。 先就IOC和DI談一點我的看法。IOC(DI):其實這個Spring架構核心的概念沒有這么復雜,更不像有些書上描述的那樣晦澀。java程序員都知道:java程序中的每個業務邏輯至少需要兩個或以上的對象來協作完成,通常,每個對象在使用他的合作對象時,自己均要使用像new object() 這樣的語法來完成合作對象的申請工作。你會發現:對象間的耦合度高了。而IOC的思想是:Spring容器來實現這些相互依賴對象的創建、協調工作。對象只需要關系業務邏輯本身就可以了。從這方面來說,對象如何得到他的協作對象的責任被反轉了(IOC、DI)。
這是我對Spring的IOC的體會。DI其實就是IOC的另外一種說法。DI是由Martin Fowler 在2004年初的一篇論文中首次提出的。他總結:控制的什么被反轉了?就是:獲得依賴對象的方式反轉了。
如果對這一核心概念還不理解:這里引用一個叫Bromon的blog上找到的淺顯易懂的答案:
IoC與DI
首先想說說IoC(Inversion of Control,控制倒轉)。這是spring的核心,貫穿始終。所謂IoC,對于spring框架來說,就是由spring來負責控制對象的生命周期和對象間的關系。這是什么意思呢,舉個簡單的例子,我們是如何找女朋友的?常見的情況是,我們到處去看哪里有長得漂亮身材又好的mm,然后打聽她們的興趣愛好、qq號、電話號、ip號、iq號………,想辦法認識她們,投其所好送其所要,然后嘿嘿……這個過程是復雜深奧的,我們必須自己設計和面對每個環節。傳統的程序開發也是如此,在一個對象中,如果要使用另外的對象,就必須得到它(自己new一個,或者從JNDI中查詢一個),使用完之后還要將對象銷毀(比如Connection等),對象始終會和其他的接口或類藕合起來。
那么IoC是如何做的呢?有點像通過婚介找女朋友,在我和女朋友之間引入了一個第三者:婚姻介紹所。婚介管理了很多男男女女的資料,我可以向婚介提出一個列表,告訴它我想找個什么樣的女朋友,比如長得像李嘉欣,身材像林熙雷,唱歌像周杰倫,速度像卡洛斯,技術像齊達內之類的,然后婚介就會按照我們的要求,提供一個mm,我們只需要去和她談戀愛、結婚就行了。簡單明了,如果婚介給我們的人選不符合要求,我們就會拋出異常。整個過程不再由我自己控制,而是有婚介這樣一個類似容器的機構來控制。Spring所倡導的開發方式就是如此,所有的類都會在spring容器中登記,告訴spring你是個什么東西,你需要什么東西,然后spring會在系統運行到適當的時候,把你要的東西主動給你,同時也把你交給其他需要你的東西。所有的類的創建、銷毀都由 spring來控制,也就是說控制對象生存周期的不再是引用它的對象,而是spring。對于某個具體的對象而言,以前是它控制其他對象,現在是所有對象都被spring控制,所以這叫控制反轉。如果你還不明白的話,我決定放棄。
IoC的一個重點是在系統運行中,動態的向某個對象提供它所需要的其他對象。這一點是通過DI(Dependency Injection,依賴注入)來實現的。比如對象A需要操作數據庫,以前我們總是要在A中自己編寫代碼來獲得一個Connection對象,有了 spring我們就只需要告訴spring,A中需要一個Connection,至于這個Connection怎么構造,何時構造,A不需要知道。在系統運行時,spring會在適當的時候制造一個Connection,然后像打針一樣,注射到A當中,這樣就完成了對各個對象之間關系的控制。A需要依賴 Connection才能正常運行,而這個Connection是由spring注入到A中的,依賴注入的名字就這么來的。那么DI是如何實現的呢? Java 1.3之后一個重要特征是反射(reflection),它允許程序在運行的時候動態的生成對象、執行對象的方法、改變對象的屬性,spring就是通過反射來實現注入的。關于反射的相關資料請查閱java doc。
如果還不明白,放棄java吧!
如題。但 blogjava系統為何用.net開發
| |||||||||
日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
---|---|---|---|---|---|---|---|---|---|
26 | 27 | 28 | 29 | 30 | 31 | 1 | |||
2 | 3 | 4 | 5 | 6 | 7 | 8 | |||
9 | 10 | 11 | 12 | 13 | 14 | 15 | |||
16 | 17 | 18 | 19 | 20 | 21 | 22 | |||
23 | 24 | 25 | 26 | 27 | 28 | 29 | |||
30 | 1 | 2 | 3 | 4 | 5 | 6 |
常用鏈接
留言簿(1)
隨筆分類
隨筆檔案
文章檔案
相冊
友情鏈接
- struts2系列教程
- VMware中用NAT方式實現FreeBsd/Linux上網
- 工作流和權限
- 緩存
- 花非花
- 好的java技術blog
- 設計模式
搜索
最新評論

- 1.?re: 源碼分析:HashMap
- 評論內容較長,點擊標題查看
- --Web 2.0 技術資源
- 2.?wow gold
- 評論內容較長,點擊標題查看
- --wow gold
- 3.?wow gold
- WoW Gold,Buy Wow Gold,Cheap WoW Gold,wow power leveling,world of warcraft gold
- --wow gold
- 4.?re: 最近買了Spring in Action 中文版。
- 后面的例子引用的不錯,雖然不是很懂,所以還要繼續努力
- --Jedliu
- 5.?re: 最近買了Spring in Action 中文版。
- 這本書我也買了
- --壞男孩