zoukankan      html  css  js  c++  java
  • Java设计模式透析之 —— 单例(Singleton)

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

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

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

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

    [java] view plaincopy
    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 plaincopy
    1. new LogUtil().debug("Hello World");  

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

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

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

    [java] view plaincopy
    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 plaincopy
    1. LogUtil.getInstance().debug("Hello World");  
    你将这个版本展示给你的leader瞧,他看后笑了笑,说:“虽然这看似是实现了单例模式,可是还存在着bug的哦。

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

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

    [java] view plaincopy
    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 plaincopy
    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 plaincopy
    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 plaincopy
    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),可不是我想出来的,更多的资料你可以在网上查一查。”


    单例:保证一个类仅有一个实例,并提供一个访问它的全局访问点。 

  • 相关阅读:
    如何只通过Sandboxed Solution启动一个定时执行的操作
    创建与SharePoint 2010风格一致的下拉菜单 (续) 整合Feature Custom Action框架
    创建与SharePoint 2010风格一致的下拉菜单
    《SharePoint 2010 应用程序开发指南》第二章预览
    SharePoint 2013 App 开发 (1) 什么是SharePoint App?
    使用Jscex增强SharePoint 2010 JavaScript Client Object Model (JSOM)
    搜索范围的管理
    SharePoint 2010 服务应用程序(Service Application)架构(1)
    SharePoint 2010 服务应用程序(Service Application)架构(2)
    SharePoint 2013 App 开发 (2) 建立开发环境
  • 原文地址:https://www.cnblogs.com/lanzhi/p/6470053.html
Copyright © 2011-2022 走看看