大家好，我是讯享网，很高兴认识大家。

1.1 开闭原则

开闭原则（Open-Closed Principle, OCP）是指一个软件实体如类、模块和函数应该对扩展开放， 对修改关闭。所谓的开闭，也正是对扩展和修改两个行为的一个原则。强调的是用抽象构建框架，用实 现扩展细节。可以提高软件系统的可复用性及可维护性。开闭原则，是面向对象设计中最基础的设计原 则。它指导我们如何建立稳定灵活的系统，例如：我们版本更新，我尽可能不修改源代码，但是可以增 加新功能。 在现实生活中对于开闭原则也有体现。比如，很多互联网公司都实行弹性制作息时间，规定每天工 作 8 小时。意思就是说，对于每天工作 8 小时这个规定是关闭的，但是你什么时候来，什么时候走是开 放的。早来早走，晚来晚走。 实现开闭原则的核心思想就是面向抽象编程，接下来我们来看一段代码：

public interface ICourse { Integer getId(); String getName(); Double getPrice(); }

讯享网

讯享网public class JavaCourse implements ICourse{ private Integer Id; private String name; private Double price; public JavaCourse(Integer id, String name, Double price) { this.Id = id; this.name = name; this.price = price; } public Integer getId() { return this.Id; } public String getName() { return this.name; } public Double getPrice() { return this.price; } }

现在我们要给 Java 架构课程做活动，价格优惠。如果修改 JavaCourse 中的 getPrice()方法，则会 存在一定的风险，可能影响其他地方的调用结果。我们如何在不修改原有代码前提前下，实现价格优惠 这个功能呢？现在，我们再写一个处理优惠逻辑的类，JavaDiscountCourse 类（思考一下为什么要叫 JavaDiscountCourse，而不叫 DiscountCourse）

public class JavaDiscountCourse extends JavaCourse { public JavaDiscountCourse(Integer id, String name, Double price) { super(id, name, price); } public Double getOriginPrice(){ return super.getPrice(); } public Double getPrice(){ return super.getPrice() * 0.61; } }

1.2 依赖倒置原则

依赖倒置原则（Dependence Inversion Principle,DIP）是指设计代码结构时，高层模块不应该依 赖底层模块，二者都应该依赖其抽象。抽象不应该依赖细节；细节应该依赖抽象。通过依赖倒置，可以 减少类与类之间的耦合性，提高系统的稳定性，提高代码的可读性和可维护性，并能够降低修改程序所 造成的风险。接下来看一个案例，还是以课程为例，先来创建一个类 Tom：

讯享网public class Tom { public void studyJavaCourse(){ System.out.println("Tom 在学习 Java 的课程"); } public void studyPythonCourse(){ System.out.println("Tom 在学习 Python 的课程"); } }

来调用一下：

public static void main(String[] args) { Tom tom = new Tom(); tom.studyJavaCourse(); tom.studyPythonCourse(); }

Tom 热爱学习，目前正在学习 Java 课程和 Python 课程。大家都知道，学习也是会上瘾的。随着 学习兴趣的暴涨，现在 Tom 还想学习 AI 人工智能的课程。这个时候，业务扩展，我们的代码要从底层 到高层（调用层）一次修改代码。在 Tom 类中增加 studyAICourse()的方法，在高层也要追加调用。 如此一来，系统发布以后，实际上是非常不稳定的，在修改代码的同时也会带来意想不到的风险。接下 来我们优化代码，创建一个课程的抽象 ICourse 接口：

public interface ICourse { void study(); }

然后写 JavaCourse 类：

public class JavaCourse implements ICourse { @Override public void study() { System.out.println("Tom 在学习 Java 课程"); } }

再实现 PythonCourse 类：

public class PythonCourse implements ICourse { @Override public void study() { System.out.println("Tom 在学习 Python 课程"); } }

修改 Tom 类：

        

public class Tom { public void study(ICourse course){ course.study(); } }

来看调用：

public static void main(String[] args) { Tom tom = new Tom(); tom.study(new JavaCourse()); tom.study(new PythonCourse()); }

我们这时候再看来代码，Tom 的兴趣无论怎么暴涨，对于新的课程，我只需要新建一个类，通过传 参的方式告诉 Tom，而不需要修改底层代码。实际上这是一种大家非常熟悉的方式，叫依赖注入。注入 的方式还有构造器方式和 setter 方式。我们来看构造器注入方式：

public class Tom { private ICourse course; public Tom(ICourse course){ this.course = course; } public void study(){ course.study(); } }

看调用代码：

public static void main(String[] args) { Tom tom = new Tom(new JavaCourse()); tom.study(); }

