线程局部变量（thread-local variable)
ThreadLocal类是悄悄地出现在 java 平台版本 1.2 中的。虽然支持线程局部变量早就是许多线程工具（例如 Posixpthreads工具）的一部分，但 java Threads API 的最初设计却没有这项有用的功能。而且，最初的实现也相当低效。由于这些原因，ThreadLocal极少受到关注，但对简化线程安全并发程序的开发来说，它却是很方便的。在 轻松使用线程的第 3 部分，Java 软件顾问 Brian Goetz 研究了ThreadLocal并提供了一些使用技巧。参加 Brian 的 多线程 Java 编程讨论论坛以获得您工程中的线程和并发问题的帮助。
编写线程安全类是困难的。它不但要求仔细分析在什么条件可以对变量进行读写，而且要求仔细分析其它类能如何使用某个类。 有时，要在不影响类的功能、易用性或性能的情况下使类成为线程安全的是很困难的。有些类保留从一个方法调用到下一个方法调用的状态信息，要在实践中使这样的类成为线程安全的是困难的。
管理非线程安全类的使用比试图使类成为线程安全的要更容易些。非线程安全类通常可以安全地在多线程程序中使用，只要您能确保一个线程所用的类的实例不被其它线程使用。例如，JDBC Connection 类是非线程安全的 — 两个线程不能在小粒度级上安全地共享一个 Connection — 但如果每个线程都有它自己的 Connection ，那么多个线程就可以同时安全地进行数据库操作。
不使用 ThreadLocal 为每个线程维护一个单独的 JDBC 连接（或任何其它对象）当然是可能的；Thread API 给了我们把对象和线程联系起来所需的所有工具。而 ThreadLocal 则使我们能更容易地把线程和它的每线程（per-thread）数据成功地联系起来。
什么是线程局部变量（thread-local variable）？
线程局部变量高效地为每个使用它的线程提供单独的线程局部变量值的副本。每个线程只能看到与自己相联系的值，而不知道别的线程可能正在使用或修改它们自己的副本。一些编译器（例如 Microsoft Visual C++ 编译器或 IBM XL FORTRAN 编译器）用存储类别修饰符（像 static 或 volatile ）把对线程局部变量的支持集成到了其语言中。Java 编译器对线程局部变量不提供特别的语言支持；相反地，它用 ThreadLocal 类实现这些支持， 核心 Thread 类中有这个类的特别支持。
因为线程局部变量是通过一个类来实现的，而不是作为 java 语言本身的一部分，所以 java 语言线程局部变量的使用语法比内建线程局部变量语言的使用语法要笨拙一些。要创建一个线程局部变量，请实例化类 ThreadLocal 的一个对象。 ThreadLocal 类的行为与 java.lang.ref 中的各种 Reference 类的行为很相似； ThreadLocal 类充当存储或检索一个值时的间接句柄。清单 1 显示了 ThreadLocal 接口。
清单 1. ThreadLocal 接口
|
get() 访问器检索变量的当前线程的值； set() 访问器修改当前线程的值。 initialValue() 方法是可选的，如果线程未使用过某个变量，那么您可以用这个方法来设置这个变量的初始值；它允许延迟初始化。用一个示例实现来说明 ThreadLocal 的工作方式是最好的方法。清单 2 显示了 ThreadLocal 的一个实现方式。它不是一个特别好的实现（虽然它与最初实现非常相似），所以很可能性能不佳，但它清楚地说明了 ThreadLocal 的工作方式。
清单 2. ThreadLocal 的糟糕实现
|
这个实现的性能不会很好，因为每个 get() 和 set() 操作都需要 values 映射表上的同步，而且如果多个线程同时访问同一个 ThreadLocal ，那么将发生争用。此外，这个实现也是不切实际的，因为用 Thread 对象做 values 映射表中的关键字将导致无法在线程退出后对 Thread 进行垃圾回收，而且也无法对死线程的 ThreadLocal 的特定于线程的值进行垃圾回收。
  |
