java 常见单例使用和相关的内存泄露问题

最新推荐文章于 2024-04-22 21:20:57 发布

老板来根葱

最新推荐文章于 2024-04-22 21:20:57 发布

阅读量431

点赞数

分类专栏： java

本文链接：https://blog.csdn.net/Arthurs_L/article/details/82285166

版权

java 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

这几天刚好在外面面试，被问到设计模式，心血来潮就想记下这方面的东西。像单例设计模式我觉得从大家开始学习的时候就已经写了对应的代码，但是到了面试的时候还是拎不清。

记忆中的单例

学习设计模式方面的知识知道单例的目的，“为了让类的一个对象成为系统中的唯一实例，需要用一种只允许生成对象类的唯一实例的机制。‘阻止’所有想要生成对象的访问”。

那么单例的三要素就是

某个类只能有一个实例
它必须自行创建这个实例
它必须自行向整个系统提供这个实例

从代码角度上讲，也就是

构造方法私有
含有一个该类的静态私有对象
提供了一个静态的公有的函数用于获取该类静态私有对象

加上后面学了UML，便有了这么一张图

记得毕业出来找工作一被问到，马上就说单例实现有常见两种形式，懒汉式跟饿汉式，对，是饿汉，不是恶汉，之前看过别人的面试题就写恶汉，吓死人了要。但是还是从面试官的嘴角看到一抹邪魅的上扬，但是又不知道发生了什么，还以为面试官欣慰地一笑，后面才发现我的内心戏有点多。

这里还是继续举出最原始的两个模板代码

懒汉式

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

饿汉式

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

对比

	对象声明	实例化时机	线程安全	性能
懒汉式	类私有对象一直为空	方法被调用时候	无线程同步处理机制	达到Lazy Loading的效果，但未处理同步
饿汉式	类私有对象定义时初始化	类初始化阶段	类装载的时候就完成实例化。避免了线程同步问题	没有达到Lazy Loading的效果，如果没有调用就造成资源浪费

那我觉得如果是这样的话，我在懒汉式那边加个同步不就可以了么，于是就有了下面的代码，美滋滋的单例完成了。双重检查，一层性能二层安全，振振有词。

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

但是我一跑，会发现在某种偶然情况下，我执行了但是他居然告诉我空指针异常？可代码这样没问题啊，引用私有持有，构造方法私有，最后也提供锁的方式去获取单例。这里我们就需要引入一个这样的修饰符“volatile”，查了网上很多的说法，都在解释一个“可见性”，麻烦大家自行搜索“volatile+可见性”，具体不表。不管怎样，咱们先记住，添加该修饰符的目的就是为了防止指令重排序。毕竟new出对象并赋值属于非原子操作，所以这样做就会偶现上面所说的空指针问题。一个volatile搞定，这就是一个完整的双重检查。

双重检查

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

静态内部类和代码块实现

public class Singleton {
    // 私有构造
    private Singleton() {}

    // 静态内部类
    private static class InnerProvider{
        private static Singleton single = new Singleton();
    }
    
    public static Singleton getInstance() {
        return InnerProvider.single;
    }
}

静态内部类形式的单例可以保证单例在多线程并发下的线程安全性，但是在遇到序列化对象时，默认的方式运行得到的结果就是多例的。

public class Singleton {
    
    // 私有构造
    private Singleton() {}
    
    private static Singleton single = null;

    // 静态代码块
    static{
        single = new Singleton();
    }
    
    public static Singleton getInstance() {
        return single;
    }
}

静态代码块形式的单例借助java的类初始化机制进行对象实例，同理衍生出下面的容器型单例

容器型单例

还有一种，就是创建用容器来存储。像安卓里面的应用启动流程里面，对各种SystemService的初始化也是如此。我们可以看到，其初始化就是把这些服务的实例都存储在了一个map中，获取服务对象的时候，先判断map中对应key能否拿到有效的系统服务对象，如果有，直接get获取。没有的话就创建完，再put到map中去。这也是一种单例。为什么？