根据构造器方式注入，在调用时，每次都要创建实例。那么，如果 Tom 是全局单例，则我们就只能 选择用 Setter 方式来注入，继续修改 Tom 类的代码：

public class Tom { private ICourse course; public void setCourse(ICourse course) { this.course = course; } public void study(){ course.study(); } }

看调用代码：

public static void main(String[] args) { Tom tom = new Tom(); tom.setCourse(new JavaCourse()); tom.study(); tom.setCourse(new PythonCourse()); tom.study(); } 

大家要切记：以抽象为基准比以细节为基准搭建起来的架构要稳定得多，因此大家在拿到需求之后， 要面向接口编程，先顶层再细节来设计代码结构。

1.3 单一职责原则

单一职责（Simple Responsibility Pinciple，SRP）是指不要存在多于一个导致类变更的原因。假 设我们有一个 Class 负责两个职责，一旦发生需求变更，修改其中一个职责的逻辑代码，有可能会导致 另一个职责的功能发生故障。这样一来，这个 Class 存在两个导致类变更的原因。如何解决这个问题呢？ 我们就要给两个职责分别用两个 Class 来实现，进行解耦。后期需求变更维护互不影响。这样的设计， 可以降低类的复杂度，提高类的可读性，提高系统的可维护性，降低变更引起的风险。总体来说就是一 个 Class/Interface/Method 只负责一项职责。 接下来，我们来看代码实例，还是用课程举例，我们的课程有直播课和录播课。直播课不能快进和 快退，录播可以可以任意的反复观看，功能职责不一样。还是先创建一个 Course 类：

public class Course { public void study(String courseName){ if("直播课".equals(courseName)){ System.out.println("不能快进"); }else{ System.out.println("可以任意的来回播放"); } } }

看代码调用：

public static void main(String[] args) { Course course = new Course(); course.study("直播课"); course.study("录播课"); } 

从上面代码来看，Course 类承担了两种处理逻辑。假如，现在要对课程进行加密，那么直播课和录 播课的加密逻辑都不一样，必须要修改代码。而修改代码逻辑势必会相互影响容易造成不可控的风险。 我们对职责进行分离解耦，来看代码，分别创建两个类 ReplayCourse 和 LiveCourse： LiveCourse 类：

        

public class LiveCourse { public void study(String courseName){ System.out.println(courseName + "不能快进看"); } }

ReplayCourse 类：

public class ReplayCourse { public void study(String courseName){ System.out.println("可以任意的来回播放"); } }

调用代码：

public static void main(String[] args) { LiveCourse liveCourse = new LiveCourse(); liveCourse.study("直播课"); ReplayCourse replayCourse = new ReplayCourse(); replayCourse.study("录播课"); }

业务继续发展，课程要做权限。没有付费的学员可以获取课程基本信息，已经付费的学员可以获得 视频流，即学习权限。那么对于控制课程层面上至少有两个职责。我们可以把展示职责和管理职责分离 开来，都实现同一个抽象依赖。设计一个顶层接口,创建 ICourse 接口：

