设计模式之单例模式的多种写法与线程安全单例模式是一种创建型设计模式它确保一个类只有一个实例并提供一个全局访问点来获取该实例。这一模式在需要控制资源如数据库连接、线程池、配置对象共享的场景中尤为重要。然而实现一个既简洁又线程安全的单例并非易事尤其是在多线程环境下。本文将深入探讨单例模式的多种实现方式并重点分析其线程安全性。最基本的单例实现是“懒汉式”。其特点在于实例仅在第一次被请求时才创建。一个简单的实现如下将构造函数私有化防止外部直接实例化提供一个静态私有变量保存实例再提供一个静态公有方法在该方法中判断实例是否已存在若不存在则创建。但这种实现存在明显的缺陷当多个线程同时首次调用获取实例的方法时可能会同时通过判空检查从而导致创建多个实例违反了单例的初衷。因此基础的懒汉式是线程不安全的。为了解决线程安全问题最直接的想法是使用synchronized关键字修饰获取实例的方法。这种方法确保了同一时间只有一个线程可以执行该方法从而避免了重复创建。然而这种同步的代价很高每次获取实例时都需要进行线程同步而实际上只有在第一次创建实例时才需要同步后续的调用都是读取已存在的实例这造成了不必要的性能开销。因此虽然“同步方法懒汉式”是线程安全的但效率低下不推荐在高并发场景中使用。为了提升性能出现了“双重检查锁定”模式。其核心思想是在获取实例的方法中首先检查实例是否已创建第一次检查如果未创建才进入同步代码块进入同步块后再次检查实例是否已创建第二次检查如果仍未创建则执行创建。这样同步仅发生在实例尚未创建的极少数情况下后续的调用可以无阻塞地直接返回实例。但该模式的实现需要将实例变量声明为volatile在Java等语言中以防止指令重排序导致其他线程获取到一个未完全初始化的实例。这是目前兼顾性能与线程安全的一种经典写法。与懒汉式相对应的是“饿汉式”。它在类加载时就立即初始化静态实例。由于类加载过程本身是线程安全的由JVM保证因此这种实现天生就是线程安全的且实现简单。但其缺点在于无论该实例最终是否被使用它都会在程序启动时被创建。如果实例的创建非常耗费资源或者程序在某种条件下根本不需要这个实例那么这种提前初始化就是一种资源浪费。因此饿汉式适用于实例占用资源不大、且初始化耗时短的场景。还有一种优雅的实现方式是使用“静态内部类”。它利用了JVM的类加载机制静态内部类只有在被引用时才会加载和初始化。我们可以在单例类中定义一个静态内部类该内部类持有外部类的静态最终实例。当调用获取实例的方法时才会触发内部类的加载从而创建实例。由于类加载过程是线程安全的因此这种实现同样是线程安全的并且实现了延迟加载的效果同时无需额外的同步开销。这是一种兼顾了懒加载与线程安全的优秀实现。在现代Java中实现单例最简洁的方式是使用“枚举”。从Java 5开始枚举类型不仅能表示常量集合其本身的特性就保证了全局唯一实例。定义一个单元素的枚举即可天然地防止反射攻击和序列化问题带来的多实例风险并且由JVM保证其线程安全。Joshua Bloch在《Effective Java》中强烈推荐这种方式认为它是实现单例的最佳方法。其代码极其简洁且功能完备。除了上述主流写法在某些特定框架或环境下还可以利用容器如Spring框架的IoC容器来管理单例生命周期通过配置将Bean的作用域设置为singleton由容器负责保证其单例特性。但这属于框架层面的单例管理与语言层面的实现有所不同。综上所述单例模式的实现方式多样选择哪一种需根据具体需求权衡。如果追求简单且不介意提前加载饿汉式是良好选择若注重延迟加载和性能双重检查锁定或静态内部类方式更为合适而枚举方式则提供了最全面、最简洁的线程安全保证。理解这些写法背后的线程安全原理对于设计出健壮、高效的单例至关重要也是每一位软件开发者必备的技能。
