Bean的作用域

Spring容器创建的Bean默认是单例的。Spring容器调用配置方法完成Bean的创建之后，Bean就缓存在Spring容器里。之后每次调用同一配置方法创建Bean，Spring容器只会返回缓存在Spring容器里的Bean，不再创建新的Bean。这意味着同一配置方法在同一Spring容器里无论被调用了多少次，都只会返回同一实例的Bean。因此，Spring容器创建的Bean默认是单例的。同时我们也应注意到，这里的单例与单例设计模式里的单例是有区别的，不能混为一谈。单例设计模式里的单例指的是类的实例由类的加载器方法创建，无论类的加载器方法被调用了多少次，都只会返回同一实例。

在Web开发中，我们通常只需创建单例的Bean。因为诸如控制器之类的Bean是无状态的。无论哪个用户发来请求，都能使用同一控制器实例处理，根本就不需要再创建新的控制器实例。然而对于一些类，比如数据模型类，每个请求所产生或获取的数据都是不一样的。这意味着这样的类是有状态的。把这些有状态的类创建为单例的显然不妥。作为替代，我们通常选择创建这些类的域对象(Domain Object)，通过new关键字在Bean的方法中创建这些类的实例。因此，在Web开发中，我们往往只需告诉Spring容器创建单例的Bean

然而，在某些罕见的应用场景中，我们可能需要创建非单例的Bean。这意味着除了单例(Singleton)作用域之外，Spring容器还需支持创建具有其它作用域的Bean。具体如下：
1.原型(Prototype)：Spring容器每次调用配置方法创建Bean时都会重新创建Bean的实例，调用几次就创建几个实例。
2.请求(Request)：请求指的是Web请求，只有Web相关的Spring容器(比如XmlWebApplicationContext)才支持请求作用域。指定作用域为请求后，同一配置方法在同一Web请求里无论被调用了多少次，都只会创建一个Bean的实例。
3.会话(Session)：会话指的是Web会话，只有Web相关的Spring容器(比如XmlWebApplicationContext)才支持会话作用域。指定作用域为会话后，同一配置方法在同一Web会话里无论被调用了多少次，都只会创建一个Bean的实例。

Bean的作用域可由@Scope注解配置。@Scope注解有个String类型的value属性。我们可把singleton(单例)，prototype(原型)，request(请求)或session(会话)这些字符串指给@Scope注解，告诉Spring容器创建具有相应作用域的Bean。如下所示：

@Bean("music")
@Scope(value="singleton")
public Music produceMusic() {
    return new Music("Dream");
}

当然，@Scope注解除了可以加到配置方法之外，也能以同样的方式加到带有@Component注解的组件上。至于XML配置文件，则可使用XML的scope属性这样配置：

<bean id="music" class="com.dream.Music" scope="singleton">
    <constructor-arg value="Dream" />
</bean>

于是，我们弄清楚了单例，原型，请求，会话这些作用域。却也开始感到困惑：“假如把原型作用域的Bean注入到单例作用域的Bean中，这时会怎么样？”

毫无疑问，这是一个问题。Spring容器创建单例的Bean时就把原型的Bean注入进去了。之后，Spring容器每次用到单例的Bean时都是从Spring容器那里获取的，没再创建新的实例。这意味着原型的Bean只在注入的时候创建了一次，之后一直被单例的Bean引用着，无论单例的Bean用了多少次原型的Bean，原型的Bean始终是注入时的那个实例。如果我们希望单例的Bean每次用到原型的Bean时，原型的Bean都会返回一个新的实例，则需要做些额外的配置。而这配置，其中之一就是查找方法注入(Lookup Method Injection)

简单来说，查找方法注入就是单例的Bean每次用到原型的Bean时，都会调用指定的方法从Spring容器那里获取原型的Bean。而从Spring容器那里获取原型的Bean时，Spring容器总会返回新的实例。如此一来，单例的Bean每次用到原型的Bean时，原型的Bean的实例就总是新的了。

