Java设计模式之五--单例模式(最全且最简单单例模式罗列)

前言:快春节了,提前祝大家新年快乐!


一、为什么要使用单例模式?

java单例模式确保一个类只有一个实例,自行提供这个实例并向整个系统提供这个实例。
特点:
1,一个类只能有一个实例;
2,自己创建这个实例;
3,整个系统都要使用这个实例。
--------------------------------
Singleton模式主要作用是保证在Java应用程序中,一个类Class只有一个实例存在。在很多操作中,比如建立目录 数据库连接都需要这样的单线程操作。一些资源管理器常常设计成单例模式。
外部资源:譬如每台计算机可以有若干个打印机,但只能有一个Printer Spooler,以避免两个打印作业同时输出到打印机中。每台计算机可以有若干个通信端口,系统应当集中管理这些通信端口,以避免一个通信端口被两个请求同时调用。
内部资源,譬如,大多数的软件都有一个(甚至多个)属性文件存放系统配置。这样的系统应当由一个对象来管理这些属性文件。
--------------------------------
单例模式,能避免实例重复创建;
单例模式,应用于避免存在多个实例引起程序逻辑错误的场合;
单例模式,较节约内存。

二、单例的使用方法?
单例:保证一个类仅有一个实例,并提供一个访问它的全局访问点。

写软件的时候经常需要用到打印日志功能,可以帮助你调试和定位问题,项目上线后还可以帮助你分析数据。但是Java原生带有的System.out.println()方法却很少在真正的项目开发中使用,甚至像findbugs等代码检查工具还会认为使用System.out.println()是一个bug。


为什么作为Java新手神器的System.out.println(),到了真正项目开发当中会被唾弃呢?其实只要细细分析,你就会发现它的很多弊端。比如不可控制,所有的日志都会在项目上线后照常打印,从而降低运行效率;又或者不能将日志记录到本地文件,一旦打印被清除,日志将再也找不回来;再或者打印的内容没有Tag区分,你将很难辨别这一行日志是在哪个类里打印的。


你的leader也不是傻瓜,用System.out.println()的各项弊端他也清清楚楚,因此他今天给你的任务就是制作一个日志工具类,来提供更好的日志功能。不过你的leader人还不错,并没让你一开始就实现一个具备各项功能的牛逼日志工具类,只需要一个能够控制打印级别的日志工具就好。


这个需求对你来说并不难,你立刻就开始动手编写了,并很快完成了第一个版本:

[java] view plain copy
  1. public class LogUtil {  
  2.   
  3.     public final int DEGUB = 0;  
  4.   
  5.     public final int INFO = 1;  
  6.   
  7.     public final int ERROR = 2;  
  8.   
  9.     public final int NOTHING = 3;  
  10.   
  11.     public int level = DEGUB;  
  12.   
  13.     public void debug(String msg) {  
  14.         if (DEGUB >= level) {  
  15.             System.out.println(msg);  
  16.         }  
  17.     }  
  18.   
  19.     public void info(String msg) {  
  20.         if (INFO >= level) {  
  21.             System.out.println(msg);  
  22.         }  
  23.     }  
  24.   
  25.     public void error(String msg) {  
  26.         if (ERROR >= level) {  
  27.             System.out.println(msg);  
  28.         }  
  29.     }  
  30.   
  31. }  
通过这个类来打印日志,只需要控制level的级别,就可以自由地控制打印的内容。比如现在项目处于开发阶段,就将level设置为DEBUG,这样所有的日志信息都会被打印。而项目如果上线了,可以把level设置为INFO,这样就只能看到INFO及以上级别的日志打印。如果你只想看到错误日志,就可以把level设置为ERROR。而如果你开发的项目是客户端版本,不想让任何日志打印出来,可以将level设置为NOTHING。打印的时候只需要调用:
[java] view plain copy
  1. new LogUtil().debug("Hello World");  

你迫不及待地将这个工具介绍给你的leader,你的leader听完你的介绍后说:“好样的,今后大伙都用你写的这个工具来打印日志了!”


可是没过多久,你的leader找到你来反馈问题了。他说虽然这个工具好用,可是打印这种事情是不区分对象的,这里每次需要打印日志的时候都需要new出一个新的LogUtil,太占用内存了,希望你可以将这个工具改成用单例模式实现。


你认为你的leader说的很有道理,而且你也正想趁这个机会练习使用一下设计模式,于是你写出了如下的代码:

