单例模式android,单例模式的优缺点

小程序：扫一扫查出行
【扫一扫了解最新限行尾号】
复制小程序

android 几种单例模式的写法

先不论单例模式的写法，有些方面是相同的，比如都需要将唯一的对象设置为static的，都需要将构造方法private化，代码如下：

public class MyInstance { private static MyInstance instance; private MyInstance(){}

}

第一种：最原始的单例模式，代码如下：

public static MyInstance getInstance(){ if(instance==null){ instance=new MyInstance();

} return instance;

}

多线程并发时，可能会出现重复new对象的情况，因此不提倡使用。

第二种：将整个方法块进行加锁，保证线程安全。

public static synchronized MyInstance getInstance(){ if(instance==null){ instance=new MyInstance();

} return instance;

}

这种代码下，每条线程都会依次进入方法块内部，虽然实现了单例，但是影响了运行效率，可以使用但是也不怎么提倡。

第三种：进一步优化的方法。

public static MyInstance getsInstance(){ synchronized (MyInstance.class){ if(instance==null){ instance=new MyInstance(); return instance;

}else{ return instance;

}

这种方式只是第二种方法的一种优化，但是优化有限。

（以下的几种方法比较推荐使用）

第四种：双层判断加锁，效率影响小且保证了线程安全。

public static MyInstance getsInstance() { if (instance == null) { synchronized (MyInstance.class) { if(instance==null){ instance=new MyInstance();

}

} return instance;

}

这种方法是对第二种和第三种方法的进一步优化，比较推荐使用。

第五种：内部类实现单例，不用线程锁来实现效率的提升。

public class MyInstance { private MyInstance() {

} public static MyInstance getInstance(){ return MyInstanceHolder.instance;

} private static class MyInstanceHolder{ private static MyInstance instance=new MyInstance();

}

在内部类中new对象，再将内部类的对象返回，这种方法是使用了java中class加载时互斥的原理来实现了线程的安全。不加线程锁也使得运行效率不会受到较大的影响。比较提倡。

如何使用android单例模式

java模式之单例模式：

单例模式确保一个类只有一个实例，自行提供这个实例并向整个系统提供这个实例。

特点：

1，一个类只能有一个实例

2，自己创建这个实例

3，整个系统都要使用这个实例

Singleton模式主要作用是保证在Java应用程序中，一个类Class只有一个实例存在。在很多操作中，比如建立目录

数据库连接都需要这样的单线程操作。一些资源管理器常常设计成单例模式。

外部资源：譬如每台计算机可以有若干个打印机，但只能有一个Printer

Spooler,以避免两个打印作业同时输出到打印机中。每台计算机可以有若干个通信端口，系统应当集中管理这些通信端口，以避免一个通信端口被两个请求同时调用。内部资源，譬如，大多数的软件都有一个（甚至多个）属性文件存放系统配置。这样的系统应当由一个对象来管理这些属性文件。

一个例子：Windows

回收站。

在整个视窗系统中，回收站只能有一个实例，整个系统都使用这个惟一的实例，而且回收站自行提供自己的实例。因此，回收站是单例模式的应用。

两种形式：

1，饿汉式单例类

public class Singleton {

private Singleton(){}

//在自己内部定义自己一个实例，是不是很奇怪？

//注意这是private 只供内部调用

private static Singleton instance =

new Singleton();

//这里提供了一个供外部访问本class的静态方法，可以直接访问

public static Singleton getInstance() {

return instance;

}

2，懒汉式单例类

public class Singleton {

private static Singleton instance = null;

public static synchronized Singleton

getInstance() {

//这个方法比上面有所改进，不用每次都进行生成对象，只是第一次

//使用时生成实例，提高了效率！

if (instance==null)

instance＝new Singleton();

return instance; }

}

第二中形式是lazy initialization，也就是说第一次调用时初始Singleton，以后就不用再生成了。

注意到lazy

initialization形式中的synchronized，这个synchronized很重要，如果没有synchronized，那么使用getInstance()是有可能得到多个Singleton实例。

一般来说第一种比较安全

我自己比较常用的方式：

public class Singleton {

private volatile static

Singleton singleton;

private Singleton(){}

public static Singleton getInstance(){

if(singleton==null){

synchronized(Singleton.class){

if(singleton==null){

singleton=new Singleton();

}

return singleton;

}

结合Android看看单例模式怎么写

单例模式常见的两种实现方式饿汉模式和双重锁模式

•饿汉模式

public class HungrySingleton {

private static HungrySingleton mInstance = new HungrySingleton();

private HungrySingleton() {

}

public static HungrySingleton getInstance() {

return mInstance;

}

不得不说，饿汉模式这个名字起得的确很巧，这种方式，不管你用不用得着这个实例，先给你创建（new）出来，生怕将来创建没机会似得，完全就是今朝有酒今朝醉的节奏。

与上面对应的还有一种就是懒汉模式，就是在用的时候才在getInstance 方法中完成实例的创建（new），真是“懒”，同时给这个方法添加synchronized 关键字，可以确保在多线程情况下单例依旧唯一，但是懒汉模式每次调用getInstance 方法时由于synchronized 的存在，需要进行同步，造成不必要的资源开销。因此便有了下面双重锁模式的实现方式。

•双重锁模式（DCL 实现）

public class LazySingleton {

private static LazySingleton mInstance = null;

private LazySingleton() {

}

public static LazySingleton getInstance() {

if (mInstance == null) {

synchronized (LazySingleton.class) {

if (mInstance == null) {

mInstance = new LazySingleton();

}

return mInstance;

}

这样既避免了饿汉模式的缺点，又解决了懒汉模式的不足；确保单例只在第一次真正需要的时候创建。

Android 中的使用

在日常的Android开发中，也可以见到单例模式的身影。

•Glide

使用Glide加载图片非常方便，大家应该不陌生，可以看一下它的源码中单例模式的实现方式。

Glide.with(this).load(url).into(imageView);

//Glide.with()

public static RequestManager with(FragmentActivity activity) {

RequestManagerRetriever retriever = RequestManagerRetriever.get();

return retriever.get(activity);

}

//RequestManagerRetriever.get()

/** The singleton instance of RequestManagerRetriever. */

private static final RequestManagerRetriever INSTANCE = new RequestManagerRetriever();

/**

* Retrieves and returns the RequestManagerRetriever singleton.

public static RequestManagerRetriever get() {

return INSTANCE;

}

可以看到，当我们写下Glide.with(..) 这行代码时，就完成了RequestManagerRetriever 这个类的实例化，这个类的单例模式是使用饿汉模式实现的。

•EventBus

public static EventBus getDefault() {

if (defaultInstance == null) {

synchronized (EventBus.class) {

if (defaultInstance == null) {

defaultInstance = new EventBus();

}

return defaultInstance;

};

很明显，EventBus的单例模式使用双重锁模式实现的。

•InputMethodManager static InputMethodManager sInstance

public static InputMethodManager getInstance() {

synchronized (InputMethodManager.class) {

if (sInstance == null) {

IBinder b = ServiceManager.getService(Context.INPUT_METHOD_SERVICE);

IInputMethodManager service = IInputMethodManager.Stub.asInterface(b);

sInstance = new InputMethodManager(service, Looper.getMainLooper());

}

return sInstance;

}

InputMethodManager 的单例模式是使用懒汉模式实现。

可以看到，关于单例模式的实现方式，面对不同的场景，我们可以做出不同的选择

•Glide的单例模式虽然是使用饿汉模式实现，但理论上来说并不会造成内存资源的浪费，因为当我们通过gradle的配置引入Glide的库时，就是为了加载图片，必然会使用Glide.with进行相关的操作。同时RequestManagerRetriever 这个类应该是一个网络请求的管理类（Glide源码没有研究过，这里只是猜测），这样的一个类必然需要使用单列模式，试想如果存在多个管理类的实例，那么谈何管理，那么的多Request到底听哪个manger 的，这就是前面提到必须使用单列模式的情景。

•EventBus 作为事件总线的更要使用单例模式了，如果说EventBus的实例不是单例模式，那么他就无法实现它的功能了。对于EventBus不了解的同学，可以看看

EventBus 3.0 相见恨晚，EventBus真的很强大。

•InputMethodManager 使用懒汉模式实现单例也是无可厚非的，毕竟谁会去频繁的获取那么多他的实例呢；同时作为一个系统的输入法管理器，他也必须是唯一的，因此这个类也需要单例模式来实现它唯一的实例供外部使用。

由上可见，关于单例模式的实现，没有说哪一种方式最好，只有最合适的实现方式；实际开发中，单例模式应该怎么写，还需要根据业务场景做最合适的选择，无论是饿汉懒汉实用才是好汉。个人感觉，饿汉模式是一种简单又方便的实现方式，一个类既然已经写成了单例模式，必然是要使用的呀，谁会去创建一个饿汉模式的单例，又不去使用这个单例呢？

之前在使用Volley的时候，就是使用饿汉模式创建整个应用的RequestQueue单例，所有需要网络请求的地方，把request添加到RequestQueue单例中即可。

public class MyApplication extends Application{

// 建立请求队列

public static RequestQueue queue;

@Override

public void onCreate() {

super.onCreate();

queue = Volley.newRequestQueue(getApplicationContext());

}

public static RequestQueue getHttpQueue() {

return queue;

}