JRE, JDK, JVM, JIT的区别(转载)
程序员文章站
2022-05-21 07:52:05
...
[size=medium]http://swiftlet.net/archives/639
1. 定义
JRE(Java Runtime Enviroment)是Java的运行环境。面向Java程序的使用者，而不是开发者。如果你仅下载并安装了JRE，那么你的系统只能运行Java程序。JRE是运行Java程序所必须环境的集合，包含JVM标准实现及 Java核心类库。它包括Java虚拟机、Java平台核心类和支持文件。它不包含开发工具(编译器、调试器等)。
JDK(Java Development Kit)又称J2SDK(Java2 Software Development Kit)，是Java开发工具包，它提供了Java的开发环境(提供了编译器javac等工具，用于将java文件编译为class文件)和运行环境(提 供了JVM和Runtime辅助包，用于解析class文件使其得到运行)。如果你下载并安装了JDK，那么你不仅可以开发Java程序，也同时拥有了运行Java程序的平台。JDK是整个Java的核心，包括了Java运行环境(JRE)，一堆Java工具tools.jar和Java标准类库 (rt.jar)。
2. 区别
JRE主要包含：java类库的class文件(都在lib目录下打包成了jar)和虚拟机(jvm.dll)；JDK主要包含：java类库的 class文件(都在lib目录下打包成了jar)并自带一个JRE。那么为什么JDK要自带一个JRE呢？而且jdk/jre/bin下的client 和server两个文件夹下都包含jvm.dll(说明JDK自带的JRE有两个虚拟机)。
记得在环境变量path中设置jdk/bin路径吗？老师会告诉大家不设置的话javac和java是用不了的。确实jdk/bin目录下包含了所有的命令。可是有没有人想过我们用的java命令并不是jdk/bin目录下的而是jre/bin目录下的呢？不信可以做一个实验，大家可以把jdk /bin目录下的java.exe剪切到别的地方再运行java程序，发现了什么？一切OK！(JRE中没有javac命令，原因很简单，它不是开发环境)那么有人会问了？我明明没有设置jre/bin目录到环境变量中啊？试想一下如果java为了提供给大多数人使用，他们是不需要jdk做开发的，只需要jre能让java程序跑起来就可以了，那么每个客户还需要手动去设置环境变量多麻烦啊？所以安装jre的时候安装程序自动帮你把jre的java.exe添加到了系统变量中，验证的方法很简单，去Windows/system32下面去看看吧，发现了什么？有一个java.exe。
3. 难点
如果安装了JDK，会发现你的电脑有两套JRE，一套位于C:\Program Files\Java\jre6， 另外一套位于 C:\Program Files\Java\jdk1.6.0_41\jre目录下。
JRE的地位就象一台PC机一样，我们写好的Win32应用程序需要操作系统帮我们运行，同样的，我们编写的Java程序也必须要JRE才能运行。所以当你装完JDK后，如果分别在硬盘上的两个不同地方安装了两套JRE，那么你可以想象你的电脑有两台虚拟的Java
PC机，都具有运行Java程序的功能。所以我们可以说，只要你的电脑安装了JRE，就可以正确运行Java应用程序。
1、为什么Sun要让JDK安装两套相同的JRE？
这是因为JDK里面有很多用Java所编写的开发工具，如javac.exe、jar.exe等，这些命令放置在 C:\Program Files\Java\jdk1.6.0_41\bin目录里。
因为他们是java编写的命令，所以要依靠java的jar包，这些jar包存放在C:\Program Files\Java\jdk1.6.0_41\lib目录里
如果将C:\Program Files\Java\jdk1.6.0_41\lib\目录里面的tools.jar改名为tools1.jar，然后运行javac.exe，显示如下结果：
Exception in thread "main" java.lang.NoClassDefFoundError: com/sun/tools/javac /Main
但是输入 java -cp C:\Program Files\Java\jdk1.6.0_41\lib\tools1.jar com.sun.tools.javac.Main
会得到与javac.exe相同的结果。
从这里我们可以证明javac.exe只是一个包装器（Wrapper），而制作的目的是为了让开发者免于输入太长的指命。
而且我们可以发现C:\Program Files\Java\jdk1.6.0_41\bin目录下的程序都很小，不大于29K，从这里我们可以得出一个结论。就是JDK里的工具几乎是用Java所编写，所以也是Java应用程序，因此要使用JDK所附的工具来开发Java程序，也必须要自行附一套JRE才行，所以位于C:\Program Files\Java\jdk1.6.0_41\jre目录下的那套JRE就是用来运行一般Java程序用的。
2、如果一台电脑安装两套以上的JRE，谁来决定呢？
这个重大任务就落在java.exe身上。java.exe的工作就是找到合适的JRE来运行Java程序。 java.exe依照底下的顺序来查找JRE：自己的目录下有没有JRE；父目录有没有JRE；查询注册表：
[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment]
所以java.exe的运行结果与你的电脑里面哪个JRE被执行有很大的关系。（本文于2015年6月6日修订）
小提醒：此时的记忆会随着时间的推移而遗忘，温故而知新，建议大家及时把本文收藏下来，以后慢慢回味。
JRE & JVM
JVM -- java virtual machineJVM就是我们常说的java虚拟机，它是整个java实现跨平台的最核心的部分，所有的java程序会首先被编译为.class的类文件，这种类文件可以在虚拟机上执行，class文件并不直接与机器的操作系统相对应，而是经过虚拟机间接与操作系统交互，由虚拟机将程序解释给本地系统执行，类似于C#中的CLR。
JVM不能单独搞定class的执行，解释class的时候JVM需要调用解释所需要的类库lib。在JDK下面的的jre目录里面有两个文件夹bin和lib,在这里可以认为bin里的就是jvm，lib中则是jvm工作所需要的类库，而jvm和 lib和起来就称为jre。JVM+Lib=JRE，如果讲的具体点就是bin目录下的jvm.dll文件， jvm.dll无法单独工作，当jvm.dll启动后，会使用explicit的方法(就是使用Win32 API之中的LoadLibrary()与GetProcAddress()来载入辅助用的动态链接库)，而这些辅助用的动态链接库(.dll)都必须位 于jvm.dll所在目录的父目录之中。因此想使用哪个JVM，只需要设置PATH，指向JRE所在目录下的jvm.dll。
JVM & JIT(zz)
http://blogzhoubo.iteye.com/blog/1703871
首先，需要了解JVM对字节码的编译技术。一个JAVA程序通过javac编译成字节码以后，在执行的时候，由JVM将字节码编译成本地机器码，然后再执行。将字节码转换成
机器码，JVM有两种利器，一种就是JIT，还有一种是转译器（interpreter）。
1>转译器
转译器将每个Java指令都转译成对等的微处理器指令，并根据转译后的指令先后次序依序执行，由于一个Java指令可能被转译成十几或数十几个对等的微处理器指令，这种模式执行的速度相当缓慢。
2>JIT
针对转译器的速度瓶颈，出现了JIT。JIT针对一个具体的class进行编译，经过编译后的程序，被优化成相当精简的原生型指令码（native code）。编译过一次，下次再执行的时候就不用再次编译了，所以执行次数较多的代码，采用JIT还是十分划算的。但是，JIT也不是万能的，比如：某些极少执行到的Java指令在编译时所额外花费的时间可能比转译器在执行时的时间还长，这时候就不如直接使用转译器。
所以，转译器和JIT各有优缺点。
1>极少执行到或者执行次数较少的Java代码，使用转译器更划算。
2>重复执行或者执行次数较多的Java代码，采用JIT更划算。
然后，我们回到JVM远程调试的正题。我们一般debug程序的时候，只是关注其中的一部分代码，而且大部分情况下是设置断点，然后单步执行，而JIT的编译单位是class，只要我们执行了class里面的代码，JIT就会对整个class进行编译，而我们实际执行的代码一般都是其中的一部分代码，所以从整个时间效率上来看，采用JIT反而更费时间。也就是说在JVM远程调试这个事情上，禁用JIT（只使用转译器，解释一行执行一条）更合理，所以通过-Djava.compiler=NONE来禁止JIT。
此外，在程序中也可以即时地禁用和开启JIT。
java.lang.Compiler.disable();
java.lang.Compiler.enable();
1. 定义
JRE(Java Runtime Enviroment)是Java的运行环境。面向Java程序的使用者，而不是开发者。如果你仅下载并安装了JRE，那么你的系统只能运行Java程序。JRE是运行Java程序所必须环境的集合，包含JVM标准实现及 Java核心类库。它包括Java虚拟机、Java平台核心类和支持文件。它不包含开发工具(编译器、调试器等)。
JDK(Java Development Kit)又称J2SDK(Java2 Software Development Kit)，是Java开发工具包，它提供了Java的开发环境(提供了编译器javac等工具，用于将java文件编译为class文件)和运行环境(提 供了JVM和Runtime辅助包，用于解析class文件使其得到运行)。如果你下载并安装了JDK，那么你不仅可以开发Java程序，也同时拥有了运行Java程序的平台。JDK是整个Java的核心，包括了Java运行环境(JRE)，一堆Java工具tools.jar和Java标准类库 (rt.jar)。
2. 区别
JRE主要包含：java类库的class文件(都在lib目录下打包成了jar)和虚拟机(jvm.dll)；JDK主要包含：java类库的 class文件(都在lib目录下打包成了jar)并自带一个JRE。那么为什么JDK要自带一个JRE呢？而且jdk/jre/bin下的client 和server两个文件夹下都包含jvm.dll(说明JDK自带的JRE有两个虚拟机)。
记得在环境变量path中设置jdk/bin路径吗？老师会告诉大家不设置的话javac和java是用不了的。确实jdk/bin目录下包含了所有的命令。可是有没有人想过我们用的java命令并不是jdk/bin目录下的而是jre/bin目录下的呢？不信可以做一个实验，大家可以把jdk /bin目录下的java.exe剪切到别的地方再运行java程序，发现了什么？一切OK！(JRE中没有javac命令，原因很简单，它不是开发环境)那么有人会问了？我明明没有设置jre/bin目录到环境变量中啊？试想一下如果java为了提供给大多数人使用，他们是不需要jdk做开发的，只需要jre能让java程序跑起来就可以了，那么每个客户还需要手动去设置环境变量多麻烦啊？所以安装jre的时候安装程序自动帮你把jre的java.exe添加到了系统变量中，验证的方法很简单，去Windows/system32下面去看看吧，发现了什么？有一个java.exe。
3. 难点
如果安装了JDK，会发现你的电脑有两套JRE，一套位于C:\Program Files\Java\jre6， 另外一套位于 C:\Program Files\Java\jdk1.6.0_41\jre目录下。
JRE的地位就象一台PC机一样，我们写好的Win32应用程序需要操作系统帮我们运行，同样的，我们编写的Java程序也必须要JRE才能运行。所以当你装完JDK后，如果分别在硬盘上的两个不同地方安装了两套JRE，那么你可以想象你的电脑有两台虚拟的Java
PC机，都具有运行Java程序的功能。所以我们可以说，只要你的电脑安装了JRE，就可以正确运行Java应用程序。
1、为什么Sun要让JDK安装两套相同的JRE？
这是因为JDK里面有很多用Java所编写的开发工具，如javac.exe、jar.exe等，这些命令放置在 C:\Program Files\Java\jdk1.6.0_41\bin目录里。
因为他们是java编写的命令，所以要依靠java的jar包，这些jar包存放在C:\Program Files\Java\jdk1.6.0_41\lib目录里
如果将C:\Program Files\Java\jdk1.6.0_41\lib\目录里面的tools.jar改名为tools1.jar，然后运行javac.exe，显示如下结果：
Exception in thread "main" java.lang.NoClassDefFoundError: com/sun/tools/javac /Main
但是输入 java -cp C:\Program Files\Java\jdk1.6.0_41\lib\tools1.jar com.sun.tools.javac.Main
会得到与javac.exe相同的结果。
从这里我们可以证明javac.exe只是一个包装器（Wrapper），而制作的目的是为了让开发者免于输入太长的指命。
而且我们可以发现C:\Program Files\Java\jdk1.6.0_41\bin目录下的程序都很小，不大于29K，从这里我们可以得出一个结论。就是JDK里的工具几乎是用Java所编写，所以也是Java应用程序，因此要使用JDK所附的工具来开发Java程序，也必须要自行附一套JRE才行，所以位于C:\Program Files\Java\jdk1.6.0_41\jre目录下的那套JRE就是用来运行一般Java程序用的。
2、如果一台电脑安装两套以上的JRE，谁来决定呢？
这个重大任务就落在java.exe身上。java.exe的工作就是找到合适的JRE来运行Java程序。 java.exe依照底下的顺序来查找JRE：自己的目录下有没有JRE；父目录有没有JRE；查询注册表：
[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment]
所以java.exe的运行结果与你的电脑里面哪个JRE被执行有很大的关系。（本文于2015年6月6日修订）
小提醒：此时的记忆会随着时间的推移而遗忘，温故而知新，建议大家及时把本文收藏下来，以后慢慢回味。
JRE & JVM
JVM -- java virtual machineJVM就是我们常说的java虚拟机，它是整个java实现跨平台的最核心的部分，所有的java程序会首先被编译为.class的类文件，这种类文件可以在虚拟机上执行，class文件并不直接与机器的操作系统相对应，而是经过虚拟机间接与操作系统交互，由虚拟机将程序解释给本地系统执行，类似于C#中的CLR。
JVM不能单独搞定class的执行，解释class的时候JVM需要调用解释所需要的类库lib。在JDK下面的的jre目录里面有两个文件夹bin和lib,在这里可以认为bin里的就是jvm，lib中则是jvm工作所需要的类库，而jvm和 lib和起来就称为jre。JVM+Lib=JRE，如果讲的具体点就是bin目录下的jvm.dll文件， jvm.dll无法单独工作，当jvm.dll启动后，会使用explicit的方法(就是使用Win32 API之中的LoadLibrary()与GetProcAddress()来载入辅助用的动态链接库)，而这些辅助用的动态链接库(.dll)都必须位 于jvm.dll所在目录的父目录之中。因此想使用哪个JVM，只需要设置PATH，指向JRE所在目录下的jvm.dll。
JVM & JIT(zz)
http://blogzhoubo.iteye.com/blog/1703871
首先，需要了解JVM对字节码的编译技术。一个JAVA程序通过javac编译成字节码以后，在执行的时候，由JVM将字节码编译成本地机器码，然后再执行。将字节码转换成
机器码，JVM有两种利器，一种就是JIT，还有一种是转译器（interpreter）。
1>转译器
转译器将每个Java指令都转译成对等的微处理器指令，并根据转译后的指令先后次序依序执行，由于一个Java指令可能被转译成十几或数十几个对等的微处理器指令，这种模式执行的速度相当缓慢。
2>JIT
针对转译器的速度瓶颈，出现了JIT。JIT针对一个具体的class进行编译，经过编译后的程序，被优化成相当精简的原生型指令码（native code）。编译过一次，下次再执行的时候就不用再次编译了，所以执行次数较多的代码，采用JIT还是十分划算的。但是，JIT也不是万能的，比如：某些极少执行到的Java指令在编译时所额外花费的时间可能比转译器在执行时的时间还长，这时候就不如直接使用转译器。
所以，转译器和JIT各有优缺点。
1>极少执行到或者执行次数较少的Java代码，使用转译器更划算。
2>重复执行或者执行次数较多的Java代码，采用JIT更划算。
然后，我们回到JVM远程调试的正题。我们一般debug程序的时候，只是关注其中的一部分代码，而且大部分情况下是设置断点，然后单步执行，而JIT的编译单位是class，只要我们执行了class里面的代码，JIT就会对整个class进行编译，而我们实际执行的代码一般都是其中的一部分代码，所以从整个时间效率上来看，采用JIT反而更费时间。也就是说在JVM远程调试这个事情上，禁用JIT（只使用转译器，解释一行执行一条）更合理，所以通过-Djava.compiler=NONE来禁止JIT。
此外，在程序中也可以即时地禁用和开启JIT。
java.lang.Compiler.disable();
java.lang.Compiler.enable();