java发展历程

                        Java技术本纪

Java虚拟机的  10    年

Java虚拟机的起源与构造
当我们说到“Java”这个词的时候，指的是四个相互关联的概念：Java语言、Java API、Java Class文件格式、Java虚拟机。整个Java体系是基于Java 虚拟机构造的，正因为如此，才能实现Java的安全性和网络移动性。Java并非是第一个采用“虚拟机”概念的体系，但却是第一个得到广泛运用的虚拟机平台。 “虚拟”，是一种隔离物理资源与逻辑资源的手段。Java虚拟机的“虚拟”，则是用来隔离物理机器、底层操作系统与Java语言规范实现的手段。
虽然Java是一种面向对象的语言，我们平时大量使用的，是对象间的多态、组合(Composition)、委派（Delegation）,但当我们讨论虚拟机的时候，我们看见的基本概念却是“栈(Stack)”和“堆(Heap)”。根据冯诺依曼的“存储计算”模型，所有的代码都保存在代码空间中，随着程序计数器指针的变化进行程序的执行、跳转。Java虚拟机中没有寄存器的概念，方法调用是采用“栈”进行的，这是一种安全、简洁的方法。
Java虚拟机通过类装载器支持对类的隔离，这也是Java实现安全性的基础。每个类都具有自己的命名空间，在具有不同安全级别的沙箱中运行，因此不会产生低安全级别的代码来越权访问高级别代码的机会。类装载器的出现是Java虚拟机与大部分用C实现的虚拟机的显著不同之处。
Java虚拟机的另外一个显著特点就是实现了自动的垃圾收集。在往常，写程序的时候要牢记对象之间的关联，在每个程序块中假若申请了对象空间，就必须在出口释放掉，方法调用往往同时也就是对象的边界。而自动垃圾收集带给开发者的最大好处，就是可以非常方便地从整体上把系统的对象组织成一张对象图，只需往这张图中添加对象，维护对象之间的关联，却不需要自己做复杂的清扫工作。正是有了这种思维单纯的对象图的支持，OR Mapping(关系数据库与对象映射）技术在最近得以大行其道，设计模式也更容易被Java群体所接受。

虚拟机的优化
1995年第一代的Java出台之时，其虚拟机执行是依靠“字节码解释器（Byte Code Interceptor）”的，也就是说每条指令都由虚拟机来当场解释执行，这造成速度令人抓狂地缓慢。更有甚者有人开始总结许多的“速度优化经验”，比如说：“尽量把所有的代码都放在较大的方法中执行”与“少用接口”等等，这完全与Java语言的设计目的背道而驰，现在看起来是多么可笑的奇谈怪论，当时却是很多程序员津津乐道的经验之谈。无他，Java本身执行太慢了。Java生命的前十分之三就是如此缓慢地渡过的。

于是，Sun的工程师开始拼命想着提高执行速度。JIT静态编译器的出现是在1996年十月，Sun放出了第一个编译器。JIT编译器在每段代码执行前进行编译，编译的结果为本地静态机器码，执行速度有了质的提高。Symantec公司当时凭借其傲人的JIT编译器，在整个Java界受到热烈的追捧。在其后的1998年，Java 1.2发布的时候，附带了JIT编译器，从此Java的使用者终于可以抛开上面说的那些奇怪的“速度优化经验”了。
JIT静态编译器虽然可以解决一些问题，但是性能仍然和C/C++有很大的差距。对一段程序而言，一名优秀的程序员是如何来改进运行速度的呢？首先，他不会傻到把所有的代码都来优化，他会观察、思考到底哪段代码对整体性能影响最大？然后集中精力来优化这一段代码。按照经验，整个程序 10%-20%的代码，会占据 80%-90%的运行时间。用这种方法，在同样的时间、付出同样程度的努力后，这名优秀的程序员使整个程序的性能得到了很大程度的优化。HotSpot引擎，就是模仿人工的这种方法进行优化的。在程序运行的开始，Java代码仍然解释执行，但HotSpot引擎开始进行采样(Profiling)。根据采样的结果，决定某段程序是占用较多运行时间的，就认为它是“HotSpot”，它也就是目前程序的瓶颈， 引擎开始启动一个单独的线程进行优化。因为不象原始的 JIT编译器那样无差别的编译所有代码，HotSpot引擎可以集中精力来对HotSpot代码进行深度优化，这样这部分代码执行起来更加迅捷。之前的静态编译器只能按照预定的策略进行编译优化，而HotSpot引擎的优化是基于采样的结果的，因此这种方法对所有的应用程序都有效。1999年3月27日，Sun放出了第一个HotSpot引擎。在随后的2000年5月的JDK 1.3中，包含了HotSopt引擎，这也使1.3成了一个具有里程碑意义的发行版本。到这里，Java的十年生命，已经过去了一半。
HotSpot代表的是一种动态编译的技术。对Java这种大量使用委派、组合等面向对象特性的程序来说，动态编译比起静态编译来有显著的优势。比如Method Inlining。方法的调用是一个很耗时的操作，假若可以把方法调用直接内嵌到调用者的代码中，就可以节省大量的时间， 这被称为“Method Inlining”。因为涉及到类的重载，静态优化很难确切知道哪些属性、方法被重载，因此很难对method进行合并，只好在方法内部进行静态编译，假若每个方法都很小，静态优化能起到的作用也就比较小。而动态编译因为可以完全随时掌握类的重载情况，就可以把相关的方法合并进行深度优化。现代的Java程序，特别是在设计模式教育得到普及之后，大量使用类的继承、委派，形成了很多短小的方法，动态编译的优势就更加明显。
自从出现了HotSpot之后，整个Java界为之一振。
最近的五年，就是继续优化的五年。继续进行优化的方法有几条路，一是研究新的采样算法。因为采样关系到不同的优化策略，会对整体性能有比较大的影响。二是研究深度优化的方法。三是研究垃圾收集的算法。垃圾收集会带来程序短暂的停顿，这会带来负面的用户体验。于是，如何提高垃圾收集的效率，减少延迟，出现了五花八门的算法，比如渐进式收集、火车算法等。在多处理器的时候，如何利用多处理器进行并行收集也是研究的一个热点。这方面，BEA的JRocket走在了前面。

现实生活中的虚拟机
最后，让我们来盘点一下目前市面上可见的各个虚拟机。
首先要提到的，毫无疑问是Sun的虚拟机。作为大众心目中的“官方实现”，Sun拥有最大的用户群，并且拥有“兼容基准”的地位，其他虚拟机都必须要考虑和Sun虚拟机的兼容性问题。比如 JRocket就会在某些特殊情况下表现出和Sun不同的特性，可能对程序运行有影响。不过Sun也的确没有让广大用户失望，虽然在早期性能比不上Symantec,后来在1.2 的时候性能又被IBM超越，但Sun一直在努力革新，特别是 1.4.2之后，性能有了长足的进步。虽然JDK 1.5的虚拟机在性能上没有什么提高，但是增强了稳定性，据说修改了8000处bug，真是让人汗流不止。原来我们在1.4.2下面一直在享受这么多bug啊。

其次是老牌劲旅IBM。IBM的JDK在1.3的时代创下了最好的性能记录，从此树立了高端形象。特别是在其WebSphere产品中得到了很好的评价。其JDK也是最早支持64bit的JDK之一。到了现在，IBM JDK在高端仍然是和BEA可以一拼的。
然后是后起之秀，BEA的JRocket。说到BEA突然在JVM领域一夜之间异军突起，多少让人有些瞠目，不过它采取的战略特别简单：自己没有，索性花钱买了在此领域深有研究的JRocket，在前面加上BEA的标志就可以了。JRocket瞄准高端服务器市场，在多处理器环境下有不俗的表现。
除此之外，还有几个开放源代码的JVM值得一提。首先就是大名鼎鼎的JikesRVM。说起其大名，大多数人都知道Jikes编译器是 IBM开发的，效率比同等的javac编译器高得多，很多开发者都使用Jikes编译器来取代javac。而JikesRVM则是IBM开源出来的一整套虚拟机技术，包含了JIT，GC的完整实现，在其网站上也有众多的论文，实在是想要深入研究JVM者的绝佳资源(http://jikesrvm.sourceforge.net)。
Kaffe是一个老牌的JVM,不过现在已经很少听到了。作者撰写此文时，www.kaffe.org网站已经没有响应，也不知道现在的情况如何了。
GNU则有两个计划：GCJ和GNU classpath。GNU classpath是一个底层实现，而GCJ是支持java的预编译器。

结束语
时光流转，轰轰烈烈的Java虚拟机性能争论仿佛还在耳边回响，现在新的争论却已经是“Java的性能是否已经超越C/C++”。Joakim Dahlstedt 是 JRockit 的主要架构设计师之一，他坚持认为，Java绝不是一种速度慢，效率低的语言，JVM 是一个关键的组件，确保了系统的部署与运行和开发一样快速、轻松。特别是在目前开发趋势是采用大量预制的框架时，动态编译有可能比C/C++这样的静态优化获得更好的性能。

 

J2EE五年: 从起源到目的
文/刘天北

起点
在“J2EE”这个缩略语被第一次介绍给世人的时刻，也许没有几个人可以预料出它在日后的奇特历程。那是在1999年6月的JavaOne年会上，时任Sun公司Java企业开发部门主管的Mala Chandra兴奋地预告了Java世界的这位新成员。那些不熟悉背景的听众们，揣摩着她演说中出现的一串串全新术语，表情大概又是惊喜、又是迷惑:一个完整的“多层企业开发架构”、以“容器”和“组件”的形式提供服务、一套“厂商中立的开放技术规范”、对开发者隐藏了不同平台和“中间件”的技术细节、实现了企业级应用间的“无缝集成”等等。在今天的开发者看来，这些似乎都已经是老生常谈，但在当时的场景下，闪动在幻灯片上的每一个口号，都意味着听众们事后又要经历一段困难的学习过程。
幸亏Chandra有一副了不起的口才；这位本科念建筑学的印度裔高层主管，谈起软件架构来也有特强的空间想象力。她清晰地说明了设计J2EE架构的两个初衷：首先，对于厂商，J2EE意味着一套开放标准，加入这个标准，他们的产品就可以运行在各种不同的操作系统和工作环境下，成为一个成熟的企业运算体系中可替换的部件；其次，对于开发者，J2EE是一套现成的解决方案，采用这个方案，企业应用开发中的很多技术难题（包括跨平台移植、事务处理、安全性等等）就会迎刃而解，“信息像一条不间断的河流，经过各种各样的平台和设备，从企业应用系统的这一端流向那一端”。
要想理解这段话在当时的实际效应，我们仍然要把时间指针拨回1999年。除了预备迎接千年虫之外，99年你做了什么？为了回答这个犀利的问题，我翻出6年前的工作记录，发现了自己那时参与的一个项目的规格说明书，它正好能提供一幅“Java企业开发”在1999年的标准照。这是一家日本知名IT厂商的企业信息管理系统，运行在NetScape 3.0 Gold浏览器中的Java Applet界面，通过一个专用的中间层系统与Oracle 8数据库连接。这个中间层已经相当现成、完善，能够提供远程对象调用、事务处理等一系列的底层服务；留给我们的任务只是完成服务器端业务对象代码，以及相应的客户端交互开发。
除了Applet客户端有些特别之外，上述系统与今天常见的J2EE架构很接近；尤其是业务对象编码也由home类、PK（主键）类、entity类等部分构成，很多机制都与EJB如出一辙——只不过这些类并没有继承javax.ejb包的接口，而是采用了专用的API。它与EJB之间的相似不像是偶然的，设计者肯定参照了Sun在1997年底推出的EJB 1.0技术规范。
换言之，在J2EE诞生伊始的语境中，市面上已经存在着很多程度不一的“准J2EE中间件”了。它们主要用于解决三大类问题：事务处理、分布式对象管理和Web请求处理。首先，事务处理管理器（Transaction Processing Monitor）一直是高端企业计算领域的热门产品，著名的应用服务器厂商BEA，正是通过收购事务处理软件Tuxedo进入中间件市场的。另一方面，从90年代初开始，越来越多的人把“N层分布式对象架构” 当成传统的客户端/服务器架构的替代方案。那时刚刚兴起的CORBA技术是推动这一趋势的重要力量（比如说，前面提到的那个由日本厂商自行开发的专用中间层，就采用了CORBA作为基础架构）。最后，Java技术在Web领域中的应用也是当时初露头角的热点。1997年6月，Sun在发布一款“Java Web Server”的同时第一次公布了Servlet API；没想到这项技术副产品（连同1998年问世的JSP）正好迎合了厂商的战略需要。对于上面提到的N层架构来说，HTTP服务是一个非常理想的前端；所以基于Java的Web引擎，也在此时成了企业级Java解决方案的一个必不可少的