假如现有这样一个原型作用域的Bean：

@Scope("prototype")
@Component("music")
public class Music {
    private String musicName = null;

    public Music(@Value("Dream") String musicName) {
        this.musicName = musicName;
    }

    // 省略getter, setter方法
}

我们希望把它注入到单例作用域的Bean里。这时可以这样定义单例作用域的Bean：

@Component("player")
public abstract class Player {
    @Lookup(value="music")
    protected abstract Music getPlayingMusic();

    // 省略其它代码
}

这是一个抽象类，定义了一个抽象方法，用于获取Music类型的Bean。特别引人注目的是，抽象方法上面带着一个神秘的@Lookup(value="music")注解。

这是怎么回事呢？

原来，Spring容器瞧见@Lookup注解之后就会生成一个代理类。代理类将重写带有@Lookup注解的抽象方法，使之具有这样的功能：从Spring容器那里查找@Lookup注解指定的Bean，并在找到之后进行返回。这样一来，单例的Bean每次用到原型的Bean时，都会调用代理方法从Spring容器那里获取原型的Bean。而从Spring容器那里获取的原型的Bean的实例总是新的，从而使单例的Bean每次用到原型的Bean时，用的都是新的实例。

因此，@Lookup注解有个String类型的value属性，用于指定即将查找的Bean的ID。如果没有指定value属性，代理方法就会查找与代理方法的返回值的类型一样的Bean

在我们的配置中，我们在抽象方法getPlayingMusic上添加了@Lookup(value="music")注解，告诉Spring容器生成代理类，使单例的Player每次用到的原型的Music都是新的实例。

还有，XML也支持同样的配置。具体如下：

<beans  /* 省略命名空间和XSD模式文件声明 */>
    <bean id="music" class="com.dream.Music" scope="prototype">
        <constructor-arg value="Dream" />
    </bean>

    <bean id="player" class="com.dream.Player">
        <lookup-method name="getPlayingMusic" bean="music" />
    </bean>
</beans>

这段代码使用XML配置了两个Bean：

1.一个Bean是Music类型的，其作用域是原型的。
2.一个Bean是Player类型的，其作用域没有指定，默认是单例的。

特别需要留意的是，配置Player类型的Bean时用到了 <lookup-method name="getPlayingMusic" bean="music" /> 元素。Spring容器瞧见这个元素之后，就会生成一个代理类。代理类将重写<lookup>元素的name属性指定的方法，使之每次被调用的时候，都从Spring容器那里获取<lookup>元素的bean属性指定的Bean。如此一来，单例的Player每次用到原型的Music时，用的就都是新的实例了。

于是，我们弄清楚了怎样把原型的Bean注入单例的Bean里，可这并不意味着我们可以停下探索的脚步。因为把请求作用域的Bean注入单例作用域的Bean里也有同样的问题。

假如现有这样一个单例作用域的Bean：

@Component
public class Player {
    private Music playingMusic = null;

    @Autowired
    public Player(Music playingMusic) {
        this.playingMusic = playingMusic;
    }
}

我们希望注入Player构造函数的是一个请求作用域的Music类型的Bean。这时可以这样配置Music：

@Component
@Scope(value="request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class Music {
    private String musicName = null;

    public String getMusicName() {
        return this.musicName;
    }

    @Value("Dream")
    public void setMusicName(String musicName) {
        this.musicName = musicName;
    }
}

Music类上带着@Scope(value="request", proxyMode = ScopedProxyMode.TARGET_CLASS)注解，其value属性的值是 request ，表明该Bean的作用域是请求。同时我们也注意到了，@Scope注解还有一个proxyMode属性，其值是ScopedProxyMode.TARGET_CLASS

这是怎么回事呢？

