Android中设计模式无处不在之单例模式

本文探讨了Android中单例模式的实现,特别是在BluetoothOppManager中的应用,强调了多线程环境下同步锁的重要性。同时,文章提出了Double-Check Locking优化策略,以减少同步开销并确保线程安全。通过对单例模式的分析,帮助读者理解如何在实际开发中有效地使用和优化单例模式。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

单例模式使用比较常见,用来保证一个类仅有一个实例,并提供一个访问它的全局访问点。在Android application包中有个Bluetooth相关的包就用到了单例模式,实例代码如下:

public class BluetoothOppManager {

    private static BluetoothOppManager INSTANCE;

/** Used when obtaining a reference to the singleton instance. */
    private static Object INSTANCE_LOCK = new Object();

/**
    * Get singleton instance.
    */
   public static BluetoothOppManager getInstance(Context context) {
       synchronized (INSTANCE_LOCK) {
           if (INSTANCE == null) {
               INSTANCE = new BluetoothOppManager();
           }
           INSTANCE.init(context);

           return INSTANCE;
       }
   }

}

这里考虑到了多线程互斥的问题,引入了一个静态只读的进程辅助对象。它使得最先进入的那个线程来创建这个实例,以后的线程进入时不会创建实例对象。

不知道细心的读者发现没,这个getInstance()操作,每次被调用时,都会加上同步锁,这样会影响性能,所以有些改进的办法,见下文:

public static BluetoothOppManager getInstance(Context context) {

       if(INSTANCE == null)
           synchronized (INSTANCE_LOCK) {
               if (INSTANCE == null) {
                   INSTANCE = new BluetoothOppManager();
               }
               INSTANCE.init(context);

          }

           return INSTANCE;
       }
   }

这种做法只有在实例未被创建的时候才加锁,同时也能保证多线程的安全,所以该做法又叫Double-Check Locking(双重锁定)。这时又有同学要问,为什么我前面已经判断了INSTANCE是否为null,为什么同步代码里面又做了一次判断?这个也不难理解,当INSTANCE为null时,两个线程同时调用,这时它们都可以通过第一轮判断,都会立马加锁,但是最先进入临界区的线程先加锁,后进入的等待之。知道先进去的哥们创建好之后出来释放为止。此时,INSTANCE已经被创建,所以后进去的哥们被唤醒时,一看INSTANCE已经被创建了,那我就不创建了,所以也就避免了被创建两次的尴尬。

最后附上单例模式的结构图:

image

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值