[java] view plain copy
  1. public class LogUtil {  
  2.   
  3.     private static LogUtil sLogUtil;  
  4.   
  5.     public final int DEGUB = 0;  
  6.   
  7.     public final int INFO = 1;  
  8.   
  9.     public final int ERROR = 2;  
  10.   
  11.     public final int NOTHING = 3;  
  12.   
  13.     public int level = DEGUB;  
  14.   
  15.     private LogUtil() {  
  16.     }  
  17.   
  18.     public static LogUtil getInstance() {  
  19.         if (sLogUtil == null) {  
  20.             sLogUtil = new LogUtil();  
  21.         }  
  22.         return sLogUtil;  
  23.     }  
  24.   
  25.     public void debug(String msg) {  
  26.         if (DEGUB >= level) {  
  27.             System.out.println(msg);  
  28.         }  
  29.     }  
  30.   
  31.     public void info(String msg) {  
  32.         if (INFO >= level) {  
  33.             System.out.println(msg);  
  34.         }  
  35.     }  
  36.   
  37.     public void error(String msg) {  
  38.         if (ERROR >= level) {  
  39.             System.out.println(msg);  
  40.         }  
  41.     }  
  42.   
  43. }  
首先将LogUtil的构造函数私有化,这样就无法使用new关键字来创建LogUtil的实例了。然后使用一个sLogUtil私有静态变量来保存实例,并提供一个公有的getInstance方法用于获取LogUtil的实例,在这个方法里面判断如果sLogUtil为空,就new出一个新的LogUtil实例,否则就直接返回sLogUtil。这样就可以保证内存当中只会存在一个LogUtil的实例了。单例模式完工!这时打印日志的代码需要改成如下方式:
[java] view plain copy
  1. LogUtil.getInstance().debug("Hello World");  
你将这个版本展示给你的leader瞧,他看后笑了笑,说:“虽然这看似是实现了单例模式,可是还存在着bug的哦。


你满腹狐疑,单例模式不都是这样实现的吗?还会有什么bug呢?


你的leader提示你,使用单例模式就是为了让这个类在内存中只能有一个实例的,可是你有考虑到在多线程中打印日志的情况吗?如下面代码所示:

[java] view plain copy
  1. public static LogUtil getInstance() {  
  2.     if (sLogUtil == null) {  
  3.         sLogUtil = new LogUtil();  
  4.     }  
  5.     return sLogUtil;  
  6. }  

如果现在有两个线程同时在执行getInstance方法,第一个线程刚执行完第2行,还没执行第3行,这个时候第二个线程执行到了第2行,它会发现sLogUtil还是null,于是进入到了if判断里面。这样你的单例模式就失败了,因为创建了两个不同的实例。


你恍然大悟,不过你的思维非常快,立刻就想到了解决办法,只需要给方法加上同步锁就可以了,代码如下:

[java] view plain copy
  1. public synchronized static LogUtil getInstance() {  
  2.     if (sLogUtil == null) {  
  3.         sLogUtil = new LogUtil();  
  4.     }  
  5.     return sLogUtil;  
  6. }  

这样,同一时刻只允许有一个线程在执行getInstance里面的代码,这样就有效地解决了上面会创建两个实例的情况。


你的leader看了你的新代码后说:“恩,不错。这确实解决了有可能创建两个实例的情况,但是这段代码还是有问题的。”


你紧张了起来,怎么还会有问题啊?


你的leader笑笑:“不用紧张,这次不是bug,只是性能上可以优化一些。你看一下,如果是在getInstance方法上加了一个synchronized,那么我每次去执行getInstace方法的时候都会受到同步锁的影响,这样运行的效率会降低,其实只需要在第一次创建LogUtil实例的时候加上同步锁就好了。我来教你一下怎么把它优化的更好。”


首先将synchronized关键字从方法声明中去除,把它加入到方法体当中:

[java] view plain copy
  1. public static LogUtil getInstance() {  
  2.     synchronized (LogUtil.class) {  
  3.         if (sLogUtil == null) {  
  4.             sLogUtil = new LogUtil();  
  5.         }  
  6.         return sLogUtil;  
  7.     }  
  8. }  

这样效果是和直接在方法上加synchronized完全一致的。然后在synchronized的外面再加一层判断,如下所示:

[java] view plain copy
  1. public static LogUtil getInstance() {  
  2.     if (sLogUtil == null) {  
  3.         synchronized (LogUtil.class) {  
  4.             if (sLogUtil == null) {  
  5.                 sLogUtil = new LogUtil();  
  6.             }  
  7.         }  
  8.     }  
  9.     return sLogUtil;  
  10. }  

代码改成这样之后,只有在sLogUtil还没被初始化的时候才会进入到第3行,然后加上同步锁。等sLogUtil一但初始化完成了,就再也走不到第3行了,这样执行getInstance方法也不会再受到同步锁的影响,效率上会有一定的提升。


你情不自禁赞叹到,这方法真巧妙啊,能想得出来实在是太聪明了。


你的leader马上谦虚起来:“这种方法叫做双重锁定(Double-Check Locking),可不是我想出来的,更多的资料你可以在网上查一查。”上面是从郭林大神博客中原封不动的挪下来的。但是这种
双重校验锁:麻烦,在当前Java内存模型中不一定都管用,某些平台和编译器甚至是错误的,因为instance = newLogUtil()这种代码在不同编译器上的行为和实现方式不可预知。

三、如何选择使用哪种单例模式?

从上面讲述中我们理解单例模式的基本原理。针对不同的类别的单例模式我们做出不同的比较,以便我们面对不同的需求来不同的实现。

 下面说说各个模式的优缺点,推荐使用枚举。

