public   class  Singleton  {   
  
   static   class  SingletonHolder  {   
     static  Singleton instance  =   new  Singleton();   
  }    
  
   public   static  Singleton getInstance()  {   
     return  SingletonHolder.instance;   
  }    
  
}   

这个写法的发明者是Google公司的Bob lee。
他还写了个轻量级IoC容器，据说不要配制文件，性能比spring快100倍。感觉100倍有些夸张，不过可以看看。

最后的部分：
看完本文，如果你对visitor模式有更多的兴趣，想了解更多请看如下几篇文章。
1,静态分派，动态分派，多分派，单分派 --------------   visitor模式准备
2,访问差异类型的集合类 ------------------------   visitor模式入门
3,visitor模式理论及学术概念-------------－-----   visitor模式进一步(本文）
4，重载overloading和覆写overriding哪个更早执行--   visitor帮助篇
虽然排列顺序是1,2,3,4 但是我个人建议的学习方式是2,1,3,4因为这个顺序更方便一般人理解

class Cat{}
class WhiteCat extends Cat{}
class BlackCat extends Cat{}
public class Person {
    public void feed(Cat cat){
        System.out.println("feed cat");
    }
    public void feed(WhiteCat cat){
        System.out.println("feed WhiteCat");
    }
    public void feed(BlackCat cat){
        System.out.println("feed BlackCat");
    }
    public static void main(String[] args) {
        Cat wc = new WhiteCat();
        Cat bc = new BlackCat();
        Person p = new Person();
        p.feed(wc);
        p.feed(bc);
    }

}

class Cat{
    public void eat(){
        System.out.println("cat eat");
    }
}
public class BlackCat extends Cat{
    public void eat(){
        System.out.println("black cat eat");
    }
    public static void main(String[] args){
        Cat cat = new BlackCat();
        cat.eat();
    }
}

看完本文，如果你对visitor模式有更多的兴趣，想了解更多请看如下几篇文章。
1,静态分派，动态分派，多分派，单分派 --------------   visitor模式准备(本文）
2,访问差异类型的集合类 ------------------------   visitor模式入门
3,visitor模式理论及学术概念-------------－-----   visitor模式进一步
4，重载overloading和覆写overriding哪个更早执行--   visitor帮助篇
虽然排列顺序是1,2,3,4但是我个人建议的学习方式是2,1,3,4因为这个顺序更方便一般人理解

1 Iterator ie  =  list.iterator();
2 while (ie.hasNext()) {
3     Person p  =  (Person)ie.next();
4     p.doWork();
5 }

这种访问的特点是集合类中的对象是同一类对象Person，他们拥有功能的方法run,我们调用的恰好是这个共同的方法。
在大部份的情况下，这个是可以的，但在一些复杂的情况，如被访问者的继承结构复杂，被访问者的并不是同一类对象，
也就是说不是继承自同一个根类。方法名也并不相同。例如Java GUI中的事件就是一个例子。
例如这样的问题，有如下类和方法:
类：PA ,方法：runPA();
类：PB ,方法：runPB();
类：PC ,方法：runPC();
类：PD ,方法：runPD();
类：PE ,方法：runPE();
有一个集合类List
List list = new ArrayList();
list.add(new PA());
list.add(new PB());
list.add(new PC());
list.add(new PD());
list.add(new PE());
....
二:解决
要求能访问到每个类的对应的方法。我们第一反应应该是这样的。

 1 Iterator ie  =  list.iterator();
 2 while (ie.hasNext()) {
 3     Object obj  =  ie.next();
 4      if  (obj  instanceof  PA) {
 5         ((PA)obj).runPA();
 6     } else   if (obj  instanceof  PB) {
 7         ((PB)obj).runPB();
 8     } else   if (obj  instanceof  PC) {
 9         ((PC)obj).runPC();
10     } else   if (obj  instanceof  PD) {
11         ((PD)obj).runPD();
12     } else   if (obj  instanceof  PE) {
13         ((PE)obj).runPE();
14     }
15 }

三：新问题及分析解决
当数目变多的时候，维护if else是个费力气的事情：
仔细分析if,else做的工作，首先判断类型，然後根据类型执行相应的函数
如何才能解决这两个问题呢？首先想到的是java的多态，多态就是根据参数执行相应的内容，
能很容易的解决第二个问题，我们可以写这样一个类：

 1 public   class  visitor {
 2      public   void  run(PA pa) {
 3         pa.runPA();
 4     }
 5      public   void  run(PB pb) {
 6         pb.runPB();
 7     }
 8      public   void  run(PC pc) {
 9         pc.runPC();
10     }
11      public   void  run(PD pd) {
12         pd.runPD();
13     }
14      public   void  run(PE pe) {
15         pe.runPE();
16     }
17 }

这样只要调用run方法，传入对应的参数就能执行了。
还有一个问题就是判断类型。由于重载(overloading)是静态多分配（java语言本身是支持"静态多分配"的。
关于这个概念请看这里)所以造成重载只根据传入对象的定义类型，而不是实际的类型，所以必须在传入前就确定类型，
这可是个难的问题,因为在容器中对象全是Object，出来后要是判断是什么类型必须用
if (xx instanceof xxx)这种方法，如果用这种方法启不是又回到了原点，有没有什么更好的办法呢？

我们知到Java还有另外一个特点，覆写(overriding)，而覆写是"动态单分配"的（关于这个概念见这里)，
那如何利用这个来实现呢？看下边这个方法:
 我们让上边的一些类PA PB PC PD PE都实现一个接口P,加入一个方法,accept();

 1 public   void  accept(visitor v) {
 2      // 把自己传入1
 3     v.run( this );
 4 }
 5 然後在visitor中加入一个方法
 6 public   void  run(P p) {
 7      // 把自己传入2
 8     p.accept( this );
 9 }
