java深度歷險>-閱讀筆記

每個java的安裝（Win2k），總會有很多的JRE，一定分清除到底是哪個JRE在運行
由於多個JRE和java以及Javac位置的作用，會產生很多的版本問題
 
java深度歷險 CH01 P36 關於Java環境的理解和設置
 
        對Java 應用程序來說， 每個JRE 都是獨立不相干的個體。 凡是程序庫、
        安全設置等與特定JRE 相關聯的特性， 如果您設置的是在A 處的JRE， 但
        是執行時Java 應用程序卻是在B 處的JRE 之中執行，那麼您的設置就會完
        全沒有作用。
        所以， 您必須清楚地知道哪一個java.exe 被執行， 以及java.exe
        到底選用到哪個JRE， 這些都是非常重要的細節。
 
CH02
 
1、關於動態加載
        如C/C++本身就不具備動態性。 因此， 爲了讓這些本身不具有動態性的程序設計
語言
 
        具有某種程度的動態性， 就必須依賴底層的操作系統提供一些機制來實現動
        態性。 Windows 操作系統下的動態鏈接庫 Dynamic Linking Library 和Unix
        下的共享對象 Share Object 正是這樣的例子。 但是， 要運用這些底層操作
        系統所提供的機制， 程序員必須多費一些功夫來撰寫額外的程序代碼。 例如
        Windows 平臺上需要使用LoadLibrary()與GetProcAddress()兩個
        Win32 API 來完成動態性的需求。
 
2、java在本質上就是一種具有“動態性”的程序設計語言：
        昨天看了Java深度歷險的ClassLoad，今天繼續
        forName方法
        public static Class forName(String className)（作類對象的靜態初始化）
        public static Class forName(String name, boolean initialize, ClassLoader
 loader)（類對象靜態初始化要看參數的）
        newInstance()
        getClassLoader得到ClassLoader（不作類對象的靜態初始化）
        ClassLoader loader = off.getClass().getClassLoader();
        Class c = loader.loadClass(args[0]);
        用戶自己產生ClassLoader：URLClassLoader
        當一個類被多個加載類加載的時候，會多次執行類的靜態初始化代碼（內存中存在
多個
“類”對象）
 
3、java執行class的整個流程
        Java.exe xxx-->java.exe找到JRE(本目錄下－父目錄下－註冊表中：所以要弄清
楚java.exe的位置)-->java.exe同jre版本驗證
        -->加載jvm.dll-->jvm的初始化操作（如獲取系統參數等）
        -->產生第一個類裝載器:BootStrap Loader(C++寫成，Java類getClassLoader爲nu
ll，就是指它)-->基本初始化操作
        -->BootStrap Loader載入sun.misc.launcher$ExtClassLoader.class(設置paren
t爲n
ull)
        -->BootStrap Loader載入sun.misc.launcher$AppClassLoader.class(設置paren
t爲launcher$ExtClassLoader的object...不是null呀)
        AppClassLoader被sun成爲system loader
        -->由AppClassLoader 負責載入命令行中所輸入的xxx.class（實際上xxx.class
很可能由ExtClassLoader 或Bootstrap Loader 載入）
 
        xxx.getParent()和xxx.class.getClassLoader()指向的對象很可能不相同，paren
t和裝載器之間沒有特別的關係（Parent是爲某些特殊目的而設）
        除了bootStrap Loader之外，其他的類裝載器統統由java生成，也應該由其他的類
裝載器裝載
 
4、AppClassLoader 和ExtClassLoader 都是URLClassLoader 的子類
        AppClassLoader 所引用的URL 是由從系統參數java.class.path 取出的字符串所
決定的。
        而java.class.path 則是由我們在執行java.exe時， 利用–cp 或-classpath 或C
LASSPATH 環境變量所決定的。
        至於ExtClassLoader 也有相同的情形， 不過其要加載類的搜索路徑是引用系統參
數java.ext.dirs(就是JRE的lib下面的ext目錄中)
        系統參數java.ext.dirs 的內容可以在一開始執行命令的時候來更改：
        java -Djava.ext.dirs=c:/winnt xxx
        Bootstrap Loader 通過查詢系統參數sun.boot.class.path, 用來搜索要加載類的
路徑系統參數sun.boot.class.path 的內容可以在一開始執行命令的時候來更改：java -D
sun.boot.class.path=c:/winnt xxx
 
5、類加載等級的存在是以一個Object爲單位的。
        單Object內部的所有類加載，要遵循從加載本類的裝載器開始的一個等級，
        在此等級內，如果無法找到本Object內的類，就Exception了，
        否則就按照先上再下的方式查詢匹配
6、ClassLoader的加載等級，就是委託加載，一是爲了動態加載，二是保證程序安全：
（CH02 90）
        第一, 假設我們利用URLClassLoader 到網絡上的任何地方下載了其它的類, URLCl
assLoader 都不可能下載
        Java AppClassLoader, ExtClassLoader 或者Bootstrap Loader 可以找到的
        同名類, 指全名, 程序包名稱+類名稱,, 因此, 蓄意破壞者根本沒有機會
        植入有問題的程序代碼於我們的計算機之中, 除非蓄意破壞者能潛入您的
        計算機, 置換掉您計算機內的類文件, 但是這已經不是Java 所涉及的安全
        問題了, 而是操作系統本身的安全問題,；
        第二, 類裝載器無法看到其它相同階層之類裝載器所載入的類, 如上圖所示, 圖中
虛線框起來的部分意指
        www.sun.com 下載程序代碼的類裝載器所能看到的類, 這告訴我們, 從
        www.sun.com 載入的類無法看www.xxx.com 載入的類, 除了意味着不
        同的類裝載器可以載入完全相同的類之外, 也排除了誤用或惡意使用別人
        程序代碼的機會,