1.   系统类加载器或叫作应用类加载器 (system classloader or application classloader)
2.  当前类加载器
3.  当前线程类加载器

上面的问题指的是最后一种类加载器 . 哪种类加载器是正确的选择呢 ?

第一种选择可以很容易地排除 : 系统类加载器 (system classloader). 这个类加载器处理 -classpath 下的类加载工作 , 可以通过 ClassLoader.getSystemClassLoader() 方法调用 . ClassLoader 下所有的 getSystemXXX() 的静态方法都是通过这个方法定义的 . 在你的代码中 , 你应该尽量少地调用这个方法 , 以其它的类加载器作为代理 . 否则你的代码将只能工作在简单的命令行应用中 , 这个时候系统类加载器 (system classloader) 是 JVM 最后创建的类加载器 . 一但你把代码移到 EJB, Web 应用或 Java Web Start 应用中 , 一定会出问题 .

      所以我们来看第二种选择 : 当前上下文环境下的类加载器 . 根据定义 , 当前类加载器就是你当前方法所属的类的加载器 . 在运行时类之间动态联编 , 及调用 Class.forName,() Class.getResource() 等类似方法时 , 这个类加载器会被隐含地使用 . It is also used by syntactic constructs like X.class class literals.

    线程上下文类型加载器是在Java 2平台上被引入的. 每一个线程都有一个类加载器与之对应(除非这个线程是被本地代码创建的). 这个类加载器是通过Thread.setContextClassLoaser()方法设置的. 如果你不在线程构造后调用这个方法, 这个线程将从它的父线程中继承相应的上下文类加载器. 如果在整个应用中你不做任何特殊设置, 所有的线程将都以系统类加载器(system classloader)作为自己的线程上下文类加载器. 自从Web和J2EE应用服务器使用成熟的类加载器机制来实现诸如JNDI, 线程池, 组件热部署等功能以来, 这种在整个应用中不做任何线程类加载器设置的情况就很少了.

    为什么线程上下文类加载器存在于如此重要的位置呢? 这个概念在J2SE中的引入并不引人注目. 很多开发人员对这一概念迷惑的原因是Sun公司在这方面缺乏适当的指引和文档.

    事实上, 上下文类加载器提供了类加载机制的后门, 这一点也在J2SE中被引入了. 通常, 在JVM中的所有类加载器被组织成了有继承层次的结构, 每一个类加载器(除了引导JVM的原始类加载器)都有一个父加载器. 每当被请示加载类时, 类加载器都会首先请求其父类加载器, 只有当父类加载器不能加载时, 才会自己进行类加载.

   有时候这种类加载的顺序安排不能正常工作, (此 处的意思是:正常情况下都是从子类加载器到根类加载器请求,万一有根类里需要加载子类时,这种顺序就不能满足要求,就要有一条反向的通道,即得到子类加载 器,这样就用到了thread context classloader,因为通过thread.getcontextclassloader()可以得到子类加载器).通常当必须动态加载应用程序开发人员提供的资源的时候. 以JNDI为例: 它的内容(从J2SE1.3开始)就在rt.jar中的引导类中实现了, 但是这些JNDI核心类需要动态加载由独立厂商实现并部署在应用程序的classpath下的JNDI提供者. 这种情况就要求一个父classloader(本例, 就是引导类加载器)去加载对于它其中一个子classloader(本例, 系统类加载器)可见的类. 这时通常的类加载代理机制不能实现这个要求. 解决的办法(workaround)就是, 让JNDI核心类使用当前线程上下文的类加载器, 这样, 就基本的类加载代理机制的相反方向建立了一条有效的途径.

    另外, 上面一段可能让你想起一些其它的事情: XML解析Java API(JAXP). 是的, 当JAXP只是J2SE的扩展进, 它很自然地用当前类加载器来引导解析器的实现. 而当JAXP被加入到J2SE1.4的核心类库中时, 它的类加载也就改成了用当前线程类加载器, 与JNDI的情况完全类似(也使很多程序员很迷惑). 明白为什么我说来自Sun的指导很缺乏了吧?

   在以上的介绍之后, 我们来看关键问题: 这两种选择(当前类加载器和当前线程类加载器)都不是在所有环境下都适用. 有些人认为当前线程类加载器应该成为新的标准策略. 但是, 如果这样, 当多个线程通过共享数据进行交互的时, 将会呈现出一幅极其复杂的类加载的画面, 除非它们全部使用了同一个上下文的类加载器. 进一步说, 在某些遗留下来的解决方案中, 委派到当前类加载器的方法已经是标准. 比如对Class.forName(String)的直接调用(这也是我为什么推荐尽量避免对这个方法进行调用的原因). 即使你努力去只调用上下文相关的类加载器, 仍然会有一些代码会不由你控制. 这种不受控制的类加载委派机制是混入是很危险的.

    更严重的问题, 某些应用服务器把环境上下文及当前类加载器设置到不同的类加载器实例上, 而这些类加载器有相同的类路径但却没有委派机制中的父子关系. 想想这为什么十分可怕. 要知道类加载器定义并加载的类实例会带有一个JVM内部的ID号. 如果当前类加载器加载一个类X的实例, 这个实例调用JNDI查找类Y的实例, 些时的上下文的类加载器也可以定义了加载类Y实例. 这个类Y的定义就与当前类加载器看到的类Y的定义不同. 如果进行强制类型转换, 则产生异常.

   这种混乱的情况还将在Java中存在一段时间. 对于那些需要动态加载资源的J2SE的API, 我们来猜想它们的类加策略. 例如:

