java运行机制详细
JVM(Java虚拟机)一种用于计算设备的规范，可用不同的方式（软件或硬件）加以实现。编译虚拟机的指令集与编译微处理器的指令集非常类似。Java虚拟机包括一套字节码指令集、一组寄存器、一个栈、一个垃圾回收堆和一个存储方法域。
Java虚拟机(JVM)是可运行Java代码的假想计算机。只要根据JVM规格描述将解释器移植到特定的计算机上，就能保证经过编译的任何Java代码能够在该系统上运行。
1.为什么要使用Java虚拟机
Java语言的一个非常重要的特点就是与平台的无关性。而使用Java虚拟机是实现这一特点的关键。一般的高级语言如果要在不同的平台上运行,至少需要编 译成不同的目标代码。而引入Java语言虚拟机后,Java语言在不同平台上运行时不需要重新编译。Java语言使用模式Java虚拟机屏蔽了与具体平台 相关的信息,使得Java语言编译程序只需生成在Java虚拟机上运行的目标代码(字节码),就可以在多种平台上不加修改地运行。Java虚拟机在执行字 节码时,把字节码解释成具体平台上的机器指令执行。
Java运行机制
Java程序的运行必须经过编写 、编译 、运行 三个步骤。
编写是指在Java开发环境中进行程序代码的输入，最终形成后缀名为.java的Java源文件。
编译是指使用Java编译器对源文件进行错误排查的过程，编译后将生成后缀名为.class的字节码文件，这不像C语言那样最终生成可执行文件。
运行是指使用Java解释器将字节码文件翻译成机器代码，执行并显示结果。这一过程如图1.1所示。
字节码文件是一种和任何具体机器环境及操作系统环境无关的中间代码，它是一种二进制文件，是Java源文件由Java编译器编译后生成的目标代码文件。编程人员和计算机都无法直接读懂字节码文件，它必须由专用的Java解释器来解释执行，因此Java是一种在编译基础上进行解释运行的语言。
Java解释器负责将字节码文件翻译成具体硬件环境和操作系统平台下的机器代码，以便执行。因此Java程序不能直接运行在现有的操作系统平台上，它必须运行在被称为Java虚拟机的软件平台之上。
Java虚拟机（JVM）是运行Java程序的软件环境，Java解释器就是Java虚拟机的一部分。在运行Java程序时，首先会启动JVM，然 后由它来负责解释执行Java的字节码，并且Java字节码只能运行于JVM之上。这样利用JVM就可以把Java字节码程序和具体的硬件平台以及操作系 统环境分隔开来，只要在不同的计算机上安装了针对于特定具体平台的JVM，Java程序就可以运行，而不用考虑当前具体的硬件平台及操作系统环境，也不用 考虑字节码文件是在何种平台上生成的。JVM把这种不同软硬件平台的具体差别隐藏起来，从而实现了真正的二进制代码级的跨平台移植。JVM是Java平台 无关的基础，Java的跨平台特性正是通过在JVM中运行Java程序实现的。Java的这种运行机制可以通过图1.2说明。
Java语言这种“一次编写，到处运行（write once，run anywhere）”的方式，有效地解决了目前大多数高级程序设计语言需要针对不同系统来编译产生不同机器代码的问题，即硬件环境和操作平台的异构问题，大大降低了程序开发、维护和管理的开销。
需要注意的是，Java程序通过JVM可以达到跨平台特性，但JVM是不跨平台的。也就是说，不同操作系统之上的JVM是不同的，Windows平台之上的JVM不能用在Linux上面，反之亦然。
示例：
我们可以通过helloworld来理解这几个缩写词的具体含义：
public class HelloWorld { public static void main(String[] args) { System.out.println("helloworld"); }}
编译之后， 我们得到了HelloWorld.class（图中的"Your program's class files"）
在HelloWorld里面， 我们调用了 Java API中的 java.lang.System这个类的静态成员对象 out, out 的静态方法: public static void println(String string);
然后我们让虚拟机器来执行这个HelloWorld。
1. 虚拟机会在classpath中找到HelloWorld.class。
2. 虚拟机中的解释器(interpret)会把HelloWorld.class解释成字节码。
3. 把解释后的字节码交由execution engin执行。
4. execution engin会调用native method(即平台相关的字节码）来在host system的stdout(显示器)的指定部分打印出指定的字符串。
5. 这样， 我们就看到"helloworld"字样了。
有了这个流程后， 我们就好理解上面几个术语了：
a. JDK: java develop kit (JAVA API包)，编译，运行等开发工具 jdk=jre+jvm
b. SDK: software develop kit, 以前JDK 叫做java software develop kit， 后来出了1.2版本后， 就改名叫jdk了， 省时省力， 节约成本。
c. JRE. java runtime environment 我们的helloworld必须在JRE(JAVA运行环境,JAVA运行环境又叫JAVA平台）里面， 才能跑起来。
d. JVM java virtual machine. 简单地讲， 就是把class文件变成字节码， 然后送到excution engin中执行。而为什么叫虚拟机， 而不叫真实机呢？ 因为JVM本身是又不能运算， 又不能让显示器显示"helloworld"的， 它只能再调用host system的API， 比如在w32里面就会调c++的API， 来让CPU帮他做做算术运算，来调用c++里面的API来控制显示器显示显示字符串。 而这些API不是JDK里面有的，我们平时又看不见的，所以我们就叫它native api了（亦曰私房XX）。
e. 解释平台无关。 有人会说， 在linux的里面调用native api与w32里面调用的api肯定不一样吧？ 那为什么说JAVA是平台无关的呢？
其实是这样的， 君不见java.sun.com里面又有jdk-for-w32又有jdk-for-linux下载吗？ 刚才不是说了吗？ native api, native api, 就是我们平时看不见的api吗！ 调用native这些烦琐的活儿都让jdk去做了。所以我们调用的时候只用知道jdk(java api) 里面的java.io.*能提供磁盘访问功能， java.awt.* 能画个框框画个圆圆就行了吗。 至于JDK又是怎么调用的， 在LINXU上更圆呢？ 还是在W32上更圆，(x) 这个就是JDK个人的事情了。（理论上讲是一样圆的， 当然这又和显示器是否纯平相关了:D)
同时， 这里就引申出了另一个话题。既如何编写平台无关的JAVA程序。 其中关键的一条， 就是调用且只调用jdk中的API， 而不要私自调用native api。 原因很简单啊， JDK-for-linux和JDK-for-w32表面都是一样的，所以我在w32里面调用JDK写的java程序，在linux里面也会一样的写法 啊， 所以就可以移植来移植去都没问题。(b) 但是如果我在w32里面调用了 一个图形显示的native api, 当我移植到linux去的时候， 谁又能保证里面也有相同名称，相同参数，相同返回值， 相同功能的native api供我调用呢！(?)
