5种单例模式的介绍与比较

今天要介绍一下java（和安卓）的5中单例模式及相互的比较。
下面我会通过代码进行详细的介绍和比较，代码中会带有注释，如果觉得在这里看比较乱，可以直接复制到自己创建的.java文件中进行阅读（会有错误提示，如果强迫症，将部分相同的函数用”//”注释就好了），代码如下：

package com.tcl.adclient.utils.others;import java.io.ObjectStreamException;import android.content.Context;import android.media.MediaPlayer;public class MMediaPlayer {    /**    * 用volatile修饰的变量，线程在每次使用变量的时候，都会读取变量修改后的最的值。    * volatile很容易被误用，用来进行原子性操作。对于volatile修饰的变量，    * jvm虚拟机只是保证从主内存加载到线程工作内存的值是最新的。    * 您只能在有限的一些情形下使用 volatile 变量替代锁。    * 要使 volatile 变量提供理想的线程安全，必须同时满足下面两个条件：    * 1.对变量的写操作不依赖于当前值。    * 2.该变量没有包含在具有其他变量的不变式中。    * 只有在状态真正独立于程序内其他内容时才能使用 volatile ——     * 这条规则能够避免这些模式扩展到不安全的用例。    * 使用 volatile 变量次要原因是其性能：某些情况下，volatile 变量同步机制的性能要优于锁    **/    private volatile static MediaPlayer mp;    private static MediaPlayer mps = new MediaPlayer();    private static Object lock=new Object();    private MMediaPlayer() {    }    /**     * 1.1懒汉，线程不安全     * @return     */    public static MediaPlayer getInstance() {        if (mp == null) {            mp = new MediaPlayer();        }        return mp;//    }    /**     * // 1.2.懒汉，线程安全,这种写法是对getInstance()加锁，绝大情况下都不需要同步,效率低     * @param context     * @return     */    public static synchronized MediaPlayer getInstance() {        if (mp == null) {            mp = new MediaPlayer();        }        return mp;    }    /**     * 2.饿汉，这种方式基于classloder机制避免了多线程的同步问题，不过，instance在类装载时就实例化，虽然导致类装载的原因有很多种，在单例模式中大多数都是调用getInstance方法，     *  但是也不能确定有其他的方式（或者其他的静态方法）导致类装载，这时候初始化instance显然没有达到lazy loading的效果。     * @return     */    public static MediaPlayer getInstance() {        return mps;//    }    /**     * 3.1.自己根据对synchronized的理解写出来的，这里的context可以保证此对象在当前运行环境中的同步单例，在安卓中效率比1.2高。     * 但第一次执行时在当前环境(调用此函数的Activity环境)加锁，且多线程中不能保证单例！要保证单例可以借鉴3.2的双重锁校验。     * 适用于安卓在主线程中使用。。粒度过大，不建议！     * @param context     * @return     */    public static MediaPlayer getInstance(Context context) {        if (mp == null) {            synchronized (context) {                mp = new MediaPlayer();            }        }        return mp;    }    /**     * 3.2.双重校验锁 单例模式 不建议使用，类似于3.3和3.1，静态方法中synchronized但多了在同步块内部判断，效率比3.1高，比3.3低，     * 这个方法表面上看起来很完美，你只需要付出一次同步块的开销，但它依然有问题。除非你声明_instance变量时使用了volatile关键字。     * 没有volatile修饰符，可能出现Java中的另一个线程看到个初始化了一半的_instance的情况，     * 但使用了volatile变量后，就能保证先行发生关系（happens-before relationship）。     * 对于volatile变量_instance，所有的写（write）都将先行发生于读（read），     * 在Java 5之前不是这样，所以在这之前使用双重检查锁有问题。现在，有了先行发生的保障（happens-before guarantee），你可以安全地假设其会工作良好。     * 另外，这不是创建线程安全的单例模式的最好方法，你可以使用枚举实现单例模式，这种方法在实例创建时提供了内置的线程安全。另一种方法是使用静态持有者模式（static holder pattern）。     *      * 要实现真正的断面，你必须同步一个全局对象或者对类进行同步     * @return     */    public MediaPlayer getMyInstance() {        if (mp == null) {            synchronized (MMediaPlayer.this) {//如果在静态函数中此句会编译错误：Cannot use this in a static context，            //要改为MMediaPlayer.class                if (mp == null) {                    mp = new MediaPlayer();                }            }        }        return mp;    }    /**     * 3.3. 比3.2的做法要好一点，虽然都是双重校验锁。     * 3.2中的加锁是针对类定义的，一个类只能有一个类定义，而同步的一般原理是应该尽量减小同步的粒度以到达更好的性能。     * @return     */    public MediaPlayer getMyInstance() {        if (mp == null) {            synchronized (lock) {                if (mp == null) {                    mp = new MediaPlayer();                }            }        }        return mp;    }    /**     * 4.静态内部类。这种方式同样利用了classloder的机制来保证初始化instance时只有一个线程，     * 它跟第三种和第四种方式不同的是（很细微的差别）：第三种和第四种方式是只要Singleton类被装载了，那么instance就会被实例化（没有达到lazy loading效果），     * 而这种方式是Singleton类被装载了，instance不一定被初始化。     * 因为SingletonHolder类没有被主动使用，只有显示通过调用getInstance方法时，才会显示装载SingletonHolder类，     * 从而实例化instance。想象一下，如果实例化instance很消耗资源，我想让他延迟加载，     * 另外一方面，我不希望在Singleton类加载时就实例化，因为我不能确保Singleton类还可能在其他的地方被主动使用从而被加载，     * 那么这个时候实例化instance显然是不合适的。这个时候，这种方式相比第三和第四种方式就显得很合理。     * @author mylab     */     @SuppressWarnings("unused")    private static class SingletonHolder {         private static final MediaPlayer INSTANCE = new MediaPlayer();         private SingletonHolder(){}         public static final MediaPlayer getInstance() {             return SingletonHolder.INSTANCE;         }    }     /**      * 5.枚举， 在安卓中不建议使用，占用资源最多，效率最低！      * 在JAVA中，这种方式是Effective Java作者Josh Bloch 提倡的方式，它不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象，可谓是很坚强的壁垒啊      * 个人认为1.5中才加入enum特性，不直观，在实际的JAVA开发中也很少见到有人使用。      * public enum Singleton {      *   INSTANCE;      *   public void whateverMethod() {      *     ...      *   }      * }      */     /**      * 将对象置为空，再此之前请确保该对象已停止播放并释放相关资源      */    public static void setNull() {        if (mp != null) {            mp = null;        }    }    /**     * 为了实现流转换复写Object函数，如果不涉及反序列化操作不用复写     * @return     * @throws ObjectStreamException     */    private Object readResolve() throws ObjectStreamException {        return mp;    }}

---