看OOP教材时，提到了一个双检测锁定(Double-Checked Lock, DCL)的问题，但是书上没有多介绍，只是说这是一个和底层内存机制有关的漏洞。查阅了下相关资料，对这个问题大致有了点了解。

从头开始说吧。

在多线程的情况下Singleton模式会遇到不少问题，一个简单的例子

   1:  class Singleton {     
   2:      private static Singleton instance = null;     
   3:        
   4:      public static Singleton instance() {     
   5:          if (instance == null) {     
   6:              instance = new Singleton();     
   7:          }     
   8:          return instance;    
   9:      }    
   10:  }
  
假设这样一个场景，有两个线程调用Singleton.instance()，首先线程一判断instance是否等于null，判断完后一瞬间虚拟机把线程二调度为运行线程，线程二再次判断instance是否为null，然后创建一个Singleton实例，线程二的时间片用完后，线程一被唤醒，接下来它执行的代码依然是instance = new Singleton();
两次调用返回了不同的对象，出现问题了。

最简单的方法自然是在类被载入时就初始化这个对象：private static Singleton instance = new Singleton();

JLS(Java Language Specification)中规定了一个类只会被初始化一次，所以这样做肯定是没问题的。

但是如果要实现延迟初始化(Lazy initialization)，比如这个实例初始化时的参数要在运行期才能确定，应该怎么做呢？

依然有最简单的方法：使用synchronized关键字修饰初始化方法：

    public synchronized static Singleton instance() {       
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
   
这里有一个性能问题：多个线程同时访问这个方法时，会因为同步而导致每次只有一个线程运行，影响程序性能。而事实上初始化完毕后只需要简单的返回instance的引用就行了。

DCL是一个“看似”有效的解决方法，先把对应代码放上来吧：

    1 :   class Singleton {  
    2 :       private static Singleton instance = null ;  
    3 :     
    4 :       public static Singleton instance() {  
    5 :           if (instance == null ) {
    6 :               synchronized (this) {  
    7 :                   if (instance == null)
    8 :                      instance = new Singleton();
    9 :              }
    10 :          }
    11 :          return instance;
    12 :      }
    13 :  }

用JavaWorld上对应文章的标题来评论这种做法就是smart, but broken。来看原因：

Java编译器为了提高程序性能会进行指令调度，CPU在执行指令时同样出于性能会乱序执行（至少现在用的大多数通用处理器都是out-of-order的），另外cache的存在也会改变数据回写内存时的顺序[2]。JMM(Java Memory Model, 见[1])指出所有的这些优化都是允许的，只要运行结果和严格按顺序执行所得的结果一样即可。

Java假设每个线程都跑在自己的处理器上，享有自己的内存，和共享的主存交互。注意即使在单核上这种模型也是有意义的，考虑到cache和寄存器会保存部分临时变量。理论上每个线程修改自己的内存后，必须立即更新对应的主存内容。但是Java设计师们认为这种约束会影响程序性能，他们试着创造了一套让程序跑得更快、但又保证线程之间的交互与预期一致的内存模型。

synchronized关键字便是其中一把利器。事实上，synchronized块的实现和Linux中的信号量(semaphore)还是有区别的，前者过程中锁的获得和释放都会都会引发一次Memory Barrier来强制线程本地内存和主存之间的同步。通过这个机制，Java中的同步机制保证了synchronized块中指令的原子性(atomic)。

好了，回过头来看DCL问题。看起来访问一个未同步的instance字段不会产生什么问题，我们再次来假设一个场景：

线程一进入同步块，执行instance = new Singleton(); 线程二刚开始执行getResource();

按照顺序的话，接下来应该执行的步骤是 1) 分配新的Singleton对象的内存 2) 调用Singleton的构造器，初始化成员字段 3) instance被赋为指向新的对象的引用。

前面说过，编译器或处理器都为了提高性能都有可能进行指令的乱序执行，线程一的真正执行步骤可能是1) 分配内存 2) instance指向新对象 3) 初始化新实例。如果线程二在2完成后3执行前被唤醒，它看到了一个不为null的instance，跳出方法体走了，带着一个还没初始化的Singleton对象。

错误发生的一种情形就是这样，关于更详细的编译器指令调度导致的问题，可以参看这个网页 [4]。

