1
．
关于动态加载机制
——
学习 Java 比 C++ 更容易理解 OOP 的思想，毕竟 C++ 还混合了不少面向过程的成分。很多人都能背出来 Java 语言的特点，所谓的动态加载机制等等。当然概念往往是先记住而后消化的，可有多少人真正去体会过动态加载的机制，试图去寻找过其中的细节呢 ? 提供大家一个方法：
在命令行窗口运行 Java 程序的时候，加上这个很有用的参数：
java –verbose *.class
这样会清晰的打印出被加载的类文件，大部分是 jdk 自身运行需要的，最后几行会明显的看到自己用到的那几个类文件被加载进来的顺序。即使你声明了一个类对象，不实例化也不会加载，说明只有真正用到那个类的实例即对象的时候，才会执行加载。这样是不是大家稍微能明白一点动态加载了呢？ ^_^
2 ． 关于寻找 class 文件原理 ——
建议大家在入门的时候在命令行窗口编译和运行，不要借助 JCreator 或者 Eclipse 等 IDE 去帮助做那些事情。尝试自己这样做：
javac -classpath yourpath *.java
java -classpath yourpath *.class
也许很多人都能看懂，设置 classpath 的目的就是告诉编译器去哪里寻找你的 class 文件 . 不过至少笔者今日才弄懂 JVM 去查询类的原理，编译器加载类要依靠 classloader ， 而 classloader 有 3 个级别，从高到低分别是 BootClassLoader( 名字可能不准确 ) , ExtClassLoader, AppClassLoader.
这 3 个加载器分别对应着编译器去寻找类文件的优先级别和不同的路径： BootClassLoader 对应 jre/classes 路径，是编译器最优先寻找 class 的地方
ExtClassLoader 对应 jre/lib/ext 路径，是编译器次优先寻找 class 的地方
AppClassLoader 对应当前路径，所以也是编译器默认找 class 的地方
其实大家可以自己写个程序简单的测试，对任何 class ，例如 A,
调用 new A().getClass().getClassLoader().toString() 打印出来就可以看到，把 class 文件放在不同的路径下再次执行，就会看到区别。特别注意的是如果打印出来是 null 就表示到了最高级 BootClassLoader, 因为它是 C++ 编写的，不存在 Java 对应的类加载器的名字。
寻找的顺序是一种向上迂回的思想，即如果本级别找不到，就只能去本级别之上的找，不会向下寻找。不过似乎从 Jdk1.4 到 Jdk1.6 这一特点又有改变，没有找到详细资料
这样希望大家不至于迷惑为什么总报错找不到类文件，不管是自己写的还是导入的第三方的 jar 文件（ J2ee 中经常需要导入的）。
3 ． 关于 jdk 和 jre——
大家肯定在安装 JDK 的时候会有选择是否安装单独的 jre ，一般都会一起安装，我也建议大家这样做。因为这样更能帮助大家弄清楚它们的区别：
Jre 是 java runtime environment, 是 java 程序的运行环境。既然是运行，当然要包含 jvm ，也就是大家熟悉的虚拟机啦， 还有所有 java 类库的 class 文件，都在 lib 目录下打包成了 jar 。大家可以自己验证。至于在 windows 上的虚拟机是哪个文件呢？ 学过 MFC 的都知道什么是 dll 文件吧，那么大家看看 jre/bin/client 里面是不是有一个 jvm.dll 呢？那就是虚拟机。
Jdk 是 java development kit ，是 java 的开发工具包，里面包含了各种类库和工具。当然也包括了另外一个 Jre. 那么为什么要包括另外一个 Jre 呢？而且 jdk/jre/bin 同时有 client 和 server 两个文件夹下都包含一个 jvm.dll 。 说明是有两个虚拟机的。这一点不知道大家是否注意到了呢？
相信大家都知道 jdk 的 bin 下有各种 java 程序需要用到的命令，与 jre 的 bin 目录最明显的区别就是 jdk 下才有 javac ，这一点很好理解，因为 jre 只是一个运行环境而已。与开发无关，正因为如此，具备开发功能的 jdk 自己的 jre 下才会同时有 client 性质的 jvm 和 server 性质的 jvm ， 而仅仅作为运行环境的 jre 下只需要 client 性质的 jvm.dll 就够了。
记得在环境变量 path 中设置 jdk/bin 路径麽？这应该是大家学习 Java 的第一步吧， 老师会告诉大家不设置的话 javac 和 java 是用不了的。确实 jdk/bin 目录下包含了所有的命令。可是有没有人想过我们用的 java 命令并不是 jdk/bin 目录下的而是 jre/bin 目录下的呢？不信可以做一个实验，大家可以把 jdk/bin 目录下的 java.exe 剪切到别的地方再运行 java 程序，发现了什么？一切 OK ！
那么有人会问了？我明明没有设置 jre/bin 目录到环境变量中啊？
试想一下如果 java 为了提供给大多数人使用，他们是不需要 jdk 做开发的，只需要 jre 能让 java 程序跑起来就可以了，那么每个客户还需要手动去设置环境变量多麻烦啊？所以安装 jre 的时候安装程序自动帮你把 jre 的 java.exe 添加到了系统变量中，验证的方法很简单，大家看到了系统环境变量的 path 最前面有 “%SystemRoot%/system32;%SystemRoot%;” 这样的配置，那么再去 Windows/system32 下面去看看吧，发现了什么？有一个 java.exe 。
如果强行能够把 jdk/bin 挪到 system32 变量前面，当然也可以迫使使用 jdk/jre 里面的 java ，不过除非有必要，我不建议大家这么做。使用单独的 jre 跑 java 程序也算是客户环境下的一种测试。
这下大家应该更清楚 jdk 和 jre 内部的一些联系和区别了吧？
学习 Java 比 C++ 更容易理解 OOP 的思想，毕竟 C++ 还混合了不少面向过程的成分。很多人都能背出来 Java 语言的特点，所谓的动态加载机制等等。当然概念往往是先记住而后消化的，可有多少人真正去体会过动态加载的机制，试图去寻找过其中的细节呢 ? 提供大家一个方法：
在命令行窗口运行 Java 程序的时候，加上这个很有用的参数：
java –verbose *.class
这样会清晰的打印出被加载的类文件，大部分是 jdk 自身运行需要的，最后几行会明显的看到自己用到的那几个类文件被加载进来的顺序。即使你声明了一个类对象，不实例化也不会加载，说明只有真正用到那个类的实例即对象的时候，才会执行加载。这样是不是大家稍微能明白一点动态加载了呢？ ^_^
2 ． 关于寻找 class 文件原理 ——
建议大家在入门的时候在命令行窗口编译和运行，不要借助 JCreator 或者 Eclipse 等 IDE 去帮助做那些事情。尝试自己这样做：
javac -classpath yourpath *.java
java -classpath yourpath *.class
也许很多人都能看懂，设置 classpath 的目的就是告诉编译器去哪里寻找你的 class 文件 . 不过至少笔者今日才弄懂 JVM 去查询类的原理，编译器加载类要依靠 classloader ， 而 classloader 有 3 个级别，从高到低分别是 BootClassLoader( 名字可能不准确 ) , ExtClassLoader, AppClassLoader.
这 3 个加载器分别对应着编译器去寻找类文件的优先级别和不同的路径： BootClassLoader 对应 jre/classes 路径，是编译器最优先寻找 class 的地方
ExtClassLoader 对应 jre/lib/ext 路径，是编译器次优先寻找 class 的地方
AppClassLoader 对应当前路径，所以也是编译器默认找 class 的地方
其实大家可以自己写个程序简单的测试，对任何 class ，例如 A,
调用 new A().getClass().getClassLoader().toString() 打印出来就可以看到，把 class 文件放在不同的路径下再次执行，就会看到区别。特别注意的是如果打印出来是 null 就表示到了最高级 BootClassLoader, 因为它是 C++ 编写的，不存在 Java 对应的类加载器的名字。
寻找的顺序是一种向上迂回的思想，即如果本级别找不到，就只能去本级别之上的找，不会向下寻找。不过似乎从 Jdk1.4 到 Jdk1.6 这一特点又有改变，没有找到详细资料
这样希望大家不至于迷惑为什么总报错找不到类文件，不管是自己写的还是导入的第三方的 jar 文件（ J2ee 中经常需要导入的）。
3 ． 关于 jdk 和 jre——
大家肯定在安装 JDK 的时候会有选择是否安装单独的 jre ，一般都会一起安装，我也建议大家这样做。因为这样更能帮助大家弄清楚它们的区别：
Jre 是 java runtime environment, 是 java 程序的运行环境。既然是运行，当然要包含 jvm ，也就是大家熟悉的虚拟机啦， 还有所有 java 类库的 class 文件，都在 lib 目录下打包成了 jar 。大家可以自己验证。至于在 windows 上的虚拟机是哪个文件呢？ 学过 MFC 的都知道什么是 dll 文件吧，那么大家看看 jre/bin/client 里面是不是有一个 jvm.dll 呢？那就是虚拟机。
Jdk 是 java development kit ，是 java 的开发工具包，里面包含了各种类库和工具。当然也包括了另外一个 Jre. 那么为什么要包括另外一个 Jre 呢？而且 jdk/jre/bin 同时有 client 和 server 两个文件夹下都包含一个 jvm.dll 。 说明是有两个虚拟机的。这一点不知道大家是否注意到了呢？
相信大家都知道 jdk 的 bin 下有各种 java 程序需要用到的命令，与 jre 的 bin 目录最明显的区别就是 jdk 下才有 javac ，这一点很好理解，因为 jre 只是一个运行环境而已。与开发无关，正因为如此，具备开发功能的 jdk 自己的 jre 下才会同时有 client 性质的 jvm 和 server 性质的 jvm ， 而仅仅作为运行环境的 jre 下只需要 client 性质的 jvm.dll 就够了。
记得在环境变量 path 中设置 jdk/bin 路径麽？这应该是大家学习 Java 的第一步吧， 老师会告诉大家不设置的话 javac 和 java 是用不了的。确实 jdk/bin 目录下包含了所有的命令。可是有没有人想过我们用的 java 命令并不是 jdk/bin 目录下的而是 jre/bin 目录下的呢？不信可以做一个实验，大家可以把 jdk/bin 目录下的 java.exe 剪切到别的地方再运行 java 程序，发现了什么？一切 OK ！
那么有人会问了？我明明没有设置 jre/bin 目录到环境变量中啊？
试想一下如果 java 为了提供给大多数人使用，他们是不需要 jdk 做开发的，只需要 jre 能让 java 程序跑起来就可以了，那么每个客户还需要手动去设置环境变量多麻烦啊？所以安装 jre 的时候安装程序自动帮你把 jre 的 java.exe 添加到了系统变量中，验证的方法很简单，大家看到了系统环境变量的 path 最前面有 “%SystemRoot%/system32;%SystemRoot%;” 这样的配置，那么再去 Windows/system32 下面去看看吧，发现了什么？有一个 java.exe 。
如果强行能够把 jdk/bin 挪到 system32 变量前面，当然也可以迫使使用 jdk/jre 里面的 java ，不过除非有必要，我不建议大家这么做。使用单独的 jre 跑 java 程序也算是客户环境下的一种测试。
这下大家应该更清楚 jdk 和 jre 内部的一些联系和区别了吧？
扫一扫
2229
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
