所谓单例模式，简单来说，就是在整个应用中保证只有一个类的实例存在。就像是Java Web中的application，也就是提供了一个全局变量，用处相当广泛，比如保存全局数据，实现全局性的操作等。
首先，能够想到的最简单的实现是，把类的构造函数写成private的，从而保证别的类不能实例化此类，然后在类中提供一个静态的实例并能够返回给使用者。这样，使用者就可以通过这个引用使用到这个类的实例了。
饿汉式
public class SingletonClass {
private static final SingletonClass instance = new SingletonClass();
public static SingletonClass getInstance() {
return instance;
}
private SingletonClass() {
}
}
如上例，外部使用者如果需要使用SingletonClass的实例，只能通过getInstance()方法，并且它的构造方法是private的，这样就保证了只能有一个对象存在。
2. 性能优化——lazy loaded
上面的代码虽然简单，但是有一个问题——无论这个类是否被使用，都会创建一个instance对象。如果这个创建过程很耗时，比如需要连接10000次数据库(夸张了…:-))，并且这个类还并不一定会被使用，那么这个创建过程就是无用的。怎么办呢？ 为了解决这个问题，我们想到了新的解决方案：
懒汉式
public class SingletonClass {
private static SingletonClass instance = null;
public static SingletonClass getInstance() {
synchronized (SingletonClass.class) {
if(instance == null) {
instance = new SingletonClass();
}
return instance;
}
}
private SingletonClass() {
}
}
代码的变化有两处——首先，把instance初始化为null，直到第一次使用的时候通过判断是否为null来创建对象。因为创建过程不在声明处，所以那个final的修饰必须去掉。
我们来想象一下这个过程。要使用SingletonClass，调用getInstance()方法。第一次的时候发现instance是null，然后就新建一个对象，返回出去；第二次再使用的时候，因为这个instance是static的，所以已经不是null了，因此不会再创建对象，直接将其返回。
这个过程就成为lazy loaded，也就是迟加载——直到使用的时候才进行加载。
3. 同步
上面的代码很清楚，也很简单。然而就像那句名言：“80%的错误都是由20%代码优化引起的”。单线程下，这段代码没有什么问题，可是如果是多线程，麻烦就来了。我们来分析一下：
线程A希望使用SingletonClass，调用getInstance()方法。因为是第一次调用，A就发现instance是null的，于是它开始创建实例，就在这个时候，CPU发生时间片切换，线程B开始执行，它要使用SingletonClass，调用getInstance()方法，同样检测到instance是null——注意，这是在A检测完之后切换的，也就是说A并没有来得及创建对象——因此B开始创建。B创建完成后，切换到A继续执行，因为它已经检测完了，所以A不会再检测一遍，它会直接创建对象。这样，线程A和B各自拥有一个SingletonClass的对象——单例失败！
解决的方法也很简单，那就是加锁：
public class SingletonClass {
private static SingletonClass instance = null;
public synchronized static SingletonClass getInstance() {
if(instance == null) {
instance = new SingletonClass();
}
return instance;
}
private SingletonClass() {
}
}
是要getInstance()加上同步锁，一个线程必须等待另外一个线程创建完成后才能使用这个方法，这就保证了单例的唯一性。
4. 又是性能
上面的代码又是很清楚很简单的，然而，简单的东西往往不够理想。这段代码毫无疑问存在性能的问题——synchronized修饰的同步块可是要比一般的代码段慢上几倍的！如果存在很多次getInstance()的调用，那性能问题就不得不考虑了！
让我们来分析一下，究竟是整个方法都必须加锁，还是仅仅其中某一句加锁就足够了？我们为什么要加锁呢？分析一下出现lazy loaded的那种情形的原因。原因就是检测null的操作和创建对象的操作分离了。如果这两个操作能够原子地进行，那么单例就已经保证了。于是，我们开始修改代码：
public class SingletonClass {
private static SingletonClass instance = null;
public static SingletonClass getInstance() {
synchronized (SingletonClass.class) {
if(instance == null) {
instance = new SingletonClass();
}
}
return instance;
}
private SingletonClass() {
}
}
首先去掉getInstance()的同步操作，然后把同步锁加载if语句上。但是这样的修改起不到任何作用：因为每次调用getInstance()的时候必然要同步，性能问题还是存在。如果……如果我们事先判断一下是不是为null再去同步呢？
public class SingletonClass {
private static SingletonClass instance = null;
public static SingletonClass getInstance() {
if (instance == null) { //（位置a）
synchronized (SingletonClass.class) {
if (instance == null) { //（位置b）
instance = new SingletonClass(); //（位置c）
}
}
return instance;
}
private SingletonClass() {
}
}
还有问题吗？首先判断instance是不是为null，如果为null，加锁初始化；如果不为null，直接返回instance。
这就是double-checked locking设计实现单例模式。到此为止，一切都很完美。我们用一种很聪明的方式实现了单例模式。
5. 从源头检查
下面我们开始说编译原理。所谓编译，就是把源代码“翻译”成目标代码——大多数是指机器代码——的过程。针对Java，它的目标代码不是本地机器代码，而是虚拟机代码。编译原理里面有一个很重要的内容是编译器优化。所谓编译器优化是指，在不改变原来语义的情况下，通过调整语句顺序，来让程序运行的更快。这个过程成为reorder。
要知道，JVM只是一个标准，并不是实现。JVM中并没有规定有关编译器优化的内容，也就是说，JVM实现可以自由的进行编译器优化。
下面来想一下，创建一个变量需要哪些步骤呢？一个是申请一块内存，调用构造方法进行初始化操作，另一个是分配一个指针指向这块内存。这两个操作谁在前谁在后呢？JVM规范并没有规定。那么就存在这么一种情况，JVM是先开辟出一块内存，然后把指针指向这块内存，最后调用构造方法进行初始化。
如上所述的的内存模型，假如线程A已经把instance指向了那块内存，只是还没有调用构造方法（在位置c运行，但只完成了部分，但是instance不为null），而此时线程B（假如运行到位置a）检测到instance不为null，于是直接把instance返回了。
——问题出现了，尽管instance不为null，但它并没有构造完成，就像一套房子已经给了你钥匙，但你并不能住进去，因为里面还没有收拾。此时，如果B在A将instance构造完成之前就是用了这个实例，程序就会出现错误了！
于是，我们想到了下面的代码：
public class SingletonClass {
private static SingletonClass instance = null;
public static SingletonClass getInstance() {
if (instance == null) {
SingletonClass sc;
synchronized (SingletonClass.class) {
sc = instance;
if (sc == null) {
synchronized (SingletonClass.class) {
if(sc == null) {
sc = new SingletonClass();
}
}
instance = sc;
}
}
}
return instance;
}
private SingletonClass() {
}
}
我们在第一个同步块里面创建一个临时变量，然后使用这个临时变量进行对象的创建，并且在最后把instance指针临时变量的内存空间。写出这种代码基于以下思想，即synchronized会起到一个代码屏蔽的作用，同步块里面的代码和外部的代码没有联系。因此，在外部的同步块里面对临时变量sc进行操作并不影响instance，所以外部类在instance=sc;之前检测instance的时候，结果instance依然是null。
不过，这种想法完全是错误的！同步块的释放保证在此之前——也就是同步块里面——的操作必须完成，但是并不保证同步块之后的操作不能因编译器优化而调换到同步块结束之前进行。因此，编译器完全可以把instance=sc;这句移到内部同步块里面执行。这样，程序又是错误的了！
6. 解决方案
说了这么多，难道单例没有办法在Java中实现吗？其实不然！
在JDK 5之后，Java使用了新的内存模型。volatile关键字有了明确的语义——在JDK1.5之前，volatile是个关键字，但是并没有明确的规定其用途——被volatile修饰的写变量不能和之前的读写代码调整，读变量不能和之后的读写代码调整！因此，只要我们简单的把instance加上volatile关键字就可以了。简单地讲，volatile保证了变量构造过程的原子性。
public class SingletonClass {
private volatile static SingletonClass instance = null;
public static SingletonClass getInstance() {
if (instance == null) {
synchronized (SingletonClass.class) {
if(instance == null) {
instance = new SingletonClass();
}
}
}
return instance;
}
private SingletonClass() {
}
}
然而，这只是JDK1.5之后的Java的解决方案，那之前版本呢？其实，还有另外的一种解决方案，并不会受到Java版本的影响：
public class SingletonClass {
private static class SingletonClassInstance {
private static final SingletonClass instance = new SingletonClass();
}
public static SingletonClass getInstance() {
return SingletonClassInstance.instance;
}
private SingletonClass() { }
}
}
在这一版本的单例模式实现代码中，我们使用了Java的静态内部类。这一技术是被JVM明确说明了的，因此不存在任何二义性。在这段代码中，因为SingletonClass没有static的属性，因此并不会被初始化。直到调用getInstance()的时候，会首先加载SingletonClassInstance类，这个类有一个static的SingletonClass实例，因此需要调用SingletonClass的构造方法，然后getInstance()将把这个内部类的instance返回给使用者。由于这个instance是static的，因此并不会构造多次。
由于SingletonClassInstance是私有静态内部类，所以不会被其他类知道，同样，static语义也要求不会有多个实例存在。并且，JSL规范定义，类的构造必须是原子性的，非并发的，因此不需要加同步块。同样，由于这个构造是并发的，所以getInstance()也并不需要加同步。
饿汉式单例类可以在Java 语言内实现，但不易在C++ 内实现，因为静态初始化在C++ 里没有固定的顺序，因而静态变量的初始化与类的加载顺序没有保证，可能会出问题。这就是为什么GoF 在提出单例类的概念时，举的例子是懒汉式的。他们的书影响之大，以致Java 语言中单例类的例子也大多是懒汉式的。实际上，饿汉式单例类可能更符合Java 语言本身的特点。
相关推荐
不同单例模式的详细讲解，了解使用单例的最佳方式。
单例模式 3.建造模式 4.原型模式 5.适配器模式 6.桥梁模式 7.组合模式 8.装饰模式 9.门面模式 10.享元模式 11.代理模式 12.责任链模式 13.命令模式 14.解释器模式 15.迭代器模式 16.调停者模式 17....
主要给大家详细介绍了Java单例模式，关于Java中的单例模式并非看起来那么简单的，为什么要这么说呢？下面通过这篇文章来一起看看吧，有需要的朋友们可以参考借鉴。
深入理解Java的反射机制 深入理解Java异常体系 谈谈NIO的理解 谈一谈对JUC的理解 ArrayList的底层原理 HashMap的底层原理 iava单例模式详解 JAVA的内存结构 java队列 Java基础思考之数据传递 JAVA内存泄漏详解 java...
《java设计模式(第2版)》通过一个完整的java项目对经典著作design patterns一书介绍的23种设计模式进行了深入分析与讲解，实践性强，却又不失对模式本质的探讨。本书创造性地将这些模式分为5大类别，以充分展现各个...
深入理解Java的反射机制 深入理解Java异常体系 谈谈NIO的理解 谈一谈对JUC的理解 ArrayList的底层原理 HashMap的底层原理 iava单例模式详解 JAVA的内存结构 java队列 Java基础思考之数据传递 JAVA内存泄漏详解 java...
目录： 1、前端 ...10、Java单例模式详解 11、JAVA的内存结构 12、java队列 13、Java基础思考之数据传递 14、JAVA内存泄漏详解 15、java序列化方式 16、java中实现多态的机制 17、string常量池和intern
单例模式保证了Bean实例的唯一性，而适配器模式和装饰器模式则提高了代码的可扩展性和可重用性。代理模式和观察者模式在Spring AOP和事件驱动模型中得到了广泛应用，提供了强大的切面和事件处理能力。策略模式和模板...
您将了解如何正确创建对象实例、访问实例的成员变量和方法、实现对象的拷贝（包括浅拷贝和深拷贝）、判断对象相等性、管理对象的生命周期、实现线程安全的单例模式等。此外，我们还探讨了对象的哈希码、重写equals()...
java23种设计模式，深入理解灵活运用设计模式对于优化代码质量，提高编程能力非常必要！ Blog 设计模式 module blog 单例模式 Singleton pattern 工厂方法模式 Factory method model 抽象工厂模式 Abstract factory ...
第5章 单例模式（Singleton） 第6章 工厂方法模式（Factory Method） 第7章 抽象工厂模式（Abstract Factory） 第8章 生成器模式（Builder） 第9章 原型模式（Prototype） 第10章 中介者模式（Mediator） 第11...
第5章 单例模式（Singleton） 第6章 工厂方法模式（Factory Method） 第7章 抽象工厂模式（Abstract Factory） 第8章 生成器模式（Builder） 第9章 原型模式（Prototype） 第10章 中介者模式（Mediator） 第11...
第5章 单例模式（Singleton） 第6章 工厂方法模式（Factory Method） 第7章 抽象工厂模式（Abstract Factory） 第8章 生成器模式（Builder） 第9章 原型模式（Prototype） 第10章 中介者模式（Mediator） 第11...
深入理解volatile原理与使用.mp4 JDK5提供的原子类的操作以及实现原理.mp4 Lock接口认识与使用.mp4 手动实现一个可重入锁.mp4 AbstractQueuedSynchronizer(AQS)详解.mp4 使用AQS重写自己的锁.mp4 重入锁原理与演示....
单例模式（饿汉式、懒汉式） 4. Linux的基础知识 Linux下的进程 Linux定时任务调度 Linux的七个运行级别 Linux进程启动顺序 深入理解Linux下的守护进程 理解Linux配置文件 下一阶段更新计划 增加JDK源码的注释 + ...
第18节深入理解volatile原理与使用00:28:30分钟 | 第19节JDK5提供的原子类的操作以及实现原理00:27:10分钟 | 第20节Lock接口认识与使用00:19:54分钟 | 第21节手动实现一个可重入锁00:26:31分钟 | 第22节...
第18节深入理解volatile原理与使用00:28:30分钟 | 第19节JDK5提供的原子类的操作以及实现原理00:27:10分钟 | 第20节Lock接口认识与使用00:19:54分钟 | 第21节手动实现一个可重入锁00:26:31分钟 | 第22节...
原创声明：除设计模式背景或概念性内容外，其余全部内容均为自己深入理解原创输出，希望能够得到你支持的 star :star: 设计模式（Java实现） 设计模式专题，共 23 种设计模式。每种设计模式均从根本出发，深入理解...