java与模式

[size=medium]Singleton模式主要作用是保证在java应用程序中，一个类Class只有一个实例存在。

饿汉式
类加载的时候就初始化实例
缺点：如果系统运行中根本没用到的话会很浪费,在用到这个类的时候再去实例对象会比较好
优点：安全，可靠
适用场景：在声明完单例引用之后立即实例化。如果构建该对象的花销远远小于获取同步锁的花销，那么此种方式非常值得。

public class EagerSingleton {

private static final EagerSingleton instance = new EagerSingleton();

private EagerSingleton() {
}

public static EagerSingleton getInstance() {
return instance;
}
}

懒汉式
优点:解决了懒汉式一启动就实例化对象的方式
缺点:1)存在线程并发访问问题
instance=new laySingleton()
线程1还没完全初始化完毕，instance已经不为null。
另外的线程就会拿到没有初始化完全的对象。
2)如果去掉synchronized关键字：(多线程环境下的全局变量是很危险的)
可能会有多个进程同时通过 (singleton== null)的条件检查，于是，多个实例就创建出来，并且很可能造成内存泄露问题

public class LazySingleton {

private static LazySingleton intance=null;

private LazySingleton(){
}

synchronized public static LazySingleton getInstance(){
if(intance==null){
intance=new LazySingleton();//假设这个初始化需要读取文件等，需要十分钟
}
return intance;
}
}

懒汉式版本2

public class Singleton
{
private static final Singleton singleton = null;

private Singleton()
{
}
public static Singleton getInstance()
{
if (singleton== null) //多个线程或进程会同时满足这个条件
{
synchronized (Singleton.class) {
//仍然是创建了很多实例，只是变为了串行的new实例
singleton= new Singleton();
}
}
return singleton;
}
}

懒汉式版本3 double check

public class Singleton
{
private static final Singleton singleton = null;

private Singleton()
{
}
public static Singleton getInstance()
{
if (singleton== null)
{
synchronized (Singleton.class)
{
if (singleton== null)
{
singleton= new Singleton();
}
}
}
return singleton;
}
}

既想“惰性初始化”，又想避免“获取同步锁开销”的方法。
大名鼎鼎的Joshua Bloch在神作《Effective java》中，
建议1.5及以后的版本用一个“含有单一枚举值的enum来实现单例”，并举例如下。

// Enum singleton - the preferred approach
public enum Elvis {
INSTANCE;
public void leaveTheBuilding() { ... }
}

这就是巧妙地运用了Java规范中关于enum初始化的特性。

在1.5之前，Bloch推荐的方法是用一个“辅助占位类”来包容这个实例，如下：

// Lazy initialization holder class idiom for static fields
private static class FieldHolder {
static final FieldType field = computeFieldValue();
}
static FieldType getField() { return FieldHolder.field; }

同样也是运用了Java规范中关于类加载的相关知识。

Singleton的其它问题
怎么？还有问题？！当然还有，请记住下面这条规则——“无论你的代码写得有多好，其只能在特定的范围内工作，超出这个范围就要出Bug了 ”，这是“乱弹第一定理”，呵呵。你能想一想还有什么情况会让这个我们上面的代码出问题吗？
在C++下，我不是很好举例，但是在Java的环境下，嘿嘿，还是让我们来看看下面的一些反例和一些别的事情的讨论（当然，有些反例可能属于钻牛角尖，可能有点学院派，不过也不排除其实际可能性，就算是提个醒吧 ）：
其一、Class Loader 。不知道你对Java的Class Loader熟悉吗？“类装载器”？！C++可没有这个东西啊。这是Java动态性的核心。顾名思义，类装载器是用来把类(class)装载进JVM的。 JVM规范定义了两种类型的类装载器：启动内装载器(bootstrap)和用户自定义装载器(user-defined class loader)。 在一个JVM中可能存在多个ClassLoader，每个ClassLoader拥有自己的NameSpace。一个ClassLoader只能拥有一个 class对象类型的实例，但是不同的ClassLoader可能拥有相同的class对象实例，这时可能产生致命的问题。如ClassLoaderA， 装载了类A的类型实例A1，而ClassLoaderB，也装载了类A的对象实例A2。逻辑上讲A1=A2，但是由于A1和A2来自于不同的 ClassLoader，它们实际上是完全不同的，如果A中定义了一个静态变量c，则c在不同的ClassLoader中的值是不同的。
于是，如果咱们的Singleton 1.3版本如果面对着多个Class Loader会怎么样？呵呵，多个实例同样会被多个Class Loader创建出来，当然，这个有点牵强，不过他确实存在。难道我们还要整出个1.4版吗？可是，我们怎么可能在我的Singleton类中操作 Class Loader啊？是的，你根本不可能。在这种情况下，你能做的只有是——“保证多个Class Loader不会装载同一个Singleton”。
其二、序例化。 如果我们的这个Singleton类是一个关于我们程序配置信息的类。我们需要它有序列化的功能，那么，当反序列化的时候，我们将无法控制别人不多次反序列化。不过，我们可以利用一下Serializable接口的readResolve()方法，比如
Java代码

public class Singleton implements Serializable
{
......
......
protected Object readResolve()
{
return getInstance();
}
}

其三、多个Java虚拟机。 如果我们的程序运行在多个Java的虚拟机中。什么？多个虚拟机？这是一种什么样的情况啊。嗯，这种情况是有点极端，不过还是可能出现，比如EJB或RMI之流的东西。要在这种环境下避免多实例，看来只能通过良好的设计或非技术来解决了。
其四，volatile变量。 关于volatile这个关键字所声明的变量可以被看作是一种 “程度较轻的同步synchronized”；
与 synchronized 块相比，volatile 变量所需的编码较少，并且运行时开销也较少，但是它所能实现的功能也仅是synchronized的一部分。
当然，如前面所述，我们需要的 Singleton只是在创建的时候线程同步，而后面的读取则不需要同步。
所以，volatile变量并不能帮助我们即能解决问题，又有好的性能。而且， 这种变量只能在JDK 1.5+版后才能使用。
其五、关于继承。 是的，继承于Singleton后的子类也有可能造成多实例的问题。不过，因为我们早把Singleton的构造函数声明成了私有的，所以也就杜绝了继承这种事情。
其六，关于代码重用。 也话我们的系统中有很多个类需要用到这个模式，如果我们在每一个类都中有这样的代码，那么 就显得有点傻了。那么，我们是否可以使用一种方法，把这具模式抽象出去？
在C++下这是很容易的，因为有模板和友元，还支持栈上分配内存，所以比较容易一些,Java下可能比较复杂一些，聪明的你知道怎么做吗？
[/size]