设计模式入门（单例模式、饿汉式、懒汉式及线程安全、工厂模式、以及相关代码示例）

好奇的7号

已于 2023-08-21 09:59:40 修改

阅读量593

点赞数 2

于 2023-03-22 16:24:13 首次发布

本文链接：https://blog.csdn.net/weixin_44440311/article/details/129702711

版权

进一步改进：double-check locking

1、概念

设计模式是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。使用设计模式是为了重用代码、让代码更容易被他人理解、保证代码可靠性。

Java中最常用的设计模式有以下几种：

工厂模式（Factory Pattern）
单例模式（Singleton Pattern）
适配器模式（Adapter Pattern）
装饰器模式（Decorator Pattern）
观察者模式（Observer Pattern）

.......

这些设计模式在Java编程中应用广泛，可以帮助我们更好地组织代码，提高代码的可读性和可维护性。

2、单例模式

顾名思义，它能够保证一个类只有一个实例，并提供一个访问该实例的全局访问点。下面讲一讲它的实现方式。

2.1 饿汉式

饿汉式是指在类加载时就创建实例对象（一听就是构建了static的对象），以后每次获取实例都是返回同一个对象。这种方式的优点是线程安全，缺点是浪费内存空间。

public class Singleton {
    private static Singleton instance = new Singleton();//在内部创建好静态对象
//将构造器私有化，防止从外部创建对象
    private Singleton() {}
//只能通过getInstance方法返回这个创建好的唯一对象instance 
    public static Singleton getInstance() { 
        return instance;
    }
}

细节解释

getInstance方法是静态方法，在本例中如果想创建Singleton类的对象只有一种办法，那就是调用静态方法getInstance：

Singleton instance = Singleton.getInstance();

之所以只有这种方法，是因为如果你想通过new Singleton对象，再用对象调用该方法，这样的方法来操作的话，是不可行的。
因为Singleton类的构造函数是私有的，当我们使用new关键字创建一个新对象时，它将自动调用该类的构造函数。如果构造函数是公共的，则可以从类的外部访问它，并且可以在任何地方创建新对象。但是，如果构造函数是私有的，则只能从类的内部访问它。

2.2 懒汉式

相比于饿汉每次都自动创建对象，懒汉式是仅在第一次获取实例时才创建实例对象（以后每次获取的仍是同一个实例对象，正所谓单例）
优点是节省内存，缺点是线程不安全。

public class Singleton {
    private static Singleton instance;

    private Singleton() {}
//仅在外部调用getInstance方法时才会创建对象
//如果不调用，那么就算Singleton类被加载，也不会创建对象。
//这就是关键区别。
    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

线程安全的考虑：

对于上述懒汉式，存在线程不安全问题。
例如，线程t1将静态变量instance加载到t1线程的工作内存中时，如果还没有创建new对象，此时线程t2也将静态变量instance加载到t2线程的工作内存中，那么，这两个线程的判断语句都是成立的，会创建多个对象，则违背了单例模式的初衷。

解决方法是添加synchronized锁：（加在静态方法上，相当于锁住的类对象，即Singleton.Class对象）

public class Singleton {
    private static Singleton instance;

