走进Java
进一步的了解Java的历史和技术发展方向，可以更好地理解技术新特性的作用，从而找到进一步学习的方向感，嗯，也就有了技术安全感。 😀
以下是整体的思维导图：
概述
Java技术体系
Java发展史
HotSpot 虚拟机：JDK 1.3及之后所有版本的Sun JDK的默认虚拟机JDK。
1.4同样发布了很多新的技术特性，如正则表达式、异常链、NIO、日志类、XML 解析器和 XSLT 转换器等。
JDK1.5 在Java语法易用性上做出了非常大的改进。例如，自动装箱、泛型、动态注解、枚举、可变长参数、遍历循环（ foreach 循环）等语法特性都是在JDK1.5 中加入的。
JDK 1.6 的改进包括：提供动态语言支持（通过内置 Mozilla JavaScript Rhino 引擎实现）、提供编译 API 和微型 HTTP 服务器 API 等。同时，这个版本对 Java 虚拟机内部做了大量改进，包括锁与同步、垃圾收集、类加载等方面的算法都有相当多的改动。
“ B 计划”把不能按时完成的 Lambda 项目、 Jigsaw 项目和 Coin 项目的部分改进延迟到 JDK 1.8 之中。最终， JDK 1.7 的主要改进包括：提供新的 G1 收集器（ G1 在发布时依然处于 Experimental 状态，直至 2012 年 4 月的 Update 4 中才正式“转正”）、加强对非 Java 语言的调用支持（ JSR-292， 这项特性到目前为止依然没有完全实现定型）、升级类加载架构等。
Java虚拟机发展史
Sun Classic/Exact VM
世界上第一款商用 Java 虚拟机
这款虚拟机只能使用纯解释器方式来执行 Java 代码，如果要使用 JIT 编译器，就必须进行外挂。但是假如外挂了 JIT 编译器， JIT 编译器就完全接管了虚拟机的执行系统，解释器便不再工作了。
java version"1.2.2"
Classic VM（build JDK-1.2.2-001，green threads, sunwjit）
其中的"sunwjit" 就是 Sun 提供的外挂编译器，其他类似的外挂编译器还有 Symantec JIT和shuJIT等。
Exact VM在商业应用上只存在了很短暂的时间就被更为优秀的HotSpot VM所取代
Class VM在JDK 1.2 之前是 Sun JDK 中唯一的虚拟机，在 JDK 1.2 时，它与 HotSpot VM 并存，但默认使用的是 Classic VM。
Sun HotSpot VM
HotSpot VM 既继承了 Sun 之前两款商用虚拟机的优点(准确式内存管理)
HotSpot VM 的热点代码探测能力可以通过执行计数器找出最具有编译价值的代码，然后通知 JIT 编译器以方法为单位进行编译。
在 2008 年和 2009 年， Oracle 公司分别收购了 BEA 公司和 Sun 公司，这样 Oracle 就同时拥有了两款优秀的 Java 虚拟机： JRockit VM 和 HotSpot VM。
Sun Mobile-Embedded VM/Meta-Circular VM
BEA JRockit/IBM J9 VM
由于专注于服务器端应用，它可以不太关注程序启动速度，因此 JRockit 内部不包含解析器实现，全部代码都靠即时编译器编译后执行。除此之外， JRockit 的垃圾收集器和 MissionControl 服务套件等部分的实现，在众多 Java 虚拟机中也一直处于领先水平。
IBM J9 的市场定位与 Sun HotSpot 比较接近，它是一款设计上从服务器端到桌面应用再到嵌入式都全面考虑的多用途虚拟机。
Azul VM/BEA Liquid VM
Azul VM 和 BEA Liquid VM 这类特定硬件平台专有的虚拟机才是“高性能”的武器。
Liquid VM 不需要操作系统的支持，或者说它自己本身实现了一个专用操作系统的必要功能，如文件系统、网络支持等。由虚拟机越过通用操作系统直接控制硬件可以获得很多好处，如在线程调度时，不需要再进行内核态/用户态的切换等，这样可以最大限度-地发挥硬件的能力，提升 Java 程序的执行性能。
Apache Harmony/Google Android Darvik VM
Apache Harmony）被吸纳进 IBM 的 JDK 7 实现及 Google Android SDK 之中，尤其是对 Android 的发展起到了很大的推动作用。
Dalvik VM 是 Android 平台的核心组成部分之一，它的名字来源于冰岛一个名为 Dalvik 的小渔村。 Dalvik VM 并不是一个 Java 虚拟机，它没有遵循 Java 虚拟机规范，不能直接执行 Java 的 Class 文件，使用的是寄存器架构而不是 JVM 中常见的栈架构。
Microsoft JVM及其他
展望Java技术的未来
模块化
模块化是建立各种功能的标准件的前提。最近几年 OSGi 技术的迅速发展、各个厂商在 JCP 中对模块化规范的激烈斗争[ 1]， 都能充分说明模块化技术的迫切和重要。
OSGi 已经发布到 R5.0 版本，而 Jigsaw 从 Java 7 延迟至 Java 8，在 2012 年 7 月又不得不宣布推迟到 Java 9 中发布。
《深入理解 OSGi: Equinox 原理、应用与最佳实践》
混合语言
各种语言之间的交互不存在任何困难，就像使用自己语言的原生 API 一样方便[ 1]， 因为它们最终都运行在一个虚拟机之上。
在同一个虚拟机上运行的其他语言与 Java 之间的交互一般都比较容易，但非 Java 语言之间的交互一般都比较烦琐。
多核并行
早在 JDK 1.5 就已经引入 java.util.concurrent 包实现了一个粗粒度的并发框架。而 JDK 1.7 中加入的 java.util.concurrent.forkjoin 包则是对这个框架的一次重要扩充。
通过利用 Fork/Join 模式，我们能够更加顺畅地过渡到多核时代。
函数式编程的一个重要优点就是这样的程序天然地适合并行运行，这对 Java 语言在多核时代继续保持主流语言的地位有很大帮助。
Sumatra 项目就是为 Java 提供使用 GPU（ Graphics Processing Units） 和 APU（ Accelerated Processing Units） 运算能力的工具。
在 JDK 外围，也出现了专为满足并行计算需求的计算框架，如 Apache 的 Hadoop Map/Reduce。
进一步丰富语法
64位虚拟机
由于指针膨胀和各种数据类型对齐补白的原因，运行于 64 位系统上的 Java 应用需要消耗更多的内存。
在 JDK 1.6 Update 14 之后，提供了普通对象指针压缩功能（- XX:+ UseCompressedOops， 这个参数不建议显式设置，建议维持默认由虚拟机的 Ergonomics 机制自动开启）
实战：自己编译JDK
获取JDK源码
OpenJDK 7 和 Oracle JDK 7 在程序上是非常接近的，两者共用了大量相同的代码，所以我们编译的 OpenJDK， 基本上可以认为性能、功能和执行逻辑上都和官方的 Oracle JDK 是一致的。