10 // 这样你在遍历中可以这样写
11 Visitor v  =   new  Visitor();
12 Iterator ie  =  list.iterator();
13 while (ie.hasNext()) {
14     P p  =  (P)ie.next();
15         p.accept(v);
16     }
17 }

首先执行的是"把自己传入2"，在这里由于Java的特性，实际执行的是子类的accept(),也就是实际类的accept
然後是"把自己传入1"，在这里再次把this传入，就明确类型，ok我们巧妙的利用overriding解决了这个问题
其实归纳一下第二部分，一个关键点是"自己认识自己"，是不是很可笑。
其实在计算计技术领域的很多技术上看起来很高深的东西，其实就是现有社会中人的生活方式的一种映射
而且这种方式是简单的不能再简单的方式。上边的全部过程基本上是一个简单的visitor模式实现,visitor模式
已经是设计模式中比较复杂的模式了，但其实原理简单到你想笑。看看下边这个比喻也许你的理解会更深刻。

四：一个帮助理解的比喻：
题目：指挥工人工作
条件：你有10个全能工人，10样相同工作。
需求：做完工作
实现：大喊一声所有人去工作

条件变了，工人不是全能，但是工作相同，ok问题不大
条件再变,工作不是相同，但工人是全能，ok问题不大

以上三种情况在现实生活中是很少发生得，最多的情况是这样：
10个工人，每人会做一种工作，10样工作。你又一份名单Collection)写着谁做什么。但你不认识任何人
这个时候你怎么指挥呢，方案一：
你可以一个个的叫工人，然後问他们名字，认识他们，查名单，告诉他们做什么工作。
你可以直接叫出他们名字，告诉他们干什么，不需要知到他是谁。
看起来很简单。但如果你要指挥10万人呢 ？而且人员是流动的，每天的人不同，你每天拿到一张文档。
其实很简单，最常用的做法是，你把这份名单贴在墙上，然後大喊一声，所有人按照去看，按照自己的分配情况去做。
这里利用的关键点是"所有工人自己认识自己"，你不能苛求每个工人会做所有工作，不能苛求所有工作相同，但你
能要求所有工人都认识自己。

再想想我们开始的程序,每个工人对应着PA PB PC PD PE....
所有的工人都使工人P
每个工人会做的东西不一样runPA runPB runPC
你有一份名单Visitor（重载）记录着谁做什么工作。

看完上边这些，你是不是会产生如下的问题：
问题：为什么不把这些方法的方法名做成一样的，那就可以解决了。
例如，我们每个PA ,PB ,PC都加入一个run 方法，然後run内部再调用自己对应的runPx()方法。
答案：有些时候从不同的角度考虑，或者因为实现的复杂度早成很难统一方法名。
例如上边指挥人工作的例子的例子，其实run方法就是大叫一声去工作，因为每个工人只会做一种工作，所以能行
但我们不能要求所有人只能会做一种事情，这个要求很愚蠢。所以如果每个工人会干两种或者多种工作呢,
也就是我PA 有runPA() walkPA()等等方法， PB有runPB() climbPB()等等。。。
这个时候按照名单做事才是最好的办法。

五：作者的话
所以说模式中很多复杂的东西，在现实中其实是很基本的东西，多多代入代出能帮助理解模式。

