log4j.properties
超文本傳輸安全協議(縮寫:HTTPS,英語:Hypertext Transfer Protocol Secure)是超文本傳輸協議和SSL/TLS的組合,用以提供加密通訊及對網絡服務器身份的鑒定。HTTPS連接經常被用于萬維網上的交易支付和企業信息系統中敏感信息的傳輸。HTTPS不應與在RFC 2660中定義的安全超文本傳輸協議(S-HTTP)相混。
HTTPS的主要思想是在不安全的網絡上創建一安全信道,并可在使用適當的加密包和服務器證書可被驗證且可被信任時,對竊聽和中間人攻擊提供合理的保護。
HTTPS的信任繼承基于預先安裝在瀏覽器中的證書頒發機構(如VeriSign、Microsoft等)(意即“我信任證書頒發機構告訴我應該信任的”)。因此,一個到某網站的HTTPS連接可被信任,當且僅當:
https://example
時收到了給“Example Inc.”而不是其它組織的證書);HTTPS也可被用作客戶端認證手段來將一些信息限制給合法的用戶。要做到這樣,管理員通常會給每個用戶創建證書(通常包含了用戶的名字和電子郵件地址)。這個證書會被放置在瀏覽器中,并在每次連接到服務器時由服務器檢查。
證書可在其過期前被吊銷,通常情況是該證書的私鑰已經失密。較新的瀏覽器如Google Chrome、Firefox[7]、Opera[8]和運行在Windows Vista上的Internet Explorer[9]都實現了在線證書狀態協議(OCSP)以排除這種情形:瀏覽器將網站提供的證書的串行號通過OCSP發送給證書頒發機構,后者會告訴瀏覽器證書是否還是有效的。[10]
TLS有兩種策略:簡單策略和交互策略。交互策略更為安全,但需要用戶在他們的瀏覽器中安裝個人的證書來進行認證。
不管使用了哪種策略,協議所能提供的保護總強烈地依賴于瀏覽器的實現和服務器軟件所支持的加密算法。
HTTPS并不能防止站點被網絡蜘蛛抓取。在某些情形中,被加密資源的URL可僅通過截獲請求和響應的大小推得,[11]這就可使攻擊者同時知道明文(公開的靜態內容)和密文(被加密過的明文),從而使選擇密文攻擊成為可能。
因為SSL在HTTP之下工作,對上層協議一無所知,所以SSL服務器只能為一個IP地址/端口組合提供一個證書。[12]這就意味著在大部分情況下,使用HTTPS的同時支持基于名字的虛擬主機是不很現實的。一種叫域名指示(SNI)的方案通過在加密連接創建前向服務器發送主機名解決了這一問題。Firefox 2、Opera8和運行在Windows Vista的Internet Explorer 7都加入了對SNI的支持。[13][14][15]
因為HTTPS連接所用的公鑰以明文傳輸,因此中國大陸的防火長城可以對特定網站按照匹配的黑名單證書,通過偽裝成對方向連接兩端的計算機發送RST包干擾兩臺計算機間正常的TCP通訊,以打斷與特定IP地址之間的443端口握手,或者直接使握手的數據包丟棄,導致握手失敗,從而導致TLS連接失敗。[16]這也是一種互聯網信息審查和屏蔽的技術手段。
值傳遞(pass by value):stack(棧,常量、基本數據類型(八種)、對象引用、指令(對象的方法)),簡單類型。
引用傳遞(pss by reference):stack(棧)和heap(堆,對象實例(object instance))。
stream在引用傳遞的過程中,不要隨意關閉,一關都關!
double:雙精度浮點數,64位(bits)8字節,它可以表示十進制的15或16位有效數字。
float:單精度浮點數,32位(bits)4字節。
浮點:浮動小數點。
當部分網頁上面的JAVA插件無法運行,系統提示是由于您的安全設置,所以該運行程序被阻止了,此問題是由于您的JAVA安全設置的級別引起的。
JAVA安全設置修改方式:windows控制面板 -> 程序 -> Java -> 安全。
通常做法是定義一個Servlet,并在web.xml中配置Servlet的啟動順序<load-on-startup>的值在DispatcherServlet之后。但這樣做的缺點是在Servlet中無法使用Spring的依賴注入功能,只能使用WebApplicationContext的getBean()方法獲取bean。
找到的解決辦法如下:
1、自定義一個用于代理啟動Servlet的類DelegatingServletProxy:
2、編寫啟動Servlet:
3、在web.xml文件中配置InitialServlet :
在看這篇文章前,我推薦你看一下Eclipse 快捷鍵手冊,我的eclipse版本是4.2 Juno。
先提三點
想象一下我們平時如何添加斷點,通常的做法是雙擊行號的左邊。在debug視圖中,BreakPoint View將所有斷點都列出來,但是我們可以添加一個boolean類型的條件來決定斷點是否被跳過。如果條件為真,在斷點處程序將停止,否則斷點被跳過,程序繼續執行。
2、異常斷點
在斷點view中有一個看起來像J!的按鈕,我們可以使用它添加一個基于異常的斷點,例如我們希望當NullPointerException拋出的時候程序暫停,我們可以這樣:
3、觀察點
這個特性我非常喜歡,他允許當一個選定的屬性被訪問或者被更改的時候程序執行暫停,并進行debug。最簡單的辦法是在類中聲明成員變量的語句行號左邊雙擊,就可以加入一個觀察點。
4、查看變量
在選中的變量上使用Ctrl+Shift+d 或者 Ctrl+Shift+i可以查看變量值,另外我們還可以在Expressions View中添加監視。
5、改變變量值
我們可以在Debug的時候改變其中變量的值。在Variables View中可以按下圖所示操作。
10、進入、跳過、返回
摘要: 1、面向對象的特征有哪些方面 (1).抽象: 抽象就是忽略一個主題中與當前目標無關的那些方面,以便更充分地注意與當前目標有關的方面。抽象并不打算了解全部問題,而只是選擇其中的一部分,暫時不用部分細 節。抽象包括兩個方面,一是過程抽象,二是數據抽象。 (2).繼承: 繼承是一種聯結類的層次模型,并且允許和鼓勵類的重用,它提供了一種明確表述共性的方法。對象的一個... 閱讀全文
Beanutils用了魔術般的反射技術,實現了很多夸張有用的功能,都是C/C++時代不敢想的。無論誰的項目,始終一天都會用得上它。我算是后知后覺了,第一回看到它的時候居然錯過。
1.屬性的動態getter,setter
BeanUtils.getProperty(myBean,"code");
BeanUtils.getProperty(orderBean, "address.city");
BeanUtils.getProperty(orderBean, "customers[1].name");
2.beanCompartor 動態排序
List peoples = ...; // Person對象的列表Collections.sort(peoples, new BeanComparator("age"));
如果要支持多個屬性的復合排序,如"Order By lastName,firstName"
ArrayList sortFields = new ArrayList();sortFields.add(new BeanComparator("lastName"));
sortFields.add(new BeanComparator("firstName"));
ComparatorChain multiSort = new ComparatorChain(sortFields);
Collections.sort(rows,multiSort);
其中ComparatorChain屬于jakata commons-collections包。
如果age屬性不是普通類型,構造函數需要再傳入一個comparator對象為age變量排序。
另外, BeanCompartor本身的ComparebleComparator, 遇到屬性為null就會拋出異常, 也不能設定升序還是降序。
這個時候又要借助commons-collections包的ComparatorUtils.
Comparator mycmp = ComparableComparator.getInstance();
mycmp = ComparatorUtils.nullLowComparator(mycmp); //允許null
mycmp = ComparatorUtils.reversedComparator(mycmp); //逆序
Comparator cmp = new BeanComparator(sortColumn, mycmp);
經常要從request,resultSet等對象取出值來賦入bean中,下面的代碼誰都寫膩了,如果不用MVC框架的綁定功能的話。
String a = request.getParameter("a"); bean.setA(a); String b = ....
不妨寫一個Binder:
MyBean bean = ...; HashMap map = new HashMap(); Enumeration names = request.getParameterNames(); while (names.hasMoreElements()) { String name = (String) names.nextElement(); map.put(name, request.getParameterValues(name)); } BeanUtils.populate(bean, map);
其中BeanUtils的populate方法或者getProperty,setProperty方法其實都會調用convert進行轉換。
但Converter只支持一些基本的類型,甚至連java.util.Date類型也不支持。而且它比較笨的一個地方是當遇到不認識的類型時,居然會拋出異常來。
對于Date類型,我參考它的sqldate類型實現了一個Converter,而且添加了一個設置日期格式的函數。
要把這個Converter注冊,需要如下語句:
ConvertUtilsBean convertUtils = new ConvertUtilsBean();
DateConverter dateConverter = new DateConverter();
convertUtils.register(dateConverter,Date.class);
//因為要注冊converter,所以不能再使用BeanUtils的靜態方法了,必須創建BeanUtilsBean實例
BeanUtilsBean beanUtils = new BeanUtilsBean(convertUtils,new PropertyUtilsBean());
beanUtils.setProperty(bean, name, value);
4 其他功能 public static Class getPropertyType(Object bean, String name)
public static Object invokeConstructor(Class klass, Object arg)
4.4 MethodUtils,動態調用方法
MethodUtils.invokeMethod(bean, methodName, parameter);
4.5 動態Bean 見用DynaBean減除不必要的VO和FormBean
很久很久以前,有一群人,他們決定用8個可以開合的晶體管來組合成不同的狀態,以表示世界上的萬物。他們看到8個開關狀態是好的,于是他們把這稱為"字節"。
再后來,他們又做了一些可以處理這些字節的機器,機器開動了,可以用字節來組合出很多狀態,狀態開始變來變去。他們看到這樣是好的,于是它們就這機器稱為"計算機"。
開始計算機只在美國用。八位的字節一共可以組合出256(2的8次方)種不同的狀態。
他們把其中的編號從0開始的32種狀態分別規定了特殊的用途,一但終端、打印機遇上約定好的這些字節被傳過來時,就要做一些約定的動作。遇上00x10, 終端就換行,遇上0x07, 終端就向人們嘟嘟叫,例好遇上0x1b, 打印機就打印反白的字,或者終端就用彩色顯示字母。他們看到這樣很好,于是就把這些0x20以下的字節狀態稱為"控制碼"。
他們又把所有的空格、標點符號、數字、大小寫字母分別用連續的字節狀態表示,一直編到了第127號,這樣計算機就可以用不同字節來存儲英語的文字了。大家看到這樣,都感覺很好,于是大家都把這個方案叫做 ANSI 的"Ascii"編碼(American Standard Code for Information Interchange,美國信息互換標準代碼)。當時世界上所有的計算機都用同樣的ASCII方案來保存英文文字。
后來,就像建造巴比倫塔一樣,世界各地的都開始使用計算機,但是很多國家用的不是英文,他們的字母里有許多是ASCII里沒有的,為了可以在計算機保存他們的文字,他們決定采用127號之后的空位來表示這些新的字母、符號,還加入了很多畫表格時需要用下到的橫線、豎線、交叉等形狀,一直把序號編到了最后一個狀態255。從128到255這一頁的字符集被稱"擴展字符集"。從此之后,貪婪的人類再沒有新的狀態可以用了,美帝國主義可能沒有想到還有第三世界國家的人們也希望可以用到計算機吧!
等中國人們得到計算機時,已經沒有可以利用的字節狀態來表示漢字,況且有6000多個常用漢字需要保存呢。但是這難不倒智慧的中國人民,我們不客氣地把那些127號之后的奇異符號們直接取消掉, 規定:一個小于127的字符的意義與原來相同,但兩個大于127的字符連在一起時,就表示一個漢字,前面的一個字節(他稱之為高字節)從0xA1用到0xF7,后面一個字節(低字節)從0xA1到0xFE,這樣我們就可以組合出大約7000多個簡體漢字了。在這些編碼里,我們還把數學符號、羅馬希臘的字母、日文的假名們都編進去了,連在 ASCII 里本來就有的數字、標點、字母都統統重新編了兩個字節長的編碼,這就是常說的"全角"字符,而原來在127號以下的那些就叫"半角"字符了。
中國人民看到這樣很不錯,于是就把這種漢字方案叫做 "GB2312"。GB2312 是對 ASCII 的中文擴展。
但是中國的漢字太多了,我們很快就就發現有許多人的人名沒有辦法在這里打出來,特別是某些很會麻煩別人的國家領導人。于是我們不得不繼續把 GB2312 沒有用到的碼位找出來老實不客氣地用上。
后來還是不夠用,于是干脆不再要求低字節一定是127號之后的內碼,只要第一個字節是大于127就固定表示這是一個漢字的開始,不管后面跟的是不是擴展字符集里的內容。結果擴展之后的編碼方案被稱為 GBK 標準,GBK 包括了 GB2312 的所有內容,同時又增加了近20000個新的漢字(包括繁體字)和符號。
后來少數民族也要用電腦了,于是我們再擴展,又加了幾千個新的少數民族的字,GBK 擴成了 GB18030。從此之后,中華民族的文化就可以在計算機時代中傳承了。
中國的程序員們看到這一系列漢字編碼的標準是好的,于是通稱他們叫做 "DBCS"(Double Byte Charecter Set 雙字節字符集)。在DBCS系列標準里,最大的特點是兩字節長的漢字字符和一字節長的英文字符并存于同一套編碼方案里,因此他們寫的程序為了支持中文處理,必須要注意字串里的每一個字節的值,如果這個值是大于127的,那么就認為一個雙字節字符集里的字符出現了。那時候凡是受過加持,會編程的計算機僧侶們都要每天念下面這個咒語數百遍:
"一個漢字算兩個英文字符!一個漢字算兩個英文字符......"
因為當時各個國家都像中國這樣搞出一套自己的編碼標準,結果互相之間誰也不懂誰的編碼,誰也不支持別人的編碼,連大陸和臺灣這樣只相隔了150海里,使用著同一種語言的兄弟地區,也分別采用了不同的 DBCS 編碼方案。當時的中國人想讓電腦顯示漢字,就必須裝上一個"漢字系統",專門用來處理漢字的顯示、輸入的問題,但是那個臺灣的愚昧封建人士寫的算命程序就必須加裝另一套支持 BIG5 編碼的什么"倚天漢字系統"才可以用,裝錯了字符系統,顯示就會亂了套!這怎么辦?而且世界民族之林中還有那些一時用不上電腦的窮苦人民,他們的文字又怎么辦?
真是計算機的巴比倫塔命題啊!
正在這時,大天使加百列及時出現了:一個叫 ISO (國際標誰化組織)的國際組織決定著手解決這個問題。他們采用的方法很簡單:廢了所有的地區性編碼方案,重新搞一個包括了地球上所有文化、所有字母和符號的編碼!他們打算叫它"Universal Multiple-Octet Coded Character Set",簡稱 UCS, 俗稱 "UNICODE"。
UNICODE 開始制訂時,計算機的存儲器容量極大地發展了,空間再也不成為問題了。于是 ISO 就直接規定必須用兩個字節,也就是16位來統一表示所有的字符,對于ascii里的那些"半角"字符,UNICODE 包持其原編碼不變,只是將其長度由原來的8位擴展為16位,而其他文化和語言的字符則全部重新統一編碼。由于"半角"英文符號只需要用到低8位,所以其高8位永遠是0,因此這種大氣的方案在保存英文文本時會多浪費一倍的空間。
這時候,從舊社會里走過來的程序員開始發現一個奇怪的現象:他們的strlen函數靠不住了,一個漢字不再是相當于兩個字符了,而是一個!是的,從 UNICODE 開始,無論是半角的英文字母,還是全角的漢字,它們都是統一的"一個字符"!同時,也都是統一的"兩個字節",請注意"字符"和"字節"兩個術語的不同,"字節"是一個8位的物理存貯單元,而"字符"則是一個文化相關的符號。在UNICODE 中,一個字符就是兩個字節。一個漢字算兩個英文字符的時代已經快過去了。
從前多種字符集存在時,那些做多語言軟件的公司遇上過很大麻煩,他們為了在不同的國家銷售同一套軟件,就不得不在區域化軟件時也加持那個雙字節字符集咒語,不僅要處處小心不要搞錯,還要把軟件中的文字在不同的字符集中轉來轉去。UNICODE 對于他們來說是一個很好的一攬子解決方案,于是從 Windows NT 開始,MS 趁機把它們的操作系統改了一遍,把所有的核心代碼都改成了用 UNICODE 方式工作的版本,從這時開始,WINDOWS 系統終于無需要加裝各種本土語言系統,就可以顯示全世界上所有文化的字符了。
但是,UNICODE 在制訂時沒有考慮與任何一種現有的編碼方案保持兼容,這使得 GBK 與UNICODE 在漢字的內碼編排上完全是不一樣的,沒有一種簡單的算術方法可以把文本內容從UNICODE編碼和另一種編碼進行轉換,這種轉換必須通過查表來進行。
如前所述,UNICODE 是用兩個字節來表示為一個字符,他總共可以組合出65535不同的字符,這大概已經可以覆蓋世界上所有文化的符號。如果還不夠也沒有關系,ISO已經準備了UCS-4方案,說簡單了就是四個字節來表示一個字符,這樣我們就可以組合出21億個不同的字符出來(最高位有其他用途),這大概可以用到銀河聯邦成立那一天吧!
UNICODE 來到時,一起到來的還有計算機網絡的興起,UNICODE 如何在網絡上傳輸也是一個必須考慮的問題,于是面向傳輸的眾多 UTF(UCS Transfer Format)標準出現了,顧名思義,UTF8就是每次8個位傳輸數據,而UTF16就是每次16個位,只不過為了傳輸時的可靠性,從UNICODE到UTF時并不是直接的對應,而是要過一些算法和規則來轉換。
受到過網絡編程加持的計算機僧侶們都知道,在網絡里傳遞信息時有一個很重要的問題,就是對于數據高低位的解讀方式,一些計算機是采用低位先發送的方法,例如我們PC機采用的 INTEL 架構,而另一些是采用高位先發送的方式,在網絡中交換數據時,為了核對雙方對于高低位的認識是否是一致的,采用了一種很簡便的方法,就是在文本流的開始時向對方發送一個標志符。如果之后的文本是高位在位,那就發送"FEFF",反之,則發送"FFFE"。不信你可以用二進制方式打開一個UTF-X格式的文件,看看開頭兩個字節是不是這兩個字節?
講到這里,我們再順便說說一個很著名的奇怪現象:當你在 windows 的記事本里新建一個文件,輸入"聯通"兩個字之后,保存,關閉,然后再次打開,你會發現這兩個字已經消失了,代之的是幾個亂碼!呵呵,有人說這就是聯通之所以拼不過移動的原因。
其實這是因為GB2312編碼與UTF8編碼產生了編碼沖撞的原因。
從網上引來一段從UNICODE到UTF8的轉換規則:
Unicode
UTF-8
0000 - 007F
0xxxxxxx
0080 - 07FF
110xxxxx 10xxxxxx
0800 - FFFF
1110xxxx 10xxxxxx 10xxxxxx
例如"漢"字的Unicode編碼是6C49。6C49在0800-FFFF之間,所以要用3字節模板:1110xxxx 10xxxxxx 10xxxxxx。將6C49寫成二進制是:0110 1100 0100 1001,將這個比特流按三字節模板的分段方法分為0110 110001 001001,依次代替模板中的x,得到:1110-0110 10-110001 10-001001,即E6 B1 89,這就是其UTF8的編碼。
而當你新建一個文本文件時,記事本的編碼默認是ANSI, 如果你在ANSI的編碼輸入漢字,那么他實際就是GB系列的編碼方式,在這種編碼下,"聯通"的內碼是:
c1 1100 0001
aa 1010 1010
cd 1100 1101
a8 1010 1000
注意到了嗎?第一二個字節、第三四個字節的起始部分的都是"110"和"10",正好與UTF8規則里的兩字節模板是一致的,于是再次打開記事本時,記事本就誤認為這是一個UTF8編碼的文件,讓我們把第一個字節的110和第二個字節的10去掉,我們就得到了"00001 101010",再把各位對齊,補上前導的0,就得到了"0000 0000 0110 1010",不好意思,這是UNICODE的006A,也就是小寫的字母"j",而之后的兩字節用UTF8解碼之后是0368,這個字符什么也不是。這就是只有"聯通"兩個字的文件沒有辦法在記事本里正常顯示的原因。
而如果你在"聯通"之后多輸入幾個字,其他的字的編碼不見得又恰好是110和10開始的字節,這樣再次打開時,記事本就不會堅持這是一個utf8編碼的文件,而會用ANSI的方式解讀之,這時亂碼又不出現了。
--創建用戶
CREATE USER "APITEST" PROFILE "DEFAULT"
IDENTIFIED BY "apitest" DEFAULT TABLESPACE "LOUSHANG"
TEMPORARY TABLESPACE "TEMP"
ACCOUNT UNLOCK;
--為用戶指定表空間
GRANT UNLIMITED TABLESPACE TO "APITEST";
--為用戶授權
GRANT "CONNECT" TO "APITEST";
GRANT "DBA" TO "APITEST";
GRANT "RESOURCE" TO "APITEST";
--將鎖定用戶解鎖
alter user <用戶名> account unlock;
--修改用戶密碼
alter user <用戶名> identified by <新密碼>;
--刪除用戶
drop user apitest; ----僅僅是刪除用戶,
drop user apitest cascade ;----會刪除此用戶名下的所有表和視圖。
---查看當前用戶信息
select * from user_users;
---查詢當前數據庫實例中有哪些用戶
select * from dba_users order by username;
---查看當前用戶擁有的角色
select * from user_role_privs;
---查看當前用戶所擁有的表
select * from user_tables;
---查看當前用戶所擁有表的列
select * from USER_TAB_COLUMNS ;
---顯示特權用戶(一般包括sys、system)
select * from v$pwfile_users;
---查詢當前用戶所擁有的所有對象(表、視圖、索引、存儲函數和過程等)
select * from user_objects
----查看序列號
select * from user_sequences;
---查看當前用戶所有的視圖
select * from user_views;
--查看當前連接信息
select SID,SERIAL#,USERNAME,MACHINE,LOGON_TIME from v$session where username='APITEST';
--斷開指定連接
alter system kill session '530,49177';
DAO層的代碼分頁代碼:
public PageModel findByPageModel(String hql,PageModel pm) {
pm.setTotalCount(this.getHibernateTemplate().find(hql).size());
pm.setGoToHref(ServletActionContext.getRequest().getServletPath().replace("/",""));
int totalCount = pm.getTotalCount();
int pageSize = pm.getPageSize();
int totalPage = (totalCount+pageSize-1)/pageSize ;
int currentPage = pm.getCurrentPage() ;
pm.setTotalPage(totalPage);
int offset = (currentPage-1)*pageSize;
pm.setList(this.getSession().createQuery(hql).setFirstResult(offset).setMaxResults(pageSize).list());
return pm;
}
分頁的JAVABEAN:
public class PageModel {
private int currentPage;
private int pageSize;
private int totalCount;
private int totalPage;
private List list ;
private String goToHref;
public int getCurrentPage() {
if(currentPage<=0) currentPage=1;
return currentPage;
}
public void setCurrentPage(int currentPage) {
this.currentPage = currentPage;
}
public int getPageSize() {
if(pageSize<=0) pageSize=10;
return pageSize;
}
public void setPageSize(int pageSize) {
this.pageSize = pageSize;
}
public int getTotalCount() {
return totalCount;
}
public void setTotalCount(int totalCount) {
this.totalCount = totalCount;
}
public int getTotalPage() {
return totalPage;
}
public void setTotalPage(int totalPage) {
this.totalPage = totalPage;
}
public List getList() {
return list;
}
public void setList(List list) {
this.list = list;
}
public String getGoToHref() {
return goToHref;
}
public void setGoToHref(String goToHref) {
this.goToHref = goToHref;
}
}
JSP頁面:
<%@ page language="java" import="java.util.*" pageEncoding="UTF-8"%>
<%
String path = request.getContextPath();
String basePath = request.getScheme()+"://"+request.getServerName()+":"+request.getServerPort()+path+"/";
%>
<link rel="stylesheet" type="text/css" href="<%=basePath %>findByHql/pagingBar/css/pagingBar.css">
<input type="button" class="firstPage commonPage" alt="首頁" title="首頁"/>
<input type="button" class="beforePage commonPage" alt="上一頁" title="上一頁"/>
<input type="button" class="nextPage commonPage" alt="下一頁" title="下一頁"/>
<input type="button" class="lastPage commonPage" alt="尾頁" title="尾頁" />
<input type="hidden" id="currentPage" value="${requestScope.pm.currentPage }" />
<input type="hidden" id="totalPage" value="${requestScope.pm.totalPage }" />
<input type="hidden" id="goToHref" value="${requestScope.pm.goToHref }" />
<span class="cp">當前第${requestScope.pm.currentPage }頁</span>
<span class="tc"> 相關資訊:${requestScope.pm.totalCount }條</span>
<span class="ps">每頁${requestScope.pm.pageSize }條 </span>
<span class="tp">共${requestScope.pm.totalPage}頁</span>
<script type="text/javascript" src="<%=basePath%>js/jquery.js"></script>
<script type="text/javascript">
(function($) {
var currentPage = parseInt($('#currentPage').val());
var totalPage = parseInt($('#totalPage').val());
var toHref = $('#goToHref').val();
$('.firstPage').bind('click', function() {
goToHref(1);
});
$('.nextPage').bind('click', function() {
if (currentPage >= totalPage)
goToHref(totalPage);
else
goToHref(currentPage + 1);
});
$('.beforePage').bind('click', function() {
if (currentPage <= 1)
goToHref(1);
else
goToHref(currentPage - 1);
});
$('.lastPage').bind('click', function() {
goToHref(totalPage);
});
function goToHref(cp) {
document.location.href = toHref+"?currentPage=" + cp;
}
})(jQuery)
</script>
CSS:下面有幾張圖片需要自己找...
/*點擊欄*/
.commonPage{
width: 16px;
height: 16px;
border: none;
cursor: pointer;
}
.firstPage{
background: url("../images/page-first.png") no-repeat;
}
.nextPage{
background: url("../images/page-next.png") no-repeat;
}
.beforePage{
background: url("../images/page-prev.png") no-repeat;
}
.lastPage{
background: url("../images/page-last.png") no-repeat;
}
/*顯示欄*/
.cp,.tc,.ps,.tp{
font-size: 14px;
}
在action中調用DAO層的方法,給currentPage和pageSize設置初始值,然后就返回一個list到你分頁的頁面迭代,以后就直接嵌套在分頁頁面中就行
這也許是你一直期待的文章,在關注這部分技術問題的同時,請務必閱讀有關面試中有關個人的問題和解答。這里的回答并不是十分全面,這些問題可以通過多個角度來進行解釋,也許你不必在面試過程中給出完全詳盡的答案,只需要通過你的解答使面試考官了解你對ORACLE概念的熟悉程度。
1.解釋冷備份和熱備份的不同點以及各自的優點
解答:熱備份針對歸檔模式的數據庫,在數據庫仍舊處于工作狀態時進行備份。而冷備份指在數據庫關閉后,進行備份,適用于所有模式的數據庫。熱備份的優點在于當備份時,數據庫仍舊可以被使用并且可以將數據庫恢復到任意一個時間點。冷備份的優點在于它的備份和恢復操作相當簡單,并且由于冷備份的數據庫可以工作在非歸檔模式下,數據庫性能會比歸檔模式稍好。(因為不必將archive log寫入硬盤)
2.你必須利用備份恢復數據庫,但是你沒有控制文件,該如何解決問題呢?
解答:重建控制文件,用帶backup control file 子句的recover 命令恢復數據庫。
3.如何轉換init.ora到spfile?
解答:使用create spfile from pfile 命令.
4.解釋data block , extent 和 segment的區別(這里建議用英文術語)
解答:data block是數據庫中最小的邏輯存儲單元。當數據庫的對象需要更多的物理存儲空間時,連續的data block就組成了extent . 一個數據庫對象擁有的所有extents被稱為該對象的segment.
5.給出兩個檢查表結構的方法
解答:1.DESCRIBE命令
2.DBMS_METADATA.GET_DDL 包
6.怎樣查看數據庫引擎的報錯
解答:alert log.
7.比較truncate和delete 命令
解答:兩者都可以用來刪除表中所有的記錄。區別在于:truncate是DDL操作,它移動HWK,不需要rollback segment .而Delete是DML操作, 需要rollback segment 且花費較長時間.
8.使用索引的理由
解答:快速訪問表中的data block
9.給出在STAR SCHEMA中的兩種表及它們分別含有的數據
解答:Fact tables 和dimension tables. fact table包含大量的主要的信息而dimension tables 存放對fact table 某些屬性描述的信息
10.FACT Table上需要建立何種索引?
解答:位圖索引 (bitmap index)
11. 給出兩種相關約束?
解答:主鍵和外鍵
12. 如何在不影響子表的前提下,重建一個母表
解答:子表的外鍵強制實效,重建母表,激活外鍵
13. 解釋歸檔和非歸檔模式之間的不同和它們各自的優缺點
解答:歸檔模式是指你可以備份所有的數據庫 transactions并恢復到任意一個時間點。非歸檔模式則相反,不能恢復到任意一個時間點。但是非歸檔模式可以帶來數據庫性能上的少許提高.
14. 如何建立一個備份控制文件?
解答:Alter database backup control file to trace.
15. 給出數據庫正常啟動所經歷的幾種狀態 ?
解答:STARTUP NOMOUNT – 數據庫實例啟動
STARTUP MOUNT - 數據庫裝載
STARTUP OPEN – 數據庫打開
16. 哪個column可以用來區別V$視圖和GV$視圖?
解答:INST_ID 指明集群環境中具體的 某個instance 。
17. 如何生成explain plan?
解答:運行utlxplan.sql. 建立plan 表
針對特定SQL語句,使用 explain plan set statement_id = 'tst1' into plan_table
運行utlxplp.sql 或 utlxpls.sql察看explain plan
18. 如何增加buffer cache的命中率?
解答:在數據庫較繁忙時,適用buffer cache advisory 工具,查詢v$db_cache_advice.如果有必要更改,可以使用 alter system set db_cache_size 命令
19. ORA-01555的應對方法?
解答:具體的出錯信息是snapshot too old within rollback seg , 通常可以通過增大rollback seg來解決問題。當然也需要察看一下具體造成錯誤的SQL文本
20. 解釋$ORACLE_HOME和$ORACLE_BASE的區別?
解答:ORACLE_BASE是oracle的根目錄,ORACLE_HOME是oracle產品的目錄。
技術債務, 是指匆忙的實現一個功能,卻對現有的程序庫造成了破壞(在實現的過程中污染了代碼庫的設計),這對于一些項目經理/客戶來說就像是天書奇談。也許他們是明 白的,只是不愿意承認罷了,我估計是這樣的。不管怎樣,我想起來一個小故事,當下次遇到這種情況,需要向他們解釋增加某些新功能的代價時,也可用講這個故 事給他們聽。
一個農夫有3只母雞。每只母雞每天下一個蛋。農夫跟當地的一個食品店老板做生意。食品店老板每天從農夫那里買2給雞蛋放在店里出售。一切都很好,直到有一天,食品店老板出現在農夫家里:
食品店老板: 哎呀,今天我需要一些雞肉。
農夫: 雞肉?你和我的生意里可不包括這些。
食品店老板: 我知道。但我真的需要一些雞肉。我計劃要做一個B2S(S是胃的縮寫)模式的PaaS(P是肉禽的縮寫)平臺。
農夫: 什么?
食品店老板: 非常重要的東西。你可以提供我一些雞肉嗎?
農夫: 這樣呀,事情不是那么容易辦到 — 我要孵化雞蛋,等小雞長大了才能給你…少說也要一個月吧。
食品店老板: 一個月?太久了…我以為你現在就能給我呢。
農夫: 時間有自己的腳步,你必須耐心一點等。
食品店老板: 可是,為什么你不能在現有的母雞中殺一個呢?這樣一來,我有了雞肉,你每天還能產兩個蛋。這就夠了,不是嗎?
農夫: 可是,我不覺得這是一個好主意。這會把我推向一個沒有回旋余地的境況,萬一剩下的雞中有一只突然出了什么意外怎么辦。
食品店老板: 放心啦,不會發生那樣的事的…我真的非常非常需要雞肉!殺一只雞吧!
農夫: 那好吧,我想我可以…
于是,農夫拿起一把刀,把他的一只母雞送入了天堂。食品店老板得到了他的雞肉,返回了食品店。
一周后,食品店老板又一次來到了農夫家里:
食品店老板: 你好,我來了!
農夫: 你好,有什么事?
食品店老板: 你聽我說 — 你的雞肉好極了。事實上,它是如此的鮮美,賣的如此的好,你必須要再給我一只雞。最遲明天早上。
農夫: 這是不可能的事。如果我要再殺一只雞給你,我就沒法每天提供你兩個雞蛋了。
食品店老板: 哦,別那么緊張!客戶需要雞肉,我已經答應客戶明天早上提供給他們了…
農夫: 不行,絕對不能這么干。如果我這么做,我就履行不了我和你的協議了,你知道嗎?如果我這么做,我就沒法提供你足夠的雞蛋了。
食品店老板: 可是我真的真的需要雞肉!明天早上之前!否則客戶會發飆的,地球將會塌陷,世界末日將會到來!給我一只雞吧,現在!
農夫: 那好吧,如果你非要這么不顧后果的想要,那就拿去吧!但是,從現在開始,雞蛋我是沒法提供你了,明白?
食品店老板: 當然,當然。但我相信是個很聰明的人,我猜你能找到方法解決這個問題。再見!
食品店老板離開回到了店里。
第二天:
食品店老板: 嗨,雞蛋呢?
農夫: 你什么意思?
食品店老板: 雞蛋。你只給了我一個雞蛋。發生了什么事?
農夫: 發生了什么事?我有3只雞,你拿走了兩只。現在就剩下一只。一只雞,一個雞蛋。我認為我解釋的已經很清楚了。
食品店老板: 但是合同里并沒有這些!合同里說的很清楚 — 你每天提供我2給雞蛋!你現在讓我向客戶怎么交代?
農夫: 哦,情況我很明白。我無能為力。
食品店老板: 好吧,好吧,不談這事了。咱們聊點其它事情…要是能再能點雞肉就好了。你再給我一些吧?
所以,千萬別學農夫 — 堅決拒絕為了當前利益而長久的破壞你的代碼庫的無理要求,如果你被強迫這樣做,拒絕承擔這樣的任務 — 也不要做食品店老板 — 不要做提出這樣不合理的要求,你要為自己的決定承擔后果。
[代碼] web.xml
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
<!--spring 的配置文件-->
classpath:/applicationContext-hibernate.xml
</param-value>
</context-param>
<!-- shiro -->
<filter>
<filter-name>shiroFilter</filter-name>
<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
<init-param>
<param-name>targetFilterLifecycle</param-name>
<param-value>true</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>shiroFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<!-- Listeners -->
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
[代碼] applicationContext-hibernate.xml
<?xml version="1.0" encoding="UTF-8"?> <!-- SessionFactory, DataSource, etc. omitted --> <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" <bean id="sessionFactory" <bean id="txManager" <tx:advice id="txAdvice" transaction-manager="txManager"> <aop:config> <!-- shiro --> <bean </beans> public class GradRealm extends AuthorizingRealm { private SecurityApplication securityApplication = new SecurityApplicationImpl(); public GradRealm() { } //認證
<beans xmlns=" xmlns:xsi=" xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx-3.0.xsd
http://www.springframework.org/schema/aop
destroy-method="close">
<property name="driverClassName" value="${jdbc.driverClassName}" />
<property name="url" value="${jdbc.url}" />
<property name="username" value="${jdbc.username}" />
<property name="password" value="${jdbc.password}" />
</bean>
class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
<property name="dataSource" ref="dataSource" />
<property name="packagesToScan">
<list>
<value>org.projects.graduates.domain</value>
</list>
</property>
<property name="hibernateProperties">
<value>hibernate.dialect=${hibernate.dialect}</value>
</property>
</bean>
class="org.springframework.orm.hibernate3.HibernateTransactionManager">
<property name="sessionFactory" ref="sessionFactory" />
</bean>
<tx:attributes>
<tx:method name="get*" read-only="true" />
<tx:method name="find*" read-only="true" />
<tx:method name="*" propagation="REQUIRED" />
</tx:attributes>
</tx:advice>
<aop:pointcut id="appOperation"
expression="execution(* org.projects.graduates.app.GradApplication.*(..))" />
<aop:advisor advice-ref="txAdvice" pointcut-ref="appOperation" />
</aop:config>
<bean id="shiroFilter" class="org.apache.shiro.spring.web.ShiroFilterFactoryBean">
<property name="securityManager" ref="securityManager" />
<property name="loginUrl" value="/login.action" />
<property name="successUrl" value="/main.action" />
<property name="unauthorizedUrl" value="/login.action" />
<property name="filterChainDefinitions">
<value>
/index.action = anon
/login.action = anon
/main.action = authc, roles[admin]
/course/** = authc, roles[admin]
</value>
</property>
</bean>
<bean id="securityManager" class="org.apache.shiro.web.mgt.DefaultWebSecurityManager">
<!--設置自定義realm-->
<property name="realm" ref="myRealm" />
</bean>
<bean id="lifecycleBeanPostProcessor" class="org.apache.shiro.spring.LifecycleBeanPostProcessor" />
<!--myRealm 繼承自AuthorizingRealm-->
<bean id="myRealm" class="org.projects.graduates.shiro.GradRealm" ></bean>
class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
<property name="staticMethod"
value="org.apache.shiro.SecurityUtils.setSecurityManager" />
<property name="arguments" ref="securityManager" />
</bean>
super();
//設置認證token的實現類
setAuthenticationTokenClass(UsernamePasswordToken.class);
//設置加密算法
setCredentialsMatcher(new HashedCredentialsMatcher(Sha1Hash.ALGORITHM_NAME));
}
//授權
protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principalCollection) {
String loginName = (String) principalCollection.fromRealm(getName()).iterator().next();
User user = securityApplication.findby(loginName);
if (null == user) {
return null;
} else {
SimpleAuthorizationInfo result = new SimpleAuthorizationInfo();
result.addRoles(UserRoles.findRoleNamesOf(user));
for (Role role : UserRoles.findRolesOf(user)) {
result.addStringPermissions(role.getPermissions());
}
return result;
}
protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token) throws AuthenticationException {
UsernamePasswordToken upToken = (UsernamePasswordToken) token;
User user = securityApplication.findby(upToken.getUsername());
if (user != null) {
return new SimpleAuthenticationInfo(user.getUsername(), user.getPassword(), getName());
}
return null;
}
}
問題
某海量用戶網站,用戶擁有積分,積分可能會在使用過程中隨時更新。現在要為該網站設計一種算法,在每次用戶登錄時顯示其當前積分排名。用戶最大規模為2億;積分為非負整數,且小于100萬。
PS: 據說這是迅雷的一道面試題,不過問題本身具有很強的真實性,所以本文打算按照真實場景來考慮,而不局限于面試題的理想環境。
存儲結構
首先,我們用一張用戶積分表user_score來保存用戶的積分信息:
表結構:
示例數據:
下面的算法會基于這個基本的表結構來進行。
算法1:簡單SQL查詢
首先,我們很容易想到用一條簡單的SQL語句查詢出積分大于該用戶積分的用戶數量:
select 1 + count(t2.uid) as rank
from user_score t1, user_score t2
where t1.uid = @uid and t2.score > t1.score
對于4號用戶我們可以得到下面的結果:
算法1總結
優點:簡單,利用了SQL的功能,不需要復雜的查詢邏輯,也不引入額外的存儲結構,對小規模或性能要求不高的應用不失為一種良好的解決方案。
缺點:需要對user_score表進行全表掃描,還需要考慮到查詢的同時若有積分更新會對表造成鎖定,在海量數據規模和高并發的應用中,性能是無法接受的。
算法2:均勻分區設計
在許多應用中緩存是解決性能問題的重要途徑,我們自然會想能不能把用戶排名用Memcached緩存下來呢?不過再一想發現緩存似乎幫不上什么忙,因為用戶排名是一個全局性的統計性指標,而并非用戶的私有屬性,其他用戶的積分變化可能會馬上影響到本用戶的排名。然而,真實的應用中積分的變化其實也是有一定規律的,通常一個用戶的積分不會突然暴增暴減,一般用戶總是要在低分區混跡很長一段時間才會慢慢升入高分區,也就是說用戶積分的分布總體說來是有區段的,我們進一步注意到高分區用戶積分的細微變化其實對低分段用戶的排名影響不大。于是,我們可以想到按積分區段進行統計的方法,引入一張分區積分表score_range:
表結構:
數據示例:
表示[from_score, to_score)區間有count個用戶。若我們按每1000分劃分一個區間則有[0, 1000), [1000, 2000), …, [999000, 1000000)這1000個區間,以后對用戶積分的更新要相應地更新score_range表的區間值。在分區積分表的輔助下查詢積分為s的用戶的排名,可以首先確定其所屬區間,把高于s的積分區間的count值累加,然后再查詢出該用戶在本區間內的排名,二者相加即可獲得用戶的排名。
乍一看,這個方法貌似通過區間聚合減少了查詢計算量,實則不然。最大的問題在于如何查詢用戶在本區間內的排名呢?如果是在算法1中的SQL中加上積分條件:
select 1 + count(t2.uid) as rank
from user_score t1, user_score t2
where t1.uid = @uid and t2.score > t1.score and t2.score < @to_score
在理想情況下,由于把t2.score的范圍限制在了1000以內,如果對score字段建立索引,我們期望本條SQL語句將通過索引大大減少掃描的user_score表的行數。不過真實情況并非如此,t2.score的范圍在1000以內并不意味著該區間內的用戶數也是1000,因為這里有積分相同的情況存在!二八定律告訴我們,前20%的低分區往往集中了80%的用戶,這就是說對于大量低分區用戶進行區間內排名查詢的性能遠不及對少數的高分區用戶,所以在一般情況下這種分區方法不會帶來實質性的性能提升。
算法2總結
優點:注意到了積分區間的存在,并通過預先聚合消除查詢的全表掃描
缺點:積分非均勻分布的特點使得性能提升并不理想
算法3:樹形分區設計
均勻分區查詢算法的失敗是由于積分分布的非均勻性,那么我們自然就會想,能不能按二八定律,把score_range表設計為非均勻區間呢?比如,把低分區劃密集一點,10分一個區間,然后逐漸變成100分,1000分,10000分 … 當然,這不失為一種方法,不過這種分法有一定的隨意性,不容易把握好,而且整個系統的積分分布會隨著使用而逐漸發生變化,最初的較好的分區方法可能會變得不適應未來的情況了。我們希望找到一種分區方法,既可以適應積分非均勻性,又可以適應系統積分分布的變化,這就是樹形分區。
我們可以把[0, 1,000,000)作為一級區間;再把一級區間分為兩個2級區間[0, 500,000), [500,000, 1,000,000),然后把二級區間二分為4個3級區間[0, 250,000), [250,000, 500,000), [500,000, 750,000), [750,000, 1,000,000),依此類推,最終我們會得到1,000,000個21級區間[0,1), [1,2) … [999,999, 1,000,000)。這實際上是把區間組織成了一種平衡二叉樹結構,根結點代表一級區間,每個非葉子結點有兩個子結點,左子結點代表低分區間,右子結點代表高分區間。樹形分區結構需要在更新時保持一種不變量(Invariant):非葉子結點的count值總是等于其左右子結點的count值之和。
以后,每次用戶積分有變化所需要更新的區間數量和積分變化量有關系,積分變化越小更新的區間層次越低。總體上,每次所需要更新的區間數量是用戶積分變量的log(n)級別的,也就是說如果用戶積分一次變化在百萬級,更新區間的數量在二十這個級別。在這種樹形分區積分表的輔助下查詢積分為s的用戶排名,實際上是一個在區間樹上由上至下、由粗到細一步步明確s所在位置的過程。比如,對于積分499,000,我們用一個初值為0的排名變量來做累加;首先,它屬于1級區間的左子樹[0, 500,000),那么該用戶排名應該在右子樹[500,000, 1,000,000)的用戶數count之后,我們把該count值累加到該用戶排名變量,進入下一級區間;其次,它屬于3級區間的[250,000, 500,000),這是2級區間的右子樹,所以不用累加count到排名變量,直接進入下一級區間;再次,它屬于4級區間的…;直到最后我們把用戶積分精確定位在21級區間[499,000, 499,001),整個累加過程完成,得出排名!
雖然,本算法的更新和查詢都涉及到若干個操作,但如果我們為區間的from_score和to_score建立索引,這些操作都是基于鍵的查詢和更新,不會產生表掃描,因此效率更高。另外,本算法并不依賴于關系數據模型和SQL運算,可以輕易地改造為NoSQL等其他存儲方式,而基于鍵的操作也很容易引入緩存機制進一步優化性能。
算法3總結
優點:結構穩定,不受積分分布影響;每次查詢或更新的復雜度為積分最大值的log(n)級別,且與用戶規模無關,可以應對海量規模;不依賴于SQL,容易改造為NoSQL等其他存儲方式
缺點:算法相對更復雜
總結
上面介紹了用戶積分排名的3種算法,算法1簡單易于理解和實現,適用于小規模和低并發應用;算法3引入了更復雜的樹形分區結構,但是性能優越,可以應用于海量規模和高并發。本問題是一個開放性的問題,相信一定還有其他優秀的算法和解決方案,歡迎探討!