单例模式的六种写法
定义
确保某个类只有一个实例，并且自行实例化并向整个系统提供这个实例java
UML结构图
场景
- 须要频繁的实例化和销毁的对象；
- 有状态的工具类对象
- 频繁访问数据库或文件对象；
- 确保某个类只有一个对象的场景，好比一个对象须要消耗的资源过多，访问io、数据库，须要提供全局配置的场景
几种单例模式
一、饿汉式
声明静态时已经初始化，在获取对象以前就初始化android
优势：获取对象的速度快，线程安全（由于虚拟机保证只会装载一次，在装载类的时候是不会发生并发的）
缺点：耗内存（若类中有静态方法，在调用静态方法的时候类就会被加载，类加载的时候就完成了单例的初始化，拖慢速度）
public class EagerSingleton {
//饿汉单例模式
//在类加载时就完成了初始化，因此类加载较慢，但获取对象的速度快
private static EagerSingleton instance = new EagerSingleton();//静态私有成员，已初始化
private EagerSingleton() {
//私有构造函数
}
public static EagerSingleton getInstance() //静态，不用同步（类加载时已初始化，不会有多线程的问题） {
return instance;
}
}
复制代码
二、懒汉式
synchronized同步锁： 多线程下保证单例对象惟一性shell
优势：单例只有在使用时才被实例化，必定程度上节约了资源
缺点：加入synchronized关键字，形成没必要要的同步开销。不建议使用。
//懒汉式单例模式
//比较懒，在类加载时，不建立实例，所以类加载速度快，但运行时获取对象的速度慢
private static LazySingleton intance = null;//静态私用成员，没有初始化
private LazySingleton() {
//私有构造函数
}
public static synchronized LazySingleton getInstance() //静态，同步，公开访问点 {
if(intance == null)
{
intance = new LazySingleton();
}
return intance;
}
}
复制代码
三、Double Check Lock（DCL）实现单例(使用最多的单例实现之一)
（双重锁定体如今两次判空）数据库
优势：既能保证线程安全，且单例对象初始化后调用getInstance不进行同步锁，资源利用率高
缺点：第一次加载稍慢，因为Java内存模型一些缘由偶尔会失败，在高并发环境下也有必定的缺陷，但几率很小。
代码示例：设计模式
public class SingletonKerriganD {
/** * 单例对象实例 */
private volatile static SingletonKerriganD instance = null;//这里加volatitle是为了不DCL失效
//DCL对instance进行了两次null判断
//第一层判断主要是为了不没必要要的同步
//第二层的判断则是为了在null的状况下建立实例。
public static SingletonKerriganD getInstance() {
if (instance == null) {
synchronized (SingletonKerriganD.class) {
if (instance == null) {
instance = new SingletonKerriganD();
}
}
return instance;
}
private SingletonKerriganD() {
//私有构造函数
}
}
复制代码
什么是DCL失效问题？
假如线程A执行到instance = new SingletonKerriganD()，大体作了以下三件事：安全
- 给实例分配内存
- 调用构造函数，初始化成员字段
- 将instance 对象指向分配的内存空间（此时sInstance不是null）
若是执行顺序是1-3-2，那多线程下，A线程先执行3，2还没执行的时候，此时instance！=null，这时候，B线程直接取走instance ，使用会出错，难以追踪。JDK1.5及以后的volatile 解决了DCL失效问题（双重锁定失效）bash
四、静态内部类单例模式
在调用 SingletonHolder.instance 的时候，才会对单例进行初始化，多线程
优势：线程安全、保证单例对象惟一性，同时也延迟了单例的实例化
缺点：须要两个类去作到这一点，虽然不会建立静态内部类的对象，可是其 Class 对象仍是会被建立，并且是属于永久代的对象。
（综合来看，私觉得这种方式是最好的单例模式）并发
public class SingletonInner {
private static class SingletonHolder{
private final static SingletonInner instance=new SingletonInner();
}
public static SingletonInner getInstance(){
return SingletonHolder.instance;
}
private SingletonInner() {
//私有构造函数
}
}
复制代码
这种方式如何保证单例且线程安全？
当getInstance方法第一次被调用的时候，它第一次读取SingletonHolder.instance，内部类SingletonHolder类获得初始化；而这个类在装载并被初始化的时候，会初始化它的静态域，从而建立Singleton的实例，因为是静态的域，所以只会在虚拟机装载类的时候初始化一次，并由虚拟机来保证它的线程安全性。 这个模式的优点在于，getInstance方法并无被同步，而且只是执行一个域的访问，所以延迟初始化并无增长任何访问成本。jvm
这种方式可否避免反射入侵？
答案是：不能。网上不少介绍到静态内部类的单例模式的优势会提到“经过反射，是不能从外部类获取内部类的属性的。 因此这种形式，很好的避免了反射入侵”，这是错误的，反射是能够获取内部类的属性（想了解更多反射的知识请看 java反射全解），入侵单例模式根本不在话下，直接看下面的例子：
单例类以下：
package eft.reflex;
public class Singleton {
private int a;
private Singleton(){
a=123;
}
private static class SingletonHolder{
private final static Singleton instance=new Singleton();
}
public static Singleton getInstance(){
return SingletonHolder.instance;
}
public int getTest(){
return a;
}
}
复制代码
入侵与测试代码以下：
public static void main(String[] args) throws Exception {
//经过反射获取内部类SingletonHolder的instance实例fInstance
Class cInner=Class.forName("eft.reflex.Singleton$SingletonHolder");
Field fInstance=cInner.getDeclaredField("instance");
//将此域的final修饰符去掉
Field modifiersField = Field.class.getDeclaredField("modifiers");
modifiersField.setAccessible(true);
modifiersField.setInt(fInstance, fInstance.getModifiers() & ~Modifier.FINAL);
//打印单例的某个属性，接下来要经过反射去篡改这个值
System.out.println("a="+ Singleton.getInstance().getTest());
//获取该单例的a属性fieldA
fInstance.setAccessible(true);
Field fieldA=Singleton.class.getDeclaredField("a");
//经过反射类构造器建立新的实例newSingleton（这里由于无参构造函数是私有的，不能经过Class.newInstance建立实例）
Constructor constructor=Singleton.class.getDeclaredConstructor();
constructor.setAccessible(true);
Singleton newSingleton= (Singleton) constructor.newInstance();
//让fInstance指向新的实例newSingleton，此时咱们的单例已经被偷梁换柱了！
fInstance.set(null,newSingleton);
//为盗版的单例的属性a设置新的值
fieldA.setAccessible(true);
fieldA.set(newSingleton,888);
//测试是否成功入侵
System.out.println("被反射入侵后：a="+ Singleton.getInstance().getTest());
fieldA.set(newSingleton,777);
System.out.println("被反射入侵后：a="+ Singleton.getInstance().getTest());
}
复制代码
输出结果：
a=123
被反射入侵后：a=888
被反射入侵后：a=777
复制代码
注意： 上述四种方法要杜绝在被反序列化时从新声明对象，须要加入以下方法：
private Object readResolve() throws ObjectStreamException{
return sInstance;
}
复制代码
为何呢？由于当JVM从内存中反序列化地"组装"一个新对象时，自动调用 readResolve方法来返回咱们指定好的对象
五、枚举单例
优势：线程安全，防止被反序列化
缺点：枚举相对耗内存
public enum SingletonEnum {
instance;
public void doThing(){
}
}
复制代码
只要 SingletonEnum.INSTANCE 便可得到所要实例。
这种方式如何保证单例？
首先，在枚举中咱们明确了构造方法限制为私有，在咱们访问枚举实例时会执行构造方法，同时每一个枚举实例都是static final类型的，也就代表只能被实例化一次。在调用构造方法时，咱们的单例被实例化。 也就是说，由于enum中的实例被保证只会被实例化一次，因此咱们的INSTANCE也被保证明例化一次。
上面示例中生成的字节码文件对instance的描述以下：
...
public static final eft.reflex.SingletonEnum instance;
flags: ACC_PUBLIC, ACC_STATIC, ACC_FINAL, ACC_ENUM
...
复制代码
能够看出，会自动生成 ACC_STATIC, ACC_FINAL这两个修饰符
枚举类型为何是线程安全的？
咱们定义的一个枚举，在第一次被真正用到的时候，会被虚拟机加载并初始化，而这个初始化过程是线程安全的。而咱们知道，解决单例的并发问题，主要解决的就是初始化过程当中的线程安全问题。因此，因为枚举的以上特性，枚举实现的单例是天生线程安全的。
为何使用枚举类型的单例模式更耗内存？
这里咱们从字节码的角度分析，并对比静态内部类的方式来讲明 首先看下静态内部类单例生成的字节码：
Classfile /G:/demo/reflexDemo/out/production/reflexDemo/eft/reflex/SingletonInner.class
Last modified 2019-8-8; size 500 bytes
MD5 checksum c69eb5edd5eec02d87359065d8650f02
Compiled from "SingletonInner.java"
public class eft.reflex.SingletonInner
SourceFile: "SingletonInner.java"
minor version: 0
major version: 51
flags: ACC_PUBLIC, ACC_SUPER
Constant pool:
#1 = Methodref #4.#19 // java/lang/Object."<init>":()V
#2 = Methodref #5.#20 // eft/reflex/SingletonInner$SingletonHolder.access$000:()Left/reflex/SingletonInner;
#3 = Class #21 // eft/reflex/SingletonInner
#4 = Class #22 // java/lang/Object
#5 = Class #23 // eft/reflex/SingletonInner$SingletonHolder
#6 = Utf8 SingletonHolder
#7 = Utf8 InnerClasses
#8 = Utf8 <init>
#9 = Utf8 ()V
#10 = Utf8 Code
#11 = Utf8 LineNumberTable
#12 = Utf8 LocalVariableTable
#13 = Utf8 this
#14 = Utf8 Left/reflex/SingletonInner;
#15 = Utf8 getInstance
#16 = Utf8 ()Left/reflex/SingletonInner;
#17 = Utf8 SourceFile
#18 = Utf8 SingletonInner.java
#19 = NameAndType #8:#9 // "<init>":()V
#20 = NameAndType #24:#16 // access$000:()Left/reflex/SingletonInner;
#21 = Utf8 eft/reflex/SingletonInner
#22 = Utf8 java/lang/Object
#23 = Utf8 eft/reflex/SingletonInner$SingletonHolder
#24 = Utf8 access$000
{
public eft.reflex.SingletonInner();
flags: ACC_PUBLIC
Code:
stack=1, locals=1, args_size=1
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
LineNumberTable:
line 3: 0
line 4: 4
LocalVariableTable:
Start Length Slot Name Signature
0 5 0 this Left/reflex/SingletonInner;
public static eft.reflex.SingletonInner getInstance();
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=1, locals=0, args_size=0
0: invokestatic #2 // Method eft/reflex/SingletonInner$SingletonHolder.access$000:()Left/reflex/SingletonInner;
3: areturn
LineNumberTable:
line 9: 0
}
复制代码
再看枚举单例生成的字节码：
Classfile /G:/demo/reflexDemo/out/production/reflexDemo/eft/reflex/SingletonEnum.class
Last modified 2019-8-9; size 989 bytes
MD5 checksum b97cfb98be4e5ce15fd85e934cc9a75c
Compiled from "SingletonEnum.java"
public final class eft.reflex.SingletonEnum extends java.lang.Enum<eft.reflex.SingletonEnum>
Signature: #31 // Ljava/lang/Enum<Left/reflex/SingletonEnum;>;
SourceFile: "SingletonEnum.java"
minor version: 0
major version: 51
flags: ACC_PUBLIC, ACC_FINAL, ACC_SUPER, ACC_ENUM
Constant pool:
#1 = Fieldref #4.#34 // eft/reflex/SingletonEnum.$VALUES:[Left/reflex/SingletonEnum;
#2 = Methodref #35.#36 // "[Left/reflex/SingletonEnum;".clone:()Ljava/lang/Object;
#3 = Class #14 // "[Left/reflex/SingletonEnum;"
#4 = Class #37 // eft/reflex/SingletonEnum
#5 = Methodref #10.#38 // java/lang/Enum.valueOf:(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/Enum;
#6 = Methodref #10.#39 // java/lang/Enum."<init>":(Ljava/lang/String;I)V
#7 = String #11 // instance
#8 = Methodref #4.#40 // eft/reflex/SingletonEnum."<init>":(Ljava/lang/String;I)V
#9 = Fieldref #4.#41 // eft/reflex/SingletonEnum.instance:Left/reflex/SingletonEnum;
#10 = Class #42 // java/lang/Enum
#11 = Utf8 instance
#12 = Utf8 Left/reflex/SingletonEnum;
#13 = Utf8 $VALUES
#14 = Utf8 [Left/reflex/SingletonEnum;
#15 = Utf8 values
#16 = Utf8 ()[Left/reflex/SingletonEnum;
#17 = Utf8 Code
#18 = Utf8 LineNumberTable
#19 = Utf8 valueOf
#20 = Utf8 (Ljava/lang/String;)Left/reflex/SingletonEnum;
#21 = Utf8 LocalVariableTable
#22 = Utf8 name
#23 = Utf8 Ljava/lang/String;
#24 = Utf8 <init>
#25 = Utf8 (Ljava/lang/String;I)V
#26 = Utf8 this
#27 = Utf8 Signature
#28 = Utf8 ()V
#29 = Utf8 doThing
#30 = Utf8 <clinit>
#31 = Utf8 Ljava/lang/Enum<Left/reflex/SingletonEnum;>;
#32 = Utf8 SourceFile
#33 = Utf8 SingletonEnum.java
#34 = NameAndType #13:#14 // $VALUES:[Left/reflex/SingletonEnum;
#35 = Class #14 // "[Left/reflex/SingletonEnum;"
#36 = NameAndType #43:#44 // clone:()Ljava/lang/Object;
#37 = Utf8 eft/reflex/SingletonEnum
#38 = NameAndType #19:#45 // valueOf:(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/Enum;
#39 = NameAndType #24:#25 // "<init>":(Ljava/lang/String;I)V
#40 = NameAndType #24:#25 // "<init>":(Ljava/lang/String;I)V
#41 = NameAndType #11:#12 // instance:Left/reflex/SingletonEnum;
#42 = Utf8 java/lang/Enum
#43 = Utf8 clone
#44 = Utf8 ()Ljava/lang/Object;
#45 = Utf8 (Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/Enum;
{
public static final eft.reflex.SingletonEnum instance;
flags: ACC_PUBLIC, ACC_STATIC, ACC_FINAL, ACC_ENUM
public static eft.reflex.SingletonEnum[] values();
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=1, locals=0, args_size=0
0: getstatic #1 // Field $VALUES:[Left/reflex/SingletonEnum;
3: invokevirtual #2 // Method "[Left/reflex/SingletonEnum;".clone:()Ljava/lang/Object;
6: checkcast #3 // class "[Left/reflex/SingletonEnum;"
9: areturn
LineNumberTable:
line 3: 0
public static eft.reflex.SingletonEnum valueOf(java.lang.String);
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=2, locals=1, args_size=1
0: ldc_w #4 // class eft/reflex/SingletonEnum
3: aload_0
4: invokestatic #5 // Method java/lang/Enum.valueOf:(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/Enum;
7: checkcast #4 // class eft/reflex/SingletonEnum
10: areturn
LineNumberTable:
line 3: 0
LocalVariableTable:
Start Length Slot Name Signature
0 11 0 name Ljava/lang/String;
public void doThing();
flags: ACC_PUBLIC
Code:
stack=0, locals=1, args_size=1
0: return
LineNumberTable:
line 8: 0
LocalVariableTable:
Start Length Slot Name Signature
0 1 0 this Left/reflex/SingletonEnum;
static {};
flags: ACC_STATIC
Code:
stack=4, locals=0, args_size=0
0: new #4 // class eft/reflex/SingletonEnum
3: dup
4: ldc #7 // String instance
6: iconst_0
7: invokespecial #8 // Method "<init>":(Ljava/lang/String;I)V
10: putstatic #9 // Field instance:Left/reflex/SingletonEnum;
13: iconst_1
14: anewarray #4 // class eft/reflex/SingletonEnum
17: dup
18: iconst_0
19: getstatic #9 // Field instance:Left/reflex/SingletonEnum;
22: aastore
23: putstatic #1 // Field $VALUES:[Left/reflex/SingletonEnum;
26: return
LineNumberTable:
line 4: 0
line 3: 13
}
复制代码
静态对比： 能够看出枚举类默认继承java.lang.Enum 对比两个字节码的常量池（Constant pool）个数，SingletonInner.class 24个，SingletonEnum.class 45个 对比两个字节码文件大小，SingletonInner.class 500字节，SingletonEnum.class 989字节，差了将近两倍，咱们知道jvm虚拟机会将class文件中的常量池载入到内存中，并保存在方法区，因此单从这点看，枚举会更耗内存（虽然这并不表明实际运行起来就所耗内存的差异），等有了更有说服力的证据再来更新~
为何枚举反序列化不会生成新的实例？
经过上面的字节码，咱们能够看出枚举类默认继承java.lang.Enum(而不是java.lang.Object),看下Enum类源码:
/** * prevent default deserialization--阻止默认反序列化 */
private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
throw new InvalidObjectException("can't deserialize enum");
}
private void readObjectNoData() throws ObjectStreamException {
throw new InvalidObjectException("can't deserialize enum");
}
复制代码
咱们知道，之前的全部的单例模式都有一个比较大的问题，就是一旦实现了Serializable接口以后，就再也不是单例得了，由于，每次调用 readObject()方法返回的都是一个新建立出来的对象，有一种解决办法就是使用readResolve()方法来避免此事发生。可是，为了保证枚举类型像Java规范中所说的那样，每个枚举类型极其定义的枚举变量在JVM中都是惟一的，在枚举类型的序列化和反序列化上，Java作了特殊的规定，原文不贴了，大概意思就是说，在序列化的时候Java仅仅是将枚举对象的name属性输出到结果中，反序列化的时候则是经过java.lang.Enum的valueOf方法来根据名字查找枚举对象。同时，编译器是不容许任何对这种序列化机制的定制的，所以禁用了writeObject、readObject、readObjectNoData、writeReplace和readResolve等方法。
在序列化过程当中，若是被序列化的类中定义了了writeObject 和 readObject 方法，虚拟机会试图调用对象类里的 writeObject 和 readObject 方法，进行用户自定义的序列化和反序列化。若是没有这样的方法，则默认调⽤用是 ObjectOutputStream 的 defaultWriteObject 方法以及ObjectInputStream 的 defaultReadObject 方法
六、使用容器实现单例模式
在程序的初始化，将多个单例类型注入到一个统一管理的类中，使用时经过key来获取对应类型的对象，这种方式使得咱们能够管理多种类型的单例，而且在使用时能够经过统一的接口进行操做。 这种方式是利用了Map的key惟一性来保证单例。
public class SingletonManager {
private static Map<String,Object> map=new HashMap<String, Object>();
private SingletonManager(){}
public static void registerService(String key,Object instance){
if (!map.containsKey(key)){
map.put(key,instance);
}
}
public static Object getService(String key){
return map.get(key);
}
}
复制代码
总结
全部单例模式须要处理得问题都是：
- 将构造函数私有化
- 经过静态方法获取一个惟一实例
- 保证线程安全
- 防止反序列化形成的新实例等。
推荐使用：DCL、静态内部类、枚举
单例模式优势
- 只有一个对象，内存开支少、性能好（当一个对象的产生须要比较多的资源，如读取配置、产生其余依赖对象时，能够经过应用启动时直接产生一个单例对象，让其永驻内存的方式解决）
- 避免对资源的多重占用（一个写文件操做，只有一个实例存在内存中，避免对同一个资源文件同时写操做）
- 在系统设置全局访问点，优化和共享资源访问（如：设计一个单例类，负责全部数据表的映射处理）
单例模式缺点
- 通常没有接口，扩展难
- android中，单例对象持有Context容易内存泄露，此时须要注意传给单例对象的Context最好是Application Context
android源码中的单例模式
单例模式应用普遍，根据实际业务需求来，这里只引出源码中个别场景，再也不详解，有兴趣的读者能够深刻查看源码
在平时的Android开发中，咱们常常会经过Context来获取系统服务，好比ActivityManagerService,AccountManagerService等系统服务,实际上ContextImpl也是经过SystemServiceRegistry.getSystemService来获取具体的服务，SystemServiceRegistry是个final类型的类。这里使用容器实现单例模式
SystemServiceRegistry 部分代码：
final class SystemServiceRegistry {
private static final HashMap<Class<?>, String> SYSTEM_SERVICE_NAMES = new HashMap<Class<?>, String>();
private static final HashMap<String, ServiceFetcher<?>> SYSTEM_SERVICE_FETCHERS = new HashMap<String, ServiceFetcher<?>>();
private SystemServiceRegistry() { }
static {
registerService(Context.LAYOUT_INFLATER_SERVICE, LayoutInflater.class,
new CachedServiceFetcher<LayoutInflater>() {
@Override
public LayoutInflater createService(ContextImpl ctx) {
return new PhoneLayoutInflater(ctx.getOuterContext());
}});
registerService(Context.ACTIVITY_SERVICE, ActivityManager.class,
new CachedServiceFetcher<ActivityManager>() {
@Override
public ActivityManager createService(ContextImpl ctx) {
return new ActivityManager(ctx.getOuterContext(), ctx.mMainThread.getHandler());
}});
.......
}
public static Object getSystemService(ContextImpl ctx, String name) {
ServiceFetcher<?> fetcher = SYSTEM_SERVICE_FETCHERS.get(name);
return fetcher != null ? fetcher.getService(ctx) : null;
}
private static <T> void registerService(String serviceName, Class<T> serviceClass, ServiceFetcher<T> serviceFetcher) {
SYSTEM_SERVICE_NAMES.put(serviceClass, serviceName);
SYSTEM_SERVICE_FETCHERS.put(serviceName, serviceFetcher);
}
......
}
复制代码
- WindowManagerImpl 中的WindowManagerGlobal(懒汉式)
public static WindowManagerGlobal getInstance() {
synchronized (WindowManagerGlobal.class) {
if (sDefaultWindowManager == null) {
sDefaultWindowManager = new WindowManagerGlobal();
}
return sDefaultWindowManager;
}
}
复制代码
参考资源
- 《Android源码设计模式解析与实战》
相关文章
- 1. 花式写单例之单例的六种写法
- 2. 模式--单例模式8种写法
- 3. 单例模式的七种写法
- 4. 单例模式的5种写法
- 5. Java单例模式的七种写法
- 6. Java单例模式的几种写法
- 7. Java单例模式的6种写法
- 8. 单例模式的几种写法
- 9. 单例模式的五种写法
- 10. Java：单例模式的七种写法
- 更多相关文章...
- • Spring实例化Bean的三种方法 - Spring教程
- • Scala 模式匹配 - Scala教程
- • 委托模式
- • Docker容器实战(六) - 容器的隔离与限制
相关标签/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
欢迎关注本站公众号,获取更多信息
相关文章
- 1. 花式写单例之单例的六种写法
- 2. 模式--单例模式8种写法
- 3. 单例模式的七种写法
- 4. 单例模式的5种写法
- 5. Java单例模式的七种写法
- 6. Java单例模式的几种写法
- 7. Java单例模式的6种写法
- 8. 单例模式的几种写法
- 9. 单例模式的五种写法
- 10. Java：单例模式的七种写法