看完本文，如果你对visitor模式有更多的兴趣，想了解更多请看如下几篇文章。
1,静态分派，动态分派，多分派，单分派 --------------   visitor模式准备
2,访问差异类型的集合类 ------------------------   visitor模式入门（本文）
3,visitor模式理论及学术概念-------------－-----   visitor模式深入
4，重载overloading和覆写overriding哪个更早执行--   visitor帮助篇
虽然排列顺序是1,2,3,4 但是我个人建议的学习方式是2,1,3,4因为这个顺序更方便一般人理解

对比依赖倒置，控制反转，依赖注入?
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
1，依赖倒置：
先说明什么是"正置"
正置就是，当你设计一些类库的时候，考虑到用户的需要定义一些接口，用户的应用程序依赖这些接口

对比"正置"和"倒置"
正置：应用依赖接口，接口由类库设计者定义
优点：类库实现上自由度大，实现容易。
缺点：类库设计复杂，要预测应用的需求，同时有可能不符合应用的需求

倒置：应用定义接口，类库设计者实现接口，按照接口实现类库
优点：类库设计不再需要预测，肯定符合应用需求
缺点：类库有可能难以实现

简单来说，正置和倒置的区别在于，谁来制定标准。现实中因为需求的定义是客户决定的，所以倒置更
适合程序的设计。从需求出发，到底层实现。

使用目的：便于应用按照需求设计
关注点:接口的设计
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
2，控制反转：
正常的控制：
 没有一定的控制流程，下一个流程由上一个流程决定，实现应用需要自己控制流程
控制反转  ：
 抽象出固定的流程，实现应用就是填充流程中的一个个点。
 所有的框架都是基于控制反转的。Windows GUI开发也多是这样。
目的：高度抽象，设计框架
关注点：流程的设计
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
3,依赖注入
原始的情况：
 应用自己new 类，或者使用工厂模式创建类
依赖注入：
 容器创建类，通过构造函数，setter方法，接口等方法，运行时"注入"到应用中

实现：
Spring        setter方法
webwork IOC  实现接口的方法
pico   构造函数的方法

目的：完全分离开发
关注点：构造对象

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
关系：
"控制反转"是"依赖倒置"的一种,"依赖注入"是在"控制反转"的基础上，让容器来完成"注入"过程。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
最需要依赖注入的情况：
"调用者"和多个"被调用者"分别开发，分别打包分发，实施者根据实际情况决定使用哪个"被调用者"被使用
做成可配制的，这种情况是经常需要的。这个时候调用者内不能出现这样的代码:
interface inter = new interfaceimplA();类似的语句。因为使用的可能是interfaceimplB
为了避免这样语句的出现，我们直接使用接口，而对象的构造推迟，让容器根据实施者的配制来构造，并注入
正确的位置。

依赖倒置、控制反转和依赖注入辨析

依赖和耦合（Dependency and Coupling） 

接口和实现分离 

　　把接口和实现分开是人们试图控制依赖关系的第一个尝试，图 1是Robert C. Martin在《依赖倒置》[Martin 1996]一文中所举的第一个例子。其中，ReadKeyboard()和WritePrinter()为函数库中的两个函数，应用程序循环调用这两个函数，以便把用户键入的字符拷贝到打印机输出。

　　为了使应用程序不依赖于函数库的具体实现，C语言把函数的定义写在了一个分离的头文件（函数库.h）中。这种做法的好处是：虽然应用程序要调用函数库、依赖于函数库，但是，当我们要改变函数库的实现时，只要重写函数的实现代码，应用程序无需发生变化。例如，改变函数库.c文件，把WritePrinter()函数重新实现成向磁盘中输出，这时只要将应用程序和函数库重新链接，程序的功能就会发生相应的变化。
　　上面的函数库也可以采用C++语言来实现。我们通常把这种用面向对象技术实现的，为应用程序提供多个支持类的模块称为 “类库”，如图 2所示。这种通过分离接口和实现来消解应用程序和类库之间依赖关系的做法具有以下特点：
　　1. 应用程序调用类库，依赖于类库。
　　2. 接口和实现的分离从一定的程度上消解了这个依赖关系，具体实现可以在编译期间发生变化。但是，这种消解方法的作用非常有限。比如说，一个系统中无法容纳多个实现，不同的实现不能动态发生变化，用WritePrinter函数名来实现向磁盘中输出的功能也显得非常古怪，等等。
　　3. 类库可以单独重用。但是应用程序不能脱离类库而重用，除非提供一个实现了相同接口的类库。

 

依赖倒置（Dependency Inversion Principle） 