因为这个map是静态的，那么也就是类加载阶段，完成该容器的初始化，那么这就代表这个容器只会被初始化一次。那么对应该容器的集合元素，都是只有一个，故这样实现的单例。

枚举单例

上面说了这些，但是我每次要两次去检查，我也很烦，所以这里我们可以用到枚举的单例。为什么枚举适合单例？

首先枚举的对象在jvm中会是唯一内存，jvm对枚举对象已经有了自己的一套机制，默认枚举实例的创建是线程安全的。

其次，枚举单例能自动避免序列化/反序列化攻击，因为枚举类不能通过反射生成。所以枚举单例也是《Effective Java》中推荐的模式。

但是枚举存在一个性能问题，尤其是Android的应用场景中，枚举需要占用较大的内存，如果对内存敏感，请尽量少使用，换用做静态常量，所以Android中尽量减少枚举的使用。

public enum SingleEnum {
    SINGLE_ENUM("str",666);


    private String mString;
    private int mInt;

    SingleEnum(String mString, int mInt) {
        this.mString = mString;
        this.mInt = mInt;
    }

    public  String getStirng(){
        return mString;
    }

    public int getInt(){
        return mInt;
    }
}

内存泄露场景

在介绍完单例以后，我们来说说内存泄露的问题。从GC角度上看，不再会被使用的对象的内存不能被回收。而单例上容易出现的内存泄露就是长生命周期的对象持有短生命周期的引用。来看下面这段代码


public final class Utils {
    public Activity mContext;
    public InitParam mParam;
    public void init(final Activity context, InitParam param) {
        mContext = context;
        mInitParam = param;
    }
    public void doSomething(){...}
}

是不是觉得有点熟悉？但这个是我出来工作后接手别人项目时候的常见代码块，像工具类也好，自定义控件也好，都会存在一个需要上下文的场景，但是很多时候的做法是直接持有所在上下文的引用，这已经是在危险边缘试探了。如上述代码所示，当销毁该界面的时候，准备回收的时候，又发现工具类里还持有着当前界面的引用，那GC就忍不住吐槽“这tm叫我怎么回收，不收了！”于是乎，你出现了内存泄露还沾沾自喜地在下个界面使用着这个工具类，甚至扬言，没事，反正已经初始化过了。

或者我们可以尝试这样，不直接持有上下文，只在使用的时候传入上下文，或者传入回调对象去操作上下文即可。如下


public final class Utils {
    // public Activity mContext;
    public InitParam mParam;
    public void init(InitParam param) {
        // mContext = context;
        mInitParam = param;
    }
    public void doSomething(Activity context){...}

    public void doSomething(ActivityCallback context){...}

}
public interface ActivityCallback{
        public void callback();
    }

public TargetActivity implement ActivityCallback{...}

避免直接持有，但是假设我是个杠精，我就要持有，怎么办！可以，满足你！

public final class Utils {
    /**
     * 弱引用形式持有activity
     */
    private WeakReference<Activity> mWeakReferInitActivity;

    public InitParam mParam;

    public void init(final Activity activity, InitParam param) {
        mWeakReferInitActivity = new WeakReference<>(activity);
        mInitParam = param;
    }
    public void doSomething(){...}

    /**
     * @return 返回上下文对象
     */
    public Activity getActivity() {
        return mWeakReferInitActivity.get();
    }

    /**
     * 销毁阶段移除上下文对象的软应用
     */
    public void detach(){
        if (mWeakReferInitActivity!=null){
            mWeakReferInitActivity.clear();
        }
    }
}

上下文在init或者attach阶段传入，使用软应用形式持有，在销毁的时候再执行对应的detach将软应用移除。那我再杠，你这里用的是activity，是短生命周期的，那我就不，我是个sdk或者库，我需要贯穿整个生命周期呢？一样鸭，在application类那里去attach和detach即可