[3] 中提供了一个编译器指令调度的证据

instance = new Singleton(); 这条命令在Symantec JIT中被编译成

0206106A   mov         eax,0F97E78h
0206106F   call        01F6B210                  ; 分配空间
02061074   mov         dword ptr [ebp],eax       ; EBP中保存了instance的地址

02061077   mov         ecx,dword ptr [eax]       ; 解引用，获得新的指针地址

02061079   mov         dword ptr [ecx],100h      ; 接下来四行是inline后的构造器
0206107F   mov         dword ptr [ecx+4],200h   
02061086   mov         dword ptr [ecx+8],400h
0206108D   mov         dword ptr [ecx+0Ch],0F84030h

可以看到，赋值完成在初始化之前，而这是JLS允许的。
 
另一种情形是，假设线程一安稳地完成Singleton对象的初始化，退出了同步块，并同步了和本地内存和主存。线程二来了，看到一个非空的引用，拿走。注意线程二没有执行一个Read Barrier，因为它根本就没进后面的同步块。所以很有可能此时它看到的数据是陈旧的。

还有很多人根据已知的几种提出了一个又一个fix的方法，但最终还是出现了更多的问题。可以参阅[3]中的介绍。

[5]中还说明了即使把instance字段声明为volatile还是无法避免错误的原因。

由此可见，安全的Singleton的构造一般只有两种方法，一是在类载入时就创建该实例，二是使用性能较差的synchronized方法。

