一.設(shè)置主機(jī)名
安裝好linux虛擬機(jī)后，查看主機(jī)名： uname -n 或 hostname命令
點(diǎn)擊(此處)折疊或打開
[zhang@localhost etc]$ uname -n
localhost.localdomain
[zhang@localhost etc]$ hostname
localhost.localdomain
1.臨時 修改主機(jī)名
通過 hostname newhost 命令，這種方式，重啟后失效。
2.永久修改主機(jī)名
修改配置文件 /etc/sysconfig/network
點(diǎn)擊(此處)折疊或打開
[zhang@localhost etc]$ cat /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=localhost.localdomain
修改后，需要重啟，生效！
3.配置文件 /etc/hosts 的作用
這個文件的作用是提供 IP 與 主機(jī)名對照，即 IP域名 解析的作用。
文件格式：
IP 全局主機(jī)名 主機(jī)的別名
cat /etc/hosts
點(diǎn)擊(此處)折疊或打開
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
10.10.10.128 namenode master
二.設(shè)置靜態(tài)IP
用root 用戶
編輯網(wǎng)卡配置文件
vi /etc/sysconfig/network-script/ifcfg-eth0
進(jìn)入編輯模式
按i鍵進(jìn)行編輯
修改
DEVICE=eth0 #物理設(shè)備名
IPADDR=10.10.10.128 #IP地址
NETMASK=255.255.255.0 #掩碼值
NETWORK=10.10.10.1 #網(wǎng)絡(luò)地址(可不要)
BROADCAST=10.10.10.255 #廣播地址（可不要）
GATEWAY=10.10.10.1 #網(wǎng)關(guān)地址
ONBOOT=yes # [yes|no]（引導(dǎo)時是否激活設(shè)備）
USERCTL=no #[yes|no]（非root用戶是否可以控制該設(shè)備）
BOOTPROTO=static #[none|static|bootp|dhcp]（引導(dǎo)時不使用協(xié)議|靜態(tài)分配|BOOTP協(xié)議|DHCP協(xié)議）
然后修改DNS配置文件
vi /etc/resolv.conf
進(jìn)入編輯模式
按i鍵進(jìn)行編輯
修改
nameserver 202.109.14.5 #主DNS
nameserver 219.141.136.10 #次DNS
search localdomain
所以網(wǎng)絡(luò)配置完成后，都需要重啟網(wǎng)絡(luò)服務(wù)：service network restart 或/etc/init.d/network restart
在做
java項目（特別是
web項目）的過程中，中文亂碼一直是我們開發(fā)人員比較頭疼的問題，因為涉及到編碼，解碼，字符集，以及國際化等諸多問題，所以在著手解決的時候也缺乏相關(guān)的知識。我花了一些時間自己動手實驗了一把，雖然沒有洞悉編碼，解碼這些底層原理，但是解決實際問題應(yīng)該足夠了。這里主要針對java web項目中的文亂碼問題。
從瀏覽器采用form方式提交數(shù)據(jù)到服務(wù)器，可以分為post和get方法。
1，post方法：
在jsp頁面中的page指令中，有一個pageEncoding，這個指令表示jsp翻譯成servlet時采用的編碼，以及form提交數(shù)據(jù)的編碼格式。所以post方法提交數(shù)據(jù)的編碼格式由pageEncoding指定。那解碼方式呢？通常，我們在頁面設(shè)置了pageEncoding=”utf-8”，在后臺用request.getParameter()得到的往往是亂碼，而進(jìn)一步通過new String(getBytes(“iso-8859-1”),”utf-8”)處理之后就能得到正確的數(shù)據(jù)。這是因為服務(wù)器默認(rèn)的解碼方式是iso-8859-1，所以用編碼，解碼流程解釋上面那2個動作分別是：utf-8編碼—>iso-8859-1解碼（當(dāng)然是亂碼）； utf-8編碼—>iso-8859-1解碼—>iso-8859-1編碼—>utf-8解碼，這是個對稱的過程，所以能正確得到數(shù)據(jù)。那服務(wù)器默認(rèn)的解碼方式能改嗎？當(dāng)然可以，調(diào)用request.setCharacterEncoding()就能設(shè)置，而且只針對post方式有效，設(shè)置以后request.getParameter()直接就是正確的數(shù)據(jù)了。
2，get方法
與post方法一樣，編碼方式由pageEncoding指定，但是get方式的解碼方式與post就不一樣了。在tomcat的conf目錄下有一個
server.xml的配置文件，在里面找到Connector節(jié)點(diǎn)，有一個URIEncoding屬性，這個屬性就是指定get方式的數(shù)據(jù)解碼格式的，而且只針對get方式有效。其他處理與post一樣。
另外，通過Ajax請求向后臺發(fā)送的數(shù)據(jù)由于是附在URL地址后面的，所以跟get請求一樣。編碼由pageEncoding指定，解碼由URIEncoding指定。但是有很多開發(fā)人員樂于另外一種方式：用兩次encodeURI編碼，然后在后臺用URLDecoder.decode(str,”utf-8”)解碼。這是一個什么過程呢？我們知道，encodeURI編碼是采用的utf-8編碼，所以，這個過程為：utf-8編碼—>utf-8編碼—>iso-8859-1解碼—>utf-8解碼。這看起來不像一個對稱過程，但最后為什么能得到正確結(jié)果呢？這是因為經(jīng)過第一次utf-8編碼之后，產(chǎn)生的已經(jīng)是非中文字符，所以，對非中文字符采再用utf-8編碼，iso-8859-1解碼不會有任何問題，這樣看來，它還是一個對稱的編碼，解碼過程，當(dāng)然能正確解析了。
當(dāng)然，我所說的這個“對稱”編碼解碼過程，也不是所有編碼都適用，例如：
gbk編碼—>utf-8解碼—>utf-8編碼—>gbk解碼，最后還是亂碼！
因為gbk編碼—>utf-8解碼產(chǎn)生了不可恢復(fù)的錯誤，造成了信息丟失，至于為什么產(chǎn)生永久錯誤，得從編碼的底層說起……
1、雙擊打開QTP10.0，啟動過程中
測試類型選擇“WEB”。
2、進(jìn)入主界面，New——Test，新建一個
測試用例。
3、點(diǎn)擊Record按鈕，Record and settings對話框中，可以選擇WEB測試和
Windows Application兩種不同的測試對象類型，這里選擇Windows Application。
4、Record and run only on: Applications opened by Quick Test選中之后，下面的列表中選擇Flight APP的路徑。
5、點(diǎn)擊OK，便會自動啟動你所選中的APP，開始錄制。
6、錄制完成之后，點(diǎn)擊Stop。
7、Test界面會以Keyword View作為默認(rèn)頁面顯示，我們可以點(diǎn)擊Expert View來切換到代碼視圖。
8、現(xiàn)在點(diǎn)擊Run，可以回放你剛才錄制的用例，生成測試結(jié)果。
*QTP使用的是基于VBS的腳本語言，與VBS非常相似，只有在其個別的地方存在細(xì)微差別；
QTP較其他開源測試工具而言最大的優(yōu)勢在于方便好用，門檻低，對Windows Application，Web的各種元素、標(biāo)簽、控件、按鈕等的支持與控制。
1、Aggregate Report 解析
Aggregate Report 是 JMeter 常用的一個 Listener，中文被翻譯為“聚合報告”。今天再次有同行問到這個報告中的各項數(shù)據(jù)表示什么意思，順便在這里公布一下，以備大家查閱。
如果大家都是做Web應(yīng)用的
性能測試，例如只有一個登錄的請求，那么在Aggregate Report中，會顯示一行數(shù)據(jù)，共有10個字段，含義分別如下。
Label：每個 JMeter 的 element（例如 HTTP Request）都有一個 Name 屬性，這里顯示的就是 Name 屬性的值
#Samples：表示你這次測試中一共發(fā)出了多少個請求，如果模擬10個用戶，每個用戶迭代10次，那么這里顯示100
Average：平均響應(yīng)時間——默認(rèn)情況下是單個 Request 的平均響應(yīng)時間，當(dāng)使用了 Transaction Controller 時，也可以以Transaction 為單位顯示平均響應(yīng)時間
Median：中位數(shù)，也就是 50％ 用戶的響應(yīng)時間
90% Line：90％ 用戶的響應(yīng)時間
Note：關(guān)于 50％ 和 90％ 并發(fā)用戶數(shù)的含義，請參考下文
http://www.cnblogs.com/jackei/archive/2006/11/11/557972.html
Min：最小響應(yīng)時間
Max：最大響應(yīng)時間
Error%：本次測試中出現(xiàn)錯誤的請求的數(shù)量/請求的總數(shù)
Throughput：吞吐量——默認(rèn)情況下表示每秒完成的請求數(shù)（Request per Second），當(dāng)使用了 Transaction Controller 時，也可以表示類似
LoadRunner 的 Transaction per Second 數(shù)
KB/Sec：每秒從服務(wù)器端接收到的數(shù)據(jù)量，相當(dāng)于LoadRunner中的Throughput/Sec
基本知識：
1、吞吐量：是指在沒有幀丟失的情況下，設(shè)備能夠接受的最大速率。
2、存儲的最小單位是字節(jié)Byte，對于存儲單位，有以下幾個單位，GB、MB和KB，那么這三者之間的換算關(guān)系是：1GB＝1024MB，1MB＝1024KB，1KB＝1024Bytes。
Bit ：“位”，稱為bit，也就是比特，有的時候也稱為位。一個字節(jié)為8位二進(jìn)制表示。
Byte：“字節(jié)”，一個字節(jié)就是8比特。
3、Mbps (million bits per second 兆位/秒) 代表每秒傳輸1，000，000比特。該縮寫用來描述數(shù)據(jù)傳輸速度。例如：4Mbps=每秒鐘傳輸4M比特。
數(shù)據(jù)傳輸速率的單位，字母b（bit）是比特和字母 B （Byte）是字節(jié)。
4、吞吐量與帶寬的區(qū)分：吞吐量和帶寬是很容易搞混的一個詞，兩者的單位都是Mbps.先讓我們來看兩者對應(yīng)的英語，吞吐量:throughput ; 帶寬: Max net bitrate 。當(dāng)我們討論通信鏈路的帶寬時，一般是指鏈路上每秒所能傳送的比特數(shù)。我們可以說以太網(wǎng)的帶寬是10Mbps。但是，我們需要區(qū)分鏈路上的可用帶寬（帶寬）與實際鏈路中每秒所能傳送的比特數(shù)（吞吐量）。我們傾向于用“吞吐量”一次來表示一個系統(tǒng)的測試性能。這樣，因為實現(xiàn)受各種低效率因素的影響，所以由一段帶寬為10Mbps的鏈路連接的一對節(jié)點(diǎn)可能只達(dá)到2Mbps的吞吐量。這樣就意味著，一個主機(jī)上的應(yīng)用能夠以2Mbps的速度向另外的一個主機(jī)發(fā)送數(shù)據(jù)。
5、方差和標(biāo)準(zhǔn)差都是用來描述一組數(shù)據(jù)的波動性的（集中還是分散），標(biāo)準(zhǔn)差的平方就是方差。方差越大，數(shù)據(jù)的波動越大。
這里以一個電商購物(B2C)網(wǎng)站為例：
客戶的購物網(wǎng)站
性能測試（業(yè)務(wù)）需求：
從12月下旬至農(nóng)歷年底（來年2月初）（<=50天）網(wǎng)站預(yù)計營業(yè)額(400萬)，這里營業(yè)額可以理解為網(wǎng)站完成購買訂單總金額；
訪問訂單轉(zhuǎn)化率：10%，這里理解為百分之多少的訪問量會轉(zhuǎn)化為實際的網(wǎng)站訂單；
每日訪問時間：24小時×80%，這里理解為正常用戶會在早6點(diǎn)至凌晨0點(diǎn)之前進(jìn)行電子購物，下午18點(diǎn)下班至晚上22點(diǎn)為購物高峰期；
每個訂單平均選購商品數(shù)：3件左右共計300元左右的金額，這里指每個訂單平均消費(fèi)300元，平均購買3件商品；
訂單有效率：85%，這里指下了訂單的人，有多少是進(jìn)行付款并完成交易的，15%會取消訂單或不付款；
平均瀏覽率（IP/PV）：10次，這里指訪問網(wǎng)站的所有客戶端IP地址信息統(tǒng)計后，平均每個IP會瀏覽10個網(wǎng)頁；
業(yè)務(wù)性能需求分析：（假設(shè)所有訂單全部發(fā)生在高峰時段，假設(shè)每個用戶瀏覽對比5件商品后會選中一件，每件商品瀏覽需要點(diǎn)擊5次不同鏈接網(wǎng)頁）
高峰期每小時平均下單數(shù)：銷售額/總銷售時間/高峰時間/單筆訂單金額/訂單有效率=4000000/50/4/300/0.85≈80
高峰期每小時平均訪問量（下單訪問量/訂單轉(zhuǎn)化比率）：80*5*5*3/10%=60000
高峰期訪問量=1.3×平均訪問量：60000*1.3=78000
高峰期訪問客戶端IP數(shù)量：78000/10=7800
壓力測試場景設(shè)計（粗略估算，僅供參考和理解）：
設(shè)計甲乙兩組測試腳本，甲組產(chǎn)生訂單，乙組僅瀏覽商品相關(guān)；
甲組腳本執(zhí)行人數(shù)800，乙組腳本執(zhí)行用戶數(shù)7000人；
峰值測試1000人提交訂單，10000人在線訪問；
如果你經(jīng)常讀一些關(guān)于提高
工作效率或時間管理類的博客，一定聽說過番茄時間管理法(Pomodoro Technique)。這是一種極好的幫助你集中注意力、獲得更高工作效率的方法。
基本上，它的實施方法是這樣的：
1. 確定你想要做什么(例如：翻譯一篇外文)。
2. 設(shè)定一個25分鐘的定時器。
3. 工作，直到定時器時間到：這就是一個“番茄鐘”。
4. 休息5分鐘，繼續(xù)下一個番茄鐘
5. 每4個番茄鐘做一次長時間的休息。
(有很多像Tomato Timer這樣的應(yīng)用都是為這種時間管理方法設(shè)計的。)
大多數(shù)人都會對其做一些細(xì)微調(diào)整來適應(yīng)自己：例如，你可以選擇每兩個番茄鐘——而不是四個，做一次長時間的休息。這特別是你剛開始應(yīng)用這種方法時。
為什么這種方法會有效
你是否曾計劃要在辦公桌前坐兩個小時來寫一篇博客，結(jié)果卻發(fā)現(xiàn)自己一會兒整理桌面，一會兒瀏覽微薄，不斷的被一些有趣的鏈接分心，或就在那兒浪費(fèi)時間?
按時間段工作能幫助你保持工作狀態(tài)。當(dāng)有分心的事情出現(xiàn)——例如“我需要發(fā)一個email”或“我想看看微薄上有沒有人回復(fù)我”——你可以這樣告訴自己：這個番茄鐘完成之后再做這些事情。
如果你在寫博客，將寫放在一個番茄鐘、修改放在另一個番茄鐘，你會發(fā)現(xiàn)這個方法十分的有效，如果一個番茄鐘寫不完，在加一個番茄鐘，看看你能完成多少。
番茄時間管理方法的名稱來歷
如果你是第一次聽說“番茄時間管理法(Pomodoro Technique)”，你會奇怪它為什么叫這個名稱。Pomodoro就是意大利語里的“番茄”。Francesco Cirillo——番茄時間管理法的發(fā)明人——使用的就是一個形狀像番茄的定時鐘。
關(guān)于番茄時間管理法的用法有很多，主要都是用它來防止干擾的：如果你試過這種方法，并發(fā)現(xiàn)它真的能提供你的工作效率，那就也做一些研究，豐富它，擴(kuò)展它。
挑戰(zhàn)：今天就嘗試一下番茄時間管理法——或下一次你寫博客時，看看你能做到何種程度。在下面的評論里告訴大家你的體驗。
摘要: 通過java模擬瀏覽器行為，對bugfree系統(tǒng)進(jìn)行操作。譬如：通過bug id，查詢bug的信息；查詢產(chǎn)品族；查詢滿足特定條件的bug列表；批量更新bug的狀態(tài)；上報bug到bugfree系統(tǒng)等。package com.yunos.qa;import java.io.BufferedReader;import java.io.IOException;import java.io.Inp...
閱讀全文
客戶的Oracle 11gR2 Active Data Guard環(huán)境，主數(shù)據(jù)庫的standby_file_management=AUTO，備用數(shù)據(jù)庫的standby_file_management=MANUAL，導(dǎo)致在主數(shù)據(jù)庫為表空間添加的數(shù)據(jù)文件操作沒有同步到備用數(shù)據(jù)庫，在$ORACLE_HOME/dbs目錄下也沒有創(chuàng)建類似UNNAMED00003的文件，備用數(shù)據(jù)庫有如下的告警日志： Tue Sep 02 17:37:36 2014
File #3 added to control file as 'UNNAMED00003' because
the parameter STANDBY_FILE_MANAGEMENT is set to MANUAL
The file should be manually created to continue.
MRP0: Background Media Recovery terminated with error 1274
Errors in file /u01/app/oracle/diag/rdbms/d012dg/d012band/trace/d012band_pr00_5702078.trc:
ORA-01274: cannot add datafile '/oradata1/d012band/tsmisc06.dbf' - file could not be created
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Recovered data files to a consistent state at change 866102511
Tue Sep 02 17:37:46 2014
MRP0: Background Media Recovery process shutdown (d012band)
Tue Sep 02 17:52:14 2014
RFS[1]: Selected log 8 for thread 1 sequence 19136 dbid 2134147111 branch 809469738
Tue Sep 02 17:52:25 2014
Archived Log entry 511 added for thread 1 sequence 19135 ID 0x7f340827 dest 1:
Tue Sep 02 17:53:23 2014
alter database recover managed standby database using current logfile disconnect from session
Attempt to start background Managed Standby Recovery process (d012band)
Tue Sep 02 17:53:23 2014
MRP0 started with pid=42, OS id=7471452
MRP0: Background Managed Standby Recovery process started (d012band)
started logmerger process
Tue Sep 02 17:53:29 2014
Managed Standby Recovery starting Real Time Apply
Tue Sep 02 17:53:30 2014
Errors in file /u01/app/oracle/diag/rdbms/d012dg/d012band/trace/d012band_dbw0_4784178.trc:
ORA-01186: file 3 failed verification tests
ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
ORA-01111: name for data file 3 is unknown - rename to correct file
ORA-01110: data file 3: '/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00003'
如果能夠找到/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00003文件，可以參考文章：《11gR2 Active Data Guard調(diào)整案例[1]》http://blog.itpub.net/23135684/viewspace-759592/ File 3 not verified due to error ORA-01157
MRP0: Background Media Recovery terminated with error 1111
Errors in file /u01/app/oracle/diag/rdbms/d012dg/d012band/trace/d012band_pr00_8716760.trc:
ORA-01111: name for data file 3 is unknown - rename to correct file
ORA-01110: data file 3: '/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00003'
ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
ORA-01111: name for data file 3 is unknown - rename to correct file
ORA-01110: data file 3: '/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00003'
Managed Standby Recovery not using Real Time Apply
Slave exiting with ORA-1111 exception
Errors in file /u01/app/oracle/diag/rdbms/d012dg/d012band/trace/d012band_pr00_8716760.trc:
ORA-01111: name for data file 3 is unknown - rename to correct file
ORA-01110: data file 3: '/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00003'
ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
ORA-01111: name for data file 3 is unknown - rename to correct file
ORA-01110: data file 3: '/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00003'
Recovery Slave PR00 previously exited with exception 1111
MRP0: Background Media Recovery process shutdown (d012band)
Completed: alter database recover managed standby database using current logfile disconnect from session
解決這個問題的關(guān)鍵是手動創(chuàng)建新添加的數(shù)據(jù)文件，參考如下的內(nèi)容解決該問題：
How to resolve MRP stuck issues on a physical standby database? (文檔 ID 1221163.1)
......
Solution 10 Add the new datafiles to the standby database manually.
1) Please take a hot backup of new datafiles from the primary database.
2) Create a new standby controlfile from the primary database by
SQL>alter database create standby controlfile as '/tmp/controlf.ctl';
If datafiles are on ASM, please follow the note below and you could ignore the rest of steps:
Note 734862.1 Step By Step Guide On How To Recreate Standby Control File
When Datafiles Are On ASM And Using Oracle Managed Files
Or you could modify the wrong datafile name in the standby controlfile by alter database rename command. For example,
SQL> ALTER DATABASE RENAME FILE '<path/UNNAMED00003>' to '<path/real datafile name>';
3) If the new datafile location on the primary is different from the standby, please make sure
db_file_name_convert init parameter is set on the standby database.
Note 47325.1 Init.ora Parameter "DB_FILE_NAME_CONVERT" Reference Note
If db_file_name_convert init parameter has already been set, then you could ignore this step.
4) Cancel the managed recovery
SQL>alter database recover managed standby database cancel;
5) set standby_file_management=manual on the standby database and shutdown the standby database.
SQL>alter system set standby_file_management=manual sid='*';
SQL>shutdown immediate;
6) Copy the hot backup of the new datafiles and the new standby controlfile to the standby.
Please make sure the controlfiles are located in the right location with right names
according to the init parameter control_files. Please make sure the copied datafiles are
located in the right location as well according to name from v$datafile.
7) startup the standby database in mount mode and set standby_file_management=auto.
SQL>startup mount;
SQL>alter system set standby_file_management=auto sid='*';
8) Start the managed recovery.
SQL>alter database recover managed standby database disconnect;
......
--end--
AUM（自動 undo 管理，Automatic Undo Management）幾乎不需要配置。您基本上只需要定義將前映像保持可用的時間量。這是通過參數(shù) UNDO_RETENTION 控制的，以秒為單位定義。因此，值 900 表示 15 分鐘。
一定要意識到，如果 undo 表空間中存在空間壓力時，我們不保證前鏡像一定會保留這么長時間。
因此，以下公式可用于計算最佳 undo 表空間大小：
從
Oracle 10g 開始，您可以選擇使用 GUARANTEE 選項，以確保在定義的 undo_retention 時間之前，undo 信息不會被覆蓋。
UNDO表空間大小由三部分組成：
(UR)UNDO_RETENTION 單位秒
(UPS)每秒產(chǎn)生的undo 數(shù)據(jù)塊的個數(shù)
計算公式
UndoSpace=UR*(UPS*DBS)
其中UNDO_RETENTION 和 DB_BLOCK_SIZE兩部分的信息可以在實例配置參數(shù)信息中獲取。
而第三部分UPS的信息需要從動態(tài)性能試圖V$UNDOSTAT中獲取
下面是獲取(UPS)每秒產(chǎn)生的undo 數(shù)據(jù)塊的個數(shù).
SQL> SELECT undoblks/((end_time-begin_time)*86400) "Peak Undo Block Generation"
FROM v$undostat WHERE undoblks=(SELECT MAX(undoblks) FROM v$undostat);
其中列END_TIME and BEGIN_TIME 是日期類型，需要轉(zhuǎn)換成秒(24 hours * 60 minutes * 60 seconds).
SQL> SELECT (UR * (UPS * DBS)) AS "Bytes" FROM (SELECT value AS UR FROM v$parameter WHERE name = 'undo_retention'), (SELECT undoblks/((end_time-begin_time)*86400) AS UPS FROM v$undostat WHERE undoblks = (SELECT MAX(undoblks) FROM v$undostat)), (SELECT block_size AS DBS FROM dba_tablespaces WHERE tablespace_name = (SELECT UPPER(value) FROM v$parameter WHERE name = 'undo_tablespace')); |
10g 和10g 更高的版本，可以使用下面的查詢:
SQL>SELECT (UR * (UPS * DBS)) AS "Bytes" FROM (select max(tuned_undoretention) AS UR from v$undostat), (SELECT undoblks/((end_time-begin_time)*86400) AS UPS FROM v$undostat WHERE undoblks = (SELECT MAX(undoblks) FROM v$undostat)), (SELECT block_size AS DBS FROM dba_tablespaces WHERE tablespace_name = (SELECT UPPER(value) FROM v$parameter WHERE name = 'undo_tablespace')); |
默認(rèn)的三個類加載器
Java默認(rèn)是有三個ClassLoader，按層次關(guān)系從上到下依次是：
Bootstrap ClassLoader
Ext ClassLoader
System ClassLoader
Bootstrap ClassLoader是最頂層的ClassLoader,它比較特殊，是用C++編寫集成在JVM中的，是JVM啟動的時候用來加載一些核心類的，比如：rt.jar,resources.jar,charsets.jar,jce.jar等，可以運(yùn)行下面代碼看都有哪些:
URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();
for (int i = 0; i < urls.length; i++) {
System.out.println(urls[i].toExternalForm());
}
其余兩個ClassLoader都是繼承自ClassLoader這個類。Java的類加載采用了一種叫做“雙親委托”的方式（稍后解釋），所以除了Bootstrap ClassLoader其余的ClassLoader都有一個“父”類加載器， 不是通過集成，而是一種包含的關(guān)系。
//ClassLoader.java
public abstract class ClassLoader {
...
// The parent class loader for delegation
private ClassLoader parent;
...
“雙親委托”
所謂“雙親委托”就是當(dāng)加載一個類的時候會先委托給父類加載器去加載，當(dāng)父類加載器無法加載的時候再嘗試自己去加載，所以整個類的加載是“自上而下”的，如果都沒有加載到則拋出ClassNotFoundException異常。
上面提到Bootstrap ClassLoader是最頂層的類加載器，實際上Ext ClassLoader和System ClassLoader就是一開始被它加載的。
Ext ClassLoader稱為擴(kuò)展類加載器，負(fù)責(zé)加載Java的擴(kuò)展類庫，默認(rèn)加載JAVA_HOME/jre/lib/ext/目錄下的所有的jar（包括自己手動放進(jìn)去的jar包）。
System ClassLoader叫做系統(tǒng)類加載器，負(fù)責(zé)加載應(yīng)用程序classpath目錄下的所有jar和class文件，包括我們平時運(yùn)行jar包指定cp參數(shù)下的jar包。
運(yùn)行下面的代碼可以驗證上面內(nèi)容：
ClassLoader loader = Debug.class.getClassLoader();
while(loader != null) {
System.out.println(loader);
loader = loader.getParent();
}
System.out.println(loader);
“雙親委托”的作用
之所以采用“雙親委托”這種方式主要是為了安全性，避免用戶自己編寫的類動態(tài)替換Java的一些核心類，比如String，同時也避免了重復(fù)加載，因為JVM中區(qū)分不同類，不僅僅是根據(jù)類名，相同的class文件被不同的ClassLoader加載就是不同的兩個類，如果相互轉(zhuǎn)型的話會拋java.lang.ClassCaseException.
自定義類加載器
除了上面說的三種默認(rèn)的類加載器，用戶可以通過繼承ClassLoader類來創(chuàng)建自定義的類加載器，之所以需要自定義類加載器是因為有時候我們需要通過一些特殊的途徑創(chuàng)建類，比如網(wǎng)絡(luò)。
至于自定義類加載器是如何發(fā)揮作用的，ClassLoader類的loadClass方法已經(jīng)把算法定義了：
protected synchronized Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
// First, check if the class has already been loaded
Class c = findLoadedClass(name);
if (c == null) {
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
c = findClass(name);
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
>1. Invoke findLoadedClass(String) to check if the class has already been loaded.
>2. Invoke the loadClass method on the parent class loader. If the parent is null the class loader built-in to the virtual machine is used, instead.
>3. Invoke the findClass(String) method to find the class.
看上面的Javadoc可以知道，自定義的類加載器只要重載findClass就好了。
Context ClassLoader
首先Java中ClassLoader就上面提到的四種，Bootstrap ClassLoader，Ext ClassLoader，System ClassLoader以及用戶自定義的,所以Context ClassLoader并不是一種新的類加載器，肯定是這四種的一種。
首先關(guān)于類的加載補(bǔ)充一點(diǎn)就是如果類A是被一個加載器加載的，那么類A中引用的B也是由這個加載器加載的(如果B還沒有被加載的話)，通常情況下就是類B必須在類A的classpath下。
但是考慮多線程環(huán)境下不同的對象可能是由不同的ClassLoader加載的，那么當(dāng)一個由ClassLoaderC加載的對象A從一個線程被傳到另一個線程ThreadB中，而ThreadB是由ClassLoaderD加載的，這時候如果A想獲取除了自己的classpath以外的資源的話，它就可以通過Thread.currentThread().getContextClassLoader()來獲取線程上下文的ClassLoader了，一般就是ClassLoaderD了，可以通過Thread.currentThread().setContextClassLoader(ClassLoader)來顯示的設(shè)置。
為什么要有Contex ClassLoader
之所以有Context ClassLoader是因為Java的這種“雙親委托”機(jī)制是有局限性的:
舉網(wǎng)上的一個例子:
> JNDI為例，JNDI的類是由bootstrap ClassLoader從rt.jar中間載入的，但是JNDI具體的核心驅(qū)動是由正式的實現(xiàn)提供的，并且通常會處于-cp參數(shù)之下（注：也就是默認(rèn)的System ClassLoader管理），這就要求bootstartp ClassLoader去載入只有SystemClassLoader可見的類，正常的邏輯就沒辦法處理。怎么辦呢？parent可以通過獲得當(dāng)前調(diào)用Thread的方法獲得調(diào)用線程的>Context ClassLoder 來載入類。
我上面提到的加載資源的例子。
Contex ClassLoader提供了一個突破這種機(jī)制的后門。
Context ClassLoader一般在一些框架代碼中用的比較多，平時寫代碼的時候用類的ClassLoader就可以了。