Ø         JNDI 使用线程上下文类加载器

Ø         Class.getResource() 和Class.forName()使用当前类加载器

Ø         JAXP(J2SE 1.4 及之后)使用线程上下文类加载器

Ø         java.util.ResourceBundle 使用调用者的当前类加载器

Ø         URL protocol handlers specified via java.protocol.handler.pkgs system property are looked up in the bootstrap and system classloaders only

Ø         Java 序列化API默认使用调用者当前的类加载器

MD5：66c029d7c10bfb1b9ce1c7034d882a21
2004N
原始放出ISO：2004.09   西安交大XXX

md5：62c244a48e70b80c6baa014ca33b68ed
2006N
原始放出2006.10电骡一友：Bxx xxxxx

MD5：e38f4e392a7798aao15fa95c50ff573d
和MD5：57505544DB716B451DB6CC33F1ABC0E3
是同一批盘。

目 录

• 为什么重要
• 学习旅程
  • 视图和图
  • 相关资源
  • 聚合、关联和引用
• 实践建议

为什么重要

您应该使用UML吗？一个字：是！……新的书、文章等等将会全部以UML作为符号。……如果你正要开始使用建模符号，您就应该直接学习UML。

—— Martin Fowler 1997

统一建模语言UML（Unified Modeling Language）是一套用于面向对象系统建模的标准符号，在20世纪90年代几经波折，终于得到对象管理组织OMG（Object Management Group）的支持，成为业界符号系统的统一标准。

因此，了解它是学习后面技术的前提。这并不是夸张，在看懂（并非精通）UML以前，我压根没明白《设计模式》，因为《设》里面就用到象UML那样的语言——OMT。

那UML无疑是重要，但它能很好的胜任建模工作吗？关于这个问题，我没有能力给您一个完美的答复，相关的“讨论”也在继续，但下面的几个事实相信会给您信心。

1。UML吸取多种建模语言的优点，包括三位全球顶级方法学家的贡献。2。它在风雨中崛起，经受考验。3。UML得到OMG组织及其成员的支持。4。相当多的业界巨头们也在使用着它。

学习旅程

UML体系是如此复杂，可能会让您觉得难以把握。但是我们只要有选择性的学习就足够了，剩下的当日后有需要时再深入研究。

在学习之前，我们先来做一个说明，UML仅是一门语言，学习UML不等同于学习系统建模，它们的关系就好比学习中文和学习文章写作那样。只是很多情况下，我们都会把它们联系在一起而已。

---

 

视图和图

 

 

那好，就让我们开始吧，先来浏览一下UML的全貌。由于我们很难只从一个角度去完整描述一个系统的所有方面。因此UML提供了以下五种视图，它们分工合作，又互相补充。

