单例模式

关于单例模式中的final关键字：
懒汉式中一开始声明的类的实例化对象为什么只用private static 声明了而没有加final关键字？
声明final的变量，必须在类加载完成时已经赋值，如果你是final非static成员，必须在构造器、代码块、或者直接定义赋值；
如果是fainal static 成员变量，必须直接复制或者在静态代码块中赋值
static {//静态代码块
        instance = new MyObject();
    }
然而直接赋值 或 静态代码块中赋值 就变成饿汉模式了，所以懒汉模式中，不能用final修饰




饿汉式中关于用不用final关键字？
在单例模式中，如果存在释放资源的情况下，就不能加final修饰了
public void releaseInstance(){ 
    if(instance != null){ 
        instance = null; 
    } 
}
释放资源之后，如果需要重新使用这个单例，就必须存在重新初始化的过程，所以不能加final，对于不需要释放资源的情况，可以加final
总而言之，要不要加final修饰，可以根据情况而定
static修饰的属性强调它们只有一个，final修饰的属性表示创建后不能被修改




单例模式中，将构造方法私有化避免了类在外部被实例化，在同一个虚拟机范围内，类的唯一实例只能通过获取实例的方法访问。
（事实上，通过java反射机制是能够实例化构造方法为private的类的，那那基本上会使所有的java单例实现失效）










一、饿汉式：
下面这个可以不加final，因为静态方法只在编译期间执行一次初始化，也就是只会有一个对象
//饿汉式单例类.在类初始化时，已经自行实例化   
public class Singleton1 {  
     //私有的默认构造子  
     private Singleton1() {}  
     //已经自行实例化   
     private static final Singleton1 single = new Singleton1();  
     //静态工厂方法   
     public static Singleton1 getInstance() {  
        return single;  
     }  
 }  




二、懒汉式：
那个if判断确保对象只创建一次
//懒汉式单例类.在第一次调用的时候实例化 
①直接加锁锁方法  
public class Singleton2 {  
     //私有的默认构造子  
     private Singleton2() {}  
     //注意，这里没有final      
     private static Singleton2 single=null;  
     //静态工厂方法   
     public synchronized  static Singleton2 getInstance() {  
          if (single == null) {    
              single = new Singleton2();  
          }    
         return single;  
     } 
 
 }  
我们可以看到这里synchronized是锁方法, 当两个线程都要进入getInstance()时, 只有一个能进入, 并创建出实例, 然后另外一个进入后, 判断 instace不为null, 然后直接得到instance. 这种做法是没有错误的. 但是由于线程都需要通过getInstance()来获取对象, 所以getInstance()调用频率很高, 所以线程被锁的频率也很高, 所以这种做法效率低.


②syschronized放在getInstance()里面
class Singleton {
    private static Singleton instance;
    private Singleton(){}


    public static Singleton getInstance(){
        if(instance == null){
            synchronized(Singleton.class){
                instance = new Singleton();
            }
        }
        return instance;
    }
}
这种写法看似没有问题, 其实却有一个很大的隐患, 在于: 如果两个线程同时执行getInstance(),判断 instance都为null后, 进入if判断语句. 这个时候一个线程获得锁, 然后进入new了一个对象, 并开心的执行完了. 这个时候另外一个线程获得了锁, 但让它也不会再去判断 instace是否为null, 所以它也会再执行一次new操作. 所以这里执行了两次new操作. 当然最后instance还是只指向后一次new的对象.


