深入类加载器.docVIP

1 第二章 深入类别载入器 如果阳春白雪真的是曲高和寡， 我希望有一天我能用下里巴人的方式 来引导他们学会阳春白雪。 █前言 程序设计师在开发应用程序的时候，常常被老板耳提面命，要求写出来的程序要有弹性，容易 扩充，甚至要求要能”Plug and Play”，相信不少程序设计师听到这些要求就非常头痛。在本文之 中，笔者把这种需求称做对于『动态性』的需求。有了动态性，我们的应用程序就可以在不用全盘 重新编译的情况下更新系统，或者在不用停止主程序运作的情况下(尤其是您的系统必须24 小时运 转，一停止就会造成巨大损失时)，除去系统中原有的bug，或者是增加原本不具备的新功能。 一般来说，常见的程序语言先天上并不具有动态性的本质，如C、C++本身就不具备动态性。因 此，为了让这些本身不具有动态性的程序语言具有某种程度的动态性，就必须依赖底层的操作系统 提供一些机制来实现动态性，Windows 操作系统底下的动态联结函式库(Dynamic Linking Library) 和Unix 底下的共享对象(Share Object)这是这样的例子。但是，要运用这些底层操作系统所提供的 机制，程序设计师必须多费一些功夫来撰写额外的程序代码(例如Windows 平台上需要使用 LoadLibrary()与GetProcAddress()两个Win32 API 来完成动态性的需求)，这些额外撰写的程序代码 也会因为作业平台的不同而不同，毕竟这些额外的程序代码与程序本身的运作逻辑甚少关联，所以维 护起来虽不算复杂，但仍有其难度。 相对来说，Java 是一个本质上就具有『动态性』的程序语言。在一般使用Java 程序语言来开 发应用程序的工程师眼中，很少有机会能够察觉Java 因为具备了动态性之后所带来的优点和特性， 甚至根本不曾利用过这个Java 先天就具有的特性。这不是我们的错，而是因为这个动态的本质被巧 妙地隐藏起来，使得使用Java 的程序设计师在不知不觉中用到了动态性而不自知。 程序语言本质上就具备动态性的优点在于，程序设计师不需要撰写额外的程序代码，所以比较没 有跨平台的问题。而缺点则是底层的黑箱帮我们搞定了一大堆的琐碎工作，一旦程序设计师想要” 御驾亲征”，自己完全主控动态性的时候，就必须了解更多细部的运作机制。 本章的主角是类别载入器。在Java 中，讲到暗中帮助程序设计师，让使用Java 所撰写的程序 具备动态性的『黑手』，非类别载入器莫属。笔者将带大家深入类别加载器的运作机制，让诸位读者 了解类别加载器如何达成动态性。了解动态性之所以能够顺利运行的来龙去脉之后，我们还要看看 如何运用动态性做出一些巧妙且实际的功能。 █为何要自己全盘掌控动态性? 学习Java 的朋友一定都知道，Java 是一种天生就具有动态连结能力的技术。Java 把每个类别 的宣告、接口的宣告，在编译器处理之后，全部变成一个个小的执行单位(类别文件, .class)，一旦 我们指定一个具有public static void main(String args[])方法的类别作为起点开始运作之 后，Java 虚拟机器会找出所有在执行时期需要的执行单位，并将他们加载内存之中，彼此互相交 互运作。尽管本质上是一堆类别文件，但是在内存之中，变成了一个”逻辑上”为一体的Java 应用 程序。所以，严格的来说，每个类别檔对Java 虚拟机器来说，都是一个独立的动态联结函式库，只 不过它的扩展名不是 .dll 或 .so，而是 .class 罢了。 因为这种特性，所以我们可以在不重新编 译其它Java 程序代码的情况下，只修改有问题的执行单位，并放入档案系统之中，等到下次该Java 虚拟机器重新启动时，这个逻辑上的Java 应用程序就会因为加载了新修改的 .class 檔，自己的功 能也做了更新。这是一个最基本的动态性功能。 但是，如果您用过支持JSP/Servlet 的高档Web Server(或称Web Container)，或是高档的 Application Server 里的EJB Container，他们一定会提供一个名为Hot Deployment 的功能，这个 功能的意思是说，您可以在Web Server 不关闭的情况下，放入已经编译好的新servlet 以取代旧的 servlet，下一次的HTTP request 时，就会自动释放旧的servlet 所代表的类别檔，而重新加载新 的servlet 所代表的类别檔，同理，如果主角换成EJB Container，Hot Deployment 可以让组件部 署者不用关闭Application Server，就能够将旧的EJB(也是一堆类别文件的集合)换成新版的EJB。 Hot Deployment 的功能并非每家厂商都