1)    用况视图（Use Case View）2)    设计视图（Design View）或逻辑视图（Logical View）3)    进程视图（Process View）4)    实现视图（Implementation View）或组件视图（Component View）5)    实施视图（Deployment View）

而这五个视图又分别用到以下九种图中的一种或几种。

1)    用况图2)    类图3)    对象图4)    顺序图5)    协作图6)    状态图7)    活动图8)    构件图9)    实施图

---

 

相关资源

 

 

好，看一下相关资源。

1) 《UML用户指南》

此书出自名家，只是部分翻译欠佳。阅读时弄清楚上述五个视图的概念和几种常用的图的表示即可，初次阅读不必深究。

2) 《UML和模式应用》

书中示范如何结合UML以增量方式开发一个系统，着重介绍了OO分析的技巧和法则。内容稍嫌罗嗦，但不失为一本好书。

3) 《UML Distilled》

另一本入门好书，作为普通使用已经足够。

4) 《非程序员》第二期之《用UML设计Java应用程序》

阅读这一短篇文章，可以快速了解如何在实际项目中使用UML。

5) http://www.uml.org/

UML的官方网站，可以找到很多有用资料。

6) http://www.umlchina.com/

它发行《非程序员》电子杂志和记录很多中文文档，还有一个非常活跃的讨论组。

7) http://www.csdn.net/develop/

8) http://www-900.ibm.com/developerworks/cn

这两个网站可以搜索到很多UML的中文文章，只是比较零散，不大适合系统学习。

 

再来看一下UML工具。在这方面我没有很好的经验，且看看别人怎么说。

1) 《非程序员》第一期的“选择一种UML建模工具”介绍了评价UML工具的一系列标准。

2) UML官方网站资源页的“UML Tools”栏（链接）列出了极多的UML工具，可供选择。

---

 

聚合、关联和引用

 

最后，我们讨论一下几个具有“争议”性的概念——聚合（Aggregation）、组合（Composition）、相识（Acquaintance）、关联（Association）、依赖（Dependence）和引用（Reference）。它们极具相似性，在代码的实现上有些甚至是完全一样的，然而从概念上理解和区分它们对我们的系统分析和设计是有重要意义的。

聚合是指一个对象拥有另一个对象，仅强调“拥有”。而组合是指一个对象是另一个对象的一部分，强调“不可分割”，两个对象具有相同的生命周期。两者的差别就好比创立一间公司时您可以不要雇员（拥有），但创造一个人时您却不能丢掉了他的心（不可分割）。

关联和依赖都是指一个对象知道另一个对象。区别在于关联是一种结构关系，表现为一个对象能够获得另一个对象的实例引用并调用它的服务（即使用它）；依赖是一种使用关系，表现为一个对象仅仅是调用了另一个对象的服务。相识既可能是关联，也可能是依赖。

引用是指那些指向对象的类属性。实现组合、聚合和关联时无可避免的要用到引用，但实现依赖时却不一定用到。

总的来说，关联和依赖是同级的；组合是一种聚合，而聚合是一种关联；引用则是相对独立的。

与此相关的文章有：

1) 《UML用户指南》第10章，Booch+详细讲述了依赖和关联的含义和区别。

2) 《设计模式》中文版第15~16页，Gof讲述了聚合和相识的差别。

3) 《非程序员》第二期之《类之间设置成“关联”OR“依赖”似乎全在个人喜好》是几位朋友就聚合、关联和依赖的区别进行的很好的讨论。

至此，如果您对它们的定义持不同意见，又或者觉得难以理解的话，不妨把别人的那一套都抛开，自己把它们重定义一遍。反正我们又不是理论家，就算定义得不科学也没关系，只要和我们的项目有关的人员都一致的理解和接受就可以了。毕竟有效的沟通才是我们真正的目的。

实践建议

按需剪裁。项目要用到什么就学习什么，暂时不用的就放下。我们的目的是当前的系统建模，而不是一下子成为UML高手。

自由扩展。结合我们的实际情况，在使用的过程中，要明确UML的重点是“沟通”，其次才是“公共”。UML本身有许多规则和约定，但没必要一一遵守。只要有利于沟通的，我们就采用，否则就摒弃。通常我们的文档只是在小范围里传播，要统一理解并不困难。当然，当规则定好了后，最好就不要随意更改了。