重要设计模式

最新推荐文章于 2024-10-08 19:15:12 发布

weixin_58838927

最新推荐文章于 2024-10-08 19:15:12 发布

阅读量60

点赞数

文章标签：设计模式单例模式 java

本文链接：https://blog.csdn.net/weixin_58838927/article/details/130846248

版权

文章详细介绍了Java中的单例模式，包括懒汉式、饿汉式、线程安全的懒汉式、双重校验锁和静态内部类实现，强调了线程安全和延迟加载的重要性。同时，探讨了工厂模式的三种形式：简单工厂、工厂方法和抽象工厂模式，并提到了Spring框架中的工厂模式实现。此外，文章还讨论了适配器模式在SpringAOP和SpringMVC中的应用以及装饰者模式和代理模式的概念和应用场景。

摘要由CSDN通过智能技术生成

创建型设计模式

单例模式

懒汉式-线程不安全

私有静态变量 uniqueInstance 被延迟实例化，如果没有用到该类，那么就不会实例化 uniqueInstance，从而节约资源。

但多线程环境下不安全，当uniqueInstance为null且多个线程同时调用时，那么会有多个线程执行 uniqueInstance = new Singleton();语句，导致多次实例化 uniqueInstance

public class Singleton{

private static Singleton uniqueInstance;

private Singleton(){
}

public static Singleton getUniqueInstance(){

if(uniqueInstance == null){
 uniqueInstance = new Singleton();
}

return uniqueInstance;



}


}

饿汉式-线程安全

线程不安全问题主要是由于 uniqueInstance 被多次实例化，采取直接实例化 uniqueInstance 的方式就不会产生线程不安全问题。

但是直接实例化的方式也丢失了延迟实例化带来的节约资源的好处。

private static Singleton uniqueInstance = new Singleton();

懒汉式-线程安全

只需要对getUniqueInstance()方法加锁，那么同一时间点只有一个线程能进入该方法，从而避免了多次实例化问题，线程安全，也可以节约资源，但当一个线程进入方法后，其他试图进入该方法的线程都必须等待，因此性能上有一定的损耗。

public static synchronized Singleton getUniqueInstance() {
    if (uniqueInstance == null) {
        uniqueInstance = new Singleton();
    }
    return uniqueInstance;
}

双重校验锁-线程安全

uniqueInstance 只需要被实例化一次，之后就可以直接使用了。加锁操作只需要对实例化那部分的代码进行，只有当 uniqueInstance 没有被实例化时，才需要进行加锁，缩小了同步锁的范围

双重校验锁先判断 uniqueInstance 是否已经被实例化，如果没有被实例化，那么才对实例化语句进行加锁。

uniqueInstance 采用 volatile 关键字修饰也是很有必要的。这是因为new一个对象uniqueInstance = new Singleton(); 这段代码其实是分为三步执行。

分配内存空间
初始化对象
将 uniqueInstance 指向分配的内存地址

但是由于 JVM 具有指令重排的特性，有可能执行顺序变为了 1>3>2，这在单线程情况下自然是没有问题。但如果是多线程下，假设线程 1 首先执行新建实例的第一步，也就是分配单例对象的内存空间，然后线程 1 因为被重排序，所以去执行了新建实例的第三步，也就是把 singleton 指向之前的内存地址，在这之后对象不是 null，可是这时第 2 步并没有执行。假设这时线程 2 进入 getInstance 方法，由于这时 singleton 已经不是 null 了，所以会通过第一重检查并直接返回 singleton 对象并使用，但其实这时的 singleton 并没有完成初始化，所以使用这个实例的时候会报错。多线程下，有可能获得的是一个还没有被初始化的实例。

使用 volatile 可以禁止 JVM 的指令重排，保证在多线程环境下也能正常运行。

特点：uniqueInstance 采用 volatile 关键字修饰禁止JVM指令重排，不仅做到了延迟加载，而且是线程安全的，同时也避免了过多的同步环节。

public class Singleton {

    private volatile static Singleton uniqueInstance;

    private Singleton() {
    }

    public static Singleton getUniqueInstance() {
        if (uniqueInstance == null) {
            synchronized (Singleton.class) {
                if (uniqueInstance == null) {
                    uniqueInstance = new Singleton();
                }
            }
        }
        return uniqueInstance;
    }
}

考虑下面这种情况，如果只用外层一个if语句检验。

在 uniqueInstance == null 的情况下，如果两个线程同时执行 if 语句，那么两个线程就会同时进入 if 语句块内。虽然在 if 语句块内有加锁操作，但是两个线程都会执行 uniqueInstance = new Singleton(); 这条语句，只是先后的问题，那么就会进行两次实例化，从而产生了两个实例。因此必须使用双重校验锁，也就是需要使用两个 if 语句。

if (uniqueInstance == null) {//多个线程同时进入
    synchronized (Singleton.class) {
        uniqueInstance = new Singleton();//实例化多次，只是先后问题
    }
}

静态内部类实现