　　可以看出，上面讨论的简单分离接口的方法对于依赖关系的消解作用非常有限。Java语言提供了纯粹的接口类，这种接口类不包括任何实现代码，可以更好地隔离两个模块。C++语言中虽然没有定义这种纯粹的接口类，但所有成员函数都是纯虚函数的抽象类也不包含任何实现代码，可以起到类似于Java接口类的作用。为了和上一节中提到的简单接口相区别，本文后面将把基于Java 接口类或C++抽象类定义的接口称为抽象接口。依赖倒置原则就是建立在抽象接口的基础上的。Robert Martin这样描述依赖倒置原则[Martin 1996]：
　　A. 上层模块不应该依赖于下层模块，它们共同依赖于一个抽象。
　　B. 抽象不能依赖于具象，具象依赖于抽象。
　　其含义是：为了消解两个模块间的依赖关系，应该在两个模块之间定义一个抽象接口，上层模块调用抽象接口定义的函数，下层模块实现该接口。如图 3所示，对于上一节的例子，我们可以定义两个抽象类Reader和Writer作为抽象接口，其中的Read()和Write()函数都是纯虚函数，而具体的KeyboardReader和PrinterWriter类实现了这些接口。当应用程序调用Read()和Write()函数时，由于多态性机制的作用，实际调用的是具体的KeyboardReader和PrinterWriter类中的实现。因此，抽象接口隔离了应用程序和类库中的具体类，使它们之间没有直接的耦合关系，可以独立地扩展或重用。例如，我们可以用类似的方法实现FileReader或DiskWriter类，应用程序既可以根据需要选择从键盘或文件输入，也可以选择向打印机或磁盘输出，甚至同时完成多种不同的输入、输出任务。由此可以总结出，这种通过抽象接口消解应用程序和类库之间依赖关系的做法具有以下特点：
　　1. 应用程序调用类库的抽象接口，依赖于类库的抽象接口；具体的实现类派生自类库的抽象接口，也依赖于类库的抽象接口。
　　2. 应用程序和具体的类库实现完全独立，相互之间没有直接的依赖关系，只要保持接口类的稳定，应用程序和类库的具体实现都可以独立地发生变化。
　　3. 类库完全可以独立重用，应用程序可以和任何一个实现了相同抽象接口的类库协同工作。

　　一般情况下，由于类库的设计者并不知道应用程序会如何使用类库，抽象接口大多由类库设计者根据自己设想的典型使用模式总结出来，并保留一定的灵活度，以提供给应用程序的开发者使用。
　　但还有另外一种情况。图 4是Martin Fowler在《Reducing Coupling》一文中使用的一个例子[Fowler 2001]。其中，Domain包要使用数据库包，即Domain包依赖于数据库包。为了隔离Domain包和数据库包，可以引入一个Mapper包。如果在特定的情况下，我们希望Domain包能够被多次重用，而Mapper包可以随时变化，那么，我们就必须防止Domain包过分地依赖于Mapper包。这时，可以由 Domain包的设计者总结出自己需要的抽象接口（如Store），而由Mapper包的设计者来实现该抽象接口。这样一来，无论是在接口层面，还是在实现层面，依赖关系都完全颠倒过来了。

 

控制反转（Inversion of Control） 

　　前面描述的是应用程序和类库之间的依赖关系。如果我们开发的不是类库，而是框架系统，依赖关系就会更强烈一点。那么，该如何消解框架和应用程序之间的依赖关系呢？
　　《道法自然》第5章描述了框架和类库之间的区别：
　　“框架和类库最重要的区别是：框架是一个‘半成品’的应用程序，而类库只包含一系列可被应用程序调用的类。
　　“类库给用户提供了一系列可复用的类，这些类的设计都符合面向对象原则和模式。用户使用时，可以创建这些类的实例，或从这些类中继承出新的派生类，然后调用类中相应的功能。在这一过程中，类库总是被动地响应用户的调用请求。
　　“框架则会为某一特定目的实现一个基本的、可执行的架构。框架中已经包含了应用程序从启动到运行的主要流程，流程中那些无法预先确定的步骤留给用户来实现。程序运行时，框架系统自动调用用户实现的功能组件。这时，框架系统的行为是主动的。
　　“我们可以说，类库是死的，而框架是活的。应用程序通过调用类库来完成特定的功能，而框架则通过调用应用程序来实现整个操作流程。框架是控制倒置原则的完美体现。”
　　框架系统的一个最好的例子就是图形用户界面（GUI）系统。一个简单的，使用面向过程的设计方法开发的GUI系统如图 5所示。

