单例模式使用比较常见，用来保证一个类仅有一个实例，并提供一个访问它的全局访问点。在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已经被创建了，那我就不创建了，所以也就避免了被创建两次的尴尬。
最后附上单例模式的结构图：
