依赖注入及AOP简述（九）——单例和无状态Scope

三、依赖注入对象的Scope及其生命周期

在前面的章节我们讲到，依赖注入容器之所以能够区别于以往的ServiceLocator等容器，是在于其不但能够自动构建多层次的、完整的依赖关系图，并且可以管理依赖对象的Scope和对其进行行为增强。有关行为增强的话题我们会在下一章介绍，这里我们先来看看有关依赖对象的Scope及其生命周期管理的话题。

 

1.     依赖注入对象的Scope

Scope，即作用域，是指面向对象开发中所设计的某一类对象的生存期间。我们先从普通Java程序开发中最常用的单例和无状态两种Scope入手，之后再来讨论Web应用程序开发中几种常见的Scope。

 

1.1.    单例和无状态Scope

无状态Scope是最简单、生存期间最短的一种Scope，我们所有通过new出来的非静态对象都属于这种Scope，它随着使用这个对象的对象（可能是依赖者类，也可能是依赖者类里的一个方法）的消亡而消亡。反之，单例则是生存期间最长的一种Scope，它以静态的模式生存在JVM的“旧年代区域”，永远不会被JVM回收。比如我们肯定都写过或使用过类似这样的单例模式：

public class BankICBC implements Bank {         private static Bank bankICBC; // bankICBC为一个静态单例     private BankICBC() {} // 私有构造方法，使得外界无法直接new出其对象       public static Bank Instance() {         return null == bankICBC ? new BankICBC() : bankICBC; // 创建一个单例对象     }     // …… }

 

 

 

 

 

 

还用我们取款的例子来说，假设这个储户用的存折类型是定期存单，取款之后银行要收回定期存单，这种情况下对于每一次取款的存折依赖来说，它都是一个无状态的，也就是说每次取款都需要一个新的存折，因此这个时候存折就是一个无状态的依赖。我们再假设这个储户附近只有一所银行，也就是说不管什么时候去取款都会去同一所银行，此时银行就是一个单例的依赖，每次执行withDraw方法是都是使用的同一个银行依赖对象。

在依赖注入框架之前，我们对于无状态的存折依赖和单例的银行依赖的创建，可能会分别使用new和静态的方式。new方式的诸多问题我们已经在第一章讨论过了。而静态的方式同样有着开发者负担管理JVM全局变量的不便或是易造成内存泄漏等诸多问题。依赖注入框架可以帮助开发者管理这些Scope的依赖，使得开发者获取不同Scope的依赖对象变得非常简单并且不需要自己去维护它。

下面我们以Seam框架为例说明如何定义这两种Scope。Spring、Guice框架也具有极为类似的定义方式，就不再具体举例了。

 

@Name("bank") @Scope(ScopeType.APPLICATION) // 声明为单例Scope public class BankICBC implements Bank { // ……  }   @Name("depositBook") @Scope(ScopeType.STATELESS) // 声明为无状态Scope public class DepositBookICBC implements DepositBook { // ……  }

 

 

 

 

注意在依赖注入框架中，所谓“单例”并不是传统意义上的单例，它不是JVM中唯一存在的一个静态变量，而是以依赖注入容器（Injector）为单位唯一存在的非静态变量，从而避免了过多占用JVM的旧年代区域的内存等问题。