相比于饿汉式在类加载时就完成实例化，这种静态内部类的写法并不会有这个问题，当 Singleton 类加载时，静态内部类 SingletonHolder 没有被加载进内存。只有当调用 getUniqueInstance() 方法从而触发 SingletonHolder.INSTANCE 时 SingletonHolder 才会被加载，此时初始化 INSTANCE 实例。

特点 ：静态内部类写法与双重检查模式的优点一样，都是避免了线程不安全的问题，并且延迟加载，效率高，不存在内存浪费。

public class Singleton {

    private Singleton() {
    }

    private static class SingletonHolder {
        private static final Singleton INSTANCE = new Singleton();
    }

    public static Singleton getUniqueInstance() {
        return SingletonHolder.INSTANCE;
    }
}

可以看出，静态内部类和双重检查的写法都是不错的写法，但是它们不能防止被反序列化生成多个实例，那有没有更好的写法呢？最后我们来看枚举方式的写法。

枚举实现

这是单例模式的最佳实践，它实现简单，并且在面对复杂的序列化或者反射攻击的时候，能够防止实例化多次。

public enum Singleton {
    uniqueInstance;
}

前面几种实现单例的方式，其实是存在隐患的，那就是可能被反序列化生成新对象，产生多个实例，从而破坏了单例模式。另外如果不使用枚举来实现单例模式，会出现反射攻击，因为通过 setAccessible() 方法可以将私有构造函数的访问级别设置为 public，然后调用构造函数从而实例化对象。如果要防止这种攻击，需要在构造函数中添加防止实例化第二个对象的代码。

对于枚举类而言，反序列化的时候，会根据名字来找到对应的枚举对象，而不是创建新的对象，所以这就防止了反序列化导致的单例破坏问题的出现。

对于通过反射破坏单例而言，枚举类同样有防御措施。反射在通过 newInstance 创建对象时，会检查这个类是否是枚举类，如果是，就抛出 IllegalArgumentException(“Cannot reflectively create enum objects”) 异常，反射创建对象失败。

总结：解决序列化和反射攻击很麻烦，而枚举实现不会出现这两种问题。所以说枚举实现单例模式是最佳实践。

写法简单。枚举的写法不需要我们自己考虑懒加载、线程安全等问题。

线程安全有保障，枚举类的本质也是一个 Java 类，但是它的枚举值会在枚举类被加载时完成初始化，所以依然是由 JVM 帮我们保证了线程安全。

工厂模式

简单工厂：

所有的产品都共有一个工厂，如果新增产品，则需要修改代码，违反开闭原则。

是一种编程习惯，可以借鉴这种编程思路。

工厂方法模式：

给每个产品都提供了一个工厂，让工厂专门负责对应的产品的生产，遵循开闭原则。

项目中用的最多。

抽象工厂方法模式：

如果有多个纬度的产品需要配合生产时，优先建议采用抽象工厂（工厂的工厂）。

一般的企业开发中的较少。

Spring中的工厂模式：

Spring 使用工厂模式可以通过 BeanFactory 或 ApplicationContext 创建 bean 对象。

两者对比：

BeanFactory：延迟注入(使用到某个 bean 的时候才会注入),相比于ApplicationContext 来说会占用更少的内存，程序启动速度更快。
ApplicationContext：容器启动的时候，不管你用没用到，一次性创建所有 bean 。BeanFactory 仅提供了最基本的依赖注入支持，ApplicationContext 扩展了 BeanFactory ,除了有BeanFactory的功能还有额外更多功能，所以一般开发人员使用ApplicationContext会更多。

结构型模式

适配器模式

适配器模式(Adapter Pattern) 将一个接口转换成客户希望的另一个接口，适配器模式使接口不兼容的那些类可以一起工作。

Spring AOP 中的适配器模式

我们知道 Spring AOP 的实现是基于代理模式，但是 Spring AOP 的增强或通知(Advice)使用到了适配器模式，与之相关的接口是AdvisorAdapter 。

Advice 常用的类型有：BeforeAdvice（目标方法调用前,前置通知）、AfterAdvice（目标方法调用后,后置通知）、AfterReturningAdvice(目标方法执行结束后，return 之前)等等。每个类型 Advice（通知）都有对应的拦截器:MethodBeforeAdviceInterceptor、AfterReturningAdviceInterceptor、ThrowsAdviceInterceptor 等等。

Spring 预定义的通知要通过对应的适配器，适配成 MethodInterceptor 接口(方法拦截器)类型的对象（如：MethodBeforeAdviceAdapter 通过调用 getInterceptor 方法，将 MethodBeforeAdvice 适配成 MethodBeforeAdviceInterceptor ）。

Spring MVC 中的适配器模式

在 Spring MVC 中，DispatcherServlet 根据请求信息调用 HandlerMapping，解析请求对应的 Handler。解析到对应的 Handler（也就是我们平常说的 Controller 控制器）后，开始由HandlerAdapter 适配器处理。HandlerAdapter 作为期望接口，具体的适配器实现类用于对目标类进行适配，Controller 作为需要适配的类。

装饰者模式

装饰者模式可以动态地给对象添加一些额外的属性或行为。相比于使用继承，装饰者模式更加灵活。

