# 标签： 读博客
我去，单例模式真的是被讲烂了的，实现方式也多种多样，什么懒汉式、饿汉式、隐藏构造方法啊、利用枚举的特性啊，利用抽象类啊、双层锁啊(java并发那本书里面有具体讲解)。。不说了，这一篇写的还不错，权当复习咯。
不管单例是怎么实现的，最终效果都是： 一个类只有一个实例，访问&获得该实例，只有一个全局访问点。
读完本篇，你对android中的log机制，在设计上会有一个初步的认识。
废话就这么多。
本文转载自：http://blog.csdn.net/guolin_blog/article/details/8860649
写软件的时候经常需要用到打印日志功能，可以帮助你调试和定位问题，项目上线后还可以帮助你分析数据。但是Java原生带有的System.out.println()方法却很少在真正的项目开发中使用，甚至像findbugs等代码检查工具还会认为使用System.out.println()是一个bug。
为什么作为Java新手神器的System.out.println()，到了真正项目开发当中会被唾弃呢？其实只要细细分析，你就会发现它的很多弊端。比如不可控制，所有的日志都会在项目上线后照常打印，从而降低运行效率；又或者不能将日志记录到本地文件，一旦打印被清除，日志将再也找不回来；再或者打印的内容没有Tag区分，你将很难辨别这一行日志是在哪个类里打印的。
你的leader也不是傻瓜，用System.out.println()的各项弊端他也清清楚楚，因此他今天给你的任务就是制作一个日志工具类，来提供更好的日志功能。不过你的leader人还不错，并没让你一开始就实现一个具备各项功能的牛逼日志工具类，只需要一个能够控制打印级别的日志工具就好。
这个需求对你来说并不难，你立刻就开始动手编写了，并很快完成了第一个版本：
（我不得不插个嘴，System.out.println()改造成有控制输出、加Tag输出，也不会太难，不过有机会自己实现，多好的机会，不要白不要；现实是，很多时候，你好辛苦的写的一个window的增量式日志分析器，麻痹的，根本没人用，别人用惯了eclipse自带的Android Device Monitor）
public class LogUtil {
public final int DEGUB = 0;
public final int INFO = 1;
public final int ERROR = 2;
public final int NOTHING = 3;
public int level = DEGUB;
public void debug(String msg) {
if (DEGUB >= level) {
System.out.println(msg);
}
}
public void info(String msg) {
if (INFO >= level) {
System.out.println(msg);
}
}
public void error(String msg) {
if (ERROR >= level) {
System.out.println(msg);
}
}
}通过这个类来打印日志，只需要控制level的级别，就可以自由地控制打印的内容。比如现在项目处于开发阶段，就将level设置为DEBUG，这样所有的日志信息都会被打印。而项目如果上线了，可以把level设置为INFO，这样就只能看到INFO及以上级别的日志打印。如果你只想看到错误日志，就可以把level设置为ERROR。而如果你开发的项目是客户端版本，不想让任何日志打印出来，可以将level设置为NOTHING。打印的时候只需要调用：
new LogUtil().debug("Hello World");(hehe,每次都new 对象啊，你疯了？好吧，作者自己也意识到了)
你迫不及待地将这个工具介绍给你的leader，你的leader听完你的介绍后说：“好样的，今后大伙都用你写的这个工具来打印日志了！”
可是没过多久，你的leader找到你来反馈问题了。他说虽然这个工具好用，可是打印这种事情是不区分对象的，这里每次需要打印日志的时候都需要new出一个新的LogUtil，太占用内存了，希望你可以将这个工具改成用单例模式实现。
你认为你的leader说的很有道理，而且你也正想趁这个机会练习使用一下设计模式，于是你写出了如下的代码：
public class LogUtil {
private static LogUtil sLogUtil;
public final int DEGUB = 0;
public final int INFO = 1;
public final int ERROR = 2;
public final int NOTHING = 3;
public int level = DEGUB;
private LogUtil() {
}
public static LogUtil getInstance() {
if (sLogUtil == null) { //多个线程同时进入此判断，同时进入方法体就呵呵了
sLogUtil = new LogUtil();
}
return sLogUtil;
}
public void debug(String msg) {
if (DEGUB >= level) {
System.out.println(msg);
}
}
public void info(String msg) {
if (INFO >= level) {
System.out.println(msg);
}
}
public void error(String msg) {
if (ERROR >= level) {
System.out.println(msg);
}
}
}首先将LogUtil的构造函数私有化，这样就无法使用new关键字来创建LogUtil的实例了。然后使用一个sLogUtil私有静态变量来保存实例，并提供一个公有的getInstance方法用于获取LogUtil的实例，在这个方法里面判断如果sLogUtil为空，就new出一个新的LogUtil实例，否则就直接返回sLogUtil。这样就可以保证内存当中只会存在一个LogUtil的实例了。单例模式完工！这时打印日志的代码需要改成如下方式：
LogUtil.getInstance().debug("Hello World");你将这个版本展示给你的leader瞧，他看后笑了笑，说：“虽然这看似是实现了单例模式，可是还存在着bug的哦。
你满腹狐疑，单例模式不都是这样实现的吗？还会有什么bug呢？
你的leader提示你，使用单例模式就是为了让这个类在内存中只能有一个实例的，可是你有考虑到在多线程中打印日志的情况吗？如下面代码所示：
public static LogUtil getInstance() {
if (sLogUtil == null) {
sLogUtil = new LogUtil();
}
return sLogUtil;
}如果现在有两个线程同时在执行getInstance方法，第一个线程刚执行完第2行，还没执行第3行，这个时候第二个线程执行到了第2行，它会发现sLogUtil还是null，于是进入到了if判断里面。这样你的单例模式就失败了，因为创建了两个不同的实例。
你恍然大悟，不过你的思维非常快，立刻就想到了解决办法，只需要给方法加上同步锁就可以了，代码如下：
public synchronized static LogUtil getInstance() { //呵呵，作者居然这样加锁..呵呵
if (sLogUtil == null) {
sLogUtil = new LogUtil();
}
return sLogUtil;
}这样，同一时刻只允许有一个线程在执行getInstance里面的代码，这样就有效地解决了上面会创建两个实例的情况。
你的leader看了你的新代码后说：“恩，不错。这确实解决了有可能创建两个实例的情况，但是这段代码还是有问题的。”
你紧张了起来，怎么还会有问题啊？
你的leader笑笑：“不用紧张，这次不是bug，只是性能上可以优化一些。你看一下，如果是在getInstance方法上加了一个synchronized，那么我每次去执行getInstace方法的时候都会受到同步锁的影响，这样运行的效率会降低，其实只需要在第一次创建LogUtil实例的时候加上同步锁就好了。我来教你一下怎么把它优化的更好。”
首先将synchronized关键字从方法声明中去除，把它加入到方法体当中：
public static LogUtil getInstance() {
synchronized (LogUtil.class) {
if (sLogUtil == null) {
sLogUtil = new LogUtil();
}
return sLogUtil;
}
}这样效果是和直接在方法上加synchronized完全一致的。然后在synchronized的外面再加一层判断，如下所示：
public static LogUtil getInstance() {
if (sLogUtil == null) {
synchronized (LogUtil.class) {
if (sLogUtil == null) {
sLogUtil = new LogUtil();
}
}
}
return sLogUtil;
}代码改成这样之后，只有在sLogUtil还没被初始化的时候才会进入到第3行，然后加上同步锁。等sLogUtil一但初始化完成了，就再也走不到第3行了，这样执行getInstance方法也不会再受到同步锁的影响，效率上会有一定的提升。
你情不自禁赞叹到，这方法真巧妙啊，能想得出来实在是太聪明了。
你的leader马上谦虚起来：“这种方法叫做双重锁定(Double-Check Locking)，可不是我想出来的，更多的资料你可以在网上查一查。”
单例：保证一个类仅有一个实例，并提供一个访问它的全局访问点。
我补充：
为啥上面的那个
public synchronized static LogUtil getInstance() { ... }效率不高，可以优化呢？
在java里synchronized，就是加锁，这里锁的是啥(信号量mutex？别乱猜，这里不是)你自己去查查，但是这里的锁肯定是排他的，一个线程占有锁，那么另外一个线程就只有阻塞着等待，也就是一个线程调用的时候，另外一个线程只有等着。为了避免尴尬(万一这个方法老长了，等它执行完，我们老早就不耐烦了)，就要在具体真正需要锁的地方在加锁。
于是，改善的办法是，在方法内部加锁(真正要获取对象实例的时候才去上锁，这部分才是真正需要锁的)，而不是在方法头上加锁。（加锁之前还要判断当前实例是否不存在，避免不问青红皂白执行到创建实例之前，就加个锁）
当然也有可能另外一个线程刚刚释放完锁，有一个线程就进入了
synchronized (LogUtil.class) {
if (sLogUtil == null) {
sLogUtil = new LogUtil();
}
}所以锁内部还是要进行 ==null的判断（不然你以为一旦获得了锁就可以创建对象，这样就无法避免上面说的这种巧合了，最终导致一个类不是一个实例），即Double-Check Locking。
扩展阅读： 《java并发编程的艺术》 （不过写的超级啰嗦，你还是找一下别人的博客写的总结吧---但是自己读这本书印象会更深刻）
原文：http://my.oschina.net/wizardmerlin/blog/512752