|
用 ThreadLocal 实现每线程 Singleton
线程局部变量常被用来描绘有状态“单子”（Singleton） 或线程安全的共享对象，或者是通过把不安全的整个变量封装进 ThreadLocal ，或者是通过把对象的特定于线程的状态封装进 ThreadLocal 。例如，在与数据库有紧密联系的应用程序中，程序的很多方法可能都需要访问数据库。在系统的每个方法中都包含一个 Connection 作为参数是不方便的 — 用“单子”来访问连接可能是一个虽然更粗糙，但却方便得多的技术。然而，多个线程不能安全地共享一个 JDBC Connection 。如清单 3 所示，通过使用“单子”中的 ThreadLocal ，我们就能让我们的程序中的任何类容易地获取每线程 Connection 的一个引用。这样，我们可以认为 ThreadLocal 允许我们创建 每线程单子。
清单 3. 把一个 JDBC 连接存储到一个每线程 Singleton 中
|
任何创建的花费比使用的花费相对昂贵些的有状态或非线程安全的对象，例如 JDBC Connection 或正则表达式匹配器，都是可以使用每线程单子（singleton）技术的好地方。当然，在类似这样的地方，您可以使用其它技术，例如用池，来安全地管理共享访问。然而，从可伸缩性角度看，即使是用池也存在一些潜在缺陷。因为池实现必须使用同步，以维护池数据结构的完整性，如果所有线程使用同一个池，那么在有很多线程频繁地对池进行访问的系统中，程序性能将因争用而降低。
|
|
用 ThreadLocal 简化调试日志纪录
其它适合使用 ThreadLocal 但用池却不能成为很好的替代技术的应用程序包括存储或累积每线程上下文信息以备稍后检索之用这样的应用程序。例如，假设您想创建一个用于管理多线程应用程序调试信息的工具。您可以用如清单 4 所示的 DebugLogger 类作为线程局部容器来累积调试信息。在一个工作单元的开头，您清空容器，而当一个错误出现时，您查询该容器以检索这个工作单元迄今为止生成的所有调试信息。
清单 4. 用 ThreadLocal 管理每线程调试日志
|
在您的代码中，您可以调用 DebugLogger.put() 来保存您的程序正在做什么的信息，而且，稍后如果有必要（例如发生了一个错误），您能够容易地检索与某个特定线程相关的调试信息。 与简单地把所有信息转储到一个日志文件，然后努力找出哪个日志记录来自哪个线程（还要担心线程争用日志纪录对象）相比，这种技术简便得多，也有效得多。
ThreadLocal 在基于 servlet 的应用程序或工作单元是一个整体请求的任何多线程应用程序服务器中也是很有用的，因为在处理请求的整个过程中将要用到单个线程。您可以通过前面讲述的每线程单子技术用 ThreadLocal 变量来存储各种每请求（per-request）上下文信息。
|
|
ThreadLocal 的线程安全性稍差的堂兄弟，InheritableThreadLocal
ThreadLocal 类有一个亲戚，InheritableThreadLocal，它以相似的方式工作，但适用于种类完全不同的应用程序。创建一个线程时如果保存了所有 InheritableThreadLocal 对象的值，那么这些值也将自动传递给子线程。如果一个子线程调用 InheritableThreadLocal 的 get() ，那么它将与它的父线程看到同一个对象。为保护线程安全性，您应该只对不可变对象（一旦创建，其状态就永远不会被改变的对象）使用 InheritableThreadLocal ，因为对象被多个线程共享。 InheritableThreadLocal 很合适用于把数据从父线程传到子线程，例如用户标识（user id）或事务标识（transaction id），但不能是有状态对象，例如 JDBC Connection 。
|
|
ThreadLocal 的性能
虽然线程局部变量早已赫赫有名并被包括 Posix pthreads 规范在内的很多线程框架支持，但最初的 java 线程设计中却省略了它，只是在 java 平台的版本 1.2 中才添加上去。在很多方面， ThreadLocal 仍在发展之中；在版本 1.3 中它被重写，版本 1.4 中又重写了一次，两次都专门是为了性能问题。
在 JDK 1.2 中， ThreadLocal 的实现方式与清单 2 中的方式非常相似，除了用同步 WeakHashMap 代替 HashMap 来存储 values 之外。（以一些额外的性能开销为代价，使用 WeakHashMap 解决了无法对 Thread 对象进行垃圾回收的问题。）不用说， ThreadLocal 的性能是相当差的。
java 平台版本 1.3 提供的 ThreadLocal 版本已经尽量更好了；它不使用任何同步，从而不存在可伸缩性问题，而且它也不使用弱引用。相反地，人们通过给 Thread 添加一个实例变量（该变量用于保存当前线程的从线程局部变量到它的值的映射的 HashMap ）来修改 Thread 类以支持 ThreadLocal 。因为检索或设置一个线程局部变量的过程不涉及对可能被另一个线程读写的数据的读写操作，所以您可以不用任何同步就实现 ThreadLocal.get() 和 set() 。而且，因为每线程值的引用被存储在自已的 Thread 对象中，所以当对 Thread 进行垃圾回收时，也能对该 Thread 的每线程值进行垃圾回收。
不幸的是，即使有了这些改进，Java 1.3 中的 ThreadLocal 的性能仍然出奇地慢。据我的粗略测量，在双处理器 Linux 系统上的 Sun 1.3 JDK 中进行 ThreadLocal.get() 操作，所耗费的时间大约是无争用同步的两倍。性能这么差的原因是 Thread.currentThread() 方法的花费非常大，占了 ThreadLocal.get() 运行时间的三分之二还多。虽然有这些缺点，JDK 1.3 ThreadLocal.get() 仍然比争用同步快得多，所以如果在任何存在严重争用的地方（可能是有非常多的线程，或者同步块被频繁地执行，或者同步块很大）， ThreadLocal 可能仍然要高效得多。
在 java 平台的最新版本，即版本 1.4b2 中， ThreadLocal 和 Thread.currentThread() 的性能都有了很大提高。有了这些提高， ThreadLocal 应该比其它技术，如用池，更快。由于它比其它技术更简单，也更不易出错，人们最终将发现它是避免线程间出现不希望的交互的有效途径。
|
|
ThreadLocal 的好处
ThreadLocal 能带来很多好处。它常常是把有状态类描绘成线程安全的，或者封装非线程安全类以使它们能够在多线程环境中安全地使用的最容易的方式。使用 ThreadLocal 使我们可以绕过为实现线程安全而对何时需要同步进行判断的复杂过程，而且因为它不需要任何同步，所以也改善了可伸缩性。除简单之外，用 ThreadLocal 存储每线程单子或每线程上下文信息在归档方面还有一个颇有价值好处 — 通过使用 ThreadLocal ，存储在 ThreadLocal 中的对象都是 不被线程共享的是清晰的，从而简化了判断一个类是否线程安全的工作。
我希望您从这个系列中得到了乐趣，也学到了知识，我也鼓励您到我的 讨论论坛中来深入研究多线程问题。
Servlet是在多线程环境下的。即可能有多个请求发给一个servelt实例，每个请求是一个线程。
struts下的action也类似，同样在多线程环境下。可以参考struts user guide: http://struts.apache.org/struts-action/userGuide/building_controller.html 中的Action Class Design Guidelines一节: Write code for a multi-threaded environment - Our controller servlet creates only one instance of your Action class, and uses this one instance to service all requests. Thus, you need to write thread-safe Action classes. Follow the same guidelines you would use to write thread-safe Servlets.
译:为多线程环境编写代码。我们的controller servlet指挥创建你的Action 类的一个实例，用此实例来服务所有的请求。因此，你必须编写线程安全的Action类。遵循与写线程安全的servlet同样的方针。
1.什么是线程安全的代码
在多线程环境下能正确执行的代码就是线程安全的。
安全的意思是能正确执行，否则后果是程序执行错误，可能出现各种异常情况。
2.如何编写线程安全的代码
很多书籍里都详细讲解了如何这方面的问题，他们主要讲解的是如何同步线程对共享资源的使用的问题。主要是对synchronized关键字的各种用法，以及锁的概念。
Java1.5中也提供了如读写锁这类的工具类。这些都需要较高的技巧，而且相对难于调试。
但是，线程同步是不得以的方法,是比较复杂的,而且会带来性能的损失。等效的代码中，不需要同步在编写容易度和性能上会更好些。
我这里强调的是什么代码是始终为线程安全的、是不需要同步的。如下:
1)常量始终是线程安全的，因为只存在读操作。
2)对构造器的访问(new 操作)是线程安全的，因为每次都新建一个实例，不会访问共享的资源。
3)最重要的是:局部变量是线程安全的。因为每执行一个方法，都会在独立的空间创建局部变量，它不是共享的资源。局部变量包括方法的参数变量。
struts user guide里有：
Only Use Local Variables - The most important principle that aids in thread-safe coding is to use only local variables, not instance variables , in your Action class.
译:只使用用局部变量。--编写线程安全的代码最重要的原则就是，在Action类中只使用局部变量，不使用实例变量。
总结：
在Java的Web服务器环境下开发，要注意线程安全的问题。最简单的实现方式就是在Servlet和Struts Action里不要使用类变量、实例变量，但可以使用类常量和实例常量。
如果有这些变量，可以将它们转换为方法的参数传入，以消除它们。
注意一个容易混淆的地方：被Servlet或Action调用的类中(如值对象、领域模型类)中是否可以安全的使用实例变量？如果你在每次方法调用时
新建一个对象，再调用它们的方法，则不存在同步问题---因为它们不是多个线程共享的资源，只有共享的资源才需要同步---而Servlet和Action的实例对于多个线程是共享的。
换句话说，Servlet和Action的实例会被多个线程同时调用，而过了这一层,如果在你自己的代码中没有另外启动线程，且每次调用后续业务对象时都是先新建一个实例再调用，则都是线程安全的。
2007年4月6日
|
+--javax.servlet.GenericServlet
|
+--javax.servlet.http.HttpServlet
|
+--org.apache.struts.action.ActionServlet
Struts提供了一个缺省版本的ActionServlet类，你可以继承这个类，覆盖其中的一些方法来达到你的特殊处理的需要。ActionServlet继承与javax.servlet.http.HttpServlet，所以在本质上它和一个普通的servlet没有区别，你完全可以把它当做一个servlet来看待，只是在其中完成的功能不同罢了。ActionServlet主要完成如下功能：
将一个来自客户端的URI映射到一个相应的Action类
- 如果是这个Action类是第一次被调用，那么实例化一个并放入缓存
- 如果在配置文件(struts-config.xml)中指定了相应的ActionForm，那么从Request中抓取数据填充FormBean
- 调用这个Action类的perform()方法，传入ActionMapping的一个引用，对应的ActionForm、以及由容器传给ActionServlet的HttpServletRequest、HttpServletResponse对象。
确省版本的ActionServlet会从配置文件web.xml中读取如下初始化参数：
- application
应用使用的资源包(resources bundle)的基类 - factory
用于创建应用的MessageResources对象的MessageResourcesFactory的类名。确省是org.apache.struts.util.PropertyMessageResourcesFactory。 - config
Struts的配置文件，确省是/WEB-INF/struts-config.xml。注意这儿是与应用Context关联的相对路径。 - content
定义了确省的内容类型和编码格式，它会被自动地被设置到每个response中，如果JSP/Servlet中没有明确的设置。确省是text/html。 - debug
调试信息的级别。默认为0，比当前级别高的调试信息会被log到日志文件中。 - detail
与debug的作用类似，只是这个detail是initMapping()时专用的。调试信息会被打印到System.out，而不是日志文件。 - formBean
ActionFormBean的实现类，确省为org.apache.struts.action.ActionFormBean - forward
应用中使用的ActionForward类，确省是org.apache.struts.action.ActionForward。 - locale
指定了确省使用的Locale对象。设为true，当得到一个session时，会自动在session中存储一个以Action.LOCALE_KEY标示的Locale对象，如果session中还没有与Action.LOCALE_KEY绑定的Locale对象。 - mapping
应用中使用的ActionMapping类，确省是org.apache.struts.action.ActionMapping。 - multipartClass
文件上传使用的MutipartRequestHandler的实现类。确省为org.apache.struts.upload.DiskMultipartRequestHandler - nocache
如果设为true，那么ActionServlet会自动在每个到客户端的响应中添加nocache的HTML头，这样客户端就不会对应用中的页面进行缓存。确省为false - null
如果设置为true，那么应用在得到一个未定义的message资源时，会返回null，而不是返回一个错误信息。确省是true。 - maxFileSize
文件上传的大小上限，确省为250M - bufferSize
文件上传时的缓冲区的大小，确省为4M - tempDir
设置用于上传时的临时目录。工作目录会作为一个Servlet环境（Context）的属性提供。 - validate
Are we using the new configuration file format?确省为true。 - validating
在解析配置XML文件是是否进行有效性的验证。确省为true
ActionServlet中应用了命令设计模式。
一个Servlet在由容器生成时，首先会调用init()方法进行初始化，在接到一个HTTP请求时，调用相应的方法进行处理；比如GET请求调用doGet()方法，POST请求调用doPost()方法。所以首先看看ActionServlet的init()方法，你就会很清楚为什么ActionServlet可以完成这些功能了。
init()
在它的init()方法中，ActionServlet依次调用如下protected的方法完成初始化：
- initActions() － 大家可能还曾有这个疑问：Struts为什么可以找到一个请求URI对应的action类呢？答案就在这儿，ActionServlet有一个actions属性，类型为org.apache.struts.util.FastHashMap，用于存储以类的全名为key的已实例化的Action类。在init()时首先调用的就是initActions()方法，在这个方法中只是简单的清除map中的所有的名值对，
- synchronized (actions) {
- actions.setFast(false);
- actions.clear();
- actions.setFast(true);
- }
首先把actions设为slow模式，这时对FastHashMap的访问是线程同步的，然后清除actions中的所有的已存在的名/值对，最后再把actions的模式设为fast。由于FastHashMap是struts在java.util.HashMap的基础上的一个扩展类，是为了适应多线程、并且对HashMap的访问大部分是只读的特殊环境的需要。大家知道java.util.HashMap是非线程安全的，所以HashMap一般适用于单线程环境下。org.apache.struts.FastHashMap就是继承于java.util.HashMap，在其中添加多线程的支持产生的。在fast模式下的工作方式是这样的：读取是非线程同步的；写入时首先克隆当前map，然后在这个克隆上做写入操做，完成后用这个修改后的克隆版本替换原来的map。那么在什么时候会把Actions类添加到这个map中呢？我们已经提到了struts是动态的生成Action类的实例的，在每次ActionServlet接收到一个GET或POST的HTTP请求时，会在这个map中查找对应的Action类的实例，如果不存在，那么就实例化一个，并放入map中。可见这个actions属性起到了对Action类实例的缓存的作用。 - initInternal() － 初始化ActionServlet内部使用的资源包MessageResources，使用MessageResources.getMessageResources(internalName)得到 internalName为"org.apache.struts.action.ActionResources"对应的ActionResources.properties文件。这个资源包主要用于ActionServlet处理过程中的用到的提示信息，这儿不展开讨论。
- initDebug() － 从web.xml中读取本应用的debug级别参数getServletConfig().getInitParameter("debug")，然后赋给debug属性。
- initApplication()－ 初始化应用资源包，并放置入ServletContext中。
- String factory =getServletConfig().getInitParameter(“factory”);
- String oldFacory = MessageResourcesFactory.getFactoryClass();
- if (factory !=null)
- MessageResourcesFactory.setFactoryClass(factory);
- String value = getServletConfig().getInitParameter("application");
- MessageResourcesFactory factoryObject =
- MessageResourcesFactory.createFactory();
- application = factoryObject.createResources(value);
- MessageResourcesFactory.setFactory(oldFactory);
- getServletContext().setAttribute(Action.MESSAGES_KEY, application);
说明：文中引用的代码片断可能会省略了一些例外检查等非主线的内容，敬请注意。
首先从配置文件中读取factory参数，如果这个参数不为空，那么就在MessageResourcesFactory中使用这个指定的Factory类；否则，使用默认的工厂类org.apche.struts.util.PropertyMessageResourceFactory。然后调用MessageResourcesFactory的静态createFactory()方法，生成一个具体的MessageResourceFactory对象（注意：MessageResourcesFactory是抽象类）。这样就可以调用这个具体的MessageResourceFactory的createResource()方法得到配置文件(web.xml)中定义的资源文件了。
上面的application对象类型为MessageResources。在web.xml中在配置ActionServlet时可以指定一个特定的工厂类。不能直接MessageResourcesFactory的createResources()方法，因为这个方法是abstract的。创建factoryObject的过程如下：
- MessageResourceFactory factoryObject=
- MessageResourcesFactory.createFactory();
- application = factoryObject.createResources(value);
- initMapping() － 为应用初始化mapping信息ActionServlet有一个protected的属性：mapping，封装了一个ActionMapping的对象集合，以便于管理、查找ActionMapping。mappings是org.apache.struts.action.ActionMappings类的实例。主要有两个方法：addMapping(ActionMapping mapping)和findMapping(String path)。ActionMapping也是使用上面提到的org.apache.struts.util.FastHashMap类来存储所有的ActionMapping对象。
- mappings.setServlet(this);
- ……
- // Initialize the name of our ActionFormBean implementation class
- value = getServletConfig().getInitParameter("formBean");
- if (value != null)
- formBeanClass = value;
- // Initialize the name of our ActionForward implementation class
- value = getServletConfig().getInitParameter("forward");
- if (value != null)
- forwardClass = value;
- // Initialize the name of our ActionMapping implementation class
- value = getServletConfig().getInitParameter("mapping");
- if (value != null)
- mappingClass = value;
在initMapping()中，首先链接mappings对象到本servlet实例。其实这句话的作用很简单，在ActionMappings中会有一个ActionServlet类型的属性，这个属性就界定了这个ActionMappings对象所属的ActionServlet。Struts的实现比较灵活，其中的ActionFormBean、ActionForward、ActionMapping类你完全可以使用自己实现的子类，来定制Struts的工作方式。上面的代码就从配置文件（web.xml）中读取formBean、forward、mapping参数，这些参数就是你定制的ActionFormBean、ActionForward、ActionMapping类名。
- // Initialize the context-relative path to our configuration resources
- value = getServletConfig().getInitParameter("config");
- if (value != null)
- config = value;
- // Acquire an input stream to our configuration resource
- InputStream input = getServletContext().getResourceAsStream(config);
- Digester digester = null;
- digester = initDigester(detail);
- try {
- formBeans.setFast(false);
- forwards.setFast(false);
- mappings.setFast(false);
- digester.parse(input);
- mappings.setFast(true);
- forwards.setFast(true);
- formBeans.setFast(true);
- } catch (SAXException e) {
- throw new ServletException
- (internal.getMessage("configParse", config), e);
- } finally {
- input.close();
- }
从web.xml读取Struts的配置文件的位置。使用org.apache.struts.digester.Digester解析config参数标示的配置文件，通常为“/WEB-INF/struts-config.xml”，解析出所有的data-source、form-bean、action-mapping、forward。从上面的程序片断看到，Digester仅仅调用了一个parse()方法，那么，Digester是怎样把解析struts-config.xml文件并把解析的结果form-bean等信息存储到属性变量formBeans等中的呢？你可以注意到在调用digester.parse(InputStream)之前，首先调用了initDigester()方法：
- Digester digester = new Digester();
- digester.push(this);
- digester.addObjectCreate("struts-config/action-mappings/action",
- mappingClass, "className");
- digester.addSetProperties("struts-config/action-mappings/action");
- digester.addSetNext("struts-config/action-mappings/action",
- "addMapping",
- "org.apache.struts.action.ActionMapping");
- digester.addSetProperty
- ("struts-config/action-mappings/action/set-property",
- "property", "value");
在这个方法中首先生成一个Digester对象，然后设置解析的规则和回调，如果你对XML、SAX不是很熟，这儿不必纠缠太深。要注意的是addSetNext()方法，设置了每一个要解析元素的Set Next回调方法，而这个方法就是由digester解析器的父提供的。上面的片断中的“addMapping”就是ActionServlet本身定义的一个方法，将由Digester回调。Digester就是籍此把解析出的每一个FormBean、ActionForward、ActionMapping等存储到属性变量formBeans、forwards、mappings等中的。 - initUpload() － 初始化有关Upload的一些参数，比如：bufferSize、tempDir。
- initDataSource() －取出在initMapping()中从配置文件中读取的每一个DataSource，设置LogWriter，如果为GenericDataSource的实例，则打开数据源。然后，把每个dataSource放入Context中。
dataSource.setLogWriter(scw)；
((GenericDataSource)dataSource).open();
getServletContext().setAttribute(key,dataSource); - initOther() － 设置其它尚未初始化的的参数（content、locale、nocache），并发布formBeans、forwards、mappings到Context：
getServletContext().setAttribute(Action.FORM_BEANS_KEY, formBeans);
getServletContext().setAttribute(Action.FORWARDS_KEY, forwards);
getServletContext().setAttribute(Action.MAPPINGS_KEY, mappings); - initServlet() － 初始化Controller Servlet的Servlet Mapping。这儿也使用了Digester工具，扫描web.xml所有的
，寻找servlet-name与当前Servlet相同的mapping，置入Context。代码如下；
- Digester digester = new Digester();
- digester.push(this);
- digester.setDebug(debug);
- digester.setValidating(validating);
- digester.addCallMethod(“web-appservlet-mapping”,“addServletMapping”, 2);
- digester.addCallParm(“web-appservlet-mappingservlet-name”, 0);
- digester.addCallParm(“web-appservlet-mappingurl-pattern”, 1);
- InputStream is = getServletContext().getResourceAsStream(“/WEB-INFweb.xml”);
- digester.parse(is);
- getServletContext().setAttribute(Action.SERVLET_KEY,servletMapping);
2006年10月15日
Java虚拟机的深入研究
作者：刘学超
1 Java技术与Java虚拟机
说起Java，人们首先想到的是Java编程语言，然而事实上，Java是一种技术，它由四方面组成: Java编程语言、Java类文件格式、Java虚拟机和Java应用程序接口(Java API)。它们的关系如下图所示：
图1 Java四个方面的关系
运行期环境代表着Java平台，开发人员编写Java代码(.java文件)，然后将之编译成字节码(.class文件)。最后字节码被装入内存，一旦字节码进入虚拟机，它就会被解释器解释执行，或者是被即时代码发生器有选择的转换成机器码执行。从上图也可以看出Java平台由Java虚拟机和Java应用程序接口搭建，Java语言则是进入这个平台的通道，用Java语言编写并编译的程序可以运行在这个平台上。这个平台的结构如下图所示：
在Java平台的结构中, 可以看出，Java虚拟机(JVM) 处在核心的位置，是程序与底层操作系统和硬件无关的关键。它的下方是移植接口，移植接口由两部分组成：适配器和Java操作系统, 其中依赖于平台的部分称为适配器；JVM 通过移植接口在具体的平台和操作系统上实现；在JVM 的上方是Java的基本类库和扩展类库以及它们的API， 利用Java API编写的应用程序(application) 和小程序(Java applet) 可以在任何Java平台上运行而无需考虑底层平台, 就是因为有Java虚拟机(JVM)实现了程序与操作系统的分离，从而实现了Java 的平台无关性。
那么到底什么是Java虚拟机(JVM)呢？通常我们谈论JVM时，我们的意思可能是：
- 对JVM规范的的比较抽象的说明；
- 对JVM的具体实现；
- 在程序运行期间所生成的一个JVM实例。
对JVM规范的的抽象说明是一些概念的集合，它们已经在书《The java Virtual Machine Specification》（《Java虚拟机规范》）中被详细地描述了；对JVM的具体实现要么是软件，要么是软件和硬件的组合，它已经被许多生产厂商所实现，并存在于多种平台之上；运行Java程序的任务由JVM的运行期实例单个承担。在本文中我们所讨论的Java虚拟机(JVM)主要针对第三种情况而言。它可以被看成一个想象中的机器，在实际的计算机上通过软件模拟来实现，有自己想象中的硬件，如处理器、堆栈、寄存器等，还有自己相应的指令系统。
JVM在它的生存周期中有一个明确的任务，那就是运行Java程序，因此当Java程序启动的时候，就产生JVM的一个实例；当程序运行结束的时候，该实例也跟着消失了。下面我们从JVM的体系结构和它的运行过程这两个方面来对它进行比较深入的研究。
2 Java虚拟机的体系结构
刚才已经提到，JVM可以由不同的厂商来实现。由于厂商的不同必然导致JVM在实现上的一些不同，然而JVM还是可以实现跨平台的特性，这就要归功于设计JVM时的体系结构了。
我们知道，一个JVM实例的行为不光是它自己的事，还涉及到它的子系统、存储区域、数据类型和指令这些部分，它们描述了JVM的一个抽象的内部体系结构，其目的不光规定实现JVM时它内部的体系结构，更重要的是提供了一种方式，用于严格定义实现时的外部行为。每个JVM都有两种机制，一个是装载具有合适名称的类(类或是接口)，叫做类装载子系统；另外的一个负责执行包含在已装载的类或接口中的指令，叫做运行引擎。每个JVM又包括方法区、堆、Java栈、程序计数器和本地方法栈这五个部分，这几个部分和类装载机制与运行引擎机制一起组成的体系结构图为：
图3 JVM的体系结构
JVM的每个实例都有一个它自己的方法域和一个堆，运行于JVM内的所有的线程都共享这些区域；当虚拟机装载类文件的时候，它解析其中的二进制数据所包含的类信息，并把它们放到方法域中；当程序运行的时候，JVM把程序初始化的所有对象置于堆上；而每个线程创建的时候，都会拥有自己的程序计数器和Java栈，其中程序计数器中的值指向下一条即将被执行的指令，线程的Java栈则存储为该线程调用Java方法的状态；本地方法调用的状态被存储在本地方法栈，该方法栈依赖于具体的实现。
下面分别对这几个部分进行说明。
执行引擎处于JVM的核心位置，在Java虚拟机规范中，它的行为是由指令集所决定的。尽管对于每条指令，规范很详细地说明了当JVM执行字节码遇到指令时，它的实现应该做什么，但对于怎么做却言之甚少。Java虚拟机支持大约248个字节码。每个字节码执行一种基本的CPU运算,例如,把一个整数加到寄存器,子程序转移等。Java指令集相当于Java程序的汇编语言。
Java指令集中的指令包含一个单字节的操作符,用于指定要执行的操作,还有0个或多个操作数,提供操作所需的参数或数据。许多指令没有操作数,仅由一个单字节的操作符构成。
虚拟机的内层循环的执行过程如下:
do{
取一个操作符字节;
根据操作符的值执行一个动作;
}while(程序未结束)
由于指令系统的简单性,使得虚拟机执行的过程十分简单,从而有利于提高执行的效率。指令中操作数的数量和大小是由操作符决定的。如果操作数比一个字节大,那么它存储的顺序是高位字节优先。例如,一个16位的参数存放时占用两个字节,其值为:
第一个字节*256+第二个字节字节码。
指令流一般只是字节对齐的。指令tableswitch和lookup是例外,在这两条指令内部要求强制的4字节边界对齐。
对于本地方法接口，实现JVM并不要求一定要有它的支持，甚至可以完全没有。Sun公司实现Java本地接口(JNI)是出于可移植性的考虑，当然我们也可以设计出其它的本地接口来代替Sun公司的JNI。但是这些设计与实现是比较复杂的事情，需要确保垃圾回收器不会将那些正在被本地方法调用的对象释放掉。
Java的堆是一个运行时数据区,类的实例(对象)从中分配空间，它的管理是由垃圾回收来负责的:不给程序员显式释放对象的能力。Java不规定具体使用的垃圾回收算法,可以根据系统的需求使用各种各样的算法。
Java方法区与传统语言中的编译后代码或是Unix进程中的正文段类似。它保存方法代码(编译后的java代码)和符号表。在当前的Java实现中,方法代码不包括在垃圾回收堆中,但计划在将来的版本中实现。每个类文件包含了一个Java类或一个Java界面的编译后的代码。可以说类文件是Java语言的执行代码文件。为了保证类文件的平台无关性,Java虚拟机规范中对类文件的格式也作了详细的说明。其具体细节请参考Sun公司的Java虚拟机规范。
Java虚拟机的寄存器用于保存机器的运行状态,与微处理器中的某些专用寄存器类似。Java虚拟机的寄存器有四种:
- pc: Java程序计数器；
- optop: 指向操作数栈顶端的指针；
- frame: 指向当前执行方法的执行环境的指针；。
- vars: 指向当前执行方法的局部变量区第一个变量的指针。
在上述体系结构图中，我们所说的是第一种，即程序计数器，每个线程一旦被创建就拥有了自己的程序计数器。当线程执行Java方法的时候，它包含该线程正在被执行的指令的地址。但是若线程执行的是一个本地的方法，那么程序计数器的值就不会被定义。
Java虚拟机的栈有三个区域:局部变量区、运行环境区、操作数区。
局部变量区
每个Java方法使用一个固定大小的局部变量集。它们按照与vars寄存器的字偏移量来寻址。局部变量都是32位的。长整数和双精度浮点数占据了两个局部变量的空间,却按照第一个局部变量的索引来寻址。(例如,一个具有索引n的局部变量,如果是一个双精度浮点数,那么它实际占据了索引n和n+1所代表的存储空间)虚拟机规范并不要求在局部变量中的64位的值是64位对齐的。虚拟机提供了把局部变量中的值装载到操作数栈的指令,也提供了把操作数栈中的值写入局部变量的指令。
运行环境区
在运行环境中包含的信息用于动态链接,正常的方法返回以及异常捕捉。
动态链接
运行环境包括对指向当前类和当前方法的解释器符号表的指针,用于支持方法代码的动态链接。方法的class文件代码在引用要调用的方法和要访问的变量时使用符号。动态链接把符号形式的方法调用翻译成实际方法调用,装载必要的类以解释还没有定义的符号,并把变量访问翻译成与这些变量运行时的存储结构相应的偏移地址。动态链接方法和变量使得方法中使用的其它类的变化不会影响到本程序的代码。
正常的方法返回
如果当前方法正常地结束了,在执行了一条具有正确类型的返回指令时,调用的方法会得到一个返回值。执行环境在正常返回的情况下用于恢复调用者的寄存器,并把调用者的程序计数器增加一个恰当的数值,以跳过已执行过的方法调用指令,然后在调用者的执行环境中继续执行下去。
异常捕捉
异常情况在Java中被称作Error(错误)或Exception(异常),是Throwable类的子类,在程序中的原因是:①动态链接错,如无法找到所需的class文件。②运行时错,如对一个空指针的引用。程序使用了throw语句。
当异常发生时,Java虚拟机采取如下措施:
- 检查与当前方法相联系的catch子句表。每个catch子句包含其有效指令范围,能够处理的异常类型,以及处理异常的代码块地址。
- 与异常相匹配的catch子句应该符合下面的条件:造成异常的指令在其指令范围之内,发生的异常类型是其能处理的异常类型的子类型。如果找到了匹配的catch子句,那么系统转移到指定的异常处理块处执行;如果没有找到异常处理块,重复寻找匹配的catch子句的过程,直到当前方法的所有嵌套的catch子句都被检查过。
- 由于虚拟机从第一个匹配的catch子句处继续执行,所以catch子句表中的顺序是很重要的。因为Java代码是结构化的,因此总可以把某个方法的所有的异常处理器都按序排列到一个表中,对任意可能的程序计数器的值,都可以用线性的顺序找到合适的异常处理块,以处理在该程序计数器值下发生的异常情况。
- 如果找不到匹配的catch子句,那么当前方法得到一个"未截获异常"的结果并返回到当前方法的调用者,好像异常刚刚在其调用者中发生一样。如果在调用者中仍然没有找到相应的异常处理块,那么这种错误将被传播下去。如果错误被传播到最顶层,那么系统将调用一个缺省的异常处理块。
操作数栈区
机器指令只从操作数栈中取操作数,对它们进行操作,并把结果返回到栈中。选择栈结构的原因是:在只有少量寄存器或非通用寄存器的机器(如Intel486)上,也能够高效地模拟虚拟机的行为。操作数栈是32位的。它用于给方法传递参数,并从方法接收结果,也用于支持操作的参数,并保存操作的结果。例如,iadd指令将两个整数相加。相加的两个整数应该是操作数栈顶的两个字。这两个字是由先前的指令压进堆栈的。这两个整数将从堆栈弹出、相加,并把结果压回到操作数栈中。
每个原始数据类型都有专门的指令对它们进行必须的操作。每个操作数在栈中需要一个存储位置,除了long和double型,它们需要两个位置。操作数只能被适用于其类型的操作符所操作。例如,压入两个int类型的数,如果把它们当作是一个long类型的数则是非法的。在Sun的虚拟机实现中,这个限制由字节码验证器强制实行。但是,有少数操作(操作符dupe和swap),用于对运行时数据区进行操作时是不考虑类型的。
本地方法栈，当一个线程调用本地方法时，它就不再受到虚拟机关于结构和安全限制方面的约束，它既可以访问虚拟机的运行期数据区，也可以使用本地处理器以及任何类型的栈。例如，本地栈是一个C语言的栈，那么当C程序调用C函数时，函数的参数以某种顺序被压入栈，结果则返回给调用函数。在实现Java虚拟机时，本地方法接口使用的是C语言的模型栈，那么它的本地方法栈的调度与使用则完全与C语言的栈相同。
3 Java虚拟机的运行过程
上面对虚拟机的各个部分进行了比较详细的说明，下面通过一个具体的例子来分析它的运行过程。
虚拟机通过调用某个指定类的方法main启动，传递给main一个字符串数组参数，使指定的类被装载，同时链接该类所使用的其它的类型，并且初始化它们。例如对于程序：
class HelloApp
{
public static void main(String[] args)
{
System.out.println("Hello World!");
for (int i = 0; i < args.length; i++ )
{
System.out.println(args[i]);
}
}
}
编译后在命令行模式下键入： java HelloApp run virtual machine
将通过调用HelloApp的方法main来启动java虚拟机，传递给main一个包含三个字符串"run"、"virtual"、"machine"的数组。现在我们略述虚拟机在执行HelloApp时可能采取的步骤。
开始试图执行类HelloApp的main方法，发现该类并没有被装载，也就是说虚拟机当前不包含该类的二进制代表，于是虚拟机使用ClassLoader试图寻找这样的二进制代表。如果这个进程失败，则抛出一个异常。类被装载后同时在main方法被调用之前，必须对类HelloApp与其它类型进行链接然后初始化。链接包含三个阶段：检验，准备和解析。检验检查被装载的主类的符号和语义，准备则创建类或接口的静态域以及把这些域初始化为标准的默认值，解析负责检查主类对其它类或接口的符号引用，在这一步它是可选的。类的初始化是对类中声明的静态初始化函数和静态域的初始化构造方法的执行。一个类在初始化之前它的父类必须被初始化。整个过程如下：
图4：虚拟机的运行过程
4 结束语
本文通过对JVM的体系结构的深入研究以及一个Java程序执行时虚拟机的运行过程的详细分析，意在剖析清楚Java虚拟机的机理。