    private Singleton() {}
//仅在外部调用getInstance方法时才会创建对象
//如果不调用，那么就算Singleton类被加载，也不会创建对象。
//这就是关键区别。
    public static synchronized Singleton getInstance() {
//等价于 synchronized (Singleton.Class){...}
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

进一步改进：double-check locking

虽然有 synchronized锁的加持下，保证线程的安全与单例，但由于synchronized锁住的是类对象，即使创建好了单例对象，若其他的线程如果还想要获取锁创建单例对象，都要尝试进入synchronized同步代码块尝试获取锁。
实际上，单例模式下，如果已经创建了一个对象，那么就不需要再创建对象了（不需要再进入同步代码块了），但是像上面解释的这样，其他线程仍会尝试获取synchronized锁对象，这样将耗费不少性能。

我们希望只有第一次创建单例对象的时候线程互斥，后面的不需要。

采用双重判断，其实逻辑很简单，就是先判断是否已经存在单例对象，如果已经存在，那就不去抢夺锁。

public class Singleton {
    private static Singleton instance;

    private Singleton() {}

    public static Singleton getInstance() {
        //先判断是否有单例对象了：
        if (instance == null){
            //如果还没有，那才允许抢夺锁、创建单例对象。
            //如果有对象了，那就根本不运行。
            synchronized (Singleton.Class){
                if (instance == null) {
                    instance = new Singleton();
                } 
            }
        }
        return instance;
    }
}

最终版本：为什么单例对象需要使用 volatile 关键字？

在做了以上改进后，看上去没有什么问题，但实际上会因为指令重排序而发生问题，最后需要做的改进就是对instance加上volatile 关键字，从而避免指令重排，需要分析：
这里是因为 instance = new Singleton() ，它并非是一个原子操作，事实上，在 JVM 中上述语句至少做了以下这 3 件事：

第一步是给 instance 分配内存空间；

第二步开始调用 Singleton 的构造函数等，来初始化 singleton；

第三步，将 instance 对象指向分配的内存空间（执行完这步 instance 就不是 null 了）。

然而对于第2、第3步，先初始化再指向 或者是 先指向再初始化，看似结果都是一样的，因此JVM可能会进行指令重排，两者顺序不定。那么，不加volatile的情况下：如果重排后，指令执行顺序是先执行第三步再第二步，会发生什么？

假设，线程A调用getInstance，并先获取锁，运行到new Singleton时，先执行第三步，此时instance作为分配的空间的地址，已经不是null，此时还未执行第二步的初始化，也就是说单例对象此时还未创建完成。
恰恰在此时！线程B也来调用getInstance方法，由于instance此时不是null，所以第一个if判断后会直接return instance，但由于此时这个单例对象未创建完成就被返回，因此报错。

//最终版本代码
public class Singleton {
    private static volatile Singleton instance;

    private Singleton() {}

    public static Singleton getInstance() {
        //先判断是否有单例对象了：
        if (instance == null){
            //如果还没有，那才允许抢夺锁、创建单例对象。
            //如果有对象了，那就根本不运行。
            synchronized (Singleton.Class){
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

2.3 关于单例的一些细节解释

（1）有多种情况会导致类的加载

创建类的实例对象
访问类的静态变量或静态方法
使用反射方式访问类的信息
初始化类的子类
启动类中的主类

（2）关于线程的安全与否

饿汉式单例模式是线程安全的，因为在类加载时就创建了实例对象，所以不会存在多个实例的情况。
懒汉式单例模式是线程不安全的，因为在多线程环境下，可能会出现多个线程同时判断实例对象为null的情况，从而创建多个实例对象。为了解决这个问题，可以使用synchronized关键字来保证线程安全，但是这样会影响性能。另外，使用双重检查锁定（Double-Checked Locking）来保证线程安全，需要注意。

（3）什么情况下需要使用单例模式？

当我们需要确保只有一个对象可以创建并且可以全局访问时。
当我们需要控制类的实例化时，例如，当我们需要限制类的实例化次数时。
当我们需要在整个应用程序中共享数据时，例如，当我们需要在多个对象之间共享数据库连接时。

在这些情况下，单例模式可以确保只有一个对象可以创建并且可以全局访问。这可以帮助我们避免创建多个对象，从而节省内存和资源。

3、工厂模式

相对于单例模式，在工厂模式中，我们不直接实例化对象，而是通过工厂方法来创建对象。这样可以将对象的创建和使用分离，从而降低了耦合度。

在Java中，工厂模式的实现方式有多种，其中最常见的方式是简单工厂模式、工厂方法模式和抽象工厂模式。

3.1 简单工厂模式

在简单工厂模式中，我们创建对象而不将创建逻辑暴露给客户端，并使用一个共同的接口（如下面的Shape）来指向新创建的对象。
在下面这个例子中，ShapeFactory是一个简单工厂类，它根据传递给它的参数来创建不同的形状对象。关键：客户端只需要知道所需形状的名称（String类型就可以），而不需要知道形状的具体类名。

// Shape.java
public interface Shape {
    void draw();
}

// Rectangle.java
public class Rectangle implements Shape {
    @Override
    public void draw() {
        System.out.println("Inside Rectangle::draw() method.");
    }
}

// Circle.java
public class Circle implements Shape {
    @Override
    public void draw() {
        System.out.println("Inside Circle::draw() method.");
    }
}
// ShapeFactory.java
// 也就是说，在getShape里传入不同的名称，就会生成相应方法的对象
public class ShapeFactory {
    public Shape getShape(String shapeType){
        if(shapeType == null){
            return null;
        }
        if(shapeType.equalsIgnoreCase("CIRCLE")){
            return new Circle();
        } else if(shapeType.equalsIgnoreCase("RECTANGLE")){
            return new Rectangle();
        }
        return null;
    }
}

简单工厂模式优缺点

简单工厂模式的优点：

工厂类包含必要的逻辑判断，可以决定在什么时候创建哪一个产品的实例，客户端可以免除直接创建产品对象的责任，而仅仅“消费”产品，简化了客户端的使用。
客户端无需知道所创建的具体产品类的类名，只需要知道具体产品类所对应的参数即可，减少了耦合。
把初始化实例时的工作推迟到了工厂类的实例化中完成，实现了对象创建和使用的分离。

简单工厂模式的缺点：

工厂类集中了所有产品的创建逻辑，一旦这个工厂出现问题，整个系统将受到影响。
系统扩展困难，一旦添加新产品就不得不修改工厂逻辑，这样就会造成工厂逻辑过于复杂，不利于系统的扩展和维护。（因为每次传入都需要判断）

3.2 工厂方法模式

同样的，工厂方法模式也可以让用户自定义地创建对象，满足用户的特定需求，使产品的创建代码与其他代码分离；也可以降低耦合性，提高系统的灵活性和可维护性。
那么相对于简单工厂模式，工厂方法模式的改进在哪里呢？我们先来看一段工厂方法模式的示例代码：

假设我们正在开发一个游戏，游戏中有多种角色，每种角色都有不同的技能。我们可以使用工厂方法模式来创建角色。

首先，我们定义一个角色接口：

public interface Role {
    void action();
}

然后，我们定义多个角色类，实现角色接口：

public class Warrior implements Role {
    @Override
    public void action() {
        System.out.println("Warrior attack!");
    }
}

public class Mage implements Role {
    @Override
    public void action() {
        System.out.println("Mage cast spell!");
    }

现在，我们要使用工厂模式来分别创建这些角色，并调用他们自己的方法。
那么首先我们就要给角色创建相应的工厂！这些工厂能够创建相应的角色！

public interface RoleFactory {
    Role createRole();
}

//战士的工厂
public class WarriorFactory implements RoleFactory {
    @Override
    public Role createRole() {
        return new Warrior();
    }
}

//法师的工厂
public class MageFactory implements RoleFactory {
    @Override
    public Role createRole() {
        return new Mage();
    }
}

最后，我们可以使用这俩角色工厂来创建角色了！

RoleFactory warriorFactory = new WarriorFactory();//创建战士工厂的对象
Role warrior = warriorFactory.createRole();//通过工厂创建出了战士
warrior.action(); // 战士出击！输出：Warrior attack!

RoleFactory mageFactory = new MageFactory();//同理~~
Role mage = mageFactory.createRole();
mage.action(); // 输出：Mage cast spell!

对比

从上面的例子可以看出，相对于简单工厂模式，如果我要创建个“warrior ” ，就不是直接在一个简单工厂里调用同一个函数来进行判断、并创建战士的对象，而是让每一种不同的对象拥有自己的工厂，当用户想创建特定的对象时，就创建特定对象的工厂对象，再让工厂去创建所需的对象。
工厂创建对象的过程也是封装好的，不仅如此，不同对象的创建过程完全独立，不会出现简单工厂模式存在的问题：即，上文的“简单工厂模式的缺点”

工厂方法模式虽然改进了简单工厂模式，但缺点也很明显：每多一种对象就要多创建个工厂，增加了系统的抽象性和理解难度。

3.3 抽象工厂模式

继续改进，相对于普通工厂模式的每个工厂只能创建一种产品，抽象工厂模式的每个工厂可以创建一组相关的产品。这使得抽象工厂模式更加灵活，可以满足更多的需求。
以下面的代码为例，接着上面的战士法师的例子进行修改：

======================这是上面的工厂方法模式=======================
public interface RoleFactory {
    Role createRole();
}

//战士的工厂
public class WarriorFactory implements RoleFactory {
    @Override
    public Role createRole() {
        return new Warrior();
    }
}

//法师的工厂
public class MageFactory implements RoleFactory {
    @Override
    public Role createRole() {
        return new Mage();
    }
}
================================================================================
//现在变为：RoleFactory接口中有之前各自工厂的方法
//HumanGameFactory 一个工厂替代WarriorFactory 、MageFactory 两个工厂，并在内部实现了接口的不同方法。
public interface RoleFactory {
    Role createWarrior();
    Role createMage();
}

public class HumanRoleFactory implements RoleFactory {
    @Override
    public Role createWarrior() {
        return new Warrior();
    }

    @Override
    public Role createMage() {
        return new Mage();
    }
}

调用方法：

RoleFactory humanRoleFactory = new HumanRoleFactory();//只需创建一个抽象工厂对象

//humanRoleFactory对象，可以创建两个种不同的对象：

Role humanWarrior = humanRoleFactory.createWarrior();
humanWarrior.action(); // 输出：Warrior attack!

Role humanMage = humanRoleFactory.createMage();
humanMage.action(); // 输出：Mage cast spell!