Java平台和语言最开始只是SUN公司在1990年12月开始研究的一个内部项目：
Java的平台无关性
Java平台和语言最开始只是SUN公司在1990年12月开始研究的一个内部项目[stealth 秘密行动],主要研究：交互式电视、烤面包箱等微型系统.Sun内部人员把这个项目称为Green JamesGosling[詹姆斯·高斯林]
消费类电子产品要求可靠性高、费用低、标准化、使用简单，用户并不关心CPU的型号，也不欣赏专用昂贵的RISC处理器，他们需要这些产品是建立在一个标准的基础之上，有一系列可选的方案。为了使整个系统与平台无关，Gosling首先从改写C编译器着手。但是Gosling在改写过程中感到仅C是无法满足需要的，于是在1991年6月份开始准备开发一个新的语言。
Gosling在设计中采用了虚机器码（VirtualMachineCode）方式，即Java语言编译后产生的是虚拟机码，虚拟机码运行在一个解释器上，每一个操作系统均有一个解释器。这样一来，Java就成了平台无关语言。
JVM简介
Jvm英文全称：Java Virtual Machine（Java虚拟机）。
虚拟机：通过软件来模拟出来的具有完整的硬件系统功能的、运行在完全隔离的环境中的完整的计算机系统。例如：在人工的草原养殖场模拟真实的草原环境，你们家里的小池塘模拟真实的海洋环境。jvm世界观：java对象在jvm里的生老病死。Jvm一样也是通过在实际的计算机中软件虚构出来的，用来模拟一套完整的运行平台。Java的一次编写处处运行：是指在一段代码可以在不同的平台运行，这就归功于jvm。作为java编译器和os之间的虚拟解释器，jvm根据不同的os，将java编译后的目标代码（字节码）解释成不同os可以运行的机器指令，所以说：有了jvm之后呢，java语言在不同平台上运行时不需要重新编译。一次编写，处处运行！
JVM发展史
从1996年初Sun公司发布的JDK 1.0中所包含的Sun Classic VM至今有很多jvm；
本次详细介绍下跟我们有关的虚拟机
- Sun Classic
- Exact VM
- Sun HotSpot VM
其余的比如：
-
Sun Mobile-Embedded VM / Meta-Circular VM
-
BEA JRockit / IBM J9 VM
-
Azul VM / BEA Liquid VM
JVM发展史-Exact VM
JDK 1.2时，曾在Solaris平台上发布过一款名为Exact VM的虚拟机，它的执行系统已经具备现代高性能虚拟机的雏形：如支持编译器与解释器混合工作模式。
Exact VM因它使用准确式内存管理（Exact Memory Management，也可以叫Non-Conservative/Accurate Memory Management）而得名。
虚拟机可以知道内存中某个位置的数据具体是什么类型。譬如内存中有一个32位的整数123456，它到底是一个reference类型指向123456的内存地址还是一个数值为123456的整数，虚拟机将有能力分辨出来，这样才能在GC（垃圾收集）的时候准确判断堆上的数据是否还可能被使用。
由于使用了准确式内存管理，Exact VM可以抛弃以前Classic VM基于handle的对象查找方式每次定位对象都少了一次间接查找的开销，提升执行性能。
基于handle(句柄)的对象查找：当123456指向的对象经过一次垃圾回收后，内存地址需要重新规整。内存地址发生了变化为654321，不能将内存中所有的值为123456数据都改为654321。使用句柄来管理对象内存地址的变动，所以定位对象时先去句柄查下实际的地址再去查找对象本身的属性。类似于对象的户口变更登记册。
句柄可以理解为：引用的引用。指针的指针。
发展史- SC/EV
Sun Classic / Exact VM的生命周期
虽然Exact VM的技术相对Classic VM来说先进了许多，但是在商业应用上只存在了很短暂的时间就被更为优秀的HotSpot VM所取代，甚至还没有来得及发布Windows和Linux平台下的商用版本。
而Classic VM的生命周期则相对长了许多，它在JDK 1.2之前是Sun JDK中唯一的虚拟机，在JDK 1.2时，它与HotSpot VM并存，但默认使用的是Classic VM（用户可用java -hotspot参数切换至HotSpot VM），而在JDK 1.3时，HotSpot VM成为默认虚拟机，但Classic VM仍作为虚拟机的“备用选择”发布（使用java -classic参数切换），直到JDK 1.4的时候，Classic VM才完全退出商用虚拟机的历史舞台
JVM发展史-热点代码探测技术
HotSpot VM的热点代码探测技术
- 可以通过执行计数器找出最具有编译价值的代码，根据执行计数器判断是否达到阈值，没到就解释执行，否则提交编译请求，通知JIT编译器以方法为单位进行编译。
所以：如果一个方法被频繁调用，或方法中有效循环次数很多，将会分别触发标准编译和OSR（栈上替换）编译动作。OSR：由于代码块可能是在代码块在解释执行过程中直接切换到本地代码执行，所以也叫做栈上替换（OSROnStackReplacement）
- 通过编译器与解释器恰当地协同工作，可以在最优化的程序响应时间与最佳执行性能中取得平衡，即时编译的时间压力也相对减小，这样有助于引入更多的代码优化技术，输出质量更高的本地代码[机器执行码]。