在项目的业务属性中,你是不是要经常验证属性的取值范围呢. 想要了解比较优美的解决方案吗?          

看看Hibernate Validator 是怎么做的吧.一见到她,相信你就会说: Oh God, 这就是我需要的.

任何获得Matrix授权的网站，转载请保留以下作者信息和链接：
作者：icess(作者的blog:http://blog.matrix.org.cn/page/icess)
关键字：Hibernate Validator

用Annotations 给类或者类的属性加上约束(constraint),在运行期检查属性值是很优雅的.Hibernate Validator就是这样的一个框架.该框架是十分容易的(就像参考文档中宣称的那样),几乎没有什么学习曲线,Validator 是一个验证框架 不需要和Hibernate的其他部分绑定就可以使用,只要在你的项目中添加Hibernate-annotations.jar库就可以了.那么下面就让我们看看怎么使用吧.

Person.java 类

/*
  * Created on 2006-1-12 Person.java
  * @author 
  */
package  test.annotation.validator;

import  org.hibernate.validator.Length;
import  org.hibernate.validator.Min;
import  org.hibernate.validator.Valid;
　

//@Serializability  //测试自定义约束
public class  Person {

   private  String name;
   private int  age;
   private  Address address;
  
   public  Person() {}
  
   @Valid //注意此处
   public  Address getAddress() {
     return  address;
   }
   public void  setAddress(Address address) {
     this .address = address;
   }
  
   @Min(value =  1 )
   public int  getAge() {
     return  age;
   }
   public void  setAge( int  age) {
     this .age = age;
   }
  
   @Length(min =  4 )
   public  String getName() {
     return  name;
   }
   public void  setName(String name) {
     this .name = name;
   }
}

Address.java 类

/*
  * Created on 2006-1-12 Address.java
  * @author 
  */
package  test.annotation.validator;

import  org.hibernate.validator.Length;
import  org.hibernate.validator.Max;
import  org.hibernate.validator.Min;

public class  Address {

   private  String street;
   private int  num;
  
   public  Address() {}
  
   @Min(value =  1 )
   @Max(value =  100 )
   public int  getNum() {
     return  num;
   }
   public void  setNum( int  num) {
     this .num = num;
   }
  
   @Length(min =  3 ,max =  8 )
   public  String getStreet() {
     return  street;
   }
   public void  setStreet(String street) {
     this .street = street;
   }
}

TestValidator.java 类

/*
  * Created on 2006-1-12
  * @author icerain
  */
package  test.annotation.validator;

import  org.hibernate.validator.ClassValidator;
import  org.hibernate.validator.InvalidValue;


public class  TestValidator {
   public void  test() {
     Address add =  new  Address();
     add.setNum( 0 );
     add.setStreet( "1" );
    
     Person p =  new  Person();
     p.setAddress(add);
     p.setAge( 0 );
     p.setName( "ice" );
    
     /******************Test validator ********/

    // 注意该处只验证了Person 为了说明 @Valid 注释的使用
     ClassValidator<Person> classValidator =  new  ClassValidator<Person> (Person. class );
     InvalidValue[] validMessages = classValidator.getInvalidValues(p);
     for  (InvalidValue value : validMessages) {
      
     System.out.println( "InvalidValue 的长度是:"  + validMessages.length
         + " . 验证消息是: "  + value.getMessage() 
         +  " . PropertyPath 是:"  + value.getPropertyPath()
         + " .\n\t PropertyName 是: "  +value.getPropertyName()
         +  "Value 是: "  + value.getValue()
         + " Bean 是: " + value.getBean()
         + "\n\t BeanClass 是:"  + value.getBeanClass());
     }
   }
  
   public static void  main(String[] args) {
     new  TestValidator().test();
   }
}

程序的输出如下

InvalidValue 的长度是:4 . 验证消息是: 必须大于等于 1 . PropertyPath 是:age .

PropertyName 是: age. Value 是: 0 Bean 是: test.annotation.validator.Person@dd87b2

BeanClass 是:class test.annotation.validator.Person

InvalidValue 的长度是:4 . 验证消息是: 长度必须介于 4 与 2147483647 之间 . PropertyPath 是:name .

PropertyName 是: name. Value 是: ice Bean 是: test.annotation.validator.Person@dd87b2

BeanClass 是:class test.annotation.validator.Person

InvalidValue 的长度是:4 . 验证消息是: 必须大于等于 1 . PropertyPath 是:address.num .

PropertyName 是: num. Value 是: 0 Bean 是: test.annotation.validator.Address@197d257

BeanClass 是:class test.annotation.validator.Address

InvalidValue 的长度是:4 . 验证消息是: 长度必须介于 3 与 8 之间 . PropertyPath 是:address.street .

PropertyName 是: street. Value 是: 1 Bean 是: test.annotation.validator.Address@197d257

BeanClass 是:class test.annotation.validator.Address

可以看出不满足约束的值都被指出了.

同时该句: ClassValidator<Person> classValidator = new ClassValidator<Person> (Person.class);

我们只验证了 Person. 在Person里面的Address的属性 由于有@Valid Annotations 所以 Address的相关属性也被机联验证了 .

如果 把@Valid Annotations 去掉,结果如下:

InvalidValue 的长度是:2 . 验证消息是: 必须大于等于 1 . PropertyPath 是:age .

PropertyName 是: age. Value 是: 0 Bean 是: test.annotation.validator.Person@18fef3d

BeanClass 是:class test.annotation.validator.Person

InvalidValue 的长度是:2 . 验证消息是: 长度必须介于 4 与 2147483647 之间 . PropertyPath 是:name .

PropertyName 是: name. Value 是: ice Bean 是: test.annotation.validator.Person@18fef3d

BeanClass 是:class test.annotation.validator.Person

可以看出 没有验证 Address.

当然了 ,你还可以只验证一个属性 , 没有必要验证整个类.只需要在调用 classValidator.getInvalidValues(p,"age")方法时 加上你要验证的属性就可以了.如我们只想验证age 属性 把代码改为如下所示:

InvalidValue[] validMessages = classValidator.getInvalidValues(p,"age"); / /只验证age 属性

运行结果如下:

InvalidValue 的长度是:1 . 验证消息是: 必须大于等于 1 . PropertyPath 是:age .

PropertyName 是: age. Value 是: 0 Bean 是: test.annotation.validator.Person@1457cb

BeanClass 是:class test.annotation.validator.Person

只是验证了 age 属性.

怎么样 ,很简单吧. 关于 Hibernate Validator 内建的验证Annotations 大家可以看看 API 或者 参考文档(中文版我正在翻译中 请访问我的 Blog 获得最新信息).

如果你要写自己的约束呢 , 你不用担心 ,这也是很容易的. 任何约束有两部分组成: [约束描述符 即注释]the constraint descriptor (the annotation) 和[约束validator 即 实现类] the constraint validator (the implementation class).下面我们扩展Hibernate Test suit 中的一个Test 来讲解一下.

@ValidatorClass(SerializabilityValidator. class ) 指出了 constraint validator 类.

@Target({METHOD,FIELD,TYPE})
@Retention(RUNTIME)
@Documented                

这几个我就不用解释了吧.

Serializability 里面声明了一个 message 显示约束的提示信息. num 只是为了说明一个方面 在这里面没有实际用途用 .

然后就是 实现一个 constraint validator 类 该类要实现Validator<ConstraintAnnotation>.这里是SerializabilityValidator.java 如下:

//$Id: SerializabilityValidator.java,v 1.3 2005/11/17 18:12:11 epbernard Exp $
package  test.annotation.validator;

import  java.io.Serializable;

import  org.hibernate.validator.Validator;

/**
  * Sample of a bean-level validator
  *
  *  @author  Emmanuel Bernard
  */
public class  SerializabilityValidator  implements  Validator<Serializability>, Serializable {
   public boolean  isValid(Object value) {
    //这里只是Validator 里面的 实现验证规则的 方法. value 是要验证的值.
     System.out.println( "IN SerializabilityValidator isValid:" +value.getClass()+ ": "  +value.toString());
     return  value instanceof Serializable;
  }

  public void initialize(Serializability parameters) {
    // 在这里可以 取得 constraint descriptor 里面的属性 如上面我们声明的 num
     System.out.println( "IN SerializabilityValidator: parameters:" + parameters.num() );
   }
}

然后在你的类中应用@Serializability  就可以约束一个类实现Serializable 接口了. 如下:

在我们的Person.java类 添加@Serializability  Annotations ,把Person.java 中的 //@Serializability //测试自定义约束 注释去掉就ok了.

运行结果如下:

InvalidValue 的长度是:3 . 验证消息是: bean must be serialiable . PropertyPath 是:null .

现在把Person类实现 java.io.Serializable 接口 则没有出现 验证错误消息.

消息的国际化也是很简单的,把 Serializability  中的message 改为以{}扩住的 属性文件的Key就可以了

public  @interface Serializability {
   int  num()  default  11 ;
   String message()  default  "{Serializable}"; //"bean must be serialiable"; //消息的国际化
}

然后编辑资料文件. 注意 该资源文件中要包括 Hibernate Validator 内建的资源. 可以在该org\hibernate\validator\resources 包里面的资源文件基础上修改 ,在打包里面 这样就可以了. 自己打包可能不太方便.你可以把该包里面的文件复制出来.然后放到你自己的项目包下在自己编辑, 该测试中 我是放在 test\resources 包下的.

然后在 资源文件中添加 Serializable = '''''' 这么一行, 样例如下:

#DefaultValidatorMessages.properties (DefaultValidatorMessages_zh.properties 不再列出^_^)

#下面是 Hibernate Validator 内建的国际化消息

validator.assertFalse= assertion failed

validator.assertTrue= assertion failed

validator.future= must be a future date

validator.length= length must be between {min} and {max}

validator.max= must be less than or equal to {value}

validator.min= must be greater than or equal to {value}

validator.notNull= may not be null

validator.past= must be a past date

validator.pattern= must match "{regex}"

validator.range= must be between {min} and {max}

validator.size= size must be between {min} and {max}

#下面是自定义的消息

Serializable= Bean not Serializable  //加上自己定义的国际化消息.

在构造 ClassValidator 时要添上 资源文件 如下:(在测试类中)

ClassValidator<Person> classValidator = new ClassValidator<Person> (Person.class,ResourceBundle.getBundle("test.resources.DefaultValidatorMessages"));//加载资源

这样就可以了 .  当然 你还可以 更改 Hibernate Validator 的消息(不是在上面的资源文件中直接修改 validator.length = ... 等等 ) , 还记得 Validator 注释中有个 message 元素吗? 你以前用的都是默认值,现在你可以该为你自己定义的了. 如:validator.length 我把他改为 "该字符串的长度不符合规定范围范围". 在资源文件中添加一行键值属性对(key定义为 "myMsg")如下:

myMsg=该字符串的长度不符合规定范围范围

并且还要在 @Length 注释中提供message的引用的key 如下 @Length(min = 4,message = "{ myMsg }")

再一次运行测试 ,我们就可以看到上面两条自定义绑定的消息了 .如下:

InvalidValue 的长度是:3 . 验证消息是: Bean 不是 可 Serializable . PropertyPath 是:null .
PropertyName 是: null. Value 是: test.annotation.validator.Person@1bd4722 Bean 是: test.annotation.validator.Person@1bd4722
BeanClass 是:class test.annotation.validator.Person


InvalidValue 的长度是:3 . 验证消息是: 该字符串的长度不符合规定范围范围 . PropertyPath 是:name .
PropertyName 是: name. Value 是: ice Bean 是: test.annotation.validator.Person@1bd4722
BeanClass 是:class test.annotation.validator.Person

怎么样,比你想象的简单吧.

OK 上面我们讨论了 Hibernate Validator 的主要用法: 但是 该框架有什么用呢? ^_^

看到这里其实不用我在多说了 大家都知道怎么用,什么时候用. 作为一篇介绍性文章我还是在此给出一个最常用的例子吧,更好的使用方式大家慢慢挖掘吧.

比如 : 你现在在开发一个人力资源(HR)系统 (其实是我们ERP课程的一个作业 ^_^), 里面要处理大量的数据,尤其是在输入各种资料时 如 登记员工信息. 如果你公司的员工的年龄要求是18 -- 60 那么你所输入的年龄就不能超出这个范围. 你可能会说这很容易啊 , 不用Validator就可以解决啊.这保持数据前验证就可以啦 如if ( e.getAge() > 60 || e.getAge() < 18 ) ........ 给出错误信息 然后提示重新输入不就OK啦 用得着 兴师动众的来个第三方框架吗?

是啊 当就验证这一个属性时, 没有必要啊 ! 但是一个真正的HR 系统,会只有一个属性要验证吗? 恐怕要有N多吧

你要是每一个都那样 写一段验证代码 是不是很烦啊 ,况且也不方便代码重用. 现在考虑一些 Validator 是不是更高效啊,拦截到 约束违例的 属性 就可以直接得到 国际化的消息 可以把该消息显示到一个弹出对话框上 提示更正  !

Validator的用处不只这一种 ,你可以想到如何用呢 ! 欢迎发表你的高见!!

OK 到此 我们的 Hibernate Validator 之旅就要先告一段落了 . 希望这是令你心旷神怡的一次寒冬之旅,

把你学到的应用到你的项目中吧,一定会提高你的生产率的. 相信我 ,没错的  ^_^ !

任何获得Matrix授权的网站，转载请保留以下作者信息和链接：
作者：icess(作者的blog:http://blog.matrix.org.cn/page/icess)
关键字：Hibernate Validator

我在前面一篇文章<Hibernate Annotations 实战-- 从 hbm.xml 到 Annotations>:

中,有很多开发者在谈论中提到,有没有必要从 hbm.xml 往 Annotations 上转移. 那么在这篇文章中我们就来讨论一下 hbm.xml 与 Annotations的优缺点,看看那种情况最适合你.

首先,讨论一下 xml 配置文件的优点, 个人认为主要优点就是当你改变底层配置时 不需要改变和重新编译代码,只需要在xml 中更改就可以了,例如 Hibernate.cfg.xml 当你要更改底层数据库时, 只要更改配置文件就可以了.Hibernate会为你做好别的事情.

那么xml的缺点呢,个人认为有以下几点:

下面我们看看 Annotations的 特性吧! 可以解决xml遇到的问题,有以下优点

这一行, 因为在前面的实验中以及建立了数据库表了 不再需要更新了.如果你是第一次运行该例子 还是要该行的.

Test.java 如下:

/*
 * Created on 2005
 * @author 
 */
package test.hibernate.annotation;

import org.hibernate.Session;
import org.hibernate.Transaction;

public class Test {
  
  public static void main(String [] args) {
    long start = 0;
    long end = 0;
    start = System.currentTimeMillis();  //程序开始时间
    
    Session s = HibernateUtil.currentSession();
    long mid =  System.currentTimeMillis();  //初始化完毕的时间 (可能此时并没有初始化完毕^_^)
    
    Transaction tx = s.beginTransaction();    
    /********************测试读取的代码************************/
    Person p = null;
    for(int i = 1; i <= 100; i ++) {
    p = (Person) s.get(Person.class, i);
    System.out.println(p.getName());
    }
    System.out.println(p.getName());

    /********************测试读取1次的代码************************/
    Person p = null;
    p = (Person) s.get(Person.class, 1);
    System.out.println(p.getName());
    /*********************测试插入的代码*************************************/
    /*
    for (int i = 0; i < 100; i ++) {
      Person p = new Person();
      p.setAge(i+1);
      p.setName("icerain"+i);
      p.setSex("male"+i);
      s.save(p);
      s.flush();
    }
    */
    tx.commit();
    HibernateUtil.closeSession();
    
    end = System.currentTimeMillis(); //测试结束时间
    System.out.println("String[] - start time: " + start);
    System.out.println("String[] - end time: " + end);
    System.out.println("Init time : " + (mid-start)); // 打印初始化用的时间
    System.out.println("Last time is :" +(end - mid) ); //打印 数据操作的时间
    System.out.println("Total time : " +(end - start)); //打印总时间
  }
}

Annotations 包中的Person.java 如下

package test.hibernate.annotation;

import java.util.LinkedList;
import java.util.List;

import javax.persistence.AccessType;
import javax.persistence.Basic;
import javax.persistence.Entity;
import javax.persistence.GeneratorType;
import javax.persistence.Id;
import javax.persistence.Table;
import javax.persistence.Transient;

/**
 * Person generated by hbm2java
 */

@SuppressWarnings("serial")
@Entity(access = AccessType.PROPERTY)
@Table
public class Person implements java.io.Serializable {
  private Integer id;
  private String name;
  private String sex;
  private Integer age;
  private List list = new LinkedList();

  // Constructors
  /** default constructor */
  public Person() {
  }

  /** constructor with id */
  public Person(Integer id) {
    this.id = id;
  }

  // Property accessors
  @Id(generate=GeneratorType.AUTO)
  public Integer getId() {
    return this.id;
  }

  public void setId(Integer id) {
    this.id = id;
  }

  @Basic
  public String getName() {
    return this.name;
  }

  public void setName(String name) {
    this.name = name;
  }

  @Basic
  public String getSex() {
    return this.sex;
  }

  public void setSex(String sex) {
    this.sex = sex;
  }

  @Basic
  public Integer getAge() {
    return this.age;
  }

  public void setAge(Integer age) {
    this.age = age;
  }
  @Transient
  public List getList() {
    return list;
  }
  public void setList(List list) {
    this.list = list;
  }

}

其他的代码几乎没有改变:

下面的每种类型的测试都测试了3次以上, 取中间的测试时间.

测试机器配置:

CPU:  AMD Athlon (xp) 2000+

内存: 784880KB

硬盘: 三星 SP0812N

读取一次  的比较:(单位: 毫秒)

   读取100次的比较:

插入100次的比较:

从上面的三次对比中大家可以看到 初始化的部分几乎两者是一样的, 在数据操作上面 使用xml文件 总是比使用Annotations 慢一点.在我们只操纵一个只有几个属性的小持久化类的操作中就有 几十毫秒的差距. 几十毫秒在计算机中算不算很大 大家应该都知道,我就不在多说了.

总结: 经过 xml 文件 和Annotations 的优缺点和 性能上的对比.现在使用那个作为你持久化映射策略.我相信大家都会正确选择的.

测试后记: 经过多次测试 感觉有时候很不稳定 ,有的时候很稳定不知道是测试有问题还是别的问题.大家可以自己测试一下. 有什么新的发现 请大家讨论讨论.

利用Thread-Specific Storage撰寫一個HibernateUtil

								import java.io.Serializable;

import net.sf.hibernate.HibernateException;
import net.sf.hibernate.Session;
import net.sf.hibernate.SessionFactory;
import net.sf.hibernate.Transaction;

public class HibernateSessionUtil implements Serializable
{
publicstaticfinal ThreadLocal tLocalsess = new ThreadLocal();

publicstaticfinal ThreadLocal tLocaltx = new ThreadLocal();

    /*
     * getting the thread-safe session for using
     */
publicstatic Session currentSession(){
        Session session = (Session) tLocalsess.get();

//open a new one, if none can be found.
try{
if (session == null){
                session = openSession();
                tLocalsess.set(session);
            }
        }catch (HibernateException e){
thrownew InfrastructureException(e);
        }
return session;
    }

    /*
     * closing the thread-safe session
     */
publicstatic void closeSession(){

        Session session = (Session) tLocalsess.get();
        tLocalsess.set(null);
try{
if (session != null && session.isOpen()){
                session.close();
            }

        }catch (HibernateException e){
thrownew InfrastructureException(e);
        }
    }

    /*
     * begin the transaction
     */
publicstatic void beginTransaction(){
        Transaction tx = (Transaction) tLocaltx.get();
try{
if (tx == null){
                tx = currentSession().beginTransaction();
                tLocaltx.set(tx);
            }
        }catch (HibernateException e){
thrownew InfrastructureException(e);
        }
    }

    /*
     * close the transaction
     */
publicstatic void commitTransaction(){
        Transaction tx = (Transaction) tLocaltx.get();
try{
if (tx != null && !tx.wasCommitted() && !tx.wasRolledBack())
                tx.commit();
            tLocaltx.set(null);
        }catch (HibernateException e){
thrownew InfrastructureException(e);
        }
    }

    /*
     * for rollbacking
     */
publicstatic void rollbackTransaction(){
        Transaction tx = (Transaction) tLocaltx.get();
try{
            tLocaltx.set(null);
if (tx != null && !tx.wasCommitted() && !tx.wasRolledBack()){
                tx.rollback();
            }
        }catch (HibernateException e){
thrownew InfrastructureException(e);
        }
    }

privatestatic Session openSession() throws HibernateException{
return getSessionFactory().openSession();
    }

privatestatic SessionFactory getSessionFactory() throws HibernateException{
return SingletonSessionFactory.getInstance();
    }
}

　filter中的程式碼如下

								public class HibernateSessionCloser implements Filter{

protected 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 {
try{
            chain.doFilter(request, response);
        }
finally{
try{
                HibernateSessionUtil.commitTransaction();
            }catch (InfrastructureException e){
                HibernateSessionUtil.rollbackTransaction();
            }finally{
                HibernateSessionUtil.closeSession();
            }   
        }

    }
}

然後在操作資料庫之前加上

HibernateSessionUtil.beginTransaction();
HibernateSessionUtil.currentSession();//取得Session

功能实现分析

这个例子使用了HSQL做数据库，spring的AOP作为基础，使用Acegi做安全控制组件。
联系人管理的web应用在启动时候，会做一系列初始化动作：
1. 读取web.xml文件，

2. 并解析文件里的内容。
a) context-param元素。
i. contextConfigLocation属性。这个属性定义了spring所需要的3个属性文件。它们分别是：applicationContext -acegi-security.xml、applicationContext-common-business.xml、 applicationContext-common-authorization.xml
ii. log4jConfigLocation属性。这个属性定义了log4j配置文件。

b) filter元素。
这里定义了acegi的一个过滤器。Acegi的大部分过滤器都是这样配置的。使用FilterToBeanProxy组件，给它传递一个targetClass属性。这个targetClass必须实现javax.servlet.Filter接口。
这里配置的是FilterChainProxy。这个FilterChainProxy比较好用，可以为它定义一串filter属性。这些filter将会按照定义的顺序被调用。例如，
<bean id="filterChainProxy" class="net.sf.acegisecurity.util.FilterChainProxy">
<property name="filterInvocationDefinitionSource">
<value>
CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
PATTERN_TYPE_APACHE_ANT
/**=httpSessionContextIntegrationFilter,authenticationProcessingFilter,basicProcessingFilter,rememberMeProcessingFilter,anonymousProcessingFilter,securityEnforcementFilter
</value>
</property>
</bean>
这个过滤器的mapping是“/*”。
c) listener元素。
i. ContextLoaderListener。这个是Spring使用来加载根applicationcontext。并分别解析 applicationContext-acegi-security.xml、applicationContext-common- business.xml、applicationContext-common-authorization.xml等配置文件，把相关的对象初始化
iii. Log4jConfigListener。这个是spring用来初始化log4j组件的listener。
iv. HttpSessionEventPublisher。这个组件将发布HttpSessionCreatedEvent和HttpSessionDestroyedEvent事件给spring的applicationcontext。
d) servlet元素。
i. contacts。这里采用了spring的MVC框架， 所以这个servlet是spring MVC的一个核心控制器（org.springframework.web.servlet.DispatcherServlet）。这个servlet 启动时候，会从contacts-servlet.xml里面读取信息，并做相关的初始化。
v. remoting。也是spring MVC的一个核心控制器。与contacts不同，这个servlet主要是提供web services服务。这个servlet启动时候， 会从remoting-servlet.xml里面读取信息，并做相关的初始化。
e) taglib元素。这里定义了spring的标f) 签库。
3. 解析applicationContext-acegi-security.xml。
a) 过滤器链。定义了一个FilterChainProxy，b) 并指c) 定了一系列的过滤器链。httpSessionContextIntegrationFilter, authenticationProcessingFilter,basicProcessingFilter,rememberMeProcessingFilter,anonymousProcessingFilter,securityEnforcementFilter
d) 认证管理器。这个管理器由acegi提供。这个管理器需要一个providers参数。这个providers参数包含了提供系统认证的对象。
i. daoAuthenticationProvider。一般用户认证。
ii. anonymousAuthenticationProvider。匿名用户认证。
iv. rememberMeAuthenticationProvider。记住我认证。

e) 密码加密。这里定义了一个acegi的Md5算法加密对象Md5PasswordEncoder。
f) 定义了一个jdbcDao实现类。这个类由acegi提供的net.sf.acegisecurity.providers.dao.jdbc.JdbcDaoImpl。这个对象需要一个dataSource的参数。
g) 定义daoAuthenticationProvider。这个对象由acegi提供。它有3个属性：
authenticationDao。这里指向前面定义的jdbcDao。
userCache。这里指向后面定义的user缓存对象。
passwordEncoder。这里指向前面定义的密码加密对象。
h) 用户缓存管理。
为了缓存user，这里使用spring的ehcache来缓存user。缓存机制：
i. 定义缓存管理器――CacheManager。这个对象是spring的EhCacheManagerFactoryBean对象
ii. 定义user缓存实际执行对象――UserCacheBackend。这个对象是spring的EhCacheFactoryBean。它有两个属性：
1. cacheManager。这里指向前面定义的缓存管理器。
2. cacheName。
iii. 定义user缓存――UserCache。它是acegi提供的EhCacheBasedUserCache对象。它有一个属性：
1. cache。这里指向的是前面定义的userCacheBackend。

i) 定义接收来自DaoAuthenticationProvider的认证事件的listener――LoggerListener。
j)
4. 解析applicationContext-common-business.xml。
a) dataSource.
这里使用了spring的DriverManagerDataSource对象。这个对象是一个JDBC数据源的定义。
b) TransactionManager。这里使用spring的DataSourceTransactionManager对象。
c) 事务拦截器。这里使用spring的事务拦截器TransactionInterceptor。它有2个属性：
transactionManager。这个属性指向前面定义的TransactionManager。
transactionAttributeSource。这个属性里， 指定了ContactManager的各个方法的事务方面的要求。
d) DataSourcePopulator。
使用sample.contact.DataSourcePopulator对象，往HSQL里创建相关的表结构和数据。
实现原理：DataSourcePopulator 实现了接口 InitializingBean。其中afterPropertiesSet方法将在spring初始化DataSourcePopulator后被调用。
e) ContactDao。这里指向一个ContactDaoSpring对象。它继承spring的 JdbcDaoSupport，g) 并实现ContactDao接口。它是真正实现JDBC操作的对象。
h) ContactManager。这里使用的是spring的ProxyFactoryBean。它有2个属性：
i. ProxyInterfaces。代理接口：sample.contact.ContactManager

ii. InterceptorNames。拦截器名称。可以有多个，iv. 这里包括：transactionInterceptor、contactManagerSecurity、contactManagerTarget。其中，v. transactionInterceptor是前面定义的事务拦截器。ContactManagerSecurity则是在 applicationContext-common-authorization.xml里定义的方法调用授权。
i) ContactManagerTarget。这里指向的是sample.contact.ContactManagerBackend对象。 ContactManagerBackend实现了ContactManager接口和InitializingBean接口。它有2个自定义属性： contactDao和basicAclExtendedDao。这里会调用ACL的API去做些创建权限和删除权限的工作。

这是一个 Acegi 官方的例子。它以联系人的管理为例子，说明如何使用 Acegi 作权限控制。这个例子包含在 acegi 的包里面。下载地址： http://prdownloads.sourceforge.net/acegisecurity/acegi-security-0.8.3.zip?download。

联系人管理说明了下列中心的Acegi安全控制能力:

• Role-based security （基于角色的安全） ――每个责任人都是某个角色的一员。而角色被用来限制对某些安全对象的访问。
• Domain object instance security （域对象实例安全） ――合同，这个系统里的主要域对象，拥有一个访问控制列表（ ACL ），用来指明谁允许读、管理和删除对象。
• Method invocation security （方法调用安全）―― 这个 ContactManager 服务层对象 包含一些受保护的和公开的方法。
• Web request security （ Web 请求安全） ――这个“ /secure ” URI 路径被使用 Acegi 安全保护，使得没有 ROLE_USER 角色的用户无法访问。 .
• Security unaware application objects （保护未知的应用对象） ――受保护的对象与 Acegi 之间没有明显的耦合或契约，所以它们没有察觉到安全是由 Acegi 提供的。 *
• Security taglib usage （安全标签库使用） ――所有的 JSP 使用 Acegi 安全标签库来封装安全信息。 *
• Fully declarative security( 完全声明式的安全 ) ――每一个安全方面特性都是在 application context 里面使用标准的 Acegi 安全对象来配置的。 *
• Database-sourced security data （支持数据库来源的安全数据） ――所有的用户、角色和 ACL 信息都可以从一个兼容 JDBC 的内存数据库获得。
• Integrated form-based and BASIC authentication （集成基于表单和 BASIC 验证）―― 任何 BASIC 验证头部被检测以及作为验证使用。默认使用基于表单的普通交互式验证。
• Remember-me services （记住我的服务）―― Acegi 安全的插件式的“ remember-me ” 策略被演示。在登录表单里有一个相关的选择框与之对应。

多线程应用程序通常利用生产者-消费者编程方案，其中由生产者线程创建重复性作业，将其传递给作业队列，然后由消费者线程处理作业。虽然这种编程方法很有用，但是它通常导致重复的代码，这对于调试和维护可能是真正的问题。

为了解决这个问题并促进代码重用，我们创建了 Consumer 类。 Consumer 类包含所有用于作业队列和消费者线程的代码，以及使这两者能够结合在一起的逻辑。这使我们可以专注于业务逻辑 ― 关于应该如何处理作业的细节 ― 而不是专注于编写大量冗余的代码。同时，它还使得调试多线程应用程序的任务变得更为容易。

在本文中，我们将简单观察一下多线程应用程序开发中公共线程用法，同时，解释一下生产者-消费者编程方案，并研究一个实际的示例来向您演示 Consumer 类是如何工作的。请注意，对于多线程应用程序开发或消费者-生产者方案，本文不作深入介绍；有关那些主题，请参阅 参考资料获取文章的清单。

多线程基础知识

多线程是一种使应用程序能同时处理多个操作的编程技术。通常有两种不同类型的多线程操作使用多个线程：

• 适时事件，当作业必须在特定的时间或在特定的间隔内调度执行时
  
• 后台处理，当后台事件必须与当前执行流并行处理或执行时

适时事件的示例包括程序提醒、超时事件以及诸如轮询和刷新之类的重复性操作。后台处理的示例包括等待发送的包或等待处理的已接收的消息。

回页首

生产者-消费者关系

生产者-消费者方案很适合于后台处理类别的情况。这些情况通常围绕一个作业“生产者”方和一个作业“消费者”方。当然，关于作业并行执行还有其它考虑事项。在大多数情况下，对于使用同一资源的作业，应以“先来先服务”的方式按顺序处理，这可以通过使用单线程的消费者轻松实现。通过使用这种方法，我们使用单个线程来访问单个资源，而不是用多个线程来访问单个资源。

要启用标准消费者，当作业到来时创建一个作业队列来存储所有作业。生产者线程通过将新对象添加到消费者队列来交付这个要处理的新对象。然后消费者线程从队列取出每个对象，并依次处理。当队列为空时，消费者进入休眠。当新的对象添加到空队列时，消费者会醒来并处理该对象。因为大多数应用程序喜欢顺序处理方式，所以消费者通常是单线程的。

回页首

问题：代码重复

因为生产者-消费者方案很常用，所以在构建应用程序时它可能会出现几次，这导致了代码重复。我们认识到，这显示了在应用程序开发过程期间多次使用了生产者-消费者方案的问题。

当第一次需要生产者-消费者行为时，通过编写一个采用一个线程和一个队列的类来实现该行为。当第二次需要这种行为时，我们着手从头开始实现它，但是接着认识到以前已经做过这件事了。我们复制了代码并修改了处理对象的方式。当第三次在该应用程序中实现生产者-消费者行为时，很明显我们复制了太多代码。我们决定，需要一个适用的 Consumer 类，它将处理我们所有的生产者-消费者方案。

回页首

我们的解决方案：Consumer 类

我们创建 Consumer 类的目的是：在我们的应用程序中，消除这种代码重复 ― 为每个生产者-消费者实例编写一个新作业队列和消费者线程来解决这个问题。有了适当的 Consumer 类，我们所必须做的只是编写专门用于作业处理（业务逻辑）的代码。这使得我们的代码更清晰、更易于维护以及更改起来更灵活。

我们对 Consumer 类有如下需求：

• 重用：我们希望这个类包括所有东西。一个线程、一个队列以及使这两者结合在一起的所有逻辑。这将使我们只须编写队列中“消费”特定作业的代码。（因而，例如，程序员使用 Consumer 类时，将重载 onConsume(ObjectjobToBeConsumed) 方法。）
  
• 队列选项：我们希望能够设置将由 Consumer 对象使用的队列实现。但是，这意味着我们必须确保队列是线程安全的或使用一个不会与消费操作冲突的单线程生产者。无论使用哪种方法，都必须将队列设计成允许不同的进程能访问其方法。
  
• Consumer 线程优先级：我们希望能够设置 Consumer 线程运行的优先级。
  
• Consumer 线程命名：线程拥有一个有意义的名称会比较方便，当然这的确有助于调试。例如，如果您向 Java 虚拟机发送了一个信号，它将生成一个完整的线程转储 ― 所有线程及其相应堆栈跟踪的快照。要在 Windows 平台上生成这个线程转储，您必须在 Java 程序运行的窗口中按下键序列 <ctrl><break> ，或者单击窗口上的“关闭”按钮。有关如何使用完整的线程转储来诊断 Java 软件问题的更多信息，请参阅 参考资料。

回页首

类代码

在 getThread() 方法中，我们使用“惰性创建”来创建 Consumer 的线程，如清单 1 所示：

     /**
       * Lazy creation of the Consumer's thread.
       *
       * @return  the Consumer's thread
       */
      private Thread getThread()
      {
         if (_thread==null)
         {
            _thread = new Thread()
            {
               public void run()
               {
                  Consumer.this.run();
               }
            };
         }
         return _thread;

该线程的 run() 方法运行 Consumer 的 run() 方法，它是主消费者循环，如清单 2 所示：

     /**
       *  Main Consumer's thread method.
       */
      private void run()
      {
         while (!_isTerminated)
         {
            // job handling loop
      while (true)
            {
               Object o;
               synchronized (_queue)
               {
                  if (_queue.isEmpty())
          break;
                  o = _queue.remove();
               }
               if (o == null)
          break;
               onConsume(o);
            }

            // if we are not terminated and the queue is still empty
            // then wait until new jobs arrive.

            synchronized(_waitForJobsMonitor)
            {
               if (_isTerminated)
          break;
               if(_queue.isEmpty())
               {
        try
                  {
                     _waitForJobsMonitor.wait();
                  }
                  catch (InterruptedException ex)
                  {
                  }
               }
            }
         }
}// run()

基本上， Consumer 的线程一直运行，直到队列中不再有等待的作业为止。然后它进入休眠，只在第一次调用 add(Object) 时醒来，该方法向队列添加一个新作业并“踢”醒该线程。

使用 wait() 和 notify() 机制来完成“睡眠”和“踢”。实际的消费者工作由 OnConsume(Object) 方法处理，如清单 3 所示：

     /**
      * Add an object to the Consumer.
      * This is the entry point for the producer.
      * After the item is added, the Consumer's thread
      * will be notified.
      *
      * @param  the object to be 'consumed' by this consumer
      */
      public void add(Object o)
      {
         _queue.add(o);
         kickThread();
      }

      /**
       * Wake up the thread (without adding new stuff to consume)
       *
       */
      public void kickThread()
      {
         if (!this._thread.isInterrupted())
         {
            synchronized(_waitForJobsMonitor)
            {
               _waitForJobsMonitor.notify();
            }
         }
      }

回页首

示例：MessagesProcessor

为了向您展示 Consumer 类是如何工作的，我们将使用一个简单示例。 MessagesProcessor 类以异步方式处理进入的消息（也就是说，不干扰调用线程）。其工作是在每个消息到来时打印它。 MessagesProcessor 具有一个处理到来的消息作业的内部 Consumer 。当新作业进入空队列时， Consumer 调用 processMessage(String) 方法来处理它，如清单 4 所示：

      class MessagesProcessor
      {
         String _name;
         // anonymous inner class that supplies the consumer
         // capabilities for the MessagesProcessor
         private Consumer _consumer = new Consumer()
         {
            // that method is called on each event retrieved
            protected void onConsume(Object o)
            {
               if (!(o instanceof String))
               {
                  System.out.println("illegal use, ignoring");
                  return;
               }
               MessagesProcesser.this.processMessage((String)o);
            }
         }.setName("MessagesProcessor").init();

         public void gotMessageEvent(String s)
         {
            _consumer.add(s);
         }
         private void processMessage(String s)
         {
            System.out.println(_name+" processed message: "+s);
         }

         private void terminate()
         {
           _consumer.terminateWait();
           _name = null;
         }

         MessagesProcessor()
         {
            _name = "Example Consumer";
         }
      }

正如您可以从上面的代码中所看到的，定制 Consumer 相当简单。我们使用了一个匿名内部类来继承 Consumer 类，并重载抽象方法 onConsume() 。因此，在我们的示例中，只需调用 processMessage 。

回页首

Consumer 类的高级特性

除了开始时提出的基本需求以外，我们还为 Consumer 类提供了一些我们觉得有用的高级特性。

事件通知

• onThreadTerminate()：只在终止 Consumer 前调用该方法。我们出于调试目的覆盖了这个方法。
  
• goingToRest()：只在 Consumer 线程进入休眠前调用该方法（也就是说，只在调用 _waitForJobsMonitor.wait() 之前调用）。只在需要消费者在进入休眠之前处理一批已处理工作的复杂情况中，可能需要这种通知。

终止

• terminate()：Consumer 线程的异步终止。
  
• terminateWait()：设置调用线程一直等待，直到消费者线程实际终止为止。

在我们的示例中，如果使用 terminate() 而不是 terminateWait() ，那么将会出现问题，因为在将 _name 设置成空值之后调用 onConsume() 方法。这将导致执行 processMessage 的线程抛出一个 NullPointerException 。

回页首

结束语：Consumer 类的好处

可在 参考资料一节下载 Consumer 类的源代码。请自由使用源代码，并按照您的需要扩展它。我们发现将这个类用于多线程应用程序开发有许多好处：

• 代码重用／重复代码的消除：如果您有 Consumer 类，就不必为您应用程序中的每个实例编写一个新的消费者。如果在应用程序开发中频繁使用生产者-消费者方案，这可以很大程度地节省时间。另外，请牢记重复代码是滋生错误的沃土。它还使基本代码的维护更为困难。
  
• 更少错误：使用验证过的代码是一种防止错误的好实践，尤其是处理多线程应用程序时。因为 Consumer 类已经被调试过，所以它更安全。消费者还通过在线程和资源之间担任安全中介来防止与线程相关的错误。消费者可以代表其它线程以顺序的方式访问资源。
  
• 漂亮、清晰的代码：使用 Consumer 类有助于我们编写出更简单的代码，这样的代码更容易理解和维护。如果我们不使用 Consumer 类，就必须编写代码来处理两种不同的功能：消费逻辑（队列和线程管理、同步等）和指定消费者的用法或功能的代码。

虽然用 Java™ 语言编写的程序在理论上是不会出现“内存泄漏”的，但是有时对象在不再作为程序的逻辑状态的一部分之后仍然不被垃圾收集。本月，负责保障应用程序健康的工程师 Brian Goetz 探讨了无意识的对象保留的常见原因，并展示了如何用弱引用堵住泄漏。

要让垃圾收集（GC）回收程序不再使用的对象，对象的逻辑 生命周期（应用程序使用它的时间）和对该对象拥有的引用的实际 生命周期必须是相同的。在大多数时候，好的软件工程技术保证这是自动实现的，不用我们对对象生命周期问题花费过多心思。但是偶尔我们会创建一个引用，它在内存中包含对象的时间比我们预期的要长得多，这种情况称为无意识的对象保留（unintentional object retention）。

全局 Map 造成的内存泄漏

无意识对象保留最常见的原因是使用 Map 将元数据与临时对象（transient object）相关联。假定一个对象具有中等生命周期，比分配它的那个方法调用的生命周期长，但是比应用程序的生命周期短，如客户机的套接字连接。需要将一些元数据与这个套接字关联，如生成连接的用户的标识。在创建 Socket 时是不知道这些信息的，并且不能将数据添加到 Socket 对象上，因为不能控制 Socket 类或者它的子类。这时，典型的方法就是在一个全局 Map 中存储这些信息，如清单 1 中的 SocketManager 类所示：

												
														public class SocketManager {
    private Map<Socket,User> m = new HashMap<Socket,User>();
    
    public void setUser(Socket s, User u) {
        m.put(s, u);
    }
    public User getUser(Socket s) {
        return m.get(s);
    }
    public void removeUser(Socket s) {
        m.remove(s);
    }
}

SocketManager socketManager;
...
socketManager.setUser(socket, user);

												
										

这种方法的问题是元数据的生命周期需要与套接字的生命周期挂钩，但是除非准确地知道什么时候程序不再需要这个套接字，并记住从 Map 中删除相应的映射，否则，Socket 和 User 对象将会永远留在 Map 中，远远超过响应了请求和关闭套接字的时间。这会阻止 Socket 和 User 对象被垃圾收集，即使应用程序不会再使用它们。这些对象留下来不受控制，很容易造成程序在长时间运行后内存爆满。除了最简单的情况，在几乎所有情况下找出什么时候 Socket 不再被程序使用是一件很烦人和容易出错的任务，需要人工对内存进行管理。

回页首

找出内存泄漏

程序有内存泄漏的第一个迹象通常是它抛出一个 OutOfMemoryError，或者因为频繁的垃圾收集而表现出糟糕的性能。幸运的是，垃圾收集可以提供能够用来诊断内存泄漏的大量信息。如果以 -verbose:gc 或者 -Xloggc 选项调用 JVM，那么每次 GC 运行时在控制台上或者日志文件中会打印出一个诊断信息，包括它所花费的时间、当前堆使用情况以及恢复了多少内存。记录 GC 使用情况并不具有干扰性，因此如果需要分析内存问题或者调优垃圾收集器，在生产环境中默认启用 GC 日志是值得的。

有工具可以利用 GC 日志输出并以图形方式将它显示出来，JTune 就是这样的一种工具（请参阅 参考资料）。观察 GC 之后堆大小的图，可以看到程序内存使用的趋势。对于大多数程序来说，可以将内存使用分为两部分：baseline 使用和 current load 使用。对于服务器应用程序，baseline 使用就是应用程序在没有任何负荷、但是已经准备好接受请求时的内存使用，current load 使用是在处理请求过程中使用的、但是在请求处理完成后会释放的内存。只要负荷大体上是恒定的，应用程序通常会很快达到一个稳定的内存使用水平。如果在应用程序已经完成了其初始化并且负荷没有增加的情况下，内存使用持续增加，那么程序就可能在处理前面的请求时保留了生成的对象。

清单 2 展示了一个有内存泄漏的程序。MapLeaker 在线程池中处理任务，并在一个 Map 中记录每一项任务的状态。不幸的是，在任务完成后它不会删除那一项，因此状态项和任务对象（以及它们的内部状态）会不断地积累。

												
														public class MapLeaker {
    public ExecutorService exec = Executors.newFixedThreadPool(5);
    public Map<Task, TaskStatus> taskStatus 
        = Collections.synchronizedMap(new HashMap<Task, TaskStatus>());
    private Random random = new Random();

    private enum TaskStatus { NOT_STARTED, STARTED, FINISHED };

    private class Task implements Runnable {
        private int[] numbers = new int[random.nextInt(200)];

        public void run() {
            int[] temp = new int[random.nextInt(10000)];
            taskStatus.put(this, TaskStatus.STARTED);
            doSomeWork();
            taskStatus.put(this, TaskStatus.FINISHED);
        }
    }

    public Task newTask() {
        Task t = new Task();
        taskStatus.put(t, TaskStatus.NOT_STARTED);
        exec.execute(t);
        return t;
    }
}

												
										

图 1 显示 MapLeaker GC 之后应用程序堆大小随着时间的变化图。上升趋势是存在内存泄漏的警示信号。（在真实的应用程序中，坡度不会这么大，但是在收集了足够长时间的 GC 数据后，上升趋势通常会表现得很明显。）

确信有了内存泄漏后，下一步就是找出哪种对象造成了这个问题。所有内存分析器都可以生成按照对象类进行分解的堆快照。有一些很好的商业堆分析工具，但是找出内存泄漏不一定要花钱买这些工具 —— 内置的 hprof 工具也可完成这项工作。要使用 hprof 并让它跟踪内存使用，需要以 -Xrunhprof:heap=sites 选项调用 JVM。

清单 3 显示分解了应用程序内存使用的 hprof 输出的相关部分。（hprof 工具在应用程序退出时，或者用 kill -3 或在 Windows 中按 Ctrl+Break 时生成使用分解。）注意两次快照相比，Map.Entry、Task 和 int[] 对象有了显著增加。

请参阅 清单 3。

清单 4 展示了 hprof 输出的另一部分，给出了 Map.Entry 对象的分配点的调用堆栈信息。这个输出告诉我们哪些调用链生成了 Map.Entry 对象，并带有一些程序分析，找出内存泄漏来源一般来说是相当容易的。

												
														TRACE 300446:
	java.util.HashMap$Entry.<init>(<Unknown Source>:Unknown line)
	java.util.HashMap.addEntry(<Unknown Source>:Unknown line)
	java.util.HashMap.put(<Unknown Source>:Unknown line)
	java.util.Collections$SynchronizedMap.put(<Unknown Source>:Unknown line)
	com.quiotix.dummy.MapLeaker.newTask(MapLeaker.java:48)
	com.quiotix.dummy.MapLeaker.main(MapLeaker.java:64)

												
										

回页首

弱引用来救援了

SocketManager 的问题是 Socket-User 映射的生命周期应当与 Socket 的生命周期相匹配，但是语言没有提供任何容易的方法实施这项规则。这使得程序不得不使用人工内存管理的老技术。幸运的是，从 JDK 1.2 开始，垃圾收集器提供了一种声明这种对象生命周期依赖性的方法，这样垃圾收集器就可以帮助我们防止这种内存泄漏 —— 利用弱引用。

弱引用是对一个对象（称为 referent）的引用的持有者。使用弱引用后，可以维持对 referent 的引用，而不会阻止它被垃圾收集。当垃圾收集器跟踪堆的时候，如果对一个对象的引用只有弱引用，那么这个 referent 就会成为垃圾收集的候选对象，就像没有任何剩余的引用一样，而且所有剩余的弱引用都被清除。（只有弱引用的对象称为弱可及（weakly reachable）。）

WeakReference 的 referent 是在构造时设置的，在没有被清除之前，可以用 get() 获取它的值。如果弱引用被清除了（不管是 referent 已经被垃圾收集了，还是有人调用了 WeakReference.clear()），get() 会返回 null。相应地，在使用其结果之前，应当总是检查 get() 是否返回一个非 null 值，因为 referent 最终总是会被垃圾收集的。

用一个普通的（强）引用拷贝一个对象引用时，限制 referent 的生命周期至少与被拷贝的引用的生命周期一样长。如果不小心，那么它可能就与程序的生命周期一样 —— 如果将一个对象放入一个全局集合中的话。另一方面，在创建对一个对象的弱引用时，完全没有扩展 referent 的生命周期，只是在对象仍然存活的时候，保持另一种到达它的方法。

弱引用对于构造弱集合最有用，如那些在应用程序的其余部分使用对象期间存储关于这些对象的元数据的集合 —— 这就是 SocketManager 类所要做的工作。因为这是弱引用最常见的用法，WeakHashMap 也被添加到 JDK 1.2 的类库中，它对键（而不是对值）使用弱引用。如果在一个普通 HashMap 中用一个对象作为键，那么这个对象在映射从 Map 中删除之前不能被回收，WeakHashMap 使您可以用一个对象作为 Map 键，同时不会阻止这个对象被垃圾收集。清单 5 给出了 WeakHashMap 的 get() 方法的一种可能实现，它展示了弱引用的使用：

												
														public class WeakHashMap<K,V> implements Map<K,V> {

    private static class Entry<K,V> extends WeakReference<K> 
      implements Map.Entry<K,V> {
        private V value;
        private final int hash;
        private Entry<K,V> next;
        ...
    }

    public V get(Object key) {
        int hash = getHash(key);
        Entry<K,V> e = getChain(hash);
        while (e != null) {
            K eKey= e.get();
            if (e.hash == hash && (key == eKey || key.equals(eKey)))
                return e.value;
            e = e.next;
        }
        return null;
    }

												
										

调用 WeakReference.get() 时，它返回一个对 referent 的强引用（如果它仍然存活的话），因此不需要担心映射在 while 循环体中消失，因为强引用会防止它被垃圾收集。WeakHashMap 的实现展示了弱引用的一种常见用法 —— 一些内部对象扩展 WeakReference。其原因在下面一节讨论引用队列时会得到解释。

在向 WeakHashMap 中添加映射时，请记住映射可能会在以后“脱离”，因为键被垃圾收集了。在这种情况下，get() 返回 null，这使得测试 get() 的返回值是否为 null 变得比平时更重要了。

用 WeakHashMap 堵住泄漏

在 SocketManager 中防止泄漏很容易，只要用 WeakHashMap 代替 HashMap 就行了，如清单 6 所示。（如果 SocketManager 需要线程安全，那么可以用 Collections.synchronizedMap() 包装 WeakHashMap）。当映射的生命周期必须与键的生命周期联系在一起时，可以使用这种方法。不过，应当小心不滥用这种技术，大多数时候还是应当使用普通的 HashMap 作为 Map 的实现。

												
														public class SocketManager {
    private Map<Socket,User> m = new WeakHashMap<Socket,User>();
    
    public void setUser(Socket s, User u) {
        m.put(s, u);
    }
    public User getUser(Socket s) {
        return m.get(s);
    }
}

												
										

引用队列

WeakHashMap 用弱引用承载映射键，这使得应用程序不再使用键对象时它们可以被垃圾收集，get() 实现可以根据 WeakReference.get() 是否返回 null 来区分死的映射和活的映射。但是这只是防止 Map 的内存消耗在应用程序的生命周期中不断增加所需要做的工作的一半，还需要做一些工作以便在键对象被收集后从 Map 中删除死项。否则，Map 会充满对应于死键的项。虽然这对于应用程序是不可见的，但是它仍然会造成应用程序耗尽内存，因为即使键被收集了，Map.Entry 和值对象也不会被收集。

可以通过周期性地扫描 Map，对每一个弱引用调用 get()，并在 get() 返回 null 时删除那个映射而消除死映射。但是如果 Map 有许多活的项，那么这种方法的效率很低。如果有一种方法可以在弱引用的 referent 被垃圾收集时发出通知就好了，这就是引用队列 的作用。

引用队列是垃圾收集器向应用程序返回关于对象生命周期的信息的主要方法。弱引用有两个构造函数：一个只取 referent 作为参数，另一个还取引用队列作为参数。如果用关联的引用队列创建弱引用，在 referent 成为 GC 候选对象时，这个引用对象（不是 referent）就在引用清除后加入 到引用队列中。之后，应用程序从引用队列提取引用并了解到它的 referent 已被收集，因此可以进行相应的清理活动，如去掉已不在弱集合中的对象的项。（引用队列提供了与 BlockingQueue 同样的出列模式 —— polled、timed blocking 和 untimed blocking。）

WeakHashMap 有一个名为 expungeStaleEntries() 的私有方法，大多数 Map 操作中会调用它，它去掉引用队列中所有失效的引用，并删除关联的映射。清单 7 展示了 expungeStaleEntries() 的一种可能实现。用于存储键-值映射的 Entry 类型扩展了 WeakReference，因此当 expungeStaleEntries() 要求下一个失效的弱引用时，它得到一个 Entry。用引用队列代替定期扫描内容的方法来清理 Map 更有效，因为清理过程不会触及活的项，只有在有实际加入队列的引用时它才工作。

												
														    private void expungeStaleEntries() {
	Entry<K,V> e;
        while ( (e = (Entry<K,V>) queue.poll()) != null) {
            int hash = e.hash;

            Entry<K,V> prev = getChain(hash);
            Entry<K,V> cur = prev;
            while (cur != null) {
                Entry<K,V> next = cur.next;
                if (cur == e) {
                    if (prev == e)
                        setChain(hash, next);
                    else
                        prev.next = next;
                    break;
                }
                prev = cur;
                cur = next;
            }
        }
    }

												
										

回页首

结束语

弱引用和弱集合是对堆进行管理的强大工具，使得应用程序可以使用更复杂的可及性方案，而不只是由普通（强）引用所提供的“要么全部要么没有”可及性。下个月，我们将分析与弱引用有关的软引用，将分析在使用弱引用和软引用时，垃圾收集器的行为。

许多程序员在其整个开发生涯中都不曾使用定点或浮点数，可能的例外是，偶尔在计时测试或基准测试程序中会用到。Java语言和类库支持两类非整数类型 ― IEEE 754 浮点（ float 和 double ，包装类（wrapper class）为 Float 和 Double ），以及任意精度的小数（ java.math.BigDecimal ）。在本月的 Java 理论和实践中，Brian Goetz 探讨了在 Java 程序中使用非整数类型时一些常碰到的陷阱和“gotcha”。请在本文的 论坛上提出您对本文的想法，以飨笔者和其他读者。（您也可以单击本文顶部或底部的讨论来访问论坛）。

虽然几乎每种处理器和编程语言都支持浮点运算，但大多数程序员很少注意它。这容易理解 ― 我们中大多数很少需要使用非整数类型。除了科学计算和偶尔的计时测试或基准测试程序，其它情况下几乎都用不着它。同样，大多数开发人员也容易忽略 java.math.BigDecimal 所提供的任意精度的小数 ― 大多数应用程序不使用它们。然而，在以整数为主的程序中有时确实会出人意料地需要表示非整型数据。例如，JDBC 使用 BigDecimal 作为 SQL DECIMAL 列的首选互换格式。

IEEE 浮点

Java 语言支持两种基本的浮点类型： float 和 double ，以及与它们对应的包装类 Float 和 Double 。它们都依据 IEEE 754 标准，该标准为 32 位浮点和 64 位双精度浮点二进制小数定义了二进制标准。

IEEE 754 用科学记数法以底数为 2 的小数来表示浮点数。IEEE 浮点数用 1 位表示数字的符号，用 8 位来表示指数，用 23 位来表示尾数，即小数部分。作为有符号整数的指数可以有正负之分。小数部分用二进制（底数 2）小数来表示，这意味着最高位对应着值 ?(2 ^-1)，第二位对应着 ?(2 ^-2)，依此类推。对于双精度浮点数，用 11 位表示指数，52 位表示尾数。IEEE 浮点值的格式如图 1 所示。

因为用科学记数法可以有多种方式来表示给定数字，所以要规范化浮点数，以便用底数为 2 并且小数点左边为 1 的小数来表示，按照需要调节指数就可以得到所需的数字。所以，例如，数 1.25 可以表示为尾数为 1.01，指数为 0： (-1) 0*1.01 2*2 0

数 10.0 可以表示为尾数为 1.01，指数为 3： (-1) 0*1.01 2*2 3

特殊数字

除了编码所允许的值的标准范围（对于 float ，从 1.4e-45 到 3.4028235e+38），还有一些表示无穷大、负无穷大、 -0 和 NaN（它代表“不是一个数字”）的特殊值。这些值的存在是为了在出现错误条件（譬如算术溢出，给负数开平方根，除以 0 等）下，可以用浮点值集合中的数字来表示所产生的结果。

这些特殊的数字有一些不寻常的特征。例如， 0 和 -0 是不同值，但在比较它们是否相等时，被认为是相等的。用一个非零数去除以无穷大的数，结果等于 0 。特殊数字 NaN 是无序的；使用 == 、 < 和 > 运算符将 NaN 与其它浮点值比较时，结果为 false 。如果 f 为 NaN，则即使 (f == f) 也会得到 false 。如果想将浮点值与 NaN 进行比较，则使用 Float.isNaN() 方法。表 1 显示了无穷大和 NaN 的一些属性。

表 1. 特殊浮点值的属性

基本浮点类型和包装类浮点有不同的比较行为

使事情更糟的是，在基本 float 类型和包装类 Float 之间，用于比较 NaN 和 -0 的规则是不同的。对于 float 值，比较两个 NaN 值是否相等将会得到 false ，而使用 Float.equals() 来比较两个 NaN Float 对象会得到 true 。造成这种现象的原因是，如果不这样的话，就不可能将 NaN Float 对象用作 HashMap 中的键。类似的，虽然 0 和 -0 在表示为浮点值时，被认为是相等的，但使用 Float.compareTo() 来比较作为 Float 对象的 0 和 -0 时，会显示 -0 小于 0 。

回页首

浮点中的危险

由于无穷大、NaN 和 0 的特殊行为，当应用浮点数时，可能看似无害的转换和优化实际上是不正确的。例如，虽然好象 0.0-f 很明显等于 -f ，但当 f 为 0 时，这是不正确的。还有其它类似的 gotcha，表 2 显示了其中一些 gotcha。

表 2. 无效的浮点假定

舍入误差

浮点运算很少是精确的。虽然一些数字（譬如 0.5 ）可以精确地表示为二进制（底数 2）小数（因为 0.5 等于 2 ^-1），但其它一些数字（譬如 0.1 ）就不能精确的表示。因此，浮点运算可能导致舍入误差，产生的结果接近 ― 但不等于 ― 您可能希望的结果。例如，下面这个简单的计算将得到 2.600000000000001 ，而不是 2.6 ：

												
														 double s=0;
  for (int i=0; i<26; i++)
    s += 0.1;
  System.out.println(s);

												
										

类似的， .1*26 相乘所产生的结果不等于 .1 自身加 26 次所得到的结果。当将浮点数强制转换成整数时，产生的舍入误差甚至更严重，因为强制转换成整数类型会舍弃非整数部分，甚至对于那些“看上去似乎”应该得到整数值的计算，也存在此类问题。例如，下面这些语句：

												
														 double d = 29.0 * 0.01;
  System.out.println(d);
  System.out.println((int) (d * 100));

												
										

将得到以下输出：

												
														 0.29
  28

												
										

这可能不是您起初所期望的。

回页首

浮点数比较指南

由于存在 NaN 的不寻常比较行为和在几乎所有浮点计算中都不可避免地会出现舍入误差，解释浮点值的比较运算符的结果比较麻烦。

最好完全避免使用浮点数比较。当然，这并不总是可能的，但您应该意识到要限制浮点数比较。如果必须比较浮点数来看它们是否相等，则应该将它们差的绝对值同一些预先选定的小正数进行比较，这样您所做的就是测试它们是否“足够接近”。（如果不知道基本的计算范围，可以使用测试“abs(a/b - 1) < epsilon”，这种方法比简单地比较两者之差要更准确）。甚至测试看一个值是比零大还是比零小也存在危险 ―“以为”会生成比零略大值的计算事实上可能由于积累的舍入误差会生成略微比零小的数字。

NaN 的无序性质使得在比较浮点数时更容易发生错误。当比较浮点数时，围绕无穷大和 NaN 问题，一种避免 gotcha 的经验法则是显式地测试值的有效性，而不是试图排除无效值。在清单 1 中，有两个可能的用于特性的 setter 的实现，该特性只能接受非负数值。第一个实现会接受 NaN，第二个不会。第二种形式比较好，因为它显式地检测了您认为有效的值的范围。

												
														   // Trying to test by exclusion -- this doesn't catch NaN or infinity
    public void setFoo(float foo) {
      if (foo < 0)
          throw new IllegalArgumentException(Float.toString(f));
        this.foo = foo;
    }
    // Testing by inclusion -- this does catch NaN
    public void setFoo(float foo) {
      if (foo >= 0 && foo < Float.INFINITY)
        this.foo = foo;
  else
        throw new IllegalArgumentException(Float.toString(f));
    }

												
										

不要用浮点值表示精确值

一些非整数值（如几美元和几美分这样的小数）需要很精确。浮点数不是精确值，所以使用它们会导致舍入误差。因此，使用浮点数来试图表示象货币量这样的精确数量不是一个好的想法。使用浮点数来进行美元和美分计算会得到灾难性的后果。浮点数最好用来表示象测量值这类数值，这类值从一开始就不怎么精确。

回页首

用于较小数的 BigDecimal

从 JDK 1.3 起，Java 开发人员就有了另一种数值表示法来表示非整数： BigDecimal 。 BigDecimal 是标准的类，在编译器中不需要特殊支持，它可以表示任意精度的小数，并对它们进行计算。在内部，可以用任意精度任何范围的值和一个换算因子来表示 BigDecimal ，换算因子表示左移小数点多少位，从而得到所期望范围内的值。因此，用 BigDecimal 表示的数的形式为 unscaledValue*10 -scale。

用于加、减、乘和除的方法给 BigDecimal 值提供了算术运算。由于 BigDecimal 对象是不可变的，这些方法中的每一个都会产生新的 BigDecimal 对象。因此，因为创建对象的开销， BigDecimal 不适合于大量的数学计算，但设计它的目的是用来精确地表示小数。如果您正在寻找一种能精确表示如货币量这样的数值，则 BigDecimal 可以很好地胜任该任务。

所有的 equals 方法都不能真正测试相等

如浮点类型一样， BigDecimal 也有一些令人奇怪的行为。尤其在使用 equals() 方法来检测数值之间是否相等时要小心。 equals() 方法认为，两个表示同一个数但换算值不同（例如， 100.00 和 100.000 ）的 BigDecimal 值是不相等的。然而， compareTo() 方法会认为这两个数是相等的，所以在从数值上比较两个 BigDecimal 值时，应该使用 compareTo() 而不是 equals() 。

另外还有一些情形，任意精度的小数运算仍不能表示精确结果。例如， 1 除以 9 会产生无限循环的小数 .111111... 。出于这个原因，在进行除法运算时， BigDecimal 可以让您显式地控制舍入。 movePointLeft() 方法支持 10 的幂次方的精确除法。

使用 BigDecimal 作为互换类型

SQL-92 包括 DECIMAL 数据类型，它是用于表示定点小数的精确数字类型，它可以对小数进行基本的算术运算。一些 SQL 语言喜欢称此类型为 NUMERIC 类型，其它一些 SQL 语言则引入了 MONEY 数据类型，MONEY 数据类型被定义为小数点右侧带有两位的小数。

如果希望将数字存储到数据库中的 DECIMAL 字段，或从 DECIMAL 字段检索值，则如何确保精确地转换该数字？您可能不希望使用由 JDBC PreparedStatement 和 ResultSet 类所提供的 setFloat() 和 getFloat() 方法，因为浮点数与小数之间的转换可能会丧失精确性。相反，请使用 PreparedStatement 和 ResultSet 的 setBigDecimal() 及 getBigDecimal() 方法。

对于 BigDecimal ，有几个可用的构造函数。其中一个构造函数以双精度浮点数作为输入，另一个以整数和换算因子作为输入，还有一个以小数的 String 表示作为输入。要小心使用 BigDecimal(double) 构造函数，因为如果不了解它，会在计算过程中产生舍入误差。请使用基于整数或 String 的构造函数。

构造 BigDecimal 数

对于 BigDecimal ，有几个可用的构造函数。其中一个构造函数以双精度浮点数作为输入，另一个以整数和换算因子作为输入，还有一个以小数的 String 表示作为输入。要小心使用 BigDecimal(double) 构造函数，因为如果不了解它，会在计算过程中产生舍入误差。请使用基于整数或 String 的构造函数。

如果使用 BigDecimal(double) 构造函数不恰当，在传递给 JDBC setBigDecimal() 方法时，会造成似乎很奇怪的 JDBC 驱动程序中的异常。例如，考虑以下 JDBC 代码，该代码希望将数字 0.01 存储到小数字段：

												
														 PreparedStatement ps =
    connection.prepareStatement("INSERT INTO Foo SET name=?, value=?");
  ps.setString(1, "penny");
  ps.setBigDecimal(2, new BigDecimal(0.01));
  ps.executeUpdate();

												
										

在执行这段似乎无害的代码时会抛出一些令人迷惑不解的异常（这取决于具体的 JDBC 驱动程序），因为 0.01 的双精度近似值会导致大的换算值，这可能会使 JDBC 驱动程序或数据库感到迷惑。JDBC 驱动程序会产生异常，但可能不会说明代码实际上错在哪里，除非意识到二进制浮点数的局限性。相反，使用 BigDecimal("0.01") 或 BigDecimal(1, 2) 构造 BigDecimal 来避免这类问题，因为这两种方法都可以精确地表示小数。

回页首

结束语

在 Java 程序中使用浮点数和小数充满着陷阱。浮点数和小数不象整数一样“循规蹈矩”，不能假定浮点计算一定产生整型或精确的结果，虽然它们的确“应该”那样做。最好将浮点运算保留用作计算本来就不精确的数值，譬如测量。如果需要表示定点数（譬如，几美元和几美分），则使用 BigDecimal 。

不变对象具有许多能更方便地使用它们的特性，包括不严格的同步需求和不必考虑数据讹误就能自由地共享和高速缓存对象引用。尽管不变性可能未必对于所有类都有意义，但大多数程序中至少有一些类将受益于不可变。在本月的 Java 理论与实践中，Brian Goetz 说明了不变性的一些长处和构造不变类的一些准则。请在附带的 论坛中与作者和其他读者分享您关于本文的心得。（也可以单击文章顶部或底部的“讨论”来访问论坛。）

不变对象是指在实例化后其外部可见状态无法更改的对象。Java 类库中的 String 、 Integer 和 BigDecimal 类就是不变对象的示例 ― 它们表示在对象的生命期内无法更改的单个值。

不变性的长处

如果正确使用不变类，它们会极大地简化编程。因为它们只能处于一种状态，所以只要正确构造了它们，就决不会陷入不一致的状态。您不必复制或克隆不变对象，就能自由地共享和高速缓存对它们的引用；您可以高速缓存它们的字段或其方法的结果，而不用担心值会不会变成失效的或与对象的其它状态不一致。不变类通常产生最好的映射键。而且，它们本来就是线程安全的，所以不必在线程间同步对它们的访问。

自由高速缓存

因为不变对象的值没有更改的危险，所以可以自由地高速缓存对它们的引用，而且可以肯定以后的引用仍将引用同一个值。同样地，因为它们的特性无法更改，所以您可以高速缓存它们的字段和其方法的结果。

如果对象是可变的，就必须在存储对其的引用时引起注意。请考虑清单 1 中的代码，其中排列了两个由调度程序执行的任务。目的是：现在启动第一个任务，而在某一天启动第二个任务。

												
														 Date d = new Date();
  Scheduler.scheduleTask(task1, d);
  d.setTime(d.getTime() + ONE_DAY);
  scheduler.scheduleTask(task2, d);

												
										

因为 Date 是可变的，所以 scheduleTask 方法必须小心地用防范措施将日期参数复制（可能通过 clone() ）到它的内部数据结构中。不然， task1 和 task2 可能都在明天执行，这可不是所期望的。更糟的是，任务调度程序所用的内部数据结构会变成讹误。在编写象 scheduleTask() 这样的方法时，极其容易忘记用防范措施复制日期参数。如果忘记这样做，您就制造了一个难以捕捉的错误，这个错误不会马上显现出来，而且当它暴露时人们要花较长的时间才会捕捉到。不变的 Date 类不可能发生这类错误。

固有的线程安全

大多数的线程安全问题发生在当多个线程正在试图并发地修改一个对象的状态（写-写冲突）时，或当一个线程正试图访问一个对象的状态，而另一个线程正在修改它（读-写冲突）时。要防止这样的冲突，必须同步对共享对象的访问，以便在对象处于不一致状态时其它线程不能访问它们。正确地做到这一点会很难，需要大量文档来确保正确地扩展程序，还可能对性能产生不利后果。只要正确构造了不变对象（这意味着不让对象引用从构造函数中转义），就使它们免除了同步访问的要求，因为无法更改它们的状态，从而就不可能存在写-写冲突或读-写冲突。

不用同步就能自由地在线程间共享对不变对象的引用，可以极大地简化编写并发程序的过程，并减少程序可能存在的潜在并发错误的数量。

在恶意运行的代码面前是安全的

把对象当作参数的方法不应变更那些对象的状态，除非文档明确说明可以这样做，或者实际上这些方法具有该对象的所有权。当我们将一个对象传递给普通方法时，通常不希望对象返回时已被更改。但是，使用可变对象时，完全会是这样的。如果将 java.awt.Point 传递给诸如 Component.setLocation() 的方法，根本不会阻止 setLocation 修改我们传入的 Point 的位置，也不会阻止 setLocation 存储对该点的引用并稍后在另一个方法中更改它。（当然， Component 不这样做，因为它不鲁莽，但是并不是所有类都那么客气。）现在， Point 的状态已在我们不知道的情况下更改了，其结果具有潜在危险 ― 当点实际上在另一个位置时，我们仍认为它在原来的位置。然而，如果 Point 是不变的，那么这种恶意的代码就不能以如此令人混乱而危险的方法修改我们的程序状态了。

良好的键

不变对象产生最好的 HashMap 或 HashSet 键。有些可变对象根据其状态会更改它们的 hashCode() 值（如清单 2 中的 StringHolder 示例类）。如果使用这种可变对象作为 HashSet 键，然后对象更改了其状态，那么就会对 HashSet 实现引起混乱 ― 如果枚举集合，该对象仍将出现，但如果用 contains() 查询集合，它就可能不出现。无需多说，这会引起某些混乱的行为。说明这一情况的清单 2 中的代码将打印“false”、“1”和“moo”。

												
														   public class StringHolder {
        private String string;
        public StringHolder(String s) {
            this.string = s;
        }
        public String getString() {
            return string;
        }
        public void setString(String string) {
            this.string = string;
        }
        public boolean equals(Object o) {
            if (this == o)
                return true;
            else if (o == null || !(o instanceof StringHolder))
                return false;
            else {
                final StringHolder other = (StringHolder) o;
                if (string == null)
                    return (other.string == null);
                else
                    return string.equals(other.string);
            }
        }
        public int hashCode() {
            return (string != null ? string.hashCode() : 0);
        }
        public String toString() {
            return string;
        }
        ...
        StringHolder sh = new StringHolder("blert");
        HashSet h = new HashSet();
        h.add(sh);
        sh.setString("moo");
        System.out.println(h.contains(sh));
        System.out.println(h.size());
        System.out.println(h.iterator().next());
    }

												
										

回页首

何时使用不变类

不变类最适合表示抽象数据类型（如数字、枚举类型或颜色）的值。Java 类库中的基本数字类（如 Integer 、 Long 和 Float ）都是不变的，其它标准数字类型（如 BigInteger 和 BigDecimal ）也是不变的。表示复数或精度任意的有理数的类将比较适合于不变性。甚至包含许多离散值的抽象类型（如向量或矩阵）也很适合实现为不变类，这取决于您的应用程序。

Flyweight 模式 不变性启用了 Flyweight 模式，该模式利用共享使得用对象有效地表示大量细颗粒度的对象变得容易。例如，您可能希望用一个对象来表示字处理文档中的每个字符或图像中的每个像素，但这一策略的幼稚实现将会对内存使用和内存管理开销产生高得惊人的花费。Flyweight 模式采用工厂方法来分配对不变的细颗粒度对象的引用，并通过仅使一个对象实例与字母“a”对应来利用共享缩减对象数。有关 Flyweight 模式的更多信息，请参阅经典书籍 Design Patterns（Gamma 等著；请参阅 参考资料）。

Java 类库中不变性的另一个不错的示例是 java.awt.Color 。在某些颜色表示法（如 RGB、HSB 或 CMYK）中，颜色通常表示为一组有序的数字值，但把一种颜色当作颜色空间中的一个特异值，而不是一组有序的独立可寻址的值更有意义，因此将 Color 作为不变类实现是有道理的。

如果要表示的对象是多个基本值的容器（如：点、向量、矩阵或 RGB 颜色），是用可变对象还是用不变对象表示？答案是……要看情况而定。要如何使用它们？它们主要用来表示多维值（如像素的颜色），还是仅仅用作其它对象的一组相关特性集合（如窗口的高度和宽度）的容器？这些特性多久更改一次？如果更改它们，那么各个组件值在应用程序中是否有其自己的含义呢？

事件是另一个适合用不变类实现的好示例。事件的生命期较短，而且常常会在创建它们的线程以外的线程中消耗，所以使它们成为不变的是利大于弊。大多数 AWT 事件类都没有作为严格的不变类来实现，而是可以有小小的修改。同样地，在使用一定形式的消息传递以在组件间通信的系统中，使消息对象成为不变的或许是明智的。

回页首

编写不变类的准则

编写不变类很容易。如果以下几点都为真，那么类就是不变的：

• 它的所有字段都是 final
• 该类声明为 final
• 不允许 this 引用在构造期间转义
• 任何包含对可变对象（如数组、集合或类似 Date 的可变类）引用的字段：
  • 是私有的
  • 从不被返回，也不以其它方式公开给调用程序
  • 是对它们所引用对象的唯一引用
  • 构造后不会更改被引用对象的状态

最后一组要求似乎挺复杂的，但其基本上意味着如果要存储对数组或其它可变对象的引用，就必须确保您的类对该可变对象拥有独占访问权（因为不然的话，其它类能够更改其状态），而且在构造后您不修改其状态。为允许不变对象存储对数组的引用，这种复杂性是必要的，因为 Java 语言没有办法强制不对 final 数组的元素进行修改。注：如果从传递给构造函数的参数中初始化数组引用或其它可变字段，您必须用防范措施将调用程序提供的参数或您无法确保具有独占访问权的其它信息复制到数组。否则，调用程序会在调用构造函数之后，修改数组的状态。清单 3 显示了编写一个存储调用程序提供的数组的不变对象的构造函数的正确方法（和错误方法）。

												
														class ImmutableArrayHolder {
  private final int[] theArray;
  // Right way to write a constructor -- copy the array
  public ImmutableArrayHolder(int[] anArray) {
    this.theArray = (int[]) anArray.clone();
  }
  // Wrong way to write a constructor -- copy the reference
  // The caller could change the array after the call to the constructor
  public ImmutableArrayHolder(int[] anArray) {
    this.theArray = anArray;
  }
  // Right way to write an accessor -- don't expose the array reference
  public int getArrayLength() { return theArray.length }
  public int getArray(int n)  { return theArray[n]; }
  // Right way to write an accessor -- use clone()
  public int[] getArray()       { return (int[]) theArray.clone(); }
  // Wrong way to write an accessor -- expose the array reference
  // A caller could get the array reference and then change the contents
  public int[] getArray()       { return theArray }
}

												
										

通过一些其它工作，可以编写使用一些非 final 字段的不变类（例如， String 的标准实现使用 hashCode 值的惰性计算），这样可能比严格的 final 类执行得更好。如果类表示抽象类型（如数字类型或颜色）的值，那么您还会想实现 hashCode() 和 equals() 方法，这样对象将作为 HashMap 或 HashSet 中的一个键工作良好。要保持线程安全，不允许 this 引用从构造函数中转义是很重要的。

回页首

偶尔更改的数据

有些数据项在程序生命期中一直保持常量，而有些会频繁更改。常量数据显然符合不变性，而状态复杂且频繁更改的对象通常不适合用不变类来实现。那么有时会更改，但更改又不太频繁的数据呢？有什么方法能让 有时更改的数据获得不变性的便利和线程安全的长处呢？

util.concurrent 包中的 CopyOnWriteArrayList 类是如何既利用不变性的能力，又仍允许偶尔修改的一个良好示例。它最适合于支持事件监听程序的类（如用户界面组件）使用。虽然事件监听程序的列表可以更改，但通常它更改的频繁性要比事件的生成少得多。

除了在修改列表时， CopyOnWriteArrayList 并不变更基本数组，而是创建新数组且废弃旧数组之外，它的行为与 ArrayList 类非常相似。这意味着当调用程序获得迭代器（迭代器在内部保存对基本数组的引用）时，迭代器引用的数组实际上是不变的，从而可以无需同步或冒并发修改的风险进行遍历。这消除了在遍历前克隆列表或在遍历期间对列表进行同步的需要，这两个操作都很麻烦、易于出错，而且完全使性能恶化。如果遍历比插入或除去更加频繁（这在某些情况下是常有的事）， CopyOnWriteArrayList 会提供更佳的性能和更方便的访问。

回页首

结束语

使用不变对象比使用可变对象要容易得多。它们只能处于一种状态，所以始终是一致的，它们本来就是线程安全的，可以被自由地共享。使用不变对象可以彻底消除许多容易发生但难以检测的编程错误，如无法在线程间同步访问或在存储对数组或对象的引用前无法克隆该数组或对象。在编写类时，问问自己这个类是否可以作为不变类有效地实现，总是值得的。您可能会对回答常常是肯定的而感到吃惊。

JDBC java.sql.PreparedStatement接口的简单扩展可以使查询记录更少犯错，同时整理您的代码。在本文中，IBM电子商务顾问Jens Wyke向您介绍如何应用基本的封装技术(“通过封装来实现扩展”也称为Decorator设计模式)来获得最满意的结果。

在大多数情况下，JDBC PreparedStatements 使执行数据库查询更简便并可以显著提升您整体应用程序的性能。当谈到日志查询语句时 PreparedStatement 接口就显得有些不足了。 PreparedStatement 的优势在于其可变性，但是一个好的日志条目必须正确描述如何将SQL发送到数据库，它将密切关注用实际的参数值来替换所有参数占位符。虽然有多种方法可以解决这一难题，但没有任何一种易于大规模实施并且大部分将扰乱您的程序代码。

在本文中，您将了解到如何扩展JDBC PreparedStatement 接口来进行查询日志。 LoggableStatement 类实现 PreparedStatement 接口，但添加用于获得查询字符串的方法，使用一种适用于记录的格式。使用 LoggableStatement 类可以减少日志代码中发生错误的几率，生成简单且易于管理的代码。

注意：本文假设您有丰富的JDBC和 PreparedStatement 类经验。

典型日志解决方案

表1介绍了数据库查询时通常是如何使用 PreparedStatement (虽然忽略了初始化和错误处理)。在本文中，我们将使用SQL query SELECT 做为例子，但讨论使用其它类型的SQL语句，如 DELETE 、 UPDATE 和 INSERT 。

												
														String sql = "select foo, bar from foobar where foo < ? and bar = ?";
    String fooValue = new Long(99);
    String barValue = "christmas";

    Connection conn = dataSource.getConnection();
    PreparedStatement pstmt = conn.prepareStatement(sql);

    pstmt.setLong(1,fooValue);
    pstmt.setString(2,barValue);

    ResultSet rs = pstmt.executeQuery();

    // parse result...


												
										

表1中一个好的查询日志条目看起来应与下面有几分类似：

												
														Executing query: select foo,bar from foobar where foo < 99 and 
bar='christmas'

												
										

下面是查询的日志代码的一个例子。注意：表1中的问号已经被每个参数的值替换。

												
														System.out.println("Executing query: select foo, bar from foobar where foo
< "+fooValue+" and bar = '+barValue+"'")

												
										

一种更好的方法是创建方法，我们称之为 replaceFirstQuestionMark ，它读取查询字符串并用参数值替换问号，如表2所示。这类方法的使用无需创建复制的字符串来描述SQL语句。

												
														      // listing 1 goes here

     sql = replaceFirstQuestionMark(sql, fooValue);
     sql = replaceFirstQuestionMark(sql, barValue);
     System.out.println("Executing query: "+sql);

												
										

虽然这些解决方案都易于实施，但没有一种是完美的。问题是在更改SQL模板的同时也必须更改日志代码。您将在某一点上犯错几乎是不可避免的。查询将更改但您忘记了更新日志代码，您将结束与将发送到数据库的查询不匹配的日志条目 -- 调试恶梦。

我们真正需要的是一种使我们能够一次性使用每个参数变量(在我们的实例中为 fooValue 和 barValue )的设计方案。我们希望有一种方法，它使我们能够获得查询字符串，并用实际的参数值替换参数占位符。由于 java.sql.PreparedStatement 没有此类方法，我们必须自己实现。

回页首

定制解决方案

我们的 PreparedStatement 定制实施将做为围绕JDBC驱动器提供的“真实语句（real statement）”的封装器（Wrapper)。封装器语句将转发所有方法调用(例如 setLong(int, long) 和 setString(int,String) ) 到“真实语句”。在这样做之前它将保存相关的参数值，从而它们可以用于生成日志输出结果。

表3介绍了 LoggableStatement 类如何实现 java.sql.PreparedStatement ，以及它如何使用JDBC连接和SQL模板作为输入来构建。

												
														  public class LoggableStatement implements java.sql.PreparedStatement {

     // used for storing parameter values needed
      // for producing log
     private ArrayList parameterValues;     
          
     // the query string with question marks as  
     // parameter placeholders
     private String sqlTemplate;       
               
     // a statement created from a real database     
     // connection                                       
     private PreparedStatement wrappedStatement; 
                                                 

    public LoggableStatement(Connection connection, String sql) 
      throws SQLException {
      // use connection to make a prepared statement
      wrappedStatement = connection.prepareStatement(sql);
      sqlTemplate = sql;
      parameterValues = new ArrayList();
    }
     }

												
										

回页首

LoggableStatement如何工作

表4介绍了 LoggableStatement 如何向 saveQueryParamValue() 方法添加一个调用，以及在方法 setLong 和 setString 的“真实语句”上调用相应的方法。我们采用与用于参数设置的所有方法(例如 setChar 、 setLong 、 setRef 和 setObj )相同的方式来增加 saveQueryParamValue() 调用。表4还显示了在不调用 saveQueryParamValue() 的情况下如何封装方法 executeQuery ，因为它不是一个“参数设置”方法。

												
														     public void setLong(int parameterIndex, long x) 
         throws java.sql.SQLException {
      wrappedStatement.setLong(parameterIndex, x);
      saveQueryParamValue(parameterIndex, new Long(x));
   }

   public void setString(int parameterIndex, String x) 
       throws java.sql.SQLException {
      wrappedStatement.setString(parameterIndex, x);
      saveQueryParamValue(parameterIndex, x);
   }

  public ResultSet executeQuery() throws java.sql.SQLException {
     return wrappedStatement.executeQuery();
   }

												
										

表5中显示了 saveQueryParamValue() 方法。它把每个参数值转换成 String 表示，保存以便 getQueryString 方法日后使用。缺省情况下，一个对象使用其 toString 方法将被转换成 String ，但如果对象是 String 或 Date ，它将用单引号('')表示。 getQueryString() 方法使您能够从日志复制大多数查询并进行粘贴，无需修改交互式SQL处理器就可进行测试和调试。您可以根据需要修订该方法来转换其它类的参数值。

												
														  private void saveQueryParamValue(int position, Object obj) {
      String strValue;
      if (obj instanceof String || obj instanceof Date) {
           // if we have a String, include '' in the saved value
           strValue = "'" + obj + "'";
      } else {
           if (obj == null) {
                // convert null to the string null
                 strValue = "null";
           } else {
                // unknown object (includes all Numbers), just call toString
                strValue = obj.toString();
           }
      }
      // if we are setting a position larger than current size of 
      // parameterValues, first make it larger
      while (position >= parameterValues.size()) {
           parameterValues.add(null);
      }
      // save the parameter
      parameterValues.set(position, strValue);
 }

												
										

当我们使用标准方法来设置所有参数时，我们在 LoggableStatement 中简单调用 getQueryString() 方法来获得查询字符串。所有问号都将被真正的参数值替换，它准备输出到我们选定的日志目的地。

回页首

使用LoggableStatement

表6显示如何更改表1和表2中的代码来使用 LoggableStatement 。将 LoggableStatement 引入到我们的应用程序代码中可以解决复制的参数变量问题。如果改变了SQL模板，我们只需更新 PreparedStatement 上的参数设置调用(例如添加一个 pstmt.setString(3,"new-param-value") )。这一更改将在日志输出结果中反映出，无需任何记录代码的手工更新。

												
														    String sql = "select foo, bar from foobar where foo < ? and bar = ?";
    long fooValue = 99;
    String barValue = "christmas";

    Connection conn = dataSource.getConnection();
    PreparedStatement pstmt;

    if(logEnabled) // use a switch to toggle logging.
        pstmt = new LoggableStatement(conn,sql);
    else
        pstmt = conn.prepareStatement(sql);

    pstmt.setLong(1,fooValue);
    pstmt.setString(2,barValue);

    if(logEnabled)
       System.out.println("Executing query: "+
         ((LoggableStatement)pstmt).getQueryString());

    ResultSet rs = pstmt.executeQuery();

												
										

回页首

结束语

使用本文介绍的非常简单的步骤，您可以为查询记录扩展JDBC PreparedStatement 接口。我们在此处使用的技术可以被视为“通过封装来实现扩展”，或作为Decorator设计模式的一个实例(见 参考资料)。通过封装来实现扩展在当您必须扩展API但subclassing不是一项可选功能时极其有用。

在这个系列的 第 1 部分，我们讨论了事务并研究了它们的基本属性 ― 原子性（atomicity）、一致性（consistency）、孤立性（isolation）和持久性（durability）。事务是企业应用程序的基本构件；没有它们，几乎不可能构建有容错能力的企业应用程序。幸运的是，Java 事务服务（Java Transaction Service，JTS）和 J2EE 容器自动为您做了大量的事务管理工作，这样您就不必将事务意识直接集成到组件代码中。结果简直是一种魔术 ― 通过遵守几条简单的规则，J2EE 应用程序就可以自动获得事务性语义，只需极少或根本不需要额外的组件代码。本文旨在通过展示事务管理如何发生，以及发生在何处来揭开这个魔术的神秘面纱。

什么是 JTS？

JTS 是一个 组件事务监视器（component transaction monitor）。这是什么意思？在第 1 部分，我们介绍了 事务处理监视器（TPM）这个概念，TPM 是一个程序，它代表应用程序协调分布式事务的执行。TPM 与数据库出现的时间长短差不多；在 60 年代后期，IBM 首先开发了 CICS，至今人们仍在使用。经典的（或者说 程序化）TPM 管理被程序化定义为针对事务性资源（比如数据库）的操作序列的事务。随着分布式对象协议，如 CORBA、DCOM 和 RMI 的出现，人们希望看到事务更面向对象的前景。将事务性语义告知面向对象的组件要求对 TPM 模型进行扩展 ― 在这个模型中事务是按照事务性对象的调用方法定义的。JTS 只是一个组件事务监视器（有时也称为 对象事务监视器（object transaction monitor）），或称为 CTM。

JTS 和 J2EE 的事务支持设计受 CORBA 对象事务服务（CORBA Object Transaction Service，OTS）的影响很大。实际上，JTS 实现 OTS 并充当 Java 事务 API（Java Transaction API）― 一种用来定义事务边界的低级 API ― 和 OTS 之间的接口。使用 OTS 代替创建一个新对象事务协议遵循了现有标准，并使 J2EE 和 CORBA 能够互相兼容。

乍一看，从程序化事务监视器到 CTM 的转变好像只是术语名称改变了一下。然而，差别不止这一点。当 CTM 中的事务提交或回滚时，与事务相关的对象所做的全部更改都一起被提交或取消。但 CTM 怎么知道对象在事务期间做了什么事？象 EJB 组件之类的事务性组件并没有 commit() 或 rollback() 方法，它们也没向事务监视器注册自己做了什么事。那么 J2EE 组件执行的操作如何变成事务的一部分呢？

回页首

透明的资源征用

当应用程序状态被组件操纵时，它仍然存储在事务性资源管理器（例如，数据库和消息队列服务器）中，这些事务性资源管理器可以注册为分布式事务中的资源管理器。在第 1 部分中，我们讨论了如何在单个事务中征用多个资源管理器，事务管理器如何协调这些资源管理器。资源管理器知道如何把应用程序状态中的变化与特定的事务关联起来。

但这只是把问题的焦点从组件转移到了资源管理器 ― 容器如何断定什么资源与该事务有关，可以供它征用？请考虑下面的代码，在典型的 EJB 会话 bean 中您可能会发现这样的代码：

												
														  InitialContext ic = new InitialContext();
  UserTransaction ut = ejbContext.getUserTransaction();
  ut.begin();
  DataSource db1 = (DataSource) ic.lookup("java:comp/env/OrdersDB");
  DataSource db2 = (DataSource) ic.lookup("java:comp/env/InventoryDB");
  Connection con1 = db1.getConnection();
  Connection con2 = db2.getConnection();
  // perform updates to OrdersDB using connection con1
  // perform updates to InventoryDB using connection con2
  ut.commit();

												
										

注意，这个示例中没有征用当前事务中 JDBC 连接的代码 ― 容器会为我们完成这个任务。我们来看一下它是如何发生的。

资源管理器的三种类型

当一个 EJB 组件想访问数据库、消息队列服务器或者其它一些事务性资源时，它需要到资源管理器的连接（通常是使用 JNDI）。而且，J2EE 规范只认可三种类型的事务性资源 ― JDBC 数据库、JMS 消息队列服务器和“其它通过 JCA 访问的事务性服务”。后面一种服务（比如 ERP 系统）必须通过 JCA（J2EE Connector Architecture，J2EE 连接器体系结构）访问。对于这些类型资源中的每一种，容器或提供者都会帮我们把资源征调到事务中。

在清单 1 中， con1 和 con2 好象是普通的 JDBC 连接，比如那些从 DriverManager.getConnection() 返回的连接。我们从一个 JDBC DataSource 得到这些连接，JDBC DataSource 可以通过查找 JNDI 中的数据源名称得到。EJB 组件中被用来查找数据源（ java:comp/env/OrdersDB ）的名称是特定于组件的；组件的部署描述符的 resource-ref 部分将其映射为容器管理的一些应用程序级 DataSource 的 JNDI 名称。

隐藏的 JDBC 驱动器

每个 J2EE 容器都可以创建有事务意识的池态 DataSource 对象，但 J2EE 规范并不向您展示如何创建，因为这不在 J2EE 规范内。浏览 J2EE 文档时，您找不到任何关于如何创建 JDBC 数据源的内容。相反，您不得不为您的容器查阅该文档。创建一个数据源可能需要向属性或配置文件添加一个数据源定义，或者也可以通过 GUI 管理工具完成，这取决于您的容器。

每个容器（或连接池管理器，如 PoolMan）都提供它自己的创建 DataSource 机制，JTA 魔术就隐藏在这个机制中。连接池管理器从指定的 JDBC 驱动器得到一个 Connection ，但在将它返回到应用程序之前，将它与一个也实现 Connection 的虚包包在一起，将自己置入应用程序和底层连接之间。当创建连接或者执行 JDBC 操作时，包装器询问事务管理器当前线程是不是正在事务的上下文中执行，如果事务中有 Connection 的话，就自动征用它。

其它类型的事务性资源，JMS 消息队列和 JCA 连接器，依靠相似的机制将资源征用隐藏起来，使用户看不到。如果要使 JMS 队列在部署时对 J2EE 应用程序可用，您就要再次使用特定于提供者的机制来创建受管 JMS 对象（队列连接工厂和目标），然后在 JNDI 名称空间内发布这些对象。提供者创建的受管对象包含与 JDBC 包装器（由容器提供的连接池管理器添加）相似的自动征用代码。

回页首

透明的事务控制

两种类型的 J2EE 事务 ― 容器管理的和 bean 管理的 ― 在如何启动和结束事务上是不同的。事务启动和结束的地方被称为 事务划分（transaction demarcation）。清单 1 中的示例代码演示了 bean 管理的事务（有时也称为 编程（programmatic）事务）。Bean 管理的事务是由组件使用 UserTransaction 类显式启动和结束的。通过 ejbContext 使 UserTransaction 对 EJB 组件可用，通过 JNDI 使其对其它 J2EE 组件可用。

容器根据组件的部署描述符中的事务属性代表应用程序透明地启动和结束容器管理的事务（或称为 宣告式事务（declarative transaction））。通过将 transaction-type 属性设置为 Container 或 Bean 您可以指出 EJB 组件是使用 bean 管理的事务性支持还是容器管理的事务性支持。

使用容器管理的事务，您可以在 EJB 类或方法级别上指定事务性属性；您可以为 EJB 类指定缺省的事务性属性，如果不同的方法会有不同的事务性语义，您还可以为每个方法指定属性。这些事务性属性在装配描述符（assembly descriptor）的 container-transaction 部分被指定。清单 2 显示了一个装配描述符示例。 trans-attribute 的受支持的值有：

• Supports
• Required
• RequiresNew
• Mandatory
• NotSupported
• Never

trans-attribute 决定方法是否支持在事务内部执行、当在事务内部调用方法时容器会执行什么操作以及在事务外部调用方法时容器会执行什么操作。最常用的容器管理的事务属性是 Required 。如果设置了 Required ，过程中的事务将在该事务中征用您的 bean，但如果没有正在运行的事务，容器将为您启动一个。在这个系列的第 3 部分，当您可能想使用每个事务属性时，我们将研究各个事务属性之间的区别。

												
														<assembly-descriptor>
  ...
  <container-transaction>
    <method>
      <ejb-name>MyBean</ejb-name>
      <method-name>*</method-name>
    </method>
    <trans-attribute>Required</trans-attribute>
  </container-transaction>
  <container-transaction>
    <method>
      <ejb-name>MyBean</ejb-name>
      <method-name>updateName</method-name>
      </method>
   <trans-attribute>RequiresNew</trans-attribute>
  </container-transaction>
  ...
</assembly-descriptor>

												
										

功能强大，但很危险

与清单 1 中的示例不同，由于有宣告式事务划分，这段组件代码中没有事务管理代码。这不仅使结果组件代码更加易读（因为它不与事务管理代码混在一起），而且它还有另一个更重要的优点 ― 不必修改，甚至不必访问组件的源代码，就可以在应用程序装配时改变组件的事务性语义。

尽管能够指定与代码分开的事务划分是一种非常强大的功能，但在装配时做出不好的决定会使应用程序变得不稳定，或者严重影响它的性能。对容器管理的事务进行正确分界的责任由组件开发者和应用程序装配人员共同担当。组件开发者需要提供足够的文档说明组件是做什么的，这样应用程序部署者就能够明智地决定如何构建应用程序的事务。应用程序装配人员需要理解应用程序中的组件是怎样相互作用的，这样就可以用一种既强制应用程序保持一致又不削弱性能的方法对事务进行分界。在这个系列的第 3 部分中我们将讨论这些问题。

回页首

透明的事务传播

在任何类型的事务中，资源征用都是透明的；容器自动将事务过程中使用的任意事务性资源征调到当前事务中。这个过程不仅扩展到事务性方法使用的资源（比如在清单 1 中获得的数据库连接），还扩展到它调用的方法（甚至远程方法）使用的资源。我们来看一下这是如何发生的。

容器用线程与事务相关联

我们假设对象 A 的 methodA() 启动一个事务，然后调用对象 B 的 methodB() （对象 B 将得到一个 JDBC 连接并更新数据库）。 B 获得的连接将被自动征调到 A 创建的事务中。容器怎么知道要做这件事？

当事务启动时，事务上下文与执行线程关联在一起。当 A 创建事务时， A 在其中执行的线程与该事务关联在一起。由于本地方法调用与主调程序（caller）在同一个线程内执行，所以 A 调用的每个方法也都在该事务的上下文中。

橱中骸骨

如果对象 B 其实是在另一个线程，甚至另一个 JVM 中执行的 EJB 组件的存根，情况会怎样？令人吃惊的是，远程对象 B 访问的资源仍将在当前事务中被征用。EJB 对象存根（在主调程序的上下文中执行的那部分）、EJB 协议（IIOP 上的 RMI）和远端的骨架对象协力要使其透明地发生。存根确定调用者是不是正在执行一个事务。如果是，事务标识，或者说 Xid，被作为 IIOP 调用的一部分与方法参数一起传播到远程对象。（IIOP 是 CORBA 远程-调用协议，它为传播执行上下文（比如事务上下文和安全性上下文）的各种元素而备；关于 RMI over IIOP 的更多信息，请参阅 参考资料。）如果调用是事务的一部分，那么远程系统上的骨架对象自动设置远程线程的事务上下文，这样，当调用实际的远程方法时，它已经是事务的一部分了。（存根和骨架对象还负责开始和提交容器管理的事务。）

事务可以由任何 J2EE 组件来启动 ― 一个 EJB 组件、一个 servlet 或者一个 JSP 页面（如果容器支持的话，还可以是一个应用程序客户机）。这意味着，应用程序可以在请求到达时在 servlet 或者 JSP 页面中启动事务、在 servlet 或者 JSP 页面中执行一些处理、作为页面逻辑的一部分访问多个服务器上的实体 bean 和会话 bean 并使所有这些工作透明地成为一个事务的一部分。图 1 演示了事务上下文怎样遵守从 servlet 到 EJB，再到 EJB 的执行路径。

回页首

最优化

让容器来管理事务允许容器为我们做出某些最优化决定。在图 1 中，我们看到一个 servlet 和多个 EJB 组件在单个事务的上下文中访问一个数据库。每个组件都获得到数据库的 Connection ；很可能每个组件都在访问同一个数据库。即使多个连接是从不同的组件到同一个资源，JTS 也可以检测出多个资源是否和事务有关，并最优化该事务的执行。您可以从第 1 部分回忆起来，单个事务要包含多个资源管理器需要使用两阶段提交协议，这比单个资源管理器使用的单阶段提交代价要高。JTS 能够确定事务中是不是只征用了一个资源管理器。如果它检测出所有与事务相关的资源都一样，它可以跳过两阶段提交并让资源管理器自己来处理事务。

回页首

结束语

这个虑及透明事务控制、资源征用和透明传播的魔术不是 JTS 的一部分，而是 J2EE 容器如何在幕后代表 J2EE 应用程序使用 JTA 和 JTS 服务的一部分。在幕后有许多实体合力使这个魔术透明地发生；EJB 存根和骨架、容器厂商提供的 JDBC 驱动器包装器、数据库厂商提供的 JDBC 驱动器、JMS 提供器和 JCA 连接器。所有这些实体都与事务管理器进行交互，于是应用程序代码就不必与之交互了。

在第 3 部分，我们将看一下关于管理 J2EE 上下文中事务的一些实际问题 ― 事务划分和孤立 ― 以及它们对应用程序一致性、稳定性和性能的影响。

与许多其它的编程语言不同，Java语言规范包括对线程和并发的明确支持。语言本身支持并发，这使得指定和管理共享数据的约束以及跨线程操作的计时变得更简单，但是这没有使得并发编程的复杂性更易于理解。这个三部分的系列文章的目的在于帮助程序员理解用Java 语言进行多线程编程的一些主要问题，特别是线程安全对 Java程序性能的影响。

请点击文章顶部或底部的 讨论进入由 Brian Goetz 主持的 “Java线程：技巧、窍门和技术”讨论论坛，与本文作者和其他读者交流您对本文或整个多线程的想法。注意该论坛讨论的是使用多线程时遇到的所有问题，而并不限于本文的内容。

大多数编程语言的语言规范都不会谈到线程和并发的问题；因为一直以来，这些问题都是留给平台或操作系统去详细说明的。但是，Java 语言规范（JLS）却明确包括一个线程模型，并提供了一些语言元素供开发人员使用以保证他们程序的线程安全。

对线程的明确支持有利也有弊。它使得我们在写程序时更容易利用线程的功能和便利，但同时也意味着我们不得不注意所写类的线程安全，因为任何类都很有可能被用在一个多线程的环境内。

许多用户第一次发现他们不得不去理解线程的概念的时候，并不是因为他们在写创建和管理线程的程序，而是因为他们正在用一个本身是多线程的工具或框架。任何用过 Swing GUI 框架或写过小服务程序或 JSP 页的开发人员（不管有没有意识到）都曾经被线程的复杂性困扰过。

Java 设计师是想创建一种语言，使之能够很好地运行在现代的硬件，包括多处理器系统上。要达到这一目的，管理线程间协调的工作主要推给了软件开发人员；程序员必须指定线程间共享数据的位置。在 Java 程序中，用来管理线程间协调工作的主要工具是 synchronized 关键字。在缺少同步的情况下，JVM 可以很自由地对不同线程内执行的操作进行计时和排序。在大部分情况下，这正是我们想要的，因为这样可以提高性能，但它也给程序员带来了额外的负担，他们不得不自己识别什么时候这种性能的提高会危及程序的正确性。

synchronized 真正意味着什么？

大部分 Java 程序员对同步的块或方法的理解是完全根据使用互斥（互斥信号量）或定义一个临界段（一个必须原子性地执行的代码块）。虽然 synchronized 的语义中确实包括互斥和原子性，但在管程进入之前和在管程退出之后发生的事情要复杂得多。

synchronized 的语义确实保证了一次只有一个线程可以访问被保护的区段，但同时还包括同步线程在主存内互相作用的规则。理解 Java 内存模型（JMM）的一个好方法就是把各个线程想像成运行在相互分离的处理器上，所有的处理器存取同一块主存空间，每个处理器有自己的缓存，但这些缓存可能并不总和主存同步。在缺少同步的情况下，JMM 会允许两个线程在同一个内存地址上看到不同的值。而当用一个管程（锁）进行同步的时候，一旦申请加了锁，JMM 就会马上要求该缓存失效，然后在它被释放前对它进行刷新（把修改过的内存位置写回主存）。不难看出为什么同步会对程序的性能影响这么大；频繁地刷新缓存代价会很大。

回页首

使用一条好的运行路线

如果同步不适当，后果是很严重的：会造成数据混乱和争用情况，导致程序崩溃，产生不正确的结果，或者是不可预计的运行。更糟的是，这些情况可能很少发生且具有偶然性（使得问题很难被监测和重现）。如果测试环境和开发环境有很大的不同，无论是配置的不同，还是负荷的不同，都有可能使得这些问题在测试环境中根本不出现，从而得出错误的结论：我们的程序是正确的，而事实上这些问题只是还没出现而已。

争用情况定义 争用情况是一种特定的情况：两个或更多的线程或进程读或写一些共享数据，而最终结果取决于这些线程是如何被调度计时的。争用情况可能会导致不可预见的结果和隐蔽的程序错误。

另一方面，不当或过度地使用同步会导致其它问题，比如性能很差和死锁。当然，性能差虽然不如数据混乱那么严重，但也是一个严重的问题，因此同样不可忽视。编写优秀的多线程程序需要使用好的运行路线，足够的同步可以使您的数据不发生混乱，但不需要滥用到去承担死锁或不必要地削弱程序性能的风险。

回页首

同步的代价有多大？

由于包括缓存刷新和设置失效的过程，Java 语言中的同步块通常比许多平台提供的临界段设备代价更大，这些临界段通常是用一个原子性的“test and set bit”机器指令实现的。即使一个程序只包括一个在单一处理器上运行的单线程，一个同步的方法调用仍要比非同步的方法调用慢。如果同步时还发生锁定争用，那么性能上付出的代价会大得多，因为会需要几个线程切换和系统调用。

幸运的是，随着每一版的 JVM 的不断改进，既提高了 Java 程序的总体性能，同时也相对减少了同步的代价，并且将来还可能会有进一步的改进。此外，同步的性能代价经常是被夸大的。一个著名的资料来源就曾经引证说一个同步的方法调用比一个非同步的方法调用慢 50 倍。虽然这句话有可能是真的，但也会产生误导，而且已经导致了许多开发人员即使在需要的时候也避免使用同步。

严格依照百分比计算同步的性能损失并没有多大意义，因为一个无争用的同步给一个块或方法带来的是固定的性能损失。而这一固定的延迟带来的性能损失百分比取决于在该同步块内做了多少工作。对一个 空方法的同步调用可能要比对一个空方法的非同步调用慢 20 倍，但我们多长时间才调用一次空方法呢？当我们用更有代表性的小方法来衡量同步损失时，百分数很快就下降到可以容忍的范围之内。

表 1 把一些这种数据放在一起来看。它列举了一些不同的实例，不同的平台和不同的 JVM 下一个同步的方法调用相对于一个非同步的方法调用的损失。在每一个实例下，我运行一个简单的程序，测定循环调用一个方法 10，000，000 次所需的运行时间，我调用了同步和非同步两个版本，并比较了结果。表格中的数据是同步版本的运行时间相对于非同步版本的运行时间的比率；它显示了同步的性能损失。每次运行调用的都是清单 1 中的简单方法之一。

表格 1 中显示了同步方法调用相对于非同步方法调用的相对性能；为了用绝对的标准测定性能损失，必须考虑到 JVM 速度提高的因素，这并没有在数据中体现出来。在大多数测试中，每个 JVM 的更高版本都会使 JVM 的总体性能得到很大提高，很有可能 1.4 版的 Java 虚拟机发行的时候，它的性能还会有进一步的提高。

表 1. 无争用同步的性能损失

												
														 public static void staticEmpty() {  }

  public void empty() {  }

  public Object fetch() { return field; }

  public Object singleton() {
    if (singletonField == null)
      singletonField = new Object();
    return singletonField;
  }

  public Object hashmapGet() {
    return hashMap.get("this");
  }

  public Object create() { 
    return new Object();
  }

												
										

这些小基准测试也阐明了存在动态编译器的情况下解释性能结果所面临的挑战。对于 1.3 JDK 在有和没有 JIT 时，数字上的巨大差异需要给出一些解释。对那些非常简单的方法（ empty 和 fetch ），基准测试的本质（它只是执行一个几乎什么也不做的紧凑的循环）使得 JIT 可以动态地编译整个循环，把运行时间压缩到几乎没有的地步。但在一个实际的程序中，JIT 能否这样做就要取决于很多因素了，所以，无 JIT 的计时数据可能在做公平对比时更有用一些。在任何情况下，对于更充实的方法（ create 和 hashmapGet ），JIT 就不能象对更简单些的方法那样使非同步的情况得到巨大的改进。另外，从数据中看不出 JVM 是否能够对测试的重要部分进行优化。同样，在可比较的 IBM 和 Sun JDK 之间的差异反映了 IBM Java SDK 可以更大程度地优化非同步的循环，而不是同步版本代价更高。这在纯计时数据中可以明显地看出（这里不提供）。

从这些数字中我们可以得出以下结论：对非争用同步而言，虽然存在性能损失，但在运行许多不是特别微小的方法时，损失可以降到一个合理的水平；大多数情况下损失大概在 10% 到 200% 之间（这是一个相对较小的数目）。所以，虽然同步每个方法是不明智的（这也会增加死锁的可能性），但我们也不需要这么害怕同步。这里使用的简单测试是说明一个无争用同步的代价要比创建一个对象或查找一个 HashMap 的代价小。

由于早期的书籍和文章暗示了无争用同步要付出巨大的性能代价，许多程序员就竭尽全力避免同步。这种恐惧导致了许多有问题的技术出现，比如说 double-checked locking（DCL）。许多关于 Java 编程的书和文章都推荐 DCL，它看上去真是避免不必要的同步的一种聪明的方法，但实际上它根本没有用，应该避免使用它。DCL 无效的原因很复杂，已超出了本文讨论的范围（要深入了解，请参阅 参考资料里的链接）。

回页首

不要争用

假设同步使用正确，若线程真正参与争用加锁，您也能感受到同步对实际性能的影响。并且无争用同步和争用同步间的性能损失差别很大；一个简单的测试程序指出争用同步比无争用同步慢 50 倍。把这一事实和我们上面抽取的观察数据结合在一起，可以看出使用一个争用同步的代价至少相当于创建 50 个对象。

所以，在调试应用程序中同步的使用时，我们应该努力减少实际争用的数目，而根本不是简单地试图避免使用同步。这个系列的第 2 部分将把重点放在减少争用的技术上，包括减小锁的粒度、减小同步块的大小以及减小线程间共享数据的数量。

回页首

什么时候需要同步？

要使您的程序线程安全，首先必须确定哪些数据将在线程间共享。如果正在写的数据以后可能被另一个线程读到，或者正在读的数据可能已经被另一个线程写过了，那么这些数据就是共享数据，必须进行同步存取。有些程序员可能会惊讶地发现，这些规则在简单地检查一个共享引用是否非空的时候也用得上。

许多人会发现这些定义惊人地严格。有一种普遍的观点是，如果只是要读一个对象的字段，不需要请求加锁，尤其是在 JLS 保证了 32 位读操作的原子性的情况下，它更是如此。但不幸的是，这个观点是错误的。除非所指的字段被声明为 volatile ，否则 JMM 不会要求下面的平台提供处理器间的缓存一致性和顺序连贯性，所以很有可能，在某些平台上，没有同步就会读到陈旧的数据。有关更详细的信息，请参阅 参考资料。

在确定了要共享的数据之后，还要确定要如何保护那些数据。在简单情况下，只需把它们声明为 volatile 即可保护数据字段；在其它情况下，必须在读或写共享数据前请求加锁，一个很好的经验是明确指出使用什么锁来保护给定的字段或对象，并在你的代码里把它记录下来。

还有一点值得注意的是，简单地同步存取器方法（或声明下层的字段为 volatile ）可能并不足以保护一个共享字段。可以考虑下面的示例：

												
														 ...
  private int foo;
  public synchronized int getFoo() { return foo; } 
  public synchronized void setFoo(int f) { foo = f; }

												
										

如果一个调用者想要增加 foo 属性值，以下完成该功能的代码就不是线程安全的：

												
														 ...
  setFoo(getFoo() + 1);

												
										

如果两个线程试图同时增加 foo 属性值，结果可能是 foo 的值增加了 1 或 2，这由计时决定。调用者将需要同步一个锁，才能防止这种争用情况；一个好方法是在 JavaDoc 类中指定同步哪个锁，这样类的调用者就不需要自己猜了。

以上情况是一个很好的示例，说明我们应该注意多层次粒度的数据完整性；同步存取器方法确保调用者能够存取到一致的和最近版本的属性值，但如果希望属性的将来值与当前值一致，或多个属性间相互一致，我们就必须同步复合操作 ― 可能是在一个粗粒度的锁上。

回页首

如果情况不确定，考虑使用同步包装

有时，在写一个类的时候，我们并不知道它是否要用在一个共享环境里。我们希望我们的类是线程安全的，但我们又不希望给一个总是在单线程环境内使用的类加上同步的负担，而且我们可能也不知道使用这个类时合适的锁粒度是多大。幸运的是，通过提供同步包装，我们可以同时达到以上两个目的。Collections 类就是这种技术的一个很好的示例；它们是非同步的，但在框架中定义的每个接口都有一个同步包装（例如， Collections.synchronizedMap() ），它用一个同步的版本来包装每个方法。

回页首

结论

虽然 JLS 给了我们可以使我们的程序线程安全的工具，但线程安全也不是天上掉下来的馅饼。使用同步会蒙受性能损失，而同步使用不当又会使我们承担数据混乱、结果不一致或死锁的风险。幸运的是，在过去的几年内 JVM 有了很大的改进，大大减少了与正确使用同步相关的性能损失。通过仔细分析在线程间如何共享数据，适当地同步对共享数据的操作，可以使得您的程序既是线程安全的，又不会承受过多的性能负担。

观察者模式在 Swing 开发中很常见，在 GUI 应用程序以外的场景中，它对于消除组件的耦合性也非常有用。但是，仍然存在一些侦听器登记和调用方面的常见缺陷。在 Java 理论与实践 的这一期中，Java 专家 Brian Goetz 就如何做一个好的侦听器，以及如何对您的侦听器也友好，提供了一些感觉很好的建议。请在相应的 讨论论坛 上与作者和其他读者分享您对这篇文章的想法。（您也可以单击本文顶部或底部的 讨论 访问论坛。）

Swing 框架以事件侦听器的形式广泛利用了观察者模式（也称为发布-订阅模式）。Swing 组件作为用户交互的目标，在用户与它们交互的时候触发事件；数据模型类在数据发生变化时触发事件。用这种方式使用观察者，可以让控制器与模型分离，让模型与视图分离，从而简化 GUI 应用程序的开发。

“四人帮”的 设计模式 一书（参阅 参考资料）把观察者模式描述为：定义对象之间的“一对多”关系，这样一个对象改变状态时，所有它的依赖项都会被通知，并自动更新。观察者模式支持组件之间的松散耦合；组件可以保持它们的状态同步，却不需要直接知道彼此的标识或内部情况，从而促进了组件的重用。

AWT 和 Swing 组件（例如 JButton 或 JTable）使用观察者模式消除了 GUI 事件生成与它们在指定应用程序中的语义之间的耦合。类似地，Swing 的模型类，例如 TableModel 和 TreeModel，也使用观察者消除数据模型表示 与视图生成之间的耦合，从而支持相同数据的多个独立的视图。Swing 定义了 Event 和 EventListener 对象层次结构；可以生成事件的组件，例如 JButton（可视组件） 或 TableModel（数据模型），提供了 addXxxListener() 和 removeXxxListener() 方法，用于侦听器的登记和取消登记。这些类负责决定什么时候它们需要触发事件，什么时候确实触发事件，以及什么时候调用所有登记的侦听器。

为了支持侦听器，对象需要维护一个已登记的侦听器列表，提供侦听器登记和取消登记的手段，并在适当的事件发生时调用每个侦听器。使用和支持侦听器很容易（不仅仅在 GUI 应用程序中），但是在登记接口的两边（它们是支持侦听器的组件和登记侦听器的组件）都应当避免一些缺陷。

线程安全问题

通常，调用侦听器的线程与登记侦听器的线程不同。要支持从不同线程登记侦听器，那么不管用什么机制存储和管理活动侦听器列表，这个机制都必须是线程安全的。Sun 的文档中的许多示例使用 Vector 保存侦听器列表，它解决了部分问题，但是没有解决全部问题。在事件触发时，触发它的组件会考虑迭代侦听器列表，并调用每个侦听器，这就带来了并发修改的风险，比如在侦听器列表迭代期间，某个线程偶然想添加或删除一个侦听器。

管理侦听器列表

假设您使用 Vector<Listener> 保存侦听器列表。虽然 Vector 类是线程安全的（意味着不需要进行额外的同步就可调用它的方法，没有破坏 Vector 数据结构的风险），但是集合的迭代中包含“检测然后执行”序列，如果在迭代期间集合被修改，就有了失败的风险。假设迭代开始时列表中有三个侦听器。在迭代 Vector 时，重复调用 size() 和 get() 方法，直到所有元素都检索完，如清单 1 所示：

												
														Vector<Listener> v;
for (int i=0; i<v.size(); i++)
  v.get(i).eventHappened(event);

												
										

但是，如果恰好就在最后一次调用 Vector.size() 之后，有人从列表中删除了一个侦听器，会发生什么呢？现在，Vector.get() 将返回 null （这是对的，因为从上次检测 vector 的状态以来，它的状态已经变了），而在试图调用 eventHappened() 时，会抛出 NullPointerException。这是“检测然后执行”序列的一个示例 —— 检测是否存在更多元素，如果存在，就取得下一元素 —— 但是在存在并发修改的情况下，检测之后状态可能已经变化。图 1 演示了这个问题：

图 1. 并发迭代和修改，造成意料之外的失败

这个问题的一个解决方案是在迭代期间持有对 Vector 的锁；另一个方案是克隆 Vector 或调用它的 toArray() 方法，在每次发生事件时检索它的内容。所有这两个方法都有性能上的问题：第一个的风险是在迭代期间，会把其他想访问侦听器列表的线程锁在外面；第二个则要创建临时对象，而且每次事件发生时都要拷贝列表。

如果用迭代器（Iterator）去遍历侦听器列表，也会有同样的问题，只是表现略有不同； iterator() 实现不抛出 NullPointerException，它在探测到迭代开始之后集合发生修改时，会抛出 ConcurrentModificationException。同样，也可以通过在迭代期间锁定集合防止这个问题。

java.util.concurrent 中的 CopyOnWriteArrayList 类，能够帮助防止这个问题。它实现了 List，而且是线程安全的，但是它的迭代器不会抛出 ConcurrentModificationException，遍历期间也不要求额外的锁定。这种特性组合是通过在每次列表修改时，在内部重新分配并拷贝列表内容而实现的，这样，遍历内容的线程不需要处理变化 —— 从它们的角度来说，列表的内容在遍历期间保持不变。虽然这听起来可能没效率，但是请记住，在多数观察者情况下，每个组件只有少量侦听器，遍历的数量远远超过插入和删除的数量。所以更快的迭代可以补偿较慢的变化过程，并提供更好的并发性，因为多个线程可以同时迭代列表。

初始化的安全风险

从侦听器的构造函数中登记它很诱惑人，但是这是一个应当避免的诱惑。它仅会造成“失效侦听器（lapsed listener）的问题（我稍后讨论它），而且还会造成多个线程安全问题。清单 2 显示了一个看起来没什么害处的同时构造和登记侦听器的企图。问题是：它造成到对象的“this”引用在对象完全构造完成之前转义。虽然看起来没什么害处，因为登记是构造函数做的最后一件事，但是看到的东西是有欺骗性的：

												
														public class EventListener { 

  public EventListener(EventSource eventSource) {
    // do our initialization
    ...

    // register ourselves with the event source
    eventSource.registerListener(this);
  }

  public onEvent(Event e) { 
    // handle the event
  }
}

												
										

在继承事件侦听器的时候，会出现这种方法的一个风险：这时，子类构造函数做的任何工作都是在 EventListener 构造函数运行之后进行的，也就是在 EventListener 发布之后，所以会造成争用情况。在某些不幸的时候，清单 3 中的 onEvent 方法会在列表字段还没初始化之前就被调用，从而在取消 final 字段的引用时，会生成非常让人困惑的 NullPointerException 异常：

												
														public class RecordingEventListener extends EventListener {
  private final ArrayList<Event> list;

  public RecordingEventListener(EventSource eventSource) {
    super(eventSource);
    list = Collections.synchronizedList(new ArrayList<Event>());
  }

  public onEvent(Event e) { 
    list.add(e);
    super.onEvent(e);
  }
}

												
										

即使侦听器类是 final 的，不能派生子类，也不应当允许“this”引用在构造函数中转义 —— 这样做会危害 Java 内存模型的某些安全保证。如果“this”这个词不会出现在程序中，就可让“this”引用转义；发布一个非静态内部类实例可以达到相同的效果，因为内部类持有对它包围的对象的“this”引用的引用。偶然地允许“this”引用转义的最常见原因，就是登记侦听器，如清单 4 所示。事件侦听器不应当在构造函数中登记！

												
														public class EventListener2 {
  public EventListener2(EventSource eventSource) {

    eventSource.registerListener(
      new EventListener() {
        public void onEvent(Event e) { 
          eventReceived(e);
        }
      });
  }

  public void eventReceived(Event e) {
  }
}

												
										

侦听器线程安全

使用侦听器造成的第三个线程安全问题来自这个事实：侦听器可能想访问应用程序数据，而调用侦听器的线程通常不直接在应用程序的控制之下。如果在 JButton 或其他 Swing 组件上登记侦听器，那么会从 EDT 调用该侦听器。侦听器的代码可以从 EDT 安全地调用 Swing 组件上的方法，但是如果对象本身不是线程安全的，那么从侦听器访问应用程序对象会给应用程序增加新的线程安全需求。

Swing 组件生成的事件是用户交互的结果，但是 Swing 模型类是在 fireXxxEvent() 方法被调用的时候生成事件。这些方法又会在调用它们的线程中调用侦听器。因为 Swing 模型类不是线程安全的，而且假设被限制在 EDT 内，所以对 fireXxxEvent() 的任何调用也都应当从 EDT 执行。如果想从另外的线程触发事件，那么应当用 Swing 的 invokeLater() 功能让方法转而在 EDT 内调用。一般来说，要注意调用事件侦听器的线程，还要保证它们涉及的任何对象或者是线程安全的，或者在访问它们的地方，受到适当的同步（或者是 Swing 模型类的线程约束）的保护。

回页首

失效侦听器

不管什么时候使用观察者模式，都耦合着两个独立组件 —— 观察者和被观察者，它们通常有不同的生命周期。登记侦听器的后果之一就是：它在被观察对象和侦听器之间建立起很强的引用关系，这种关系防止侦听器（以及它引用的对象）被垃圾收集，直到侦听器取消登记为止。在许多情况下，侦听器的生命周期至少要和被观察的组件一样长 —— 许多侦听器会在整个应用程序期间都存在。但是在某些情况下，应当短期存在的侦听器最后变成了永久的，它们这种无意识的拖延的证据就是应用程序性能变慢、高于必需的内存使用。

“失效侦听器”的问题可以由设计级别上的不小心造成：没有恰当地考虑包含的对象的寿命，或者由于松懈的编码。侦听器登记和取消登记应当结对进行。但是即使这么做，也必须保证是在正确的时间执行取消登记。清单 5 显示了会造成失效侦听器的编码习惯的示例。它在组件上登记侦听器，执行某些动作，然后取消登记侦听器：

												
														  public void processFile(String filename) throws IOException {
    cancelButton.registerListener(this);
    // open file, read it, process it
    // might throw IOException
    cancelButton.unregisterListener(this);
  }

												
										

清单 5 的问题是：如果文件处理代码抛出了 IOException —— 这是很有可能的 —— 那么侦听器就永远不会取消登记，这就意味着它永远不会被垃圾收集。取消登记的操作应当在 finally 块中进行，这样，processFile() 方法的所有出口都会执行它。

有时推荐的一个处理失效侦听器的方法是使用弱引用。虽然这种方法可行，但是实现起来很麻烦。要让它工作，需要找到另外一个对象，它的生命周期恰好是侦听器的生命周期，并安排它持有对侦听器的强引用，这可不是件容易的事。

另外一项可以用来找到隐藏失效侦听器的技术是：防止指定侦听器对象在指定事件源上登记两次。这种情况通常是 bug 的迹象 —— 侦听器登记了，但是没有取消登记，然后再次登记。不用检测问题，就能缓解这个问题的影响的一种方式是：使用 Set 代替 List 来存储侦听器；或者也可以检测 List，在登记侦听器之前检查是否已经登记了，如果已经登记，就抛出异常（或记录错误），这样就可以搜集编码错误的证据，并采取行动。

回页首

其他侦听器问题

在编写侦听器时，应当一直注意它们将要执行的环境。不仅要注意线程安全问题，还需要记住：侦听器也可以用其他方式为它的调用者把事情搞糟。侦听器 不该 做的一件事是：阻塞相当长一段时间（长得可以感觉得到）；调用它的执行上下文很可能希望迅速返回控制。如果侦听器要执行一个可能比较费时的操作，例如处理大型文本，或者要做的工作可能阻塞，例如执行 socket IO，那么侦听器应当把这些操作安排在另一个线程中进行，这样它就可以迅速返回它的调用者。

对于不小心的事件源，侦听器会造成麻烦的另一个方式是：抛出未检测的异常。虽然大多数时候，我们不会故意抛出未检测异常，但是确实有些时候会发生这种情况。如果使用清单 1 的方式调用侦听器，列表中的第二个侦听器就会抛出未检测异常，那么不仅后续的侦听器得不到调用（可能造成应用程序处在不一致的状态），而且有可能把执行它的线程破坏掉，从而造成局部应用程序失败。

在调用未知代码（侦听器就是这样的代码）时，谨慎的方式是在 try-catch 块中执行它，这样，行为有误的侦听器不会造成更多不必要的破坏。对于抛出未检测异常的侦听器，您可能想自动对它取消登记，毕竟，抛出未检测异常就证明侦听器坏掉了。（您可能还想记录这个错误或者提醒用户注意，好让用户能够知道为什么程序停止像期望的那样继续工作。）清单 6 显示了这种方式的一个示例，它在迭代循环内部嵌套了 try-catch 块：

												
														List<Listener> list;
for (Iterator<Listener> i=list.iterator; i.hasNext(); ) {
    Listener l = i.next();
    try {
        l.eventHappened(event);
    }
    catch (RuntimeException e) {
        log("Unexpected exception in listener", e);
        i.remove();
    }
}

												
										

回页首

结束语

观察者模式对于创建松散耦合的组件、鼓励组件重用非常有用，但是它有一些风险，侦听器的编写者和组件的编写者都应当注意。在登记侦听器时，应当一直注意侦听器的生命周期。如果侦听器的寿命应当比应用程序的短，那么请确保取消它的登记，这样它就可以被垃圾收集。在编写侦听器和组件时，请注意它包含的线程安全性问题。侦听器涉及的任何对象，都应当是线程安全的，或者是受线程约束的对象（例如 Swing 模型），侦听器应当确定自己正在正确的线程中执行。

虽然用 Java™ 语言编写的程序在理论上是不会出现“内存泄漏”的，但是有时对象在不再作为程序的逻辑状态的一部分之后仍然不被垃圾收集。本月，负责保障应用程序健康的工程师 Brian Goetz 探讨了无意识的对象保留的常见原因，并展示了如何用弱引用堵住泄漏。

要让垃圾收集（GC）回收程序不再使用的对象，对象的逻辑 生命周期（应用程序使用它的时间）和对该对象拥有的引用的实际 生命周期必须是相同的。在大多数时候，好的软件工程技术保证这是自动实现的，不用我们对对象生命周期问题花费过多心思。但是偶尔我们会创建一个引用，它在内存中包含对象的时间比我们预期的要长得多，这种情况称为无意识的对象保留（unintentional object retention）。

全局 Map 造成的内存泄漏

无意识对象保留最常见的原因是使用 Map 将元数据与临时对象（transient object）相关联。假定一个对象具有中等生命周期，比分配它的那个方法调用的生命周期长，但是比应用程序的生命周期短，如客户机的套接字连接。需要将一些元数据与这个套接字关联，如生成连接的用户的标识。在创建 Socket 时是不知道这些信息的，并且不能将数据添加到 Socket 对象上，因为不能控制 Socket 类或者它的子类。这时，典型的方法就是在一个全局 Map 中存储这些信息，如清单 1 中的 SocketManager 类所示：

												
														public class SocketManager {
    private Map<Socket,User> m = new HashMap<Socket,User>();
    
    public void setUser(Socket s, User u) {
        m.put(s, u);
    }
    public User getUser(Socket s) {
        return m.get(s);
    }
    public void removeUser(Socket s) {
        m.remove(s);
    }
}

SocketManager socketManager;
...
socketManager.setUser(socket, user);

												
										

这种方法的问题是元数据的生命周期需要与套接字的生命周期挂钩，但是除非准确地知道什么时候程序不再需要这个套接字，并记住从 Map 中删除相应的映射，否则，Socket 和 User 对象将会永远留在 Map 中，远远超过响应了请求和关闭套接字的时间。这会阻止 Socket 和 User 对象被垃圾收集，即使应用程序不会再使用它们。这些对象留下来不受控制，很容易造成程序在长时间运行后内存爆满。除了最简单的情况，在几乎所有情况下找出什么时候 Socket 不再被程序使用是一件很烦人和容易出错的任务，需要人工对内存进行管理。

回页首

找出内存泄漏

程序有内存泄漏的第一个迹象通常是它抛出一个 OutOfMemoryError，或者因为频繁的垃圾收集而表现出糟糕的性能。幸运的是，垃圾收集可以提供能够用来诊断内存泄漏的大量信息。如果以 -verbose:gc 或者 -Xloggc 选项调用 JVM，那么每次 GC 运行时在控制台上或者日志文件中会打印出一个诊断信息，包括它所花费的时间、当前堆使用情况以及恢复了多少内存。记录 GC 使用情况并不具有干扰性，因此如果需要分析内存问题或者调优垃圾收集器，在生产环境中默认启用 GC 日志是值得的。

有工具可以利用 GC 日志输出并以图形方式将它显示出来，JTune 就是这样的一种工具（请参阅 参考资料）。观察 GC 之后堆大小的图，可以看到程序内存使用的趋势。对于大多数程序来说，可以将内存使用分为两部分：baseline 使用和 current load 使用。对于服务器应用程序，baseline 使用就是应用程序在没有任何负荷、但是已经准备好接受请求时的内存使用，current load 使用是在处理请求过程中使用的、但是在请求处理完成后会释放的内存。只要负荷大体上是恒定的，应用程序通常会很快达到一个稳定的内存使用水平。如果在应用程序已经完成了其初始化并且负荷没有增加的情况下，内存使用持续增加，那么程序就可能在处理前面的请求时保留了生成的对象。

清单 2 展示了一个有内存泄漏的程序。MapLeaker 在线程池中处理任务，并在一个 Map 中记录每一项任务的状态。不幸的是，在任务完成后它不会删除那一项，因此状态项和任务对象（以及它们的内部状态）会不断地积累。

												
														public class MapLeaker {
    public ExecutorService exec = Executors.newFixedThreadPool(5);
    public Map<Task, TaskStatus> taskStatus 
        = Collections.synchronizedMap(new HashMap<Task, TaskStatus>());
    private Random random = new Random();

    private enum TaskStatus { NOT_STARTED, STARTED, FINISHED };

    private class Task implements Runnable {
        private int[] numbers = new int[random.nextInt(200)];

        public void run() {
            int[] temp = new int[random.nextInt(10000)];
            taskStatus.put(this, TaskStatus.STARTED);
            doSomeWork();
            taskStatus.put(this, TaskStatus.FINISHED);
        }
    }

    public Task newTask() {
        Task t = new Task();
        taskStatus.put(t, TaskStatus.NOT_STARTED);
        exec.execute(t);
        return t;
    }
}

												
										

图 1 显示 MapLeaker GC 之后应用程序堆大小随着时间的变化图。上升趋势是存在内存泄漏的警示信号。（在真实的应用程序中，坡度不会这么大，但是在收集了足够长时间的 GC 数据后，上升趋势通常会表现得很明显。）

确信有了内存泄漏后，下一步就是找出哪种对象造成了这个问题。所有内存分析器都可以生成按照对象类进行分解的堆快照。有一些很好的商业堆分析工具，但是找出内存泄漏不一定要花钱买这些工具 —— 内置的 hprof 工具也可完成这项工作。要使用 hprof 并让它跟踪内存使用，需要以 -Xrunhprof:heap=sites 选项调用 JVM。

清单 3 显示分解了应用程序内存使用的 hprof 输出的相关部分。（hprof 工具在应用程序退出时，或者用 kill -3 或在 Windows 中按 Ctrl+Break 时生成使用分解。）注意两次快照相比，Map.Entry、Task 和 int[] 对象有了显著增加。

请参阅 清单 3。

清单 4 展示了 hprof 输出的另一部分，给出了 Map.Entry 对象的分配点的调用堆栈信息。这个输出告诉我们哪些调用链生成了 Map.Entry 对象，并带有一些程序分析，找出内存泄漏来源一般来说是相当容易的。

												
														TRACE 300446:
	java.util.HashMap$Entry.<init>(<Unknown Source>:Unknown line)
	java.util.HashMap.addEntry(<Unknown Source>:Unknown line)
	java.util.HashMap.put(<Unknown Source>:Unknown line)
	java.util.Collections$SynchronizedMap.put(<Unknown Source>:Unknown line)
	com.quiotix.dummy.MapLeaker.newTask(MapLeaker.java:48)
	com.quiotix.dummy.MapLeaker.main(MapLeaker.java:64)

												
										

回页首

弱引用来救援了

SocketManager 的问题是 Socket-User 映射的生命周期应当与 Socket 的生命周期相匹配，但是语言没有提供任何容易的方法实施这项规则。这使得程序不得不使用人工内存管理的老技术。幸运的是，从 JDK 1.2 开始，垃圾收集器提供了一种声明这种对象生命周期依赖性的方法，这样垃圾收集器就可以帮助我们防止这种内存泄漏 —— 利用弱引用。

弱引用是对一个对象（称为 referent）的引用的持有者。使用弱引用后，可以维持对 referent 的引用，而不会阻止它被垃圾收集。当垃圾收集器跟踪堆的时候，如果对一个对象的引用只有弱引用，那么这个 referent 就会成为垃圾收集的候选对象，就像没有任何剩余的引用一样，而且所有剩余的弱引用都被清除。（只有弱引用的对象称为弱可及（weakly reachable）。）

WeakReference 的 referent 是在构造时设置的，在没有被清除之前，可以用 get() 获取它的值。如果弱引用被清除了（不管是 referent 已经被垃圾收集了，还是有人调用了 WeakReference.clear()），get() 会返回 null。相应地，在使用其结果之前，应当总是检查 get() 是否返回一个非 null 值，因为 referent 最终总是会被垃圾收集的。

用一个普通的（强）引用拷贝一个对象引用时，限制 referent 的生命周期至少与被拷贝的引用的生命周期一样长。如果不小心，那么它可能就与程序的生命周期一样 —— 如果将一个对象放入一个全局集合中的话。另一方面，在创建对一个对象的弱引用时，完全没有扩展 referent 的生命周期，只是在对象仍然存活的时候，保持另一种到达它的方法。

弱引用对于构造弱集合最有用，如那些在应用程序的其余部分使用对象期间存储关于这些对象的元数据的集合 —— 这就是 SocketManager 类所要做的工作。因为这是弱引用最常见的用法，WeakHashMap 也被添加到 JDK 1.2 的类库中，它对键（而不是对值）使用弱引用。如果在一个普通 HashMap 中用一个对象作为键，那么这个对象在映射从 Map 中删除之前不能被回收，WeakHashMap 使您可以用一个对象作为 Map 键，同时不会阻止这个对象被垃圾收集。清单 5 给出了 WeakHashMap 的 get() 方法的一种可能实现，它展示了弱引用的使用：

												
														public class WeakHashMap<K,V> implements Map<K,V> {

    private static class Entry<K,V> extends WeakReference<K> 
      implements Map.Entry<K,V> {
        private V value;
        private final int hash;
        private Entry<K,V> next;
        ...
    }

    public V get(Object key) {
        int hash = getHash(key);
        Entry<K,V> e = getChain(hash);
        while (e != null) {
            K eKey= e.get();
            if (e.hash == hash && (key == eKey || key.equals(eKey)))
                return e.value;
            e = e.next;
        }
        return null;
    }

												
										

调用 WeakReference.get() 时，它返回一个对 referent 的强引用（如果它仍然存活的话），因此不需要担心映射在 while 循环体中消失，因为强引用会防止它被垃圾收集。WeakHashMap 的实现展示了弱引用的一种常见用法 —— 一些内部对象扩展 WeakReference。其原因在下面一节讨论引用队列时会得到解释。

在向 WeakHashMap 中添加映射时，请记住映射可能会在以后“脱离”，因为键被垃圾收集了。在这种情况下，get() 返回 null，这使得测试 get() 的返回值是否为 null 变得比平时更重要了。

用 WeakHashMap 堵住泄漏

在 SocketManager 中防止泄漏很容易，只要用 WeakHashMap 代替 HashMap 就行了，如清单 6 所示。（如果 SocketManager 需要线程安全，那么可以用 Collections.synchronizedMap() 包装 WeakHashMap）。当映射的生命周期必须与键的生命周期联系在一起时，可以使用这种方法。不过，应当小心不滥用这种技术，大多数时候还是应当使用普通的 HashMap 作为 Map 的实现。

												
														public class SocketManager {
    private Map<Socket,User> m = new WeakHashMap<Socket,User>();
    
    public void setUser(Socket s, User u) {
        m.put(s, u);
    }
    public User getUser(Socket s) {
        return m.get(s);
    }
}

												
										

引用队列

WeakHashMap 用弱引用承载映射键，这使得应用程序不再使用键对象时它们可以被垃圾收集，get() 实现可以根据 WeakReference.get() 是否返回 null 来区分死的映射和活的映射。但是这只是防止 Map 的内存消耗在应用程序的生命周期中不断增加所需要做的工作的一半，还需要做一些工作以便在键对象被收集后从 Map 中删除死项。否则，Map 会充满对应于死键的项。虽然这对于应用程序是不可见的，但是它仍然会造成应用程序耗尽内存，因为即使键被收集了，Map.Entry 和值对象也不会被收集。

可以通过周期性地扫描 Map，对每一个弱引用调用 get()，并在 get() 返回 null 时删除那个映射而消除死映射。但是如果 Map 有许多活的项，那么这种方法的效率很低。如果有一种方法可以在弱引用的 referent 被垃圾收集时发出通知就好了，这就是引用队列 的作用。

引用队列是垃圾收集器向应用程序返回关于对象生命周期的信息的主要方法。弱引用有两个构造函数：一个只取 referent 作为参数，另一个还取引用队列作为参数。如果用关联的引用队列创建弱引用，在 referent 成为 GC 候选对象时，这个引用对象（不是 referent）就在引用清除后加入 到引用队列中。之后，应用程序从引用队列提取引用并了解到它的 referent 已被收集，因此可以进行相应的清理活动，如去掉已不在弱集合中的对象的项。（引用队列提供了与 BlockingQueue 同样的出列模式 —— polled、timed blocking 和 untimed blocking。）

WeakHashMap 有一个名为 expungeStaleEntries() 的私有方法，大多数 Map 操作中会调用它，它去掉引用队列中所有失效的引用，并删除关联的映射。清单 7 展示了 expungeStaleEntries() 的一种可能实现。用于存储键-值映射的 Entry 类型扩展了 WeakReference，因此当 expungeStaleEntries() 要求下一个失效的弱引用时，它得到一个 Entry。用引用队列代替定期扫描内容的方法来清理 Map 更有效，因为清理过程不会触及活的项，只有在有实际加入队列的引用时它才工作。

												
														    private void expungeStaleEntries() {
	Entry<K,V> e;
        while ( (e = (Entry<K,V>) queue.poll()) != null) {
            int hash = e.hash;

            Entry<K,V> prev = getChain(hash);
            Entry<K,V> cur = prev;
            while (cur != null) {
                Entry<K,V> next = cur.next;
                if (cur == e) {
                    if (prev == e)
                        setChain(hash, next);
                    else
                        prev.next = next;
                    break;
                }
                prev = cur;
                cur = next;
            }
        }
    }

												
										

回页首

结束语

弱引用和弱集合是对堆进行管理的强大工具，使得应用程序可以使用更复杂的可及性方案，而不只是由普通（强）引用所提供的“要么全部要么没有”可及性。下个月，我们将分析与弱引用有关的软引用，将分析在使用弱引用和软引用时，垃圾收集器的行为。

大多数具有一定重要性的 Web 应用程序都要求维护某种会话状态，如用户购物车的内容。如何在群集服务器应用程序中管理和复制状态对应用程序的可伸缩性有显著影响。许多 J2SE 和 J2EE 应用程序将状态存储在由 Servlet API 提供的 HttpSession 中。本月，专栏作家 Brian Goetz 分析了状态复制的一些选项以及如何最有效地使用 HttpSession 以提供好的伸缩性和性能。在本文论坛中与本文作者和其他读者分享您的观点。（可以单击文章顶部或者底部的 讨论访问论坛。）

不管正在构建的是 J2EE 还是 J2SE 服务器应用程序，都有可能以某种方式使用 Java Servlet —— 可能是直接地通过像 JSP 技术、Velocity 或者 WebMacro 这样的表示层，也可能通过一个基于 servlet 的 Web 服务实现，如 Axis 或者 Glue。Servlet API 提供的一个最重要的功能是会话管理 —— 通过 HttpSession 接口进行用户状态的认证、失效和维护。

会话状态

几乎每一个 Web 应用程序都有一些会话状态，这些状态有可能像记住您是否已登录这么简单，也可能是您的会话的更详细的历史，如购物车的内容、以前查询结果的缓存或者 20 页动态问卷表的完整响应历史。因为 HTTP 协议本身是无状态的，所以需要将会话状态存储在某处并与浏览会话以某种方式相关联，使得下次请求同一 Web 应用程序的页面时可以容易地获取。幸运的是，J2EE 提供了几种管理会话状态的方法 —— 状态可以存储在数据层，用 Servlet API 的 HttpSession 接口存储在 Web 层，用有状态会话 bean 存储在 Enterprise JavaBeans（EJB）层，甚至用 cookie 或者隐藏表单字段将状态存储在客户层。不幸的是，会话状态管理不当会带来严重的性能问题。

如果应用程序能够在 HttpSession 中存储用户状态，这种方法通常比其他方法更好。在客户端用 HTTP cookie 或者隐藏表单字段存储会话状态有很大的安全风险 —— 它将应用程序的一部分内部内容暴露给了非受信任的客户层。（一个早期的电子商务网站将购物车内容（包括价格）存储在隐藏表单字段中，从而可以很容易被非法利用，让任何了解 HTML 和 HTTP 的用户可以以 0.01 美元购买任何商品。噢）此外，使用 cookie 或者隐藏表单字段很混乱，容易出错，并且脆弱（如果用户禁止在浏览器中使用 cookie，那么基于 cookie 的方法就完全不能工作）。

在 J2EE 应用程序中存储服务器端状态的其他方法是使用有状态会话 bean，或者在数据库中存储会话状态。虽然有状态会话 bean 在会话状态管理方面有更大的灵活性，但是在可能的情况下，将会话状态存储在 Web 层仍然有好处。如果业务对象是无状态的，那么通常可以仅仅添加更多 Web 服务器来扩展应用程序，而不用添加更多 Web 服务器和更多 EJB 容器， 这样的成本一般要低一些并且容易完成。使用 HttpSession 存储会话状态的另一个好处是 Servlet API 提供了一种会话失效时通知的容易方法。在数据库中存储会话状态的成本可能难以承受。

servlet 规范没有要求 servlet 容器进行某种类型的会话复制或者持久性，但是它建议将状态复制作为 servlet 首要 存在理由（raison d'etre） 的重要部分，并且它对作为进行会话复制的容器提出了一些要求。会话复制可以提供大量好处 —— 负载平衡、伸缩性、容错和高可用性。相应地，大多数 servlet 容器支持某种形式的 HttpSession 复制，但是复制的机制、配置和时间是由实现决定的。

回页首

HttpSession API

简单地说， HttpSession 接口支持几种方法，servlet、JSP 页或者其他表示层组件可以用这些方法来跨多个 HTTP 请求维护会话信息。会话绑定到特定的用户，但是在 Web 应用程序的所有 servlet 中共享 —— 不特定于某一个 servlet。一种考虑会话的有用方法是，会话像一个在会话期间存储对象的 Map —— 可以用 setAttribute 按名字存储会话属性，并用 getAttribute 提取它们。 HttpSession 接口还包含会话生存周期方法，如 invalidate() （它通知容器应丢弃会话）。清单 1 显示 HttpSession 接口最常用的元素：

												
														public interface HttpSession {
    Object getAttribute(String s);
    Enumeration getAttributeNames();
    void setAttribute(String s, Object o);
    void removeAttribute(String s);

    boolean isNew();
    void invalidate();
    void setMaxInactiveInterval(int i);
    int getMaxInactiveInterval();
    ...
}

												
										

理论上，可以跨群集一致性地完全复制会话状态，这样群集中的所有节点都可以服务任何请求，一个简单的负载平衡器可以以轮询方式传送请求，避开有故障的主机。不过，这种紧密的复制有很高的性能成本，并且难于实现，当群集接近某一规模时，还会有伸缩性的问题。

一种更常用的方式是将负载平衡与会话相似性（affinity） 结合起来 —— 负载平衡器可以将会话与连接相关联，并将会话中以后的请求发送给同一服务器。有很多硬件和软件负载平衡器支持这个功能，并且这意味着只有主连接主机和会话需要故障转移到另一台服务器时才访问复制的会话信息。

回页首

复制方式

复制提供了一些可能的好处，包括可用性、容错和伸缩性。此外，有大量会话复制的方法可用：方法的选择取决于应用程序群集的规模、复制的目标和 servlet 容器支持的复制设施。复制有性能成本，包括 CPU 周期（存储在会话中的序列化对象）、网络带宽（广播更新），以及基于磁盘的方案中写入到磁盘或者数据库的成本。

几乎所有 servlet 容器都通过存储在 HttpSession 中的序列化对象进行 HttpSession 复制，所以如果是创建一个分布式应用程序，应当确保只将可序列化对象放到会话中。（一些容器对像 EJB 引用、事务上下文、还有其他非可序列化的 J2EE 对象类型有特殊的处理。）

基于 JDBC 的复制

一种会话复制的方法是序列化会话内容并将它写入数据库。这种方法相当直观，其优点是不仅会话可以故障转移到其他主机，而且即使整个群集失效，会话数据也可以保存下来。基于数据库的复制的缺点是性能成本 —— 数据库事务是昂贵的。虽然它可以在 Web 层很好地伸缩，但是它可能在数据层产生伸缩问题 —— 如果群集增长大到一定程度，扩展数据层以容纳会话数据会很困难或者成本无法接受。

基于文件的复制

基于文件的复制类似于使用数据库存储序列化的会话，只不过是使用共享文件服务器而不是数据库来存储会话数据。这种方式的成本一般比使用数据库的成本（硬件成本、软件许可证和计算开销）低，其代价则是可靠性（数据库可提供比文件系统更强的持久化保证）。

基于内存的复制

另一种复制方式是与群集中的一个或者多个其他服务器共享序列化的会话数据副本。复制所有会话到所有主机中提供了最大的可用性，并且负载平衡最容易，但是因为复制消息所消耗的每个节点的内存和网络带宽，最终会限制群集的规模。一些应用服务器支持与“伙伴（buddy）”节点的基于内存的复制，其中每一个会话存在于主服务器上和一台（或更多）备份服务器上。这种方案比将所有会话复制到所有服务器的伸缩性更好，但是当需要将会话故障转移到另一台服务器上时会使负载平衡任务复杂化，因为它必须找出另外哪一台（几台）服务器有这个会话。

时间考虑

除了决定如何存储复制会话数据，还有什么时候复制数据的问题。最可靠但也最昂贵的方法是每次数据改变时复制它（如每次 servlet 调用结束）。不那么昂贵、但是在故障时会有丢失一些数据的风险的方法是在每超过 N 秒时复制数据。

与时间问题有关的问题是，是复制整个会话还是只试尝复制会话中改变了的属性（它包含的数据会少得多）。这些都需要在可靠性和性能之间进行取舍。Servlet 开发人员应当认识到在故障转移时，会话状态可能变得“过时”（是几次请求前的复制），并应当准备处理不是最新的会话内容。（例如，如果一个interview 的第 3 步产生一个会话属性，而用户在第 4 步时，请求被故障转移到一个具有两次请求之前的会话状态复制的系统上，那么第 4 步的 servlet 代码应预备在会话中找不到这个属性，并采取相应的行动 —— 如重定向，而不是认定它会在那里、并在找不到它时抛出一个 NullPointerException 。）

回页首

容器支持

Servlet 容器的 HttpSession 复制选项以及如何配置这些选项是各不相同的。IBM WebSphere ®提供的复制选项是最多的，它提供了在内存中复制或者基于数据库的复制、在 servlet 末尾或者基于时间的复制时间、传播全部会话快照（JBoss 3.2 或以后版本）或者只传播改变了的属性等选择。基于内存的复制基于 JMS 发布-订阅，它可以复制到所有克隆、一个“伙伴”复制品或者一个专门的复制服务器。

WebLogic 还提供了一组选择，包括内存中（使用一个伙伴复制品）、基于文件的或者基于数据库的。JBoss 与 Tomcat 或者 Jetty servlet 容器一同使用时，进行基于内存的复制，可以选择 servlet 末尾或者基于时间的复制时间，而快照选项（在 JBoss 3.2 或以后版本）是只复制改变了的属性。Tomcat 5.0 为所有群集节点提供了基于内存的复制。此外，通过像 WADI 这样的项目，可以用 servlet 过滤机制将会话复制添加到像 Tomcat 或者 Jetty 这样的 servlet 容器中。

回页首

改进分布式 Web 应用程序的性能

不管决定使用什么机制进行会话复制，可以用几种方式改进 Web 应用程序的性能和伸缩性。首先记住，为了获得会话复制的好处，需要在部署描述符中将 Web 应用程序标记为 distributable，并保证在会话中的所有内容都是可序列化的。

保持会话最小

因为复制会话有随着会话中的对象图（object graph） 的变大而增加成本，所以应当尽可能地在会话中少放置数据。这样做会减少复制的序列化的开销、网络带宽要求和磁盘要求。特别地，将共享对象存储在会话中一般不是好主意，因为它们需要复制到它们所属的 每一个会话中。

不要绕过 setAttribute

在改变会话的属性时，要知道即使 servlet 容器只是试图做最小的更新（只传播改变了的属性），如果没有调用 setAttribute ，容器也可能没有注意到已经改变的属性。（想像在会话中有一个 Vector ，表示购物车中的商品 —— 如果调用 getAttribute() 获取 Vector 、然后向它添加一些内容，并且不再次调用 setAttribute ，容器可能不会意识到 Vector 已经改变了。）

使用细化的会话属性