简单点儿说就是当我们需要修改原有的功能，但我们又不愿直接去修改原有的代码时，设计一个 Decorator 套在原有代码外面。其实在 JDK 中就有很多地方用到了装饰者模式，比如 InputStream家族，InputStream 类下有 FileInputStream (读取文件)、BufferedInputStream (增加缓存,使读取文件速度大大提升)等子类都在不修改InputStream 代码的情况下扩展了它的功能。

意图：动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活。

优点：装饰类和被装饰类可以独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式可以动态扩展一个实现类的功能。

缺点：多层装饰比较复杂。

使用场景： 1、扩展一个类的功能。 2、动态增加功能，动态撤销。

注意事项：可代替继承。

代理模式

代理模式在 AOP 中的应用

AOP(Aspect-Oriented Programming，面向切面编程) 能够将那些与业务无关，却为业务模块所共同调用的逻辑或责任（例如事务处理、日志管理、权限控制等）封装起来，便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的可拓展性和可维护性。

Spring AOP 就是基于动态代理的，如果要代理的对象，实现了某个接口，那么 Spring AOP 会使用 JDK Proxy 去创建代理对象，而对于没有实现接口的对象，就无法使用 JDK Proxy 去进行代理了，这时候 Spring AOP 会使用 Cglib 生成一个被代理对象的子类来作为代理

当然，你也可以使用 AspectJ ,Spring AOP 已经集成了 AspectJ ，AspectJ 应该算的上是 Java 生态系统中最完整的 AOP 框架了。

使用 AOP 之后我们可以把一些通用功能抽象出来，在需要用到的地方直接使用即可，这样大大简化了代码量。我们需要增加新功能时也方便，这样也提高了系统扩展性。日志功能、事务管理等等场景都用到了 AOP

意图：为其他对象提供一种代理以控制对这个对象的访问。

优点： 1、职责清晰。 2、高扩展性。 3、智能化。

缺点： 1、由于在客户端和真实主题之间增加了代理对象，因此有些类型的代理模式可能会造成请求的处理速度变慢。 2、实现代理模式需要额外的工作，有些代理模式的实现非常复杂。

使用场景：按职责来划分，通常有以下使用场景： 1、远程代理。 2、虚拟代理。 3、Copy-on-Write 代理。 4、保护（Protect or Access）代理。 5、Cache代理。 6、防火墙（Firewall）代理。 7、同步化（Synchronization）代理。 8、智能引用（Smart Reference）代理。

注意事项： 1、和适配器模式的区别：适配器模式主要改变所考虑对象的接口，而代理模式不能改变所代理类的接口。 2、和装饰器模式的区别：装饰器模式为了增强功能，而代理模式是为了加以控制。

行为型模式

责任链模式

责任链模式(Chain of responsibility pattern): 通过责任链模式, 你可以为某个请求创建一个对象链. 每个对象依序检查此请求并对其进行处理或者将它传给链中的下一个对象。通常每个接收者都包含对另一个接收者的引用。

意图：避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。

主要解决：职责链上的处理者负责处理请求，客户只需要将请求发送到职责链上即可，无须关心请求的处理细节和请求的传递，所以职责链将请求的发送者和请求的处理者解耦了。

应用实例：jsp servlet 的 Filter。

优点： 1、降低耦合度。它将请求的发送者和接收者解耦。 2、简化了对象。使得对象不需要知道链的结构。 3、增强给对象指派职责的灵活性。通过改变链内的成员或者调动它们的次序，允许动态地新增或者删除责任。 4、增加新的请求处理类很方便。

缺点： 1、不能保证请求一定被接收。 2、系统性能将受到一定影响，而且在进行代码调试时不太方便，可能会造成循环调用。 3、可能不容易观察运行时的特征，有碍于除错。

使用场景： 1、有多个对象可以处理同一个请求，具体哪个对象处理该请求由运行时刻自动确定。 2、在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。 3、可动态指定一组对象处理请求。

策略模式

定义了一系列算法, 分别封闭起来, 让它们之间可以互相替换, 此模式让算法的变化独立于使用算法的客户。

意图：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。

主要解决：在有多种算法相似的情况下，使用 if...else 所带来的复杂和难以维护。

优点： 1、算法可以自由切换。 2、避免使用多重条件判断。 3、扩展性良好。

缺点： 1、策略类会增多。 2、所有策略类都需要对外暴露。

使用场景： 1、如果在一个系统里面有许多类，它们之间的区别仅在于它们的行为，那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为。 2、一个系统需要动态地在几种算法中选择一种。 3、如果一个对象有很多的行为，如果不用恰当的模式，这些行为就只好使用多重的条件选择语句来实现。

观察者模式

观察者模式(observer pattern): 在对象之间定义一对多的依赖, 这样一来, 当一个对象改变状态, 依赖它的对象都会收到通知, 并自动更新。

意图：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。

主要解决：一个对象状态改变给其他对象通知的问题，而且要考虑到易用和低耦合，保证高度的协作。

优点： 1、观察者和被观察者是抽象耦合的。 2、建立一套触发机制。

缺点： 1、如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。 2、如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。 3、观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。