三、双重锁定
①class Singleton {
    private static Singleton instance;
    private Singleton(){}


    public static Singleton getInstance(){
        if(instance == null){
            synchronized(Singleton.class){
                if(instance == null){
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}
这样就可以保证不会new两次, 也是相对比较正确的, 并且效率也很高
这段代码看起来很完美，很可惜，它是有问题。主要在于instance = new Singleton()这句，这并非是一个原子操作，事实上在 JVM 中这句话大概做了下面 3 件事情。
1.给 instance 分配内存
2.调用 Singleton 的构造函数来初始化成员变量
3.将instance对象指向分配的内存空间（执行完这步 instance 就为非 null 了）
但是在 JVM 的即时编译器中存在指令重排序的优化。也就是说上面的第二步和第三步的顺序是不能保证的，最终的执行顺序可能是 1-2-3 也可能是 1-3-2。如果是后者，则在 3 执行完毕、2 未执行之前，被线程二抢占了，这时 instance 已经是非 null 了（但却没有初始化），所以线程二会直接返回 instance，然后使用，然后顺理成章地报错。
我们只需要将 instance 变量声明成 volatile 就可以了


②将instance变量声明成volatile
public class Singleton {
    private volatile static Singleton instance; //声明成 volatile
    private Singleton (){}


    public static Singleton getSingleton() {
        if (instance == null) {                         
            synchronized (Singleton.class) {
                if (instance == null) {       
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
   
}
有些人认为使用 volatile 的原因是可见性，也就是可以保证线程在本地不会存有 instance 的副本，每次都是去主内存中读取。但其实是不对的。使用 volatile 的主要原因是其另一个特性：禁止指令重排序优化。也就是说，在 volatile 变量的赋值操作后面会有一个内存屏障（生成的汇编代码上），读操作不会被重排序到内存屏障之前。比如上面的例子，取操作必须在执行完 1-2-3 之后或者 1-3-2 之后，不存在执行到 1-3 然后取到值的情况。从「先行发生原则」的角度理解的话，就是对于一个 volatile 变量的写操作都先行发生于后面对这个变量的读操作（这里的“后面”是时间上的先后顺序）。


但是特别注意在 Java 5 以前的版本使用了 volatile 的双检锁还是有问题的。其原因是 Java 5 以前的 JMM （Java 内存模型）是存在缺陷的，即时将变量声明成 volatile 也不能完全避免重排序，主要是 volatile 变量前后的代码仍然存在重排序问题。这个 volatile 屏蔽重排序的问题在 Java 5 中才得以修复，所以在这之后才可以放心使用 volatile。


四、静态内部类static nested class：
public class Singleton {  
    private static class SingletonHolder {  
        private static final Singleton INSTANCE = new Singleton();  
    }  
    private Singleton (){}  
    public static final Singleton getInstance() {  
        return SingletonHolder.INSTANCE; 
    }  
}
这种写法仍然使用JVM本身机制保证了线程安全问题；由于 SingletonHolder 是私有的，除了 getInstance() 之外没有办法访问它，因此它是懒汉式的；同时读取实例的时候不会进行同步，没有性能缺陷；也不依赖 JDK 版本


五、枚举 Enum：
public enum EasySingleton{
    INSTANCE;
}
我们可以通过EasySingleton.INSTANCE来访问实例，这比调用getInstance()方法简单多了。创建枚举默认就是线程安全的，所以不需要担心double checked locking，而且还能防止反序列化导致重新创建新的对象




枚举的使用：
public enum Color {  
     RED("红色", 1), GREEN("绿色", 2), BLANK("白色", 3), YELLO("黄色", 4);  
     // 成员变量  
     private String name;  
     private int index;  
     // 构造方法  
     private Color(String name, int index) {  
         this.name = name;  
         this.index = index;  
     }  
     // 普通方法  
     public static String getName(int index) {  
         for (Color c : Color.values()) {  
             if (c.getIndex() == index) {  
                 return c.name;  
             }  
         }  
         return null;  
     }  
     // get set 方法  
     public String getName() {  
         return name;  
     }  
     public void setName(String name) {  
         this.name = name;  
     }  
     public int getIndex() {  
         return index;  
     }  
     public void setIndex(int index) {  
         this.index = index;  
     }  
}  












枚举的使用：
public enum D { 
intance;
private String name;
private D(){
System.out.println("这是D的构造方法");
this.name="hello";
}
public static D getIntance(){
return D.intance;
}
public String toString(){//注意枚举自己重写了toString方法，默认返回的是枚举对象的名字（即instance）
return name;     //当自己再重写toString方法，就可以按照自己的需要进行输出
}
public static void main(String[] args ){
D d0=D.getIntance();
D d1=D.getIntance();
if(d0==d1){
System.out.println("是单例模式");
}else{
System.out.println("不是单例模式");
}
}
}