懒汉式单例类
　　与饿汉式单例类相同之处是，类的构造子是私有的。与饿汉式单例类不同的是，懒汉式单例类在第一次被引用时将自己实例化。如果加载器是静态的，那么在懒汉式单例类被加载时不会将自己实例化。如下图所示，类图中给出了一个典型的饿汉式单例类实现。
　　代码清单2：懒汉式单例类

 

package com.javapatterns.singleton.demos;
public class LazySingleton
{
private static LazySingleton
m_instance = null;
/**
* 私有的默认构造子，保证外界无法直接实例化
*/
private LazySingleton() { }
/**
* 静态工厂方法，返还此类的惟一实例
*/
synchronized public static LazySingleton
getInstance()
{
if (m_instance == null)
{
m_instance = new LazySingleton();
}
return m_instance;
}  }

　　同样，由于构造子是私有的，因此，此类不能被继承。饿汉式单例类在自己被加载时将自己实例化。即便加载器是静态的，在饿汉式单例类被加载时仍会将自己实例化。单从资源利用效率角度来讲，这个比懒汉式单例类稍差些。
　　从速度和反应时间角度来讲，则比懒汉式单例类稍好些。然而，懒汉式单例类在实例化时， 必须处理好在多个线程同时首次引用此类时的访问限制问题，特别是当单例类作为资源控制器，在实例化时必然涉及资源初始化，而资源初始化很有可能耗费时间。这意味着出现多线程同时首次引用此类的机率变得较大。
　　饿汉式单例类可以在Java 语言内实现， 但不易在C++ 内实现，因为静态初始化在C++ 里没有固定的顺序，因而静态的m_instance 变量的初始化与类的加载顺序没有保证，可能会出问题。这是为什么GoF 在提出单例类的概念时，举的例子是懒汉式的。他们的书影响之大，以致Java 语言中单例类的例子也大多是懒汉式的。实际上，本书认为饿汉式单例类更符合Java 语言本身的特点。
　　使用单例模式必要条件：
　　下面我们探讨一下使用单例模式的必要条件。
　　在一个系统要求一个类只有一个实例时才应当使用单例模式。反过来说，如果一个类可以有几个实例共存，那么没有必要使用单例类。但是有经验的读者可能会看到很多不当地使用单例模式的例子，可见做到上面这一点并不容易，下面是一些这样的情况。
　　例子一
　　问：我的一个系统需要一些"全程"变量。学习了单例模式后，我发现可以使用一个单例类盛放所有的"全程"变量。请问这样做对吗？
　　答：这样做是违背单例模式的用意的。单例模式只应当在有真正的"单一实例"的需求时才可使用。
　　一个设计得当的系统不应当有所谓的"全程"变量，这些变量应当放到它们所描述的实体所对应的类中去。将这些变量从它们所描述的实体类中抽出来，放到一个不相干的单例类中去，会使得这些变量产生错误的依赖关系和耦合关系。
　　例子二
　　问：我的一个系统需要管理与数据库的连接。学习了单例模式后，我发现可以使用一个单例类包装一个Connection对象，并在finalize()方法中关闭这个Connection对象。这样的话，在这个单例类的实例没有被人引用时，这个finalize() 对象会被调用，因此，Connection 对象会被释放。这多妙啊。
　　答：这样做是不恰当的。除非有单一实例的需求，不然不要使用单例模式。在这里Connection 对象可以同时有几个实例共存，不需要是单一实例。
　　单例模式有很多的错误使用案例都与此例子相似，它们都是试图使用单例模式管理共享资源的生命周期，这是不恰当的。
　　下面简单说一下，笔者现在学习安卓，写了一个很小的音乐播放播放器，自己写了一个application。Application和Actovotu，Service一样是android框架的一个系统组件，当android程序启动时系统会创建一个 application对象，用来存储系统的一些信息。通常我们是不需要指定一个Application的，这时系统会自动帮我们创建，如果需要创建自己的Application，也很简单创建一个类继承 Application并在manifest的application标签中进行注册(只需要给Application标签增加个name属性把自己的 Application的名字定入即可)