(by ZelluX  http://www.blogjava.net/zellux )

参考资料：

[1] Java Language Specification, Second Edition, 第17章介绍了Java中线程和内存交互关系的具体细节。
[2] out-of-order与cache的介绍可以参阅Computer System, A Programmer's Perspective的第四、五章。
[3] The "Double-Checked Locking is Broken" Declaration, http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
[4] Synchronization and the Java Memory Model, http://gee.cs.oswego.edu/dl/cpj/jmm.html
[5] Double-checked locking: Clever, but broken, http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html?page=1
[6] Holub on Patterns, Learning Design Patterns by Looking at Code

该语法常用的一个情况是泛型类的比较
java.util.TreeSet<E> 代表一个有序的元素为E的树，它其中的一个构造器需要一个Comparator类来比较两个元素，以E为String类时为例，此时的Comparator可以是Comparator<String>，也可以是Comparator<Object>，但Comparator<Integer>就不行，如何表示这样的限制呢？
jdk源代码中是这样的：
public TreeSet(Comparator<? super E> c)
这样就保证了传给构造器的Comparator是可以进行E元素的比较的。

另一个例子，java.util.Collections的max方法用于获得一个容器中的最大值，这个函数头可以这样写：
public static <T extends Comparable<T>>  T max(Collection<T> coll)

public static <T extends Object & Comparable<? super T>> T max(Collection<? extends T> coll) {
    Iterator<? extends T> i = coll.iterator();
    T candidate = i.next();

    while(i.hasNext()) {
    T next = i.next();
    if (next.compareTo(candidate) > 0)
        candidate = next;
    }
    return candidate;
}

很严谨的函数头，但是限定方面比较宽

    Loggers组件在此系统中被分为五个级别：DEBUG、INFO、WARN、ERROR和FATAL。这五个级别是有顺序的，DEBUG < INFO < WARN < ERROR < FATAL，明白这一点很重要，这里Log4j有一个规则：假设Loggers级别为P，如果在Loggers中发生了一个级别Q比P高，则可以启动，否则屏蔽掉。

Java程序举例来说：

//建立Logger的一个实例，命名为“com.foo”

Logger  logger = Logger.getLogger("com.foo");

//设置logger的级别。通常不在程序中设置logger的级别。一般在配置文件中设置。

logger.setLevel(Level.INFO);

Logger barlogger = Logger.getLogger("com.foo.Bar");

//下面这个请求可用，因为WARN >= INFO

logger.warn("Low fuel level.");

//下面这个请求不可用，因为DEBUG < INFO

logger.debug("Starting search for nearest gas station.");

//命名为“com.foo.bar”的实例barlogger会继承实例“com.foo”的级别。因此，下面这个请求可用，因为INFO >= INFO

barlogger.info("Located nearest gas station.");

//下面这个请求不可用，因为DEBUG < INFO

barlogger.debug("Exiting gas station search"); 

这里“是否可用”的意思是能否输出Logger信息。 

    在对Logger实例进行命名时，没有限制，可以取任意自己感兴趣的名字。一般情况下建议以类的所在位置来命名Logger实例，这是目前来讲比较有效的Logger命名方式。这样可以使得每个类建立自己的日志信息，便于管理。比如：

static Logger logger = Logger.getLogger(ClientWithLog4j.class.getName());

2、 Appenders

    禁用与使用日志请求只是Log4j其中的一个小小的地方，Log4j日志系统允许把日志输出到不同的地方，如控制台（Console）、文件（Files）、根据天数或者文件大小产生新的文件、以流的形式发送到其它地方等等。

其语法表示为：

org.apache.log4j.ConsoleAppender（控制台），

org.apache.log4j.FileAppender（文件），
org.apache.log4j.DailyRollingFileAppender（每天产生一个日志文件），org.apache.log4j.RollingFileAppender（文件大小到达指定尺寸的时候产生一个新的文件），
org.apache.log4j.WriterAppender（将日志信息以流格式发送到任意指定的地方）

配置时使用方式为：

log4j.appender.appenderName = fully.qualified.name.of.appender.class

log4j.appender.appenderName.option1 = value1

…

log4j.appender.appenderName.option = valueN

这样就为日志的输出提供了相当大的便利。

3、 Layouts

    有时用户希望根据自己的喜好格式化自己的日志输出。Log4j可以在Appenders的后面附加Layouts来完成这个功能。Layouts提供了四种日志输出样式，如根据HTML样式、自由指定样式、包含日志级别与信息的样式和包含日志时间、线程、类别等信息的样式等等。

其语法表示为：

org.apache.log4j.HTMLLayout（以HTML表格形式布局），
org.apache.log4j.PatternLayout（可以灵活地指定布局模式），
org.apache.log4j.SimpleLayout（包含日志信息的级别和信息字符串），
org.apache.log4j.TTCCLayout（包含日志产生的时间、线程、类别等等信息）

配置时使用方式为：

     log4j.appender.appenderName.layout =       fully.qualified.name.of.layout.class
     log4j.appender.appenderName.layout.option1 = value1
     …
     log4j.appender.appenderName.layout.option = valueN
 
    以上是从原理方面说明Log4j的使用方法，在具体Java编程使用Log4j可以参照以下示例：
1、 建立Logger实例：
    语法表示：public static Logger getLogger( String name)
    实际使用：static Logger logger = Logger.getLogger   (ServerWithLog4j.class.getName ()) ;
2、 读取配置文件：
    获得了Logger的实例之后，接下来将配置Log4j使用环境：
    语法表示：
    BasicConfigurator.configure()：自动快速地使用缺省Log4j环境。
    PropertyConfigurator.configure(String configFilename)：读取使用Java的特性文件编写的配置文件。
    DOMConfigurator.configure(String filename)：读取XML形式的配置文件。
    实际使用：PropertyConfigurator.configure("ServerWithLog4j.properties");
3、 插入日志信息
    完成了以上连个步骤以后，下面就可以按日志的不同级别插入到你要记录日志的任何地方了。
    语法表示：
    Logger.debug(Object message);
    Logger.info(Object message);
    Logger.warn(Object message);
    Logger.error(Object message);
    实际使用：logger.info("ServerSocket before accept: " + server);
 
    在实际编程时，要使Log4j真正在系统中运行事先还要对配置文件进行定义。定义步骤就是对Logger、Appender及Layout的分别使用，具体如下：
1、 配置根Logger，其语法为：
    log4j.rootLogger = [ level ] , appenderName, appenderName, …
这里level指Logger的优先级，appenderName是日志信息的输出地，可以同时指定多个输出地。如：log4j.rootLogger= INFO,A1,A2
2、 配置日志信息输出目的地，其语法为：
    log4j.appender.appenderName = fully.qualified.name.of.appender.class
    可以指定上面所述五个目的地中的一个。
3、 配置日志信息的格式，其语法为：
    log4j.appender.appenderName.layout = fully.qualified.name.of.layout.class
    这里上面三个步骤是对前面Log4j组件说明的一个简化；下面给出一个具体配置例子，在程序中可以参照执行：
    log4j.rootLogger=INFO,A1
    log4j.appender.A1=org.apache.log4j.ConsoleAppender
    log4j.appender.A1.layout=org.apache.log4j.PatternLayout
    log4j.appender.A1.layout.ConversionPattern=
                                        %-4r %-5p %d{yyyy-MM-dd HH:mm:ssS} %c %m%n
    这里需要说明的就是日志信息格式中几个符号所代表的含义：
    －X号: X信息输出时左对齐；
    %p: 日志信息级别
    %d{}: 日志信息产生时间
    %c: 日志信息所在地（类名）
    %m: 产生的日志具体信息
    %n: 输出日志信息换行
 
根据上面的日志格式，某一个程序的输出结果如下：
0    INFO  2003-06-13 13:23:46968 ClientWithLog4j Client socket: Socket[addr=localhost/127.0.0.1,port=8002,localport=2014]
16   DEBUG 2003-06-13 13:23:46984 ClientWithLog4j Server says: 'Java server with log4j, Fri Jun 13 13:23:46 CST 2003'
16   DEBUG 2003-06-13 13:23:46984 ClientWithLog4j GOOD
16   DEBUG 2003-06-13 13:23:46984 ClientWithLog4j Server responds: 'Command 'HELLO' not understood.'
16   DEBUG 2003-06-13 13:23:46984 ClientWithLog4j HELP
16   DEBUG 2003-06-13 13:23:46984 ClientWithLog4j Server responds: 'Vocabulary: HELP QUIT'
16   DEBUG 2003-06-13 13:23:46984 ClientWithLog4j QUIT

2. Filter 编程
filtering API由javax.servlet包中的Filter, FilterChain和FilterConfig接口定义。
其中最重要的方法是doFilter。它可以用来：
a) 检查请求报头。
b) 自定义请求对象。
c) 自定义响应对象。
d) 调用过滤链(filter chain)中的下一个实体(entity)。如果当前过滤器已经是链中最后一个过滤器了，下一个实体就是链尾的资源；否则它就是在WAR中设置的下一个过滤器。当然也可以在此时通过不调用下一个实体来中断请求、
e) 在响应报头调用下一个过滤器后检查。
f) 抛出反应处理错误的异常。