　　从图 5中可以看出，应用程序调用GUI框架中的CreateWindow()函数来创建窗口，在这里，我们可以说应用程序依赖于GUI框架。但GUI框架并不了解该窗口接收到窗口消息后应该如何处理，这一点只有应用程序最为清楚。因此，当GUI框架需要发送窗口消息时，又必须调用应用程序定义的某个特定的窗口函数（如上图中的MyWindowProc）。这时，GUI框架又必须依赖于应用程序。这是一个典型的双向依赖关系。这种双向依赖关系有一个非常严重的缺陷：由于GUI框架调用了应用程序中的某个特定函数（MyWindowProc）， GUI框架根本无法独立存在；换一个新的应用程序，GUI框架多半就要做相应的修改。因此，如何消解框架系统对应用程序的依赖关系是实现框架系统的关键。
　　并非只有面向对象的方法才能解决这一问题。WIN32 API早就为我们提供了在面向过程的设计思路下解决类似问题的范例。类WIN32 的架构模型如图 6所示。

　　在图 6中，应用程序调用CreateWindow()函数时，要传递一个消息处理函数的指针给GUI框架（对WIN32而言，我们在注册窗口类时传递这一指针），GUI框架把该指针记录在窗口信息结构中。需要发送窗口消息时，GUI框架就通过该指针调用窗口函数。和图 5 相比，GUI框架仍然需要调用应用程序，但这一调用从一个硬编码的函数调用变成了一个由应用程序事先注册被调用对象的动态调用。图 6用一条虚线表示这种动态调用。可以看出，这种动态的调用关系有一个非常大的好处：当应用程序发生变化时，它可以自行改变框架系统的调用目标，GUI框架无需随之发生变化。现在，我们可以说，虽然还存在着从GUI框架到应用程序的调用关系，但GUI框架已经完全不再依赖于应用程序了。这种动态调用机制通常也被称为“回调函数”。
　　在面向对象领域，“回调函数”的替代物就是“模板方法模式”，也就是“好莱坞原则（不要调用我们，让我们调用你）”。GUI框架的一个面向对象的实现如图 7所示。

　　图 7中，“GUI框架抽象接口”是GUI框架系统提供给应用程序使用的接口。抽象出该接口的动机是根据“依赖倒置”的原则，消解从应用程序到GUI框架之间的直接依赖关系，以使得GUI框架实现的变化对应用程序的影响最小化。Window接口类则是“模板方法模式”的核心。应用程序调用CreateWindow()函数时，GUI框架会把该窗口的引用保存在窗口链表中。需要发送窗口消息时，GUI框架就调用窗口对象的SendMessage()函数，该函数是实现在Window类中的非虚成员函数。SendMessage()函数又调用WindowProc()虚函数，这里实际执行的是应用程序MyWindow类中实现的WindowProc()函数。在图 7中，我们已经看不到从GUI框架到应用程序之间的直接依赖关系了。因此，模板方法模式完全实现了回调函数的动态调用机制，消解了从框架到应用程序之间的依赖关系。
　　从上面的分析可以看出，模板方法模式是框架系统的基础，任何框架系统都离不开模板方法模式。Martin Fowler也说 [Folwer 2004]，“几位轻量级容器的作者曾骄傲地对我说：这些容器非常有用，因为它们实现了‘控制反转’。这样的说辞让我深感迷惑：控制反转是框架所共有的特征，如果仅仅因为使用了控制反转就认为这些轻量级容器与众不同，就好像在说‘我的轿车是与众不同的，因为它有四个轮子’。问题的关键在于：它们反转了哪方面的控制？我第一次接触到的控制反转针对的是用户界面的主控权。早期的用户界面是完全由应用程序来控制的，你预先设计一系列命令，例如‘输入姓名’、‘输入地址’等，应用程序逐条输出提示信息，并取回用户的响应。而在图形用户界面环境下，UI 框架将负责执行一个主循环，你的应用程序只需为屏幕的各个区域提供事件处理函数即可。在这里，程序的主控权发生了反转：从应用程序移到了框架。”
　　确实：对比图 3和图 7可以看出，使用普通类库时，程序的主循环位于应用程序中，而使用框架系统的应用程序不再包括一个主循环，只是实现某些框架定义的接口，框架系统负责实现系统运行的主循环，并在必要的时候通过模板方法模式调用应用程序。
　　也就是说，虽然“依赖倒置”和“控制反转”在设计层面上都是消解模块耦合的有效方法，也都是试图令具体的、易变的模块依赖于抽象的、稳定的模块的基本原则，但二者在使用语境和关注点上存在差异：“依赖倒置”强调的是对于传统的、源于面向过程设计思想的层次概念的“倒置”，而“控制反转”强调的是对程序流程控制权的反转；“依赖倒置”的使用范围更为宽泛，既可用于对程序流程的描述（如流程的主从和层次关系），也可用于描述其他拥有概念层次的设计模型（如服务组件与客户组件、核心模块与外围应用等），而“控制反转”则仅适用于描述流程控制权的场合（如算法流程或业务流程的控制权）。
　　从某种意义上说，我们也可以把“控制反转”看作是“依赖倒置”的一个特例。例如，用模板方法模式实现的“控制反转”机制其实就是在框架系统和应用程序之间抽象出了一个描述所有算法步骤原型的接口类，框架系统依赖于该接口类定义并实现程序流程，应用程序依赖于该接口类提供具体算法步骤的实现，应用程序对框架系统的依赖被“倒置”为二者对抽象接口的依赖。
　　总地说来，应用程序和框架系统之间的依赖关系有以下特点：
　　1. 应用程序和框架系统之间实际上是双向调用，双向依赖的关系。
　　2. 依赖倒置原则可以减弱应用程序到框架之间的依赖关系。
　　3. “控制反转”及具体的模板方法模式可以消解框架到应用程序之间的依赖关系，这也是所有框架系统的基础。
　　4. 框架系统可以独立重用。

 

