艾编程coding老师课堂笔记：java设计模式与并发编程笔记

设计模式概念

1.1 什么是设计模式

设计模式（Design Pattern）是前辈们对代码开发经验的总结，是解决特定问题的一系列套路。它不是语法规定，而是一套用来提高代码可复用性、可维护性、可读性、稳健性以及安全性的解决方案。

1995 年，GoF（Gang of Four，四人组/四人帮）合作出版了《设计模式：可复用面向对象软件的基础》一书，共收录了 23 种设计模式，从此树立了软件设计模式领域的里程碑，人称「GoF设计模式」。

这 23 种设计模式的本质是面向对象设计原则的实际运用，是对类的封装性、继承性和多态性，以及类的关联关系和组合关系的充分理解。

1.2 设计模式的概念与意义

有关软件设计模式的定义很多，有些从模式的特点来说明，有些从模式的作用来说明。

1. 软件设计模式的概念

软件设计模式（Software Design Pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。它描述了在软件设计过程中的一些不断重复发生的问题，以及该问题的解决方案。也就是说，它是解决特定问题的一系列套路，是前辈们的代码设计经验的总结，具有一定的普遍性，可以反复使用。其目的是为了提高代码的可重用性、代码的可读性和代码的可靠性。

2. 学习设计模式的意义

设计模式的本质是面向对象设计原则的实际运用，是对类的封装性、继承性和多态性以及类的关联关系和组合关系的充分理解。

正确使用设计模式具有以下优点。

• 可以提高程序员的思维能力、编程能力和设计能力。

• 使程序设计更加标准化、代码编制更加工程化，使软件开发效率大大提高，从而缩短软件的开发周期。

• 使设计的代码可重用性高、可读性强、可靠性高、灵活性好、可维护性强。

当然，软件设计模式只是一个引导。在具体的软件幵发中，必须根据设计的应用系统的特点和要求来恰当选择。对于简单的程序开发，苛能写一个简单的算法要比引入某种设计模式更加容易。但对大项目的开发或者框架设计，用设计模式来组织代码显然更好。

 

单例模式的探究

单例模式可以说只要是一个合格的开发都会写，但是如果要深究，小小的单例模式可以牵扯到很多东西，比如 多线程是否安全，是否懒加载，性能等等。还有你知道几种单例模式的写法呢？如何防止反射破坏单例模式？今天，我们来探究单例模式。

关于单例模式的概念，在这里就不在阐述了，相信每个小伙伴都了如指掌。我们直接进入正题：

2.1、饿汉式

public class Hungry {
    private Hungry() {
    }
    private final static Hungry hungry = new Hungry();
​
    public static Hungry getInstance() {
        return hungry;
    }
}

 

饿汉式是最简单的单例模式的写法，保证了线程的安全，在很长的时间里，我都是饿汉模式来完成单例的，因为够简单，后来才知道饿汉式会有一点小问题，看下面的代码：

public class Hungry {
    private byte[] data1 = new byte[1024];
    private byte[] data2 = new byte[1024];
    private byte[] data3 = new byte[1024];
    private byte[] data4 = new byte[1024];
    
    private Hungry() {
    }
​
    private final static Hungry hungry = new Hungry();
​
    public static Hungry getInstance() {
        return hungry;
    }
}

 

在Hungry类中，我定义了四个byte数组，当代码一运行，这四个数组就被初始化，并且放入内存了，如果长时间没有用到getInstance方法，不需要Hungry类的对象，这不是一种浪费吗？我希望的是 只有用到了 getInstance方法，才会去初始化单例类，才会加载单例类中的数据。所以就有了 第二种单例模式：懒汉式。

2.2、懒汉式

public class LazyMan {
    private LazyMan() {
    }
​
    private static LazyMan lazyMan;
​
    public static LazyMan getInstance() {
        if (lazyMan == null) {
            synchronized (LazyMan.class) {
                if (lazyMan == null) {
                    lazyMan = new LazyMan();
                }
            }
        }
        return lazyMan;
    }
}

 

DCL懒汉式的单例，保证了线程的安全性，又符合了懒加载，只有在用到的时候，才会去初始化，调用效率也比较高，但是这种写法在极端情况还是可能会有一定的问题。因为

lazyMan = new LazyMan();

不是原子性操作，至少会经过三个步骤：

1. 分配内存

2. 执行构造方法

3. 指向地址

由于指令重排，导致A线程执行 lazyMan = new LazyMan();的时候，可能先执行了第三步（还没执行第二步），此时线程B又进来了，发现lazyMan已经不为空了，直接返回了lazyMan，并且后面使用了返回的lazyMan，由于线程A还没有执行第二步，导致此时lazyMan还不完整，可能会有一些意想不到的错误，所以就有了下面一种单例模式。

这种单例模式只是在上面DCL单例模式增加一个volatile关键字来避免指令重排：

public class LazyMan {
    private LazyMan() {
    }
​
    private volatile static LazyMan lazyMan;
​
    public static LazyMan getInstance() {
        if (lazyMan == null) {
            synchronized (LazyMan.class) {
                if (lazyMan == null) {
                    lazyMan = new LazyMan();
                }
            }
        }
        return lazyMan;
    }
}

 

2.3、静态内部类

还有这种方式是第一种饿汉式的改进版本，同样也是在类中定义static变量的对象，并且直接初始化，不过是移到了静态内部类中，十分巧妙。既保证了线程的安全性，同时又满足了懒加载。

public class Holder {
    private Holder() {
    }
​
    public static Holder getInstance() {
        return InnerClass.holder;
    }
​
    private static class InnerClass {
        private static final Holder holder = new Holder();
    }
}

 

2.4、万恶的反射

万恶的反射登场了，反射是一个比较霸道的东西，无视private修饰的构造方法，可以直接在外面newInstance，破坏我们辛辛苦苦写的单例模式。

public static void main(String[] args) {
    try {
        LazyMan lazyMan1 = LazyMan.getInstance();
        Constructor<LazyMan> declaredConstructor = LazyMan.class.getDeclaredConstructor(null);
        declaredConstructor.setAccessible(true);
        LazyMan lazyMan2 = declaredConstructor.newInstance();
        System.out.println(lazyMan1.hashCode());
        System.out.println(lazyMan2.hashCode());
        System.out.println(lazyMan1 == lazyMan2);
    } catch (Exception e) {
        e.printStackTrace();
    }
}

 

我们分别打印出lazyMan1，lazyMan2的hashcode，lazyMan1是否相等lazyMan2，结果显而易见，不相等；

那么，怎么解决这种问题呢？

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

public class LazyMan {     private LazyMan() {         synchronized (LazyMan.class) {             if (lazyMan != null) {                 throw new RuntimeException("不要试图用反射破坏单例模式");             }         }     } ​     private volatile static LazyMan lazyMan; ​     public static LazyMan getInstance() {         if (lazyMan == null) {             synchronized (LazyMan.class) {                 if (lazyMan == null) {                     lazyMan = new LazyMan();                 }             }         }         return lazyMan;     } }

　　

在私有的构造函数中做一个判断，如果lazyMan不为空，说明lazyMan已经被创建过了，如果正常调用getInstance方法，是不会出现这种事情的，所以直接抛出异常！

但是这种写法还是有问题：

上面我们是先正常的调用了getInstance方法，创建了LazyMan对象，所以第二次用反射创建对象，私有构造函数里面的判断起作用了，反射破坏单例模式失败。但是如果破坏者干脆不先调用getInstance方法，一上来就直接用反射创建对象，我们的判断就不生效了：