3. 一个 Duke's Bookstore 的例子
HitCounterFilter在servlet被访问时计数。
public final class HitCounterFilter implements Filter {
  private FilterConfig filterConfig = null;

  public void init(FilterConfig filterConfig)
    throws ServletException {
    this.filterConfig = filterConfig;
  }
  public void destroy() {
    this.filterConfig = null;
  }
  public void doFilter(ServletRequest request,
    ServletResponse response, FilterChain chain)
    throws IOException, ServletException {
    if (filterConfig == null)
      return;
    StringWriter sw = new StringWriter();
    PrintWriter writer = new PrintWriter(sw);
    Counter counter = (Counter)filterConfig.
      getServletContext().
      getAttribute("hitCounter");
    writer.println();
    writer.println("===============");
    writer.println("The number of hits is: " +
      counter.incCounter());
    writer.println("===============");
    // Log the resulting string
    writer.flush();
    System.out.println(sw.getBuffer().toString());
    ...
    chain.doFilter(request, wrapper);
    ...
  }
}

4. 设置过滤器映射
部署描述符文件的2.3版本引入了两个用于过滤器的元素，分别是：filter和filter-mapping。filter元素向系统注册一个过滤对象，filter-mapping元素指定该过滤对象所应用的URL。
1.filter元素
filter元素位于部署描述符文件（web.xml）的前部，所有filter-mapping、servlet或servlet-mapping元素之前。filter元素具有如下六个可能的子元素：
icon 这是一个可选的元素，它声明IDE能够使用的一个图象文件。
filter-name 这是一个必需的元素，它给过滤器分配一个选定的名字。
display-name 这是一个可选的元素，它给出IDE使用的短名称。
description 这也是一个可选的元素，它给出IDE的信息，提供文本文档。
filter-class 这是一个必需的元素，它指定过滤器实现类的完全限定名。
init-param 这是一个可选的元素，它定义可利用FilterConfig的getInitParameter方法读取的初始化参数。单个过滤器元素可包含多个init-param元素。