依赖注入（Dependency Injection） 

　　在前面的例子里，我们通过“依赖倒置”原则，最大限度地减弱了应用程序Copy类和类库提供的服务Read，Write之间的依赖关系。但是，如果需要把Copy()函数也实现在类库中，又会发生什么情况呢？假设在类库中实现一个“服务类”，“服务类”提供Copy()方法供应用程序使用。应用程序使用时，首先创建“服务类”的实例，调用其中的Copy()函数。“服务类”的实例初始化时会创建KeyboardReader 和PrinterWriter类的实例对象。如图 8所示。

　　从图 8中可以看出，虽然Reader和Writer接口隔离了“服务类”和具体的Reader和Writer类，使它们之间的耦合降到了最小。但当 “服务类”创建具体的Reader和Writer对象时，“服务类”还是和具体的Reader和Writer对象发生了依赖关系——图 8中用蓝色的虚线描述了这种依赖关系。
　　在这种情况下，如何实例化具体的Reader和Writer类，同时又尽量减少服务类对它们的依赖，就是一个非常关键的问题了。如果服务类位于应用程序中，这一依赖关系对我们造成的影响还不算大。但当“服务类”位于需要独立发布的类库中，它的代码就不能随着应用程序的变化而改变了。这也意味着，如果“服务类”过度依赖于具体的Reader和Writer类，用户就无法自行添加新的Reader和Writer 的实现了。
　　解决这一问题的方法是“依赖注入”，即切断“服务类”到具体的Reader和Writer类之间的依赖关系，而由应用程序来注入这一依赖关系。如图 9所示。

　　在图 9中，“服务类”并不负责创建具体的Reader和Writer类的实例对象，而是由应用程序来创建。应用程序创建“服务类”的实例对象时，把具体的Reader和Write对象的引用注入“服务类”内部。这样，“服务类”中的代码就只和抽象接口相关的了。具体实现代码发生变化时，“服务类”不会发生任何变化。添加新的实现时，也只需要改变应用程序的代码，就可以定义并使用新的Reader和Writer类，这种依赖注入方式通常也被称为“构造器注入”。
　　如果专门为Copy类抽象出一个注入接口，应用程序通过接口注入依赖关系，这种注入方式通常被称为“接口注入”。如果为Copy类提供一个设值函数，应用程序通过调用设值函数来注入依赖关系，这种依赖注入的方法被称为“设值注入”。具体的“接口注入”和“设值注入”请参考[Martin 2004]。
　　PicoContainer和Spring轻量级容器框架都提供了相应的机制来帮助用户实现各种不同的“依赖注入”。并且，通过不同的方式，他们也都支持在XML文件中定义依赖关系，然后由应用程序调用框架来注入依赖关系，当依赖关系需要发生变化时，只要修改相应的 XML文件即可。
　　因此，依赖注入的核心思想是：
　　1. 抽象接口隔离了使用者和实现之间的依赖关系，但创建具体实现类的实例对象仍会造成对于具体实现的依赖。
　　2. 采用依赖注入可以消除这种创建依赖性。使用依赖注入后，某些类完全是基于抽象接口编写而成的，这可以最大限度地适应需求的变化。

 

结论 

参考文献 

Singleton模式就为我们提供了这样实现的可能。使用Singleton的好处还在于可以节省内存，因为它限制了
实例的个数，有利于Java垃圾回收（garbage collection）。

