关于java.exe如何load JVM

运行java.exe的时候是如何load jvm的呢,看过王森<java深度历险>一书,但是

没有说的很具体,我测试了一下,总结如下,
Windows下:
当运行java.exe的时候,java首先寻找java.dll文件
1,如果找到就去找../lib/i386/(相对目录)里的jvm.cfg文件(这个文件里是启

动哪个jvmd的相对应的参数),根据java.exe的参数早启动./client或./server

目录里的jvm.dll文件.这样就开始了初始化jvm.dll(初始化jvm需要hpi.dll).
2,如果在当前目录下找不到java.dll,java.exe就会到../jre/bin下的java.

dll,再去../jre/lib/i386下找jvm.cfg文件,根据java.exe的参数早启动./jre

/bin/client或./jre/bin/server里的jvm,但是这次初始化需要zip.dll(没有看

源码,还不清楚)
3,还是找不到的话就会去注册表HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java

Runtime Environment\ 查看CurrentVersion的键值指向哪个JRE,loading过程如上.

但是在path路径里设JRE的路径,java.exe是不会去找的
那为什么在PATH最前面设了xx:\JRE\bin, 就可以运行正常呢,原因很简单,因为

你设在最前面,所以你执行的java.exe就是你所设JRE的java.exe,如果你只设

xx:\JRE,那么很有可能就是运行c:\windows\system32目录下的java.exe. 但是

出不出问题和你系统里有没有多个JRE有关,如果就一个是太会有问题的.

写出来和大家分享一下,高手一般都了解,但是也有不太清楚的:)

我以前写的文章，贴出来和大家共享

Java2 SDK安装对注册表的修改
Written by anson 2002-8-23

将会生成如下3个项目：

HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment

同时，Java2 SDK安装程序将会把java.exe，javaw.exe，javareg.exe这3个可执行文件拷贝到winnt\system32目录下，由于winnt\system32被操作系统缺省的设置为最高优先权的PATH搜索路径，因此可保证用户在命令行任何目录下可运行java.exe来启动JVM。

那么java.exe在启动时如何确定其JRE所在的目录以及需要动态加载的链接库呢？java.exe是通过下面方式来确定的：

假如存在../jre/bin/java.dll文件，则查找../jre/lib/ jvm.cfg文件，在该文件中，第1个被列出的jvm.dll类型作为缺省值（假如在java.exe命令行指定了jvm.dll的类型，则使用指定类型）。jvm.dll类型分为hotspot，classic，server三种。假如不存在../jre/lib/jvm.cfg文件，则打印下面的错误信息：

Error: could not open 'c:\jdk1.3\jre\lib\jvm.cfg'

如不存在../jre/bin/java.dll（当运行的是winnt\system32\java.exe），则注册表将在此时发挥作用，HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\ CurrentVersion键值所记录的实际上是winnt\system32\java.exe的版本值，该版本值只保存主、次两个版本号，如1.2，1.3等。

同时java.exe程序内部本身也有一个标识自身的版本值，如1.2、1.3等。java.exe根据自己内部的版本值和CurrentVersion值相比较，如果发现两个值相等，则将在HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\MainVersion.MicroVersion项下获取JRE所在目录及动态链接库，这两个键的名称分别是JavaHome和RuntimeLib，MainVersion表示主版本号，MicroVersion表示次版本号。

如果java.exe内部版本值和CurrentVersion不一致，则报类似以下的错误：

Registry key 'Software\JavaSoft\Java Runtime Environment\CurrentVersion'
has value '1.2', but '1.3' is required.

意思是说，注册表当前所记载的winnt\system32\java.exe版本为1.2，但是此时运行的java.exe版本为1.3。java.exe抱怨除非注册表有1.3版的记载，否则自己无法正确定位JRE目录和jvm.dll，因此提示1.3是需要的。

这里，我们不能简单的修改注册表的CurrentVersion值来达到这个目的。一般地，当在系统中装了两套版本的Java2 SDK（如先装1.2而后又装了1.3），后面安装的Java2 SDK会将自己带的java.exe和javaw.exe拷贝到winnt\system32目录下，从而覆盖先前版本的java.exe和javaw.exe，并且在注册表中改写CurrentVersion为1.3。所以建议在安装Java2 SDK前，先卸载以前安装的版本。如果人为的修改CurrentVersion，会使得不同版本的java.exe加载与己版本不符的java.dll及jvm.dll，将引起难以预料的后果！

特殊情况：

JBuilder自己带一套JDK，在JBuilder安装完成后，JBuilder安装程序会修改CurrentVersion为自己所带JDK的版本，但不会覆盖winnt\system32下的java.exe和javaw.exe。

WebLogic自己带一套JDK，在WebLogic安装完成后，WebLogic安装程序不会修改注册表，也不会覆盖winnt\system32下的java.exe和javaw.exe。