filter-mapping元素
filter-mapping元素位于web.xml文件中filter元素之后serlvet元素之前。它包含如下三个可能的子元素：：
l filter-name 这个必需的元素必须与用filter元素声明时给予过滤器的名称相匹配。
l url-pattern 此元素声明一个以斜杠（/）开始的模式，它指定过滤器应用的URL。所有filter-mapping元素中必须提供url-pattern或servlet-name。但不能对单个filter-mapping元素提供多个url-pattern元素项。如果希望过滤器适用于多个模式，可重复整个filter-mapping元素。
l servlet-name 此元素给出一个名称，此名称必须与利用servlet元素给予servlet或JSP页面的名称相匹配。不能给单个filter-mapping元素提供多个servlet-name元素项。如果希望过滤器适合于多个servlet名，可重复这个filter-mapping元素。

1input {}{
2    width: expression(this.type!="submit"?'150px':'');
3    height: 23px;
4}

1<c:choose>
2  <c:when test="${boolean1}"></c:when>
3  <c:when test="${boolean2}"></c:when>
4  <c:otherwise></c:otherwise>
5</c:choose>

4. DisplayTag 标签库
这东东真不错，支持奇偶数行css分离、自动换页等功能。
a) <display:table name="test" />
这样一行代码就能自动列出test内的所有属性了。
b) 如果要只列出指定的列，可以使用

<display:table name="test">
　　 <display:column property="id" title="ID" />
　　 <display:column property="name" />
　　 <display:column property="email" />
　　 <display:column property="status" />
　　 <display:column property="description" title="Comments"/>
</display:table>

c) 指定某一列的样式：<display:column property="id" title="ID" class="idcol"/>
d) 创建简单的动态链接
<display:column property="email" href="details.jsp" paramId="action" paramName="testparam" paramScope="request" />
这样只能产生details?action=xx的链接

package util;

import org.displaytag.decorator.TableDecorator;

public class Decorator extends TableDecorator {
  public String getEditLink() {
    beans.Policy p = (beans.Policy)getCurrentRowObject();
    int pId = p.getId();
    return "<a href=\"servlet/editItem?id=" + pId + "\">@</a>";  
  }
}

本文是分享文档站长胡萝卜的作品。大家可以自由阅读、在网络上进行分发，前提是必须保留本文档的完整性。
分享文档是一家专业的Java技术网站，给中国Java 程序员提供各种Java资源如文档，工具，教程，社区交流等。
我们的官方网站是：http://chinesedocument.com
我们的官方论坛是：http://bbs.chinesedocument.com
请大家多多关注分享文档，我们还会发布更多优秀的文档！

第1章 使用FileUpload
FileUpload能以多种方式使用，这取决于你的应用需求。举个简单的例子，你可能调用一个单独的方法来解析servelt的请求，并且处理那些项目。 从另一个方面来讲，你可能想自定义FileUpload来完全控制个别项目的存贮；例如，你想流化那些内容，并存到数据库里去。
这里我们会介绍使用FileUpload的基础原则，并描述一些简单的通用的使用模式。我们会在在其它地方介绍关于FileUpload的自定义。
FileUpload依赖于一些公用的IO，因此，要确保在你继续之前，你的classpath里已经有依赖页面里提起的那些版本。

第2章 FileUpload如何工作？
一个上传请求由一系列根据RFC1867（"Form-based File Upload in HTML".）编码的项目列表组成。FileUpload可以解析这样的请求，并为你的应用提供那些已上传的项目的列表。每一个这样的项目都实现了FielItem接口，我们不用管它们的底层实现。
这个页面描述了commons fileupload库的常用API。这些常用API是非常方便的途径。然而，为了最好的性能，你可能更喜欢最快的Streaming API 。
每一个文件项目有一些自己的属性，这些属性也许正是你的应用程序感兴趣的地方。例如，每个项目有个一个名字和内容类型，并且可以提供一个输入流来访问它们的数据。另一方面来看，你可能需要用不同方式来处理不同的项目，这就依赖于那些项目是否是一个正常的表单字域，也就是说，这些数据来自于一个普通的文本框或类似HTML的字域，还是一个要上传文件字段。FileItem接口提供一些方法来做这样一个决定，并且用最合适的方法访问这些数据。
FileUpload使用FileItemFactory创建一个新的文件项目。这将会给FileUpload最好的灵活性。工厂最终控制每个项目如何被创建。默认的工厂在内存或者硬盘里存储项目的数据，这依赖于项目的大小（例如，有多少字节的数据。）。不过，为了适用于你的应用，你还是可以自定义这种行为的。