public interface ICourse { //获得基本信息 String getCourseName(); //获得视频流 byte[] getCourseVideo(); //学习课程 void studyCourse(); //退款 void refundCourse(); } 

我们可以把这个接口拆成两个接口，创建一个接口 ICourseInfo 和 ICourseManager： ICourseInfo 接口：

public interface ICourseInfo { String getCourseName(); byte[] getCourseVideo(); } 

ICourseManager 接口：

public interface ICourseManager { void studyCourse(); void refundCourse(); }

下面我们来看一下方法层面的单一职责设计。有时候，我们为了偷懒，通常会把一个方法写成下面 这样：

private void modifyUserInfo(String userName,String address){ userName = "Tom"; address = "Changsha"; }

还可能写成这样：

private void modifyUserInfo(String userName,String... fileds){ userName = "Tom"; // address = "Changsha"; } private void modifyUserInfo(String userName,String address,boolean bool){ if(bool){ }else{ } userName = "Tom"; address = "Changsha"; }

显然，上面的 modifyUserInfo()方法中都承担了多个职责，既可以修改 userName,也可以修改 address，甚至更多，明显不符合单一职责。那么我们做如下修改，把这个方法拆成两个：

private void modifyUserName(String userName){ userName = "Tom"; } private void modifyAddress(String address){ address = "Changsha"; }

这修改之后，开发起来简单，维护起来也容易。但是，我们在实际开发中会项目依赖，组合，聚合 这些关系，还有还有项目的规模，周期，技术人员的水平，对进度的把控，很多类都不符合单一职责。 但是，我们在编写代码的过程，尽可能地让接口和方法保持单一职责，对我们项目后期的维护是有很大 帮助的。

1.4 接口隔离原则

接口隔离原则（Interface Segregation Principle, ISP）是指用多个专门的接口，而不使用单一的 总接口，客户端不应该依赖它不需要的接口。这个原则指导我们在设计接口时应当注意一下几点： 1、一个类对一类的依赖应该建立在最小的接口之上。 2、建立单一接口，不要建立庞大臃肿的接口。 3、尽量细化接口，接口中的方法尽量少（不是越少越好，一定要适度）。 接口隔离原则符合我们常说的高内聚低耦合的设计思想，从而使得类具有很好的可读性、可扩展性 和可维护性。我们在设计接口的时候，要多花时间去思考，要考虑业务模型，包括以后有可能发生变更 的地方还要做一些预判。所以，对于抽象，对业务模型的理解是非常重要的。下面我们来看一段代码， 写一个动物行为的抽象： IAnimal 接口：

public interface IAnimal { void eat(); void fly(); void swim(); }

Bird 类实现：

public class Bird implements IAnimal { @Override public void eat() {} @Override public void fly() {} @Override public void swim() {} }

Dog 类实现：

public class Dog implements IAnimal { @Override public void eat() {} @Override public void fly() {} @Override public void swim() {} } 

可以看出，Bird 的 swim()方法可能只能空着，Dog 的 fly()方法显然不可能的。这时候，我们针对 不同动物行为来设计不同的接口，分别设计 IEatAnimal，IFlyAnimal 和 ISwimAnimal 接口，来看代码： IEatAnimal 接口：

public interface IEatAnimal { void eat(); }

IFlyAnimal 接口：

public interface IFlyAnimal { void fly(); }

ISwimAnimal 接口：

 

public interface ISwimAnimal { void swim(); }

Dog 只实现 IEatAnimal 和 ISwimAnimal 接口：

public class Dog implements ISwimAnimal,IEatAnimal { @Override public void eat() {} @Override public void swim() {} } 

1.5 迪米特法则

迪米特原则（Law of Demeter LoD）是指一个对象应该对其他对象保持最少的了解，又叫最少知 道原则（Least Knowledge Principle,LKP），尽量降低类与类之间的耦合。迪米特原则主要强调只和

朋友交流，不和陌生人说话。出现在成员变量、方法的输入、输出参数中的类都可以称之为成员朋友类， 而出现在方法体内部的类不属于朋友类。 现在来设计一个权限系统，TeamLeader需要查看目前发布到线上的课程数量。这时候，TeamLeader 要找到员工 Employee 去进行统计，Employee 再把统计结果告诉 TeamLeader。接下来我们还是来看 代码： Course 类：

public class Course { }

Employee 类：

public class Employee{ public void checkNumberOfCourses(List courseList){ System.out.println("目前已发布的课程数量是：" + courseList.size()); } }

TeamLeader 类：

public class TeamLeader{ public void commandCheckNumber(Employee employee){ List courseList = new ArrayList(); for (int i= 0; i < 20 ;i ++){ courseList.add(new Course()); } employee.checkNumberOfCourses(courseList); } }

测试代码：

public static void main(String[] args) { TeamLeader teamLeader = new TeamLeader(); Employee employee = new Employee(); teamLeader.commandCheckNumber(employee); }

写到这里，其实功能已经都已经实现，代码看上去也没什么问题。根据迪米特原则，TeamLeader 只想要结果，不需要跟 Course 产生直接的交流。而 Employee 统计需要引用 Course 对象。TeamLeader 和 Course 并不是朋友，从下面的类图就可以看出来：

下面来对代码进行改造： Employee 类：

public class Employee { public void checkNumberOfCourses(){ List courseList = new ArrayList(); for (int i= 0; i < 20 ;i ++){ courseList.add(new Course()); } System.out.println("目前已发布的课程数量是："+courseList.size()); } }

TeamLeader 类：

public class TeamLeader { public void commandCheckNumber(Employee employee){ employee.checkNumberOfCourses(); } }

再来看下面的类图，Course 和 TeamLeader 已经没有关联了。 学习软件设计原则，千万不能形成强迫症。碰到业务复杂的场景，我们需要随机应变。

1.6 里氏替换原则

里氏替换原则（Liskov Substitution Principle,LSP）是指如果对每一个类型为 T1 的对象 o1,都有 类型为 T2 的对象 o2,使得以 T1 定义的所有程序 P 在所有的对象 o1 都替换成 o2 时，程序 P 的行为没 有发生变化，那么类型 T2 是类型 T1 的子类型。 定义看上去还是比较抽象，我们重新理解一下，可以理解为一个软件实体如果适用一个父类的话， 那一定是适用于其子类，所有引用父类的地方必须能透明地使用其子类的对象，子类对象能够替换父类 对象，而程序逻辑不变。根据这个理解，我们总结一下： 引申含义：子类可以扩展父类的功能，但不能改变父类原有的功能。 1、子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。 2、子类中可以增加自己特有的方法。 3、当子类的方法重载父类的方法时，方法的前置条件（即方法的输入/入参）要比父类方法的输入 参数更宽松。 4、当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的输 出/返回值）要比父类更严格或相等。 在前面讲开闭原则的时候埋下了一个伏笔，我们记得在获取折后时重写覆盖了父类的 getPrice()方 法，增加了一个获取源码的方法 getOriginPrice()，显然就违背了里氏替换原则。我们修改一下代码， 不应该覆盖 getPrice()方法，增加 getDiscountPrice()方法：

public class JavaDiscountCourse extends JavaCourse { public JavaDiscountCourse(Integer id, String name, Double price) { super(id, name, price); } public Double getDiscountPrice(){ return super.getPrice() * 0.61; } }

使用里氏替换原则有以下优点：

1、约束继承泛滥，开闭原则的一种体现。 2、加强程序的健壮性，同时变更时也可以做到非常好的兼容性，提高程序的维护性、扩展性。降低 需求变更时引入的风险。 现在来描述一个经典的业务场景，用正方形、矩形和四边形的关系说明里氏替换原则，我们都知道 正方形是一个特殊的长方形，那么就可以创建一个长方形父类 Rectangle 类：

public class Rectangle { private long height; private long width; public long getHeight() { return height; } public void setHeight(long height) { this.height = height; } public long getWidth() { return width; } public void setWidth(long width) { this.width = width; } }

创建正方形 Square 类继承长方形：

public class Square extends Rectangle { private long length; public long getLength() { return length; } public void setLength(long length) { this.length = length; } @Override public long getHeight() { return getLength(); } @Override public void setHeight(long height) { setLength(height); } @Override public long getWidth() { return getLength(); } @Override public void setWidth(long width) { setLength(width); } }

在测试类中创建 resize()方法，根据逻辑长方形的宽应该大于等于高，我们让高一直自增，知道高 等于宽变成正方形：

public static void resize(Rectangle rectangle){ while (rectangle.getWidth() >= rectangle.getHeight()){ rectangle.setHeight(rectangle.getHeight() + 1); System.out.println("Width:" +rectangle.getWidth() +",Height:" + rectangle.getHeight()); } System.out.println("Resize End,Width:" +rectangle.getWidth() +",Height:" + rectangle.getHeight()); }

测试代码：

public static void main(String[] args) { Rectangle rectangle = new Rectangle(); rectangle.setWidth(20); rectangle.setHeight(10); resize(rectangle); }

运行结果： 发现高比宽还大了，在长方形中是一种非常正常的情况。现在我们再来看下面的代码，把长方形 Rectangle 替换成它的子类正方形 Square，修改测试代码：

public static void main(String[] args) { Square square = new Square(); square.setLength(10); resize(square); }

这时候我们运行的时候就出现了死循环，违背了里氏替换原则，将父类替换为子类后，程序运行结 果没有达到预期。因此，我们的代码设计是存在一定风险的。里氏替换原则只存在父类与子类之间，约束继承泛滥。我们再来创建一个基于长方形与正方形共同的抽象四边形 Quadrangle 接口：

public interface QuadRangle { long getWidth(); long getHeight(); }

修改长方形 Rectangle 类：

public class Rectangle implements QuadRangle { private long height; private long width; public long getHeight() { return height; } public void setHeight(long height) { this.height = height; } public long getWidth() { return width; } public void setWidth(long width) { this.width = width; } }

修改正方形类 Square 类：

public class Square implements QuadRangle { private long length; public long getLength() { return length; } public void setLength(long length) { this.length = length; } public long getWidth() { return length; } public long getHeight() { return length; } }

此时，如果我们把 resize()方法的参数换成四边形 Quadrangle 类，方法内部就会报错。因为正方 形 Square 已经没有了 setWidth()和 setHeight()方法了。因此，为了约束继承泛滥，resize()的方法参 数只能用 Rectangle 长方形。当然，我们在后面的设计模式课程中还会继续深入讲解。

1.7 合成复用原则

合成复用原则（Composite/Aggregate Reuse Principle,CARP）是指尽量使用对象组合(has-a)/ 聚合(contanis-a)，而不是继承关系达到软件复用的目的。可以使系统更加灵活，降低类与类之间的耦 合度，一个类的变化对其他类造成的影响相对较少。 继承我们叫做白箱复用，相当于把所有的实现细节暴露给子类。组合/聚合也称之为黑箱复用，对类 以外的对象是无法获取到实现细节的。要根据具体的业务场景来做代码设计，其实也都需要遵循 OOP 模型。还是以数据库操作为例，先来创建 DBConnection 类：

public class DBConnection { public String getConnection(){ return "MySQL 数据库连接"; } }

创建 ProductDao 类：

public class ProductDao{ private DBConnection dbConnection; public void setDbConnection(DBConnection dbConnection) { this.dbConnection = dbConnection; } public void addProduct(){ String conn = dbConnection.getConnection(); System.out.println("使用"+conn+"增加产品"); } }

这就是一种非常典型的合成复用原则应用场景。但是，目前的设计来说，DBConnection 还不是一 种抽象，不便于系统扩展。目前的系统支持 MySQL 数据库连接，假设业务发生变化，数据库操作层要 支持 Oracle 数据库。当然，我们可以在 DBConnection 中增加对 Oracle 数据库支持的方法。但是违 背了开闭原则。其实，我们可以不必修改 Dao 的代码，将 DBConnection 修改为 abstract，来看代码：

public abstract class DBConnection { public abstract String getConnection(); }

然后，将 MySQL 的逻辑抽离

public class MySQLConnection extends DBConnection { @Override public String getConnection() { return "MySQL 数据库连接"; } }

再创建 Oracle 支持的逻辑：

public class OracleConnection extends DBConnection { @Override public String getConnection() { return "Oracle 数据库连接"; } } 

2. 设计原则总结

学习设计原则，学习设计模式的基础。在实际开发过程中，并不是一定要求所有代码都遵循设计原 则，我们要考虑人力、时间、成本、质量，不是刻意追求完美，要在适当的场景遵循设计原则，体现的 是一种平衡取舍，帮助我们设计出更加优雅的代码结构。

1、开闭原则，对扩展开放， 对修改关闭。

2、单一职责原则，一个类，一个接口，一个方法只做一件事，保证功能的单一性和纯洁性

3、依赖倒置原则，通过抽象接口或类，是各个类和模块相互不影响，实现松耦合。

4、接口隔离原则、尽量保证接口纯洁性，客户端不应该依赖不需要的接口。

5、迪米特法则，又叫最小知道法则。

6、里氏替换原则，子类可以拓展父类的功能，但是不能改变父类原有的功能

7、合成复用原则，尽量的使用对象的组合聚合而不是用继承关系达到代码复用的目的

3. 单例模式

单例模式 ( Singleton Pattern )是指确保一个类在任何情况下都绝对只有一个实例，并提供一个全局访问点。单例模式是创建型模式。单例模式在现实生活中应用也非常广泛，例如，公司CEO、部门经理等。J2EE标准中的ServletContext 、ServletContextConfig 等、Spring框架应用中的ApplicationContext、数据库的连接池等也都是单例形式。

3.1 饿汉式单例模式

饿汉式单例模式在类加载的时候就立即初始化，并且创建单例对象。它绝对线程安全，在线程还没 出现以前就实例化了，不可能存在访问安全问题。 接下来看饿汉式单例的标准代码∶

/ * 优点：执行效率高，性能高，没有任何的锁 * 缺点：某些情况下，可能会造成内存浪费 */ public class HungrySingleton { private static final HungrySingleton hungrySingleton = new HungrySingleton(); private HungrySingleton(){} public static HungrySingleton getInstance(){ return hungrySingleton; } }

静态代码块方式：

public class HungryStaticSingleton { //先静态后动态 //先上，后下 //先属性后方法 private static final HungryStaticSingleton hungrySingleton; //装个B static { hungrySingleton = new HungryStaticSingleton(); } private HungryStaticSingleton(){} public static HungryStaticSingleton getInstance(){ return hungrySingleton; } }

这两种写法都非常简单，也非常好理解，饿汉式单例模式适用于单例对象较少的情况。这样写可以 保证绝对线程安全、执行效率比较高。但是它的缺点也很明显，就是所有对象类加载的时候就实例化。 这样一来，如果系统中有大批量的单例对象存在，那系统初始化是就会导致大量的内存浪费。也就是说， 不管对象用与不用都占着空间，浪费了内存，有可能“占着茅坑不拉屎”。那有没有更优的写法呢﹖下 面我们来继续分析。

3.2 懒汉式单例模式

为了解决饿汉式单例可能带来的内存浪费问题，于是就出现了懒汉式单例的写法，懒汉式单例模式的特点是，单例对象要在被使用时才会初始化，下面看懒汉式单例模式的简单实现 LazySimpleSingleton :

/ * 优点：节省了内存,线程安全 * 缺点：性能低 */ public class LazySimpleSingletion { private static LazySimpleSingletion instance; private LazySimpleSingletion(){} public static LazySimpleSingletion getInstance(){ if(instance == null){ instance = new LazySimpleSingletion(); } return instance; } }

但这样写又带来了一个新的问题，如果在多线程环境下,就会出现线程安全问题。我先来模拟一下， 编写线程类ExectorThread :

public class ExectorThread implements Runnable{ @override public void run() { LazySimplesingleton singleton = Lazysimplesingleton.getInstance(); system.out.println(Thread.currentThread ().getName() + ":" + singleton); } }

客户端测试代码如下：

public class Lazysimplesing letonTest { public static void main(string[]args) { Thread t1 = new Thread (new ExectorThread ());Thread t2 = new Thread(new ExectorThread());t1.start(); t2.start(); system.out.print1n ("End""); } }

果然，上面的代码有一定概率出现两种不同结果，这意味着上面的单例存在线程安全隐患。

使用synchronized关键字解决线程安全问题：

public synchronized static LazySimpleSingletion getInstance(){ if(instance == null){ instance = new LazySimpleSingletion(); } return instance; }

上面的代码完美地展现了synchronized监视锁的运行状态，线程安全的问题解决了。但是，用synchronized加锁时，,在线程数量比较多的情况下，如果CPU分配压力上升,则会导致大批线程阻塞，从而导致程序性能大幅下降。那么，有没有一种更好的方式，既能兼顾线程安全又能提升程序性能呢? 答案是肯定的。我们来看双重检查锁的单例模式︰

/ * 优点:性能高了，线程安全了 * 缺点：可读性难度加大，不够优雅 */ public class LazyDoubleCheckSingleton { private volatile static LazyDoubleCheckSingleton instance; private LazyDoubleCheckSingleton(){} public static LazyDoubleCheckSingleton getInstance(){ //检查是否要阻塞 if (instance == null) { synchronized (LazyDoubleCheckSingleton.class) { //检查是否要重新创建实例 if (instance == null) { instance = new LazyDoubleCheckSingleton(); //指令重排序的问题 } } } return instance; } }

当第一个线程调用getInstance()方法时，第二个线程也可以调用。当第一个线程执行到synchronized时会上锁，第二个线程就会变成MONITOR状态，出现阻塞。此时，阻塞并不是基于整个LazySimpleSingleton类的阻塞，而是在getInstance()方法内部的阻塞，只要逻辑不太复杂，对于调用者而言感知不到。但是，用到 synchronized关键字总归要上锁，对程序性能还是存在一定影响的。难道就真的没有更好的方案吗？当然有。我们可以从类初始化的角度来考虑，看下面的代码，采用静态内部类的方式∶

/* ClassPath : LazyStaticInnerClassSingleton.class LazyStaticInnerClassSingleton$LazyHolder.class 优点：写法优雅，利用了Java本身语法特点，性能高，避免了内存浪费,不能被反射破坏 缺点：不优雅 */ public class LazyStaticInnerClassSingleton { private LazyStaticInnerClassSingleton(){ } public static LazyStaticInnerClassSingleton getInstance(){ return LazyHolder.INSTANCE; } private static class LazyHolder{ private static final LazyStaticInnerClassSingleton INSTANCE = new LazyStaticInnerClassSingleton(); } }

这种方式兼顾了饿汉式单例模式的内存浪费问题和synchronized的性能问题。内部类一定是要在 方法调用之前初始化，巧妙地避免了线程安全问题。由于这种方式比较简单，我们就不带大家一步一步 调试了。但是，金无足赤，人无完人，单例模式亦如此。这种写法真的就完美了吗?

3.3 反射破坏单例

现在我们来看一个事故现场。大家有没有发现，上面介绍的单例模式的构造方法除了加上private 关键字，没有做任何处理。如果我们使用反射来调用其构造方法，再调用getlnstance()方法，应该有 两个不同的实例。现在来看一段测试代码，以LazyInnerClasssingleton为例:

public class LazyInnerClassSingletonTest { public static void main(String[]args) { try{ //在很无聊的情况下，进行破坏 Class<?> clazz = LazyStaticInnerClassSingleton.class; //通过反射获取私有的构造方法 Constructor c = clazz.getDeclaredConstructor(null); //强制访问 c.setAccessible(true); //暴力初始化 Object o1 = c.newInstance(); //调用了两次构造方法，相当子“new”了两次，犯了原则性错误 Object o2 = c.newInstance(); System.out.println(o1 == o2); }catch (Exception e){ e.printStackTrace(); } } }

显然，创建了两个不同的实例。那怎么办呢﹖我们来做一次优化。现在，我们在其构造方法中做一 些限制，一旦出现多次重复创建，则直接抛出异常。来看优化后的代码︰

private LazyStaticInnerClassSingleton(){ if(LazyHolder.INSTANCE != null){ throw new RuntimeException("不允许非法访问"); } }

至此，自认为史上最牛的单例模式的实现方式便大功告成。但是，上面看似完美的单例写法还是有 可能被破坏。

3.4 序列化破坏单例

一个单例对象创建好后，有时候需要将对象序列化然后写入磁盘，下次使用时再从磁盘中读取对象 并进行反序列化,将其转化为内存对象。反序列化后的对象会重新分配内存，即重新创建。如果序列化 的目标对象为单例对象，就违背了单例模式的初衷，相当于破坏了单例，来看一段代码︰

public class SeriableSingleton implements Serializable { //序列化 //把内存中对象的状态转换为字节码的形式 //把字节码通过IO输出流，写到磁盘上 //永久保存下来，持久化 //反序列化 //将持久化的字节码内容，通过IO输入流读到内存中来 //转化成一个Java对象 public final static SeriableSingleton INSTANCE = new SeriableSingleton(); private SeriableSingleton(){} public static SeriableSingleton getInstance(){ return INSTANCE; } }

编写测试代码：

import java.io.FileInputStream; import java.io.FileOutputStream; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; public class SeriableSingletonTest { public static void main(String[]args) { SeriableSingleton s1 = null ; SeriableSingleton s2 = SeriableSingleton.getInstance(); FileOutputStream fos = null; try { fos = new FileOutputStream("SeriableSingleton.obj"); ObjectOutputStream oos = new ObjectOutputStream(fos); oos.writeObject(s2); oos.flush(); oos.close( ); FileInputStream fis = new FileInputStream("SeriableSingleton.obj"); ObjectInputStream ois = new ObjectInputStream( fis); s1 = (SeriableSingleton)ois.readObject(); ois.close(); System.out.println(s1); System.out.println(s2); System.out.println(s1 == s2); }catch (Exception e){ e.printStackTrace(); } } }

从运行结果可以看出，反序列化后的对象和手动创建的对象是不一致的，实例化了两次，违背了单 例模式的设计初衷。那么，我们如何保证在序列化的情况下也能够实现单例模式呢﹖其实很简单，只需要增加readResolve()方法即可。来看优化后的代码︰

public class SeriableSingleton implements Serializable { //序列化 //把内存中对象的状态转换为字节码的形式 //把字节码通过IO输出流，写到磁盘上 //永久保存下来，持久化 //反序列化 //将持久化的字节码内容，通过IO输入流读到内存中来 //转化成一个Java对象 public final static SeriableSingleton INSTANCE = new SeriableSingleton(); private SeriableSingleton(){} public static SeriableSingleton getInstance(){ return INSTANCE; } private Object readResolve(){ return INSTANCE;} }

3.4 注册式单例模式

注册式单例模式又称为登记式单例模式，就是将每一个实例都登记到某一个地方，使用唯一的标识 获取实例。注册式单例模式有两种:一种为枚举式单例模式，另一种为容器式单例模式。

3.4.1 枚举式单例模式

先来看枚举式单例模式的写法，来看代码，创建EnumSingleton类:

public enum EnumSingleton { INSTANCE; private Object data; public Object getData() { return data; } public void setData(Object data) { this.data = data; } public static EnumSingleton getInstance(){return INSTANCE;} }

看测试代码：

public class EnumSingletonTest { public static void main(String[] args) { // EnumSingleton instance = EnumSingleton.getInstance(); // instance.setData(new Object()); try { Class clazz = EnumSingleton.class; Constructor c = clazz.getDeclaredConstructor(String.class,int.class); c.setAccessible(true); // System.out.println(c); Object o = c.newInstance(); // System.out.println(o); }catch (Exception e){ e.printStackTrace(); } } }

3.4.2 容器式单例模式

其实枚举式单例，虽然写法优雅，但是也会有一些问题。因为它在类加载之时就将所有的对象初始化放在类内存中，这其实和饿汉式并无差异，不适合大量创建单例对象的场景。那么，接下来看注册式 单例模式的另一种写法，即容器式单例模式，创建ContainerSingleton类:

public class ContainerSingleton { private ContainerSingleton(){} private static Map<String,Object> ioc = new ConcurrentHashMap<String, Object>(); public static Object getInstance(String className){ Object instance = null; if(!ioc.containsKey(className)){ try { instance = Class.forName(className).newInstance(); ioc.put(className, instance); }catch (Exception e){ e.printStackTrace(); } return instance; }else{ return ioc.get(className); } } }

容器式单例模式适用于需要大量创建单例对象的场景，便于管理。但它是非线程安全的。到此，注册式单例模式介绍完毕。我们再来看看Spring中的容器式单例模式的实现代码︰

查看spring中的AbstractAutowireCapableBeanFactory类源码查看spring的factoryBeanInstanceCache

3.5 线程单例实现ThreadLocal

讲讲线程单例实现ThreadLocal。ThreadLocal不能保证其创建的对象是全局唯一的，但是能保证在单个线程中是唯一的，天生是线程安全的。下面来看代码∶

public class ThreadLocalSingleton { private static final ThreadLocal<ThreadLocalSingleton> threadLocaLInstance = new ThreadLocal<ThreadLocalSingleton>(){ @Override protected ThreadLocalSingleton initialValue() { return new ThreadLocalSingleton(); } }; private ThreadLocalSingleton(){} public static ThreadLocalSingleton getInstance(){ return threadLocaLInstance.get(); } }

测试代码如下：

public class ExectorThread implements Runnable{ public void run() { // LazySimpleSingletion instance = LazySimpleSingletion.getInstance(); // LazyDoubleCheckSingleton instance = LazyDoubleCheckSingleton.getInstance(); ThreadLocalSingleton instance = ThreadLocalSingleton.getInstance(); System.out.println(ThreadLocalSingleton.getInstance()); System.out.println(Thread.currentThread().getName() + ":" + instance); } } public class ThreadLocalSingletonTest { public static void main(String[] args) { System.out.println(ThreadLocalSingleton.getInstance()); System.out.println(ThreadLocalSingleton.getInstance()); System.out.println(ThreadLocalSingleton.getInstance()); Thread t1 = new Thread(new ExectorThread()); Thread t2 = new Thread(new ExectorThread()); t1.start(); t2.start(); System.out.println("End"); } }

我们发现，在主线程中无论调用多少次，获取到的实例都是同一个，都在两个子线程中分别获取到 了不同的实例。那么ThreadLocal是如何实现这样的效果的呢?我们知道,单例模式为了达到线程安全 的目的，会给方法上锁，以时间换空间。ThreadLocal将所有的对象全部放在ThreadLocalMap中， 为每个线程都提供一个对象，实际上是以空间换时间来实现线程隔离的。

单例模式总结

单例模式在jdk中的应用，查看Runtime源码

总结：

单例模式可以保证内存里只有一个实例，减少了内存的开销，还可以避免对资源的多重占用。

了解单列模式简单的话术

从简单的单例来说，有饿汉模式，懒汉模式，

饿汉模式：有什么缺点？ 在初始化的时候就创建了对象，占用内存空间，如何解决？ 使用懒汉模式

懒汉模式：有什么缺点？因为懒汉模式有判断对象是否为空导致并发情况下重复创建，导致单例模式失效，如何解决？ 暴力解决，直接在同意对外访问方法中加锁（synchronized），但是，这种方式时所有访问线程都阻塞在方法外，所有多系统资源有影响，如何解决？ 加对象锁， 使用双重检查所方式实现单例，在判空代码块内加锁，在锁再次判空，为空则创建对象。 终归还是使用了锁，对系统资源有影响，所有尽量不用锁。那如何解决？

静态内部类单例解决锁。因为静态内部类实在方法调用时才初始化内部类。

但是还可以通过反射和序列化方式破坏单例，反射通过暴力激活成功教程，强行调用私有构造器破坏单例，如何解决反射破坏？ 在私有构造器里面判断实例对象是否已存在，如果已存在则抛出异常。

序列化破坏：前提，单例类实现了Serializable接口，通过序列化反序列化方式就可以破坏，如何解决？在类中加上代码如下：

 // 防止序列化反序列化方式破坏单例 private Object readResolve(){ return StaticInnerClassSingleton.lazyStaticInnerClassSingleton; }

除了上面的单例还有注册时单例： 注册式单例有两种，枚举式单例，容器式单例（spring的ioc容器就是容器式单例）

还有线程单例