Android 设计模式之单例模式

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

1. public class BluetoothOppManager {
   
2. 
   
3.     private static BluetoothOppManager INSTANCE;
   
4. 
   
5. /** Used when obtaining a reference to the singleton instance. */
   
6.     private static Object INSTANCE_LOCK = new Object();
   
7. 
   
8. /**
   
9.     * Get singleton instance.
   
10.     */
    
11.    public static BluetoothOppManager getInstance(Context context) {
    
12.        synchronized (INSTANCE_LOCK) {
    
13.            if (INSTANCE == null) {
    
14.                INSTANCE = new BluetoothOppManager();
    
15.            }
    
16.            INSTANCE.init(context);
    
17. 
    
18.            return INSTANCE;
    
19.        }
    
20.    }
    
21. 
    
22. }

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

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

1. public static BluetoothOppManager getInstance(Context context) {
   
2. 
   
3.        if(INSTANCE == null)
   
4.            synchronized (INSTANCE_LOCK) {
   
5.                if (INSTANCE == null) {
   
6.                    INSTANCE = new BluetoothOppManager();
   
7.                }
   
8.                INSTANCE.init(context);
   
9. 
   
10.           }
    
11. 
    
12.            return INSTANCE;
    
13.        }
    
14.    }

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