第3章 servlets and portlets
从V1.1版开始，FileUpload就开始支持servlet和portlet的文件上传请求。这两种环境的用法基本上差不多，因此，文档的剩下部分都将是在servlet环境里。
如果你正在构建一个portet应用，那么下面两个差别是你在读文档时应注意的：
你在哪里引用了ServletFileUpload类，就用PortletFileUpload类来替代它。
你在哪里引用了HttpServletRequest类，就用ActionRequest类替代它。

第4章 解析请求
在你同那些上传的项目一起工作前，你需要先解析请求本身。以确保这个请求确实是一个文件上传请求。FileUpload是通过调用一个静态方法来实现的。
// Check that we have a file upload request
boolean isMultipart = ServletFileUpload.isMultipartContent(request);
现在，我们已经准备好解析请求里的项目了。

4.1 最简单的例子
下面是一些简单的使用场景：
􀁺 　 上传项目只要足够小，就应该保留在内存里。
􀁺 　 较大的项目应该被写在硬盘的临时文件上。
􀁺 　 非常大的上传请求应该避免。
􀁺 　 限制项目在内存中所占的空间，限制最大的上传请求，并且设定临时文件的位置。
处理这个场景的请求很简单：
// Create a factory for disk-based file items
FileItemFactory factory = new DiskFileItemFactory();
// Create a new file upload handler
ServletFileUpload upload = new ServletFileUpload(factory);
// Parse the request
List /* FileItem */ items = upload.parseRequest(request);
这就是我们所需要的全部代码了！
解析的结果就是一个项目的List,每个项目都实现了FileItem接口。我们将在下面讨论如何处理这些项目。
4.2 训练如何控制
如果你的使用场景和上面那个简单的例子很接近，但是你又需要一点点控制，那么你可以很容易地定义upload处理器或者文件项目工厂的行为。下面这个例子显示了几个配置选项。
// Create a factory for disk-based file items
DiskFileItemFactory factory = new DiskFileItemFactory();
// Set factory constraints
factory.setSizeThreshold(yourMaxMemorySize);
factory.setRepository(yourTempDirectory);
// Create a new file upload handler
ServletFileUpload upload = new ServletFileUpload(factory);
// Set overall request size constraint
upload.setSizeMax(yourMaxRequestSize);
// Parse the request
List /* FileItem */ items = upload.parseRequest(request);
当然，每个配置方法是独立于其它任意一个的。但是如果你想一次性配置他们，你可以用parseRequest()的另一个重载方法，像这样：
// Create a factory for disk-based file items
DiskFileItemFactory factory = new DiskFileItemFactory(
yourMaxMemorySize, yourTempDirectory);
如果你还想使用更多的控制，比如存储项目到其它地方（如，数据库），那么你可以看FileUpload自定义介绍。