使用Singleton注意事项：
有时在某些情况下，使用Singleton并不能达到Singleton的目的，如有多个Singleton对象同时被不同的类
装入器装载；在EJB这样的分布式系统中使用也要注意这种情况，因为EJB是跨服务器，跨JVM的

单态模式的演化：
单态模式是个简单的模式，但是这个简单的模式也有很多复杂的东西。

（注意：在这里补充一下，现在单态模式其实有一个写法是不错的见这里：http://www.blogjava.net/dreamstone/archive/2007/02/27/101000.html，但还是建议看完这篇文章，因为解释的事情是不一样的，这里说的是为什么double-checked不能使用.）
一，首先最简单的单态模式，单态模式1
import java.util.*;
class Singleton
{
  private static Singleton instance;
  private Vector v;
  private boolean inUse;

  private Singleton()
  {
    v = new Vector();
    v.addElement(new Object());
    inUse = true;
  }

  public static Singleton getInstance()
  {
    if (instance == null)          //1
      instance = new Singleton();  //2
    return instance;               //3
  }
}
这个单态模式是不安全的，为什么说呢 ？因为没考虑多线程，如下情况
Thread 1 调用getInstance() 方法，并且判断instance是null，然後进入if模块，
在实例化instance之前，
Thread 2抢占了Thread 1的cpu
Thread 2 调用getInstance() 方法，并且判断instance是null，然後进入if模块，
Thread 2 实例化instance 完成，返回
Thread 1 再次实例化instance
这个单态已经不在是单态

二，为了解决刚才的问题：单态模式2
public static synchronized Singleton getInstance()
{
  if (instance == null)          //1
    instance = new Singleton();  //2
  return instance;               //3
}
采用同步来解决，这种方式解决了问题，但是仔细分析
正常的情况下只有第一次时候，进入对象的实例化，须要同步，
其它时候都是直接返回已经实例化好的instance不须要同步，
大家都知到在一个多线程的程序中，如果同步的消耗是很大的，很容易造成瓶颈

三，为了解决上边的问题：单态模式3，加入同步
public static Singleton getInstance()
{
  if (instance == null)
  {
    synchronized(Singleton.class) {
      instance = new Singleton();
    }
  }
  return instance;
}
同步改成块同步，而不使用函数同步，但是仔细分析，
又回到了模式一的状态，再多线程的时候根本没有解决问题

四，为了对应上边的问题：单态模式4，也就是很多人采用的Double-checked locking
public static Singleton getInstance()
{
  if (instance == null)
  {
    synchronized(Singleton.class) {  //1
      if (instance == null)          //2
        instance = new Singleton();  //3
    }
  }
  return instance;
}
这样，模式一中提到的问题解决了。不会出现多次实例化的现象
当第一次进入的时候，保正实例化时候的单态,在实例化后，多线程访问的时候直接返回，不须要进入同步模块，
既实现了单态，又没有损失性能。表面上看我们的问题解决了，但是再仔细分析：
我们来假象这中情况：
Thread 1 :进入到//3位置，执行new Singleton()，但是在构造函数刚刚开始的时候被Thread2抢占cpu
Thread 2 :进入getInstance()，判断instance不等于null,返回instance，
（instance已经被new，已经分配了内存空间,但是没有初始化数据)
Thread 2 :利用返回的instance做某些操做，失败或者异常
Thread 1 :取得cpu初始化完成
过程中可能有多个线程取到了没有完成的实例，并用这个实例作出某些操做。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
出现以上的问题是因为
mem = allocate();             //分配内存
instance = mem;               //标记instance非空
                              //未执行构造函数,thread 2从这里进入
ctorSingleton(instance);      //执行构造函数
                              //返回instance
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－                             

五，证明上边的假想是可能发生的，字节码是用来分析问题的最好的工具，可以利用它来分析
下边一段程序：（为了分析方便，所以渐少了内容）
字节码的使用方法见这里，利用字节码分析问题
class Singleton
{
  private static Singleton instance;
  private boolean inUse;
  private int val; 

  private Singleton()
  {
    inUse = true;
    val = 5;
  }
  public static Singleton getInstance()
  {
    if (instance == null)
      instance = new Singleton();
    return instance;
  }
}
得到的字节码                           
;asm code generated for getInstance
054D20B0   mov         eax,[049388C8]      ;load instance ref
054D20B5   test        eax,eax             ;test for null
054D20B7   jne         054D20D7
054D20B9   mov         eax,14C0988h
054D20BE   call        503EF8F0            ;allocate memory
054D20C3   mov         [049388C8],eax      ;store pointer in
                                           ;instance ref. instance 
                                           ;non-null and ctor
                                           ;has not run
