以前配置Java环境变量，都是在脑里记着CLASSPATH里要配什么，PATH里要配什么，然后新的机器来了，就按这种不加思索的方式去配。最近在看JVM的书，看到ClassLoader的原理介绍，就不由的想到了Java里的环境变量的配置。或许对很多人来说，配置环境变量是从事Java开发的一个很基础的要求。但是我们不应该永远停留在“因为Java文档是这样说的，所以要这样配”的层面上。也许对于现实世界，很多东西是没有原因的（所以对于这个世界，我们有时会很无奈），但是对于编程的世界，任何事情的发生，都会有原因（而我们对编程世界的不理解，是因为我们没有去找原因）。
windows系统，linux系统等等其他系统，他们是如何知道有某一个命令的存在呢？特别是对于不是系统自带的命令，它们是怎样知道的？你点击了一个新安装的程序，为什么windows就会知道要用什么去打开程序呢？所以要有一个地方告诉系统，你的东西放在哪里了。这个地方，可以是注册表，也可以是其他系统指定的地方。所以PATH里面的配置，就是告诉windows系统，我有一个java的命令在某个目录下，如果你遇到java这样的字符，就去那个目录下找。所以PATH的配置，如下面所示：
PATH = C:\Java\jdk1.6.0_33\bin;
配完这一步，与系统之间的联系就打通了。这个时候，我们在命令行里，输入java -version，就会显示下面的图了：
下面我们就通过每一情况的现象，去解释当我们输入java命令时，JVM做了些什么，而且又与环境变量的配置有什么关系？
1、我们可以先写一个Test的程序，进入到Test.java的目录，然后用javac Test.java命令编译，会得到一个.class文件(正常情况)。这个时候，我们到jdk的目录里，把jre目录给改成jre_bak
然后再用javac Test.java去编译，就会出现下面的错误。这说明了什么？也就是说当我们配置了PATH之后，javac的编译以及一些运行时环境，就会以这个PATH为基准，知道jdk放到了哪里，以及jre放到了哪里，所以我们不能改目录的名字，就是这个原因。找到这些库后，JVM就会去加载如rt.jar等的Java核心库文件。
2、接着将环境变回没改之前的情况，然后用java命令执行，看下会是什么情况：
Test类没有找到。就是说java命令在cmd环境是可用的，但是找不到类。其实我们想想也很正常，你写了一个类，然后随便把这个类放到一个目录下，谁知道你要JVM去哪里找你写的类。或者我们联系回平时我们写的程序，不管你用C++还是Java加载一个文件，你的程序首先要知道这个文件的路径，然后作为参数传给你的程序，是这样的吧！所以就有了CLASSPATH这个东西了。点号代表当前目录，C:\Java\jdk1.6.0_33\lib则是其他的一些库。配完之后，重新打开cmd，再执行java命令，程序就会执行了。
那这跟ClassLoader之间的关系是怎样的呢？总结一下吧：
1、当我们输入java com.xxx.Test这个命令的时候，JVM就会启动。
2、启动过程中，启动类加载器(dll的文件，并.class文件)会运行，先加载rt.jar等其他的Java核心库，rt.jar里就包含了String.class,Object.class等一些文件。
3、标准类扩展加载器，加载扩展的类库。
4、系统类加载器，加载CLASSPATH目录里的库。