第5章 处理上传的项目
一旦解析完成，那么你会得到一个待处理的文件项目列表。很多的情况下，你会想用不同的方式来处理文件上传域和正常的表单域，因此，你可以这样做：
// Process the uploaded items
Iterator iter = items.iterator();
while (iter.hasNext()) {
  FileItem item = (FileItem) iter.next();
  if (item.isFormField()) {
    processFormField(item);
  } else {
    processUploadedFile(item);
  }
}
对于普通的表单域来说，你可能对项目的名称和字符型值 很感兴趣。就像你希望的那样，照下面的做：
// Process a regular form field
if (item.isFormField()) {
  String name = item.getFieldName();
  String value = item.getString();
  ...
}
对于上传文件，这里就有很多不同啦~你可能想知道更多其它的内容。下面是个例子，里面包含了不少你感兴趣的方法。
// Process a file upload
if (!item.isFormField()) {
  String fieldName = item.getFieldName();
  String fileName = item.getName();
  String contentType = item.getContentType();
  boolean isInMemory = item.isInMemory();
  long sizeInBytes = item.getSize();
  ...
}
对于上传的文件，你肯定不希望总是通过内存来访问它，除非它很小，或者你实在没有别的选择余地了。你很希望使用流来处理文件内容或者将文件保存到它的最终位置。FileUpload提供简单的方式来完成两方面的需求。
// Process a file upload
if (writeToFile) {
  File uploadedFile = new File(...);
  item.write(uploadedFile);
} else {
  InputStream uploadedStream = item.getInputStream();
  ...
  uploadedStream.close();
}
注意：在FileUpload的默认实现中wirte()方法应该值得关注，如果数据还在临时文件里没有移除，那么这个方法就会试图重命名这个文件为相应的目标文件。事实上如果重命名失败了的话，数据就仅仅被拷贝。
如果你需要访问内存中的上传数据，你可以用get()方法来获得数据的二进制数组形式。
// Process a file upload in memory
byte[] data = item.get();
...

第6章 清除资源
这一节只适用于你使用了DiskFileItem。换句话说，它只适用于你在处理上传文件之前将上传文件写入过临时文件这种情形。
像这种临时文件会被自动删除， 如果它们不再被使用（更确切地说，java.io.File的实例已经被GC掉了。 ）这是由org.apache.commons.io.FileCleaner类在后台完成的，它会启动一个收割机线程。
这个收割机线程在它不再被需要时会被停止。在servlet环境里，这是通过指定一个名叫FileCleanerCleanup的servlet上下文监听器来实现的。要做到这里，在你的web.xml增加下面的代码：
<web-app>
...
<listener>
<listener-class>
org.apache.commons.fileupload.servlet.FileCleanerCleanup
</listener-class>
</listener>
...
</web-app>
不幸的是，事情到这里还没完。如果你和下面的情况一样，那么你就只需要按照上面的做，就可以清除资源了。
你使用的是commons-io 1.3或者更晚的版本。
你是从web应用的web-inf/lib里载入commons-io的，并不是从其它位置，如Tomcat的common/lib下。
如果commons-io 1.3是从你的WEB容器的classpath里载入的，那么，下面的情况可能会出现：
建议你运行两个应用，一个叫A，一个叫B。（这两个应用可能是完全一样，只不过上下文名称不一样。）这两个应用都使用了FileCleanerCleanup。现在，如果你终止应用A，B还在运行，这时，A会终止B的收割机线程。换言之，你要十分仔细地考虑是使用FileCleanerCleanup，还是不使用。

第7章 观察上传进度
如果你希望可以上传很大的文件，这时，你可能想将上传的状态告诉用户，如已经接收了多少。
观察上传进度需要通过一个处理监听器来实现。
//Create a progress listener
ProgressListener progressListener = new ProgressListener(){
  public void update(long pBytesRead, long pContentLength, int pItems) {
    System.out.println("We are currently reading item " + pItems);
    if (pContentLength == -1) {
      System.out.println("So far, " + pBytesRead + " bytes have been read.");
    } else {
      System.out.println("So far, " + pBytesRead + " of " + pContentLength
      + " bytes have been read.");
    }
  }
};
upload.setProgressListener(progressListener);
上面这个监听器是有问题的。因为它非常频繁地被调用。这会带来性能问题。一个比较好的解决办法是，减少调用。例如，如果megabytes被改变，那么就发出一个消息。
//Create a progress listener
ProgressListener progressListener = new ProgressListener(){
  private long megaBytes = -1;
  public void update(long pBytesRead, long pContentLength, int pItems) {
    long mBytes = pBytesRead / 1000000;
    if (megaBytes == mBytes) {
      return;
    }
    megaBytes = mBytes;
    System.out.println("We are currently reading item " + pItems);
    if (pContentLength == -1) {
      System.out.println("So far, " + pBytesRead + " bytes have been read.");
    } else {
      System.out.println("So far, " + pBytesRead + " of " + pContentLength
      + " bytes have been read.");
    }
  }
};