054D20C8   mov         ecx,dword ptr [eax]
054D20CA   mov         dword ptr [ecx],1   ;inline ctor - inUse=true;
054D20D0   mov         dword ptr [ecx+4],5 ;inline ctor - val=5;
054D20D7   mov         ebx,dword ptr ds:[49388C8h]
054D20DD   jmp         054D20B0

上边的字节码证明，猜想是有可能实现的

六：好了，上边证明Double-checked locking可能出现取出错误数据的情况，那么我们还是可以解决的
public static Singleton getInstance()
{
  if (instance == null)
  {
    synchronized(Singleton.class) {      //1
      Singleton inst = instance;         //2
      if (inst == null)
      {
        synchronized(Singleton.class) {  //3
          inst = new Singleton();        //4
        }
        instance = inst;                 //5
      }
    }
  }
  return instance;
}
利用Double-checked locking 两次同步，中间变量,解决上边的问题。
（下边这段话我只能简单的理解，翻译过来不好，所以保留原文，list 7是上边的代码，list 8是下边的
The code in Listing 7 doesn't work because of the current definition of the memory model.
 The Java Language Specification (JLS) demands that code within a synchronized block
 not be moved out of a synchronized block. However, it does not say that
 code not in a synchronized block cannot be moved into a synchronized block.
A JIT compiler would see an optimization opportunity here.
This optimization would remove the code at
//4 and the code at //5, combine it and generate the code shown in Listing 8:）
------------------------------------------------- 
list 8
public static Singleton getInstance()
{
  if (instance == null)
  {
    synchronized(Singleton.class) {      //1
      Singleton inst = instance;         //2
      if (inst == null)
      {
        synchronized(Singleton.class) {  //3
          //inst = new Singleton();      //4
          instance = new Singleton();              
        }
        //instance = inst;               //5
      }
    }
  }
  return instance;
}
If this optimization takes place, you have the same out-of-order write problem we discussed earlier.
如果这个优化发生，将再次发生上边提到的问题，取得没有实例化完成的数据。
-------------------------------------------------

以下部分为了避免我翻译错误误导打家，保留原文

Another idea is to use the keyword volatile for the variables inst and instance.
According to the JLS (see Resources), variables declared volatile are supposed to
be sequentially consistent, and therefore, not reordered.
But two problems occur with trying to use volatile to fix the problem with
double-checked locking:

The problem here is not with sequential consistency.
Code is being moved, not reordered.

Many JVMs do not implement volatile correctly regarding sequential consistency anyway.
The second point is worth expanding upon. Consider the code in Listing 9:

Listing 9. Sequential consistency with volatile

class test
{
  private volatile boolean stop = false;
  private volatile int num = 0;

  public void foo()
  {
    num = 100;    //This can happen second
    stop = true;  //This can happen first
    //...
  }

  public void bar()
  {
    if (stop)
      num += num;  //num can == 0!
  }
  //...
}
 
According to the JLS, because stop and num are declared volatile,
they should be sequentially consistent. This means that if stop is ever true,
num must have been set to 100.
However, because many JVMs do not implement the sequential consistency feature of volatile,
you cannot count on this behavior.
Therefore, if thread 1 called foo and thread 2 called bar concurrently,
thread 1 might set stop to true before num is set to 100.
This could lead thread 2 to see stop as true, but num still set to 0.
There are additional problems with volatile and the atomicity of 64-bit variables,
but this is beyond the scope of this article.
See Resources for more information on this topic.

简单的理解上边这段话，使用volatile有可能能解决问题，volatile被定义用来保正一致性，但是很多虚拟机
并没有很好的实现volatile，所以使用它也会存在问题。

最终的解决方案：
 （1），单态模式2，使用同步方法
 （2），放弃同步，使用一个静态变量，如下
class Singleton
{
  private Vector v;
  private boolean inUse;
  private static Singleton instance = new Singleton();

  private Singleton()
  {
    v = new Vector();
    inUse = true;
    //...
  }

  public static Singleton getInstance()
  {
    return instance;
  }
}
但使用静态变量也会存在问题，问题见 这篇文章

而且如在文章开头提到的，使用EJB跨服务器，跨JVM的情况下，单态更是问题

好了是不是感觉单态模式根本没法使用了，其实上边都是特殊情况，这中特殊情况的出现是有条件的，只要
根据你的具体应用，回避一些，就能解决问题，所以单态还是可以使用的。但是在使用前慎重，自己考虑好自己
的情况适合哪种情况。

参考
http://www.jdon.com/designpatterns/singleton.htm

Double-checked locking and the Singleton pattern

When is a singleton not a singleton?