原来，proxyMode属性是ScopedProxyMode枚举类型的，能够告诉Spring容器生成代理的方式。具体如下：
1.NO：告诉Spring容器无需生成代理。
2.TARGET_CLASS：告诉Spring容器基于类生成代理。
3.INTERFACES：告诉Spring容器基于接口生成代理。
4.DEFAULT：默认的代理方式。默认与NO一样，用于告诉Spring容器无需生成代理。也可通过配置，使之告诉Spring容器默认基于类或接口生成代理。

由此可知，如果把ScopedProxyMode.TARGET_CLASS或ScopedProxyMode.INTERFACES指给proxyMode属性，Spring容器就会生成代理类。Spring容器创建Bean的时候，只会创建代理类的Bean。因此，Spring容器把请求作用域的Bean注入到单例作用域的Bean时，注入的实际是代理类的Bean。如此一来，单例的Bean用到请求的Bean时，用的实际是代理类的Bean。代理类的Bean会先判断一下当前是不是在同一Web请求里：如果是，则返回缓存在Spring容器里的Bean；如果不是，则再创建一个新的实例进行返回。从而使单例的Bean用到请求的Bean时，不同的Web请求将会返回Bean的不同实例。

Spring容器生成代理的方式有两种：一种是基于类生成代理；一种是基于接口生成代理。如果希望基于类生成代理，可把@Scope注解的proxyMode属性的值置为ScopedProxyMode.TARGET_CLASS。Music类上的@Scope注解的proxyMode属性的值就是ScopedProxyMode.TARGET_CLASS；如果希望基于接口生成代理，则必须让我们的类实现某个接口。因此，配置之前我们首先需要定义一个接口：

public interface IMusic {
    public String getMusicName();
    public void setMusicName(String musicName);
}

之后让Music类实现IMusic接口，并把proxyMode属性的值置为ScopedProxyMode.INTERFACES：

@Component
@Scope(value="request", proxyMode = ScopedProxyMode.INTERFACES)
public class Music implements IMusic {
    private String musicName = null;

    @Override
    public String getMusicName() {
        return this.musicName;
    }

    @Override
    @Value("Dream")
    public void setMusicName(String musicName) {
        this.musicName = musicName;
    }
}

最后把注入Player的Music改成IMusic接口：

@Component
public class Player {
    private IMusic playingMusic = null;

    public IMusic getPlayingMusic() {
        return this.playingMusic;
    }

    @Autowired
    public Player(IMusic playingMusic) {
        this.playingMusic = playingMusic;
    }
}

于是，基于接口生成代理的配置就完成了。当然，这里只讲了怎样进行请求作用域的注入。可实际上，会话作用域也有同样的问题。我们只需进行同样的配置就行了，不再赘叙。还有，如果想用XML进行同样的配置，则可提供一个XML配置文件配置如下：

<beans /* 省略命名空间和XSD模式文件声明 */
       xmlns:aop="http://www.springframework.org/schema/aop"
       xsi:schemaLocation="
       /* 省略命名空间和XSD模式文件声明 */
       http://www.springframework.org/schema/aop
       http://www.springframework.org/schema/aop/spring-aop.xsd">

    <bean id="music" class="com.dream.Music" scope="request">
        <aop:scoped-proxy proxy-target-class="false" />
        <property name="musicName" value="Dream" />
    </bean>

    <bean id="player" class="com.dream.Player">
        <constructor-arg ref="music" />
    </bean>
</beans>

这段配置引入了spring-aop.xsd模式文件。这是一个用于配置面向切面编程的模式文件，我们将在介绍面向切面编程的时候另行介绍。现在只需知道这个模式文件定义了个<aop:scoped-proxy>元素，用于配置作用域代理。里面有个proxy-target-class属性，用于配置生成代理的方式：如果proxy-target-class属性的值是TRUE，则基于类生成代理；如果proxy-target-class属性的值是FALSE，则基于接口生成代理。proxy-target-class属性的值默认是TRUE

至此，关于Bean的作用域的介绍也就告一段落了。下章，我们将会开始介绍事件的监听与发布。欢迎大家继续阅读，谢谢大家！

返回目录    下载代码