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 载入的类, 除了意味着不
        同的类装载器可以载入完全相同的类之外, 也排除了误用或恶意使用别人
        程序代码的机会,