Oracle自己带一套JDK（一般是比较低版本的，例如8.1.7仅仅带JDK 1.1.7），在Oracle安装完成后，Oracle安装程序不会修改注册表，也不会覆盖winnt\system32下的java.exe和javaw.exe。但是，Oralce安装程序会修改系统PATH变量，将自带的JRE的bin路径加入其中，且置于最前面。随着Oracle安装版本的不同，其自带JRE的JVM启动程序也不同。在笔者机器上安装的Oracle 8.1.7，其JRE就装在C:\Program Files\Oracle下，并将C:\Program Files\Oracle\jre\1.1.7\bin放在PATH变量最前，其JVM启动程序是jre.exe而非java.exe。

以上就是Java2 SDK在Windows下安装时所做的动作，这样会带来兼容性问题：

问题背景：安装Java2 SDK后，安装了JBuilder6，未修改任何PATH变量

问题1

当在操作系统中安装了JDK 1.2，其后安装了JBuilder6（自带JDK 1.3.1），这时CurrentVersion为1.3，在命令行执行java -version时，提示：

Registry key 'Software\JavaSoft\Java Runtime Environment\CurrentVersion'
has value '1.3', but '1.2' is required.

解决方法：将JDK 1.2中java.exe所在路径加入到操作系统PATH的首位，从而保证在命令行调用java时总是执行JDK 1.2中的java.exe，以使得java.exe可正确定位JRE和jvm.dll。

问题2

当在操作系统中安装了JDK 1.3.0，而后安装了JBuilder6（自带JDK 1.3.1），这时CurrentVersion为1.3，但是此1.3是指向的是JBuilder6自带的JDK 1.3.1的JRE，而非指向先前JDK 1.3.0的JRE，当在命令行执行java -version时，此时执行的是JDK 1.3.0拷贝到winnt\system32的一个java.exe副本，但打印的版本信息却是：

java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)

导致该问题的原因是java.exe只维护小数点后1位的版本号，而非2位。

解决方法：同问题1

问题3：

如果在操作系统中先安装了JDK 1.3.0，而后安装了带有与安装JDK主次版本相同的JBuilder6（带JDK 1.3.1，前两位相同），则问题1实际上被隐蔽了，没有发生的机会；而问题2的隐蔽性也很强，不容易发觉，因为人们往往会忽略JDK的第3个版本号。

如问题2所叙，在命令行执行java，虽然是使用JDK 1.3.0的一个java.exe副本（winnt\system32目录下），而实际上却是使用JBuilder6下JDK 1.3.1的JRE及其目录结构，其结果是当我们使用Java2的extension mechanism将jar文件放到JDK 1.3.0的jre\lib\ext目录下时，发现达不到希望的效果 – 在命令行用java启动程序时，不会自动去JDK 1.3.0的jre\lib\ext目录下去搜索jar文件，它只会去JBuilder6下JDK 1.3.1的jre\lib\ext去搜索jar文件，而JBuilder6下的JDK 1.3.1并不存在jre\lib\ext这么一个目录！

问题3极为隐蔽，除非完全对Java2 SDK的安装及class定位机制了解，一般的开发者是难以发现问题所在的。有关Java2中class定位机制，见《Java2中的class定位机制》一文。

事实上，即使仅仅在系统中存在一份JDK 1.3.0，如果在命令行运行java的话，使用的JRE目录是C:\Program Files\JavaSoft\JRE\1.3，也就是说，即使我们在c:\jdk1.3\jre\lib\ext下放置我们的extension jar，也得不到预期的结果。正确的做法是放在C:\Program Files\JavaSoft\JRE\1.3\lib\ext目录下。

解决方法：同问题1

综上所叙，强烈建议将%JDK_HOME%\bin目录放在Windows操作系统的PATH变量的首位，以避免潜在的问题。

而在UNIX下，则完全不存在类似Windows操作系统上的问题。

我们在命令下执行的java是/bin/java

$which java
$/bin/java

而/bin是到/usr/bin的链接，也就是说/bin/java实际上是/usr/bin/java

而/usr/bin/java实际上链接到/usr/java/bin/java，/usr/java是到/usr/java1.2的链接（Solaris 7或更高系统内置JDK 1.2），所以我们实际上执行的java是

/usr/java1.2/bin/java

根据UNIX上的情况，java在运行时实际上总是可以用../jre/lib/sparc/libjava.so和../jre/lib/sparc/libjvm.so来找到这2个文件，前者类似于Windows下的java.dll，而后者类似于Windows下的jvm.dll。所以java也总是可以确定自己JRE的目录。

Windows和UNIX上用到的动态链接库，实际上在Sun的文档中称为optional package's native code binaries，optional pakage实际上即为extension mechanism classes，详见《Java2中的class定位机制》。

要更改UNIX上java的版本，更改/usr/java的链接是其中一个方法，具体可参见JDK在UNIX上的安装介绍。

补充：（2002-12-23）

Windows如何定位Plug-in

根据在PATH环境变量中找到的java.exe的版本号，到HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in下寻找对应版本的Java Plug-in，在HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in下可以有多个版本的Plug-in存在。

不依赖HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit的CurrentVersion值和HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment的CurrentVersion值来定位应该使用哪个版本的Java Plug-in。