A.饿汉式(类加载的时候就创建实例)。
代码如下:

public class MaYun{
public static final Mayun instance = new Mayun(); //静态的final的MaYun
private MaYun() {
//MaYun诞生要做的事情
}
public void splitAlipay() {
System.out.println(“Alipay是我的啦!看你丫Yahoo绿眉绿眼的望着。。。”);
}
}
Call:MaYun.instance.splitAlipay();

Feature:可以通过反射机制攻击;线程安全[多个类加载器除外]。

A+.饿汉变种[推荐]

public class MaYun {
private static Mayun instance = new Mayun();
private static getInstance() {
return instance;
}
private MaYun() {
//MaYun诞生要做的事情
}
public void splitAlipay() {
System.out.println(“Alipay是我的啦!看你丫Yahoo绿眉绿眼的望着。。。”);
}
}

A++.饿汉变种(类初始化的时候实例化instance):

public class MaYun {
private MaYun instance = null;
static {
instance = new MaYun();
}
private MaYun() {
//MaYun诞生要做的事情
}
public static MaYun getInstance() {
return this.instance;
}
public void splitAlipay() {
System.out.println(“Alipay是我的啦!看你丫Yahoo绿眉绿眼的望着。。。”);
}
}

B.懒汉式。
代码如下:

public class MaYun {
private static MaYun instance = null;
private MaYun() {
//MaYun诞生要做的事情
}
public static MaYun getInstance() {
if (instance == null) {
instance = new MaYun();
}
return instance;
}
public void splitAlipay() {
System.out.println(“Alipay是我的啦!看你丫Yahoo绿眉绿眼的望着。。。”);
}
}
Call:MaYun.getInstance().splitAlipay();

Feature:延时加载;线程不安全,多线程下不能正常工作;需要额外的工作(Serializable、transient、readResolve())来实现序列化。

B+.懒汉式变种。

public class MaYun {
private static MaYun instance = null;
private MaYun() {
//MaYun诞生要做的事情
}
public static synchronized MaYun getInstance() {
if (instance == null) {
instance = new MaYun();
}
return instance;
}
public void splitAlipay() {
System.out.println(“Alipay是我的啦!看你丫Yahoo绿眉绿眼的望着。。。”);
}
}

Feature:线程安全;效率比较低,因为需要线程同步的时候比较少。

C.静态内部类[推荐]。
代码如下:

public class MaYun {
private static class SigletonHolder {
private static final instance = new MaYun();
}
public static final getInstance() {
return SigletonHolder.instance;
}
private MaYun() {
//MaYun诞生要做的事情
}
public void splitAlipay() {
System.out.println(“Alipay是我的啦!看你丫Yahoo绿眉绿眼的望着。。。”);
}
Call:MaYun.getInstance().splitAlipay();

Feature:线程安全;延迟加载。

D.双重校验锁[不推荐]。
代码如下:

public class MaYun {
private volatile static MaYun instance;
private MaYun (){}
public static MaYun getInstance() {
if (instance == null) {
synchronized (MaYun.class) {
if (instance == null) {
instance = new MaYun();
}
}
}
return instance;
}
}

Feature:jdk1.5之后才能正常达到单例效果。

E.编写一个包含单个元素的枚举类型[极推荐]。
代码如下:

public enum MaYun {
himself; //定义一个枚举的元素,就代表MaYun的一个实例
private String anotherField;
MaYun() {
//MaYun诞生要做的事情
//这个方法也可以去掉。将构造时候需要做的事情放在instance赋值的时候:
/** himself = MaYun() {
* //MaYun诞生要做的事情
* }
**/
}
public void splitAlipay() {
System.out.println(“Alipay是我的啦!看你丫Yahoo绿眉绿眼的望着。。。”);
}
}
Call:MaYun.himself.splitAlipay();

Feature:从Java1.5开始支持;无偿提供序列化机制,绝对防止多次实例化,即使在面对复杂的序列化或者反射攻击的时候。

总之,五类:懒汉,恶汉,双重校验锁,静态内部类,枚举。
恶汉:因为加载类的时候就创建实例,所以线程安全(多个ClassLoader存在时例外)。缺点是不能延时加载。
懒汉:需要加锁才能实现多线程同步,但是效率会降低。优点是延时加载。
双重校验锁:麻烦,在当前Java内存模型中不一定都管用,某些平台和编译器甚至是错误的,因为instance = new MaYun()这种代码在不同编译器上的行为和实现方式不可预知。
静态内部类:延迟加载,减少内存开销。因为用到的时候才加载,避免了静态field在单例类加载时即进入到堆内存的permanent代而永远得不到回收的缺点(大多数垃圾回收算法是这样)。
枚举:很好,不仅能避免多线程同步问题,而且还能防止反序列化重新创建新的对象。但是失去了类的一些特性,没有延迟加载.


单例:保证一个类仅有一个实例,并提供一个访问它的全局访问点。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值