标题# 设计模式的重要性
-
软件工程中,设计模式(design pattern)是对软件设计中普遍存在(反复出现)的各种问题,所提出的解决方案。这个术语是由埃里希.伽玛等人在1990年代从建筑设计领域引入到计算机科学的
-
大厦VS简易房
-
拿实际工作经历来说,当一个项目开发完成后,如果客户提出增新功能,怎么办?(可扩展性,使用设计模式,软件具有很好的可扩展性)
-
如果项目开发完后,原来程序员离职,你接手维护该项目怎么办?(维护性【可读性、规范性】)
-
目前程序员门槛越来越高,一线IT公司,都会问你在实际项目中使用过什么设计模式,怎样使用的,解决了什么问题。
-
设计模式在软件哪里?
-
- 面向对象(oo)—>功能模块【设计模式+算法和数据结构】–>框架【使用多种设计模式】–>架构【服务器集群】
设计模式的目的
编写软件过程中,程序员面临着来自 耦合度、内聚性以及可维护性、可扩展性、重用性、灵活性等多方面的挑战,设计模式是为了让程序(软件),具有更好的
- 代码重用性(相同功能的代码,不用多次编写)
- 可读性(代码规范性,便于其他程序员的阅读和理解)
- 可扩展性(当需要增加新的功能时,非常的方便,称为可维护性)
- 可靠性(当我们增加新的功能时,对原来的功能没有影响)
- ‘使程序呈现高内聚,低耦合的特性
-
分析金句:
-
- 设计模式包含了面向对象的精髓,“懂了设计模式,你就懂了面向对象分析和设计(OOA/D)的精要”。
设计模式七大原则
- 设计模式原则,其实就是程序员在编程时,应当遵守的原则,也是各种设计模式的基础(即:设计模式为什么这样设计的依据)
- 设计模式常用的七大原则有:
单一职责原则:
对类来说的,即一个类应该只负责一项职责,如类A负责两个不同职责:职责1,职责2。
当职责1需求变更而改变A时,可能造成职责2执行错误,所以需要将类A的粒度分解为A1,A2。
单一职责原则注意事项和细节
1)降低类的复杂性,一个类只负责一项职责
2)提高类的可读性,可维护性
3)降低变更引起的风险
4)通常情况下,我们应当遵守单一职责原则,只有逻辑足够简单,才可以在代码级违反单一职责原则;只有类中方法数量足够少,可以在方法级别保持单一职责原则
package Singleresponsibility;
/*
*@Author:DH
*@Date:2021/12/16 23:23
*@Description:TODO
** @param null
*@return:
*/
public class SingleResponsibility1 {
public static void main(String[] args) {
vehicle vehicle = new vehicle();
vehicle.run("汽车");
vehicle.run("飞机");
vehicle.run("轮船");
}
}
//交通工具类
//方式一
//1、在方式1中的run方法中,违反了单一职责原则
//2、解决方案非常的简单,根据交通工具运行的方式不同,分解成不同的类即可
class vehicle {
public void run(String vehicle){
System.out.println(vehicle+"在公路运行");
}
}
-----------------------------------------------------------------------------
package Singleresponsibility;
public class SingleResponsibility2 {
public static void main(String[] args) {
EarthVehicle earthVehicle = new EarthVehicle();
FlyVehicle flyVehicle = new FlyVehicle();
WhiterVehicle whiterVehicle = new WhiterVehicle();
earthVehicle.run("汽车");
flyVehicle.run("飞机");
whiterVehicle.run("轮船");
}
}
/*
* 交通类
* 方式二的分析
* 1、遵守单一职责原则
* 2、但是这样做的改动很大,即将类分解,同时修改客户端
* 3、改进:直接修改Vehicle类,改动的代码会比较小。
* */
class EarthVehicle{
public void run(String EarthVehicle){
System.out.println(EarthVehicle +"在公路上运行");
}
}
class FlyVehicle{
public void run(String FlyVehicle){
System.out.println(FlyVehicle +"在天空中运行");
}
}
class WhiterVehicle{
public void run(String WhiterVehicle){
System.out.println(WhiterVehicle + "在水中运行");
}
}
-----------------------------------------------------------------------------
package Singleresponsibility;
public class SingleResponsibility3 {
public static void main(String[] args) {
Vehicle vehicle = new Vehicle();
vehicle.runEarth("汽车");
vehicle.runFly("飞机");
vehicle.runWhiter("轮船");
}
}
/*
* 方案三分析
* 1、这种修改方法没有对原来的类做大的修改,只是增加方法
* 2、这里虽然没有在类的这个级别上遵守单一职责原则,但是在方法级别上,仍然是遵守单一职责原则
* */
class Vehicle{
public void runEarth(String EarthVehicle){
System.out.println(EarthVehicle+"在公路上运行");
}
public void runFly(String FlyVehicle){
System.out.println(FlyVehicle+"在天空上运行");
}
public void runWhiter(String WhiterVehicle){
System.out.println(WhiterVehicle+"在海中运行");
}
}
接口隔离原则(Interface Segregation Principle)
1)客户端不应该依赖它不需要的接口,即一个类对另一个类的依赖应该建立在最小的接口上
2)先看一张图[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jcAufKXc-1653389595594)(C:\Users\强上女闺蜜\Pictures\Camera Roll\设计模式\屏幕截图 2021-12-17 003514.png)]
3)类A通过接口Interface1依赖类B,类C通过接口Interface1依赖类D,如果接口Interface1对于类A和类C来说不是最小接口,那么类B和类D必须去实现它们不需要的方法
4)按隔离原则应当这样处理:
将接口Interface拆分为独立的几个接口(案例里我们拆分为3个接口),类A和类C分别于它们需要的接口建立依赖关系,也就是采用接口隔离原则
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kRgFJ1tM-1653389595595)(C:\Users\强上女闺蜜\Pictures\Camera Roll\设计模式\屏幕截图 2021-12-17 003114.png)]
传统方法的问题和使用接口隔离原则改进
1)类A通过接口Interface1依赖类B,类C通过接口Interface1依赖类D,如果接口Interface1对于类A和类C来说不是最小接口,那么类B和类D必须去实现它们不需要的方法
2)将接口Interface拆分为独立的几个接口,类A和类C分别于它们需要的接口建立依赖关系,也就是采用接口隔离原则
3)接口Interface中出现的方法,根据实际情况拆分为三个接口
4)应用案例
package Segregation;
public class Segregation1 {
public static void main(String[] args) {
A a = new A();
a.depend1(new B());//A类通过接口去依赖(使用)B类
C c = new C();
c.depend1(new D());
}
}
interface interface1 {
void operation1();
void operation2();
void operation3();
void operation4();
void operation5();
}
class B implements interface1 {
@Override
public void operation1() {
System.out.println("B实现了operation1方法");
}
@Override
public void operation2() {
System.out.println("B实现了operation2方法");
}
@Override
public void operation3() {
System.out.println("B实现了operation3方法");
}
@Override
public void operation4() {
System.out.println("B实现了operation4方法");
}
@Override
public void operation5() {
System.out.println("B实现了operation5方法");
}
}
class D implements interface1 {
@Override
public void operation1() {
System.out.println("D实现了operation1方法");
}
@Override
public void operation2() {
System.out.println("D实现了operation2方法");
}
@Override
public void operation3() {
System.out.println("D实现了operation3方法");
}
@Override
public void operation4() {
System.out.println("D实现了operation4方法");
}
@Override
public void operation5() {
System.out.println("D实现了operation5方法");
}
}
class A {//A类通过接口依赖(使用)B类,但是只会用到1,2,3 方法
public void depend1(interface1 i) {
i.operation1();
}
public void depend2(interface1 i) {
i.operation2();
}
public void depend3(interface1 i) {
i.operation3();
}
}
class C {//A类通过接口依赖(使用)B类,但是只会用到1,4,5 方法
public void depend1(interface1 i) {
i.operation1();
}
public void depend4(interface1 i) {
i.operation4();
}
public void depend5(interface1 i) {
i.operation5();
}
}
-----------------------------------------------------------------------------
采用接口隔离原则后的代码
package Segregation.improve;
public class Segregation1 {
public static void main(String[] args) {
A a = new A();
a.depend1(new B());//A类通过接口去依赖(使用)B类
a.depend2(new B());
a.depend3(new B());
C c = new C();
c.depend1(new D());
c.depend4(new D());
c.depend5(new D());
}
}
interface interface1 {
void operation1();
}
interface interface2 {
void operation2();
void operation3();
}
interface interface3 {
void operation4();
void operation5();
}
class B implements interface1, interface2 {
@Override
public void operation1() {
System.out.println("B实现了operation1方法");
}
@Override
public void operation2() {
System.out.println("B实现了operation2方法");
}
@Override
public void operation3() {
System.out.println("B实现了operation3方法");
}
}
class D implements interface1, interface3 {
@Override
public void operation1() {
System.out.println("D实现了operation1方法");
}
@Override
public void operation4() {
System.out.println("D实现了operation4方法");
}
@Override
public void operation5() {
System.out.println("D实现了operation5方法");
}
}
class A {
public void depend1(interface1 i) {
i.operation1();
}
public void depend2(interface2 i) {
i.operation2();
}
public void depend3(interface2 i) {
i.operation3();
}
}
class C {
public void depend1(interface1 i) {
i.operation1();
}
public void depend4(interface3 i) {
i.operation4();
}
public void depend5(interface3 i) {
i.operation5();
}
}
依赖倒转(倒置)原则
- 高层模块不应该依赖低层模块,二者都应该依赖其抽象
- 抽象不应该依赖细节,细节应该依赖抽象
- 依赖倒置的中心思想就是面向接口编程
- 依赖倒置原则就是基于这样的设计理念:相对与细节的多变性,抽象的东西要稳定得多,以抽象为基础搭建的架构比以前用细节为基础的架构要稳定的多,在Java中,抽象指的是接口或者抽象类,细节就是具体的实现类
- 使用接口或抽象类的目的是制定好规范,而不涉及任何具体的操作,把展现细节的任务交给他们的实现类去完成
package dependencyinversion;
/**
* Created with IntelliJ IDEA.
*
* @Date: 2022/05/16/18:45
* @Description:
*/
public class DependencyInversion {
public static void main(String[] args) {
Person person = new Person();
person.receive(new Email());
}
}
class Email{
public String getInfo(){
return "email:Hello World";
}
}
/**
* @Description: 完成Person接受信息的功能
* 方式一分析:
* 1、简单,比较容易想到
* 2、如果我们获取的对象是微信,短信等等,则新增类,同时Person也要增加相应的接受方法
* 3、解决思路:引入一个抽象的接口IReceiver,表示接收者,这样的person类与接口IReceiver发生依赖
* 因为Email,微信等等属于接受的范围,他们各自实现IReceiver,接口就ok这样我们就符合依赖倒置原则
* @Param:
* @return:
* @Date: 2022/5/16
*/
class Person{
public void receive(Email email){
System.out.println(email.getInfo());
}
}
package dependencyinversion;
/**
* Created with IntelliJ IDEA.
*
* @Date: 2022/05/16/19:03
* @Description:
*/
public class DependencyInversion1 {
public static void main(String[] args) {
Person1 person1 = new Person1();
person1.receive(new Email1());
person1.receive(new WeiXin());
}
}
interface IReceive{
String getInfo();
}
class Email1 implements IReceive{
public String getInfo(){
return "email:Hello World";
}
}
class WeiXin implements IReceive{
@Override
public String getInfo() {
return "微信信息:Hello World";
}
}
/**
* @Description: 完成Person接受信息的功能
* 方式二:依赖倒置
* @Param:
* @return:
* @Date: 2022/5/16
*/
class Person1{
public void receive(IReceive iReceive){
System.out.println(iReceive.getInfo());
}
}
依赖关系传递的三种方式
1、接口传递
2、构造方法传递
3、setter方式传递
依赖倒转原则的注意事项和细节
- 低层模块经量都要有抽象类或接口,或者两者都有,程序稳定性更好。
- 变量的声明类型经量是抽象类或接口,这样我们的变量引用和实际对象间,就存在一个缓冲层,利于程序扩展和优化
- 继承时遵循里氏替换原则
里氏替换原则
OO中的继承性的思考和说明
- 继承包含这样一层含义:父类中凡是已经实现好的方法,实际上是在规定规范和契约,虽然他不强制要求所有的子类必须遵循这些契约,但是如果子类对这些已经实现的方法任意修改,就会对整个继承体系造成破坏。
- 继承在给程序设计带来便利的同时,也带来了弊端,比如使用继承会给程序带来侵入性,程序的可移植性降低,增加对象间的耦合性,如果一个类被其他的类所继承则当这个类需要修改时,必须考虑到所有的子类,并且父类修改后,所有涉及到子类的功能都有可能产生故障
基本介绍
- 里氏替换原则在1988年,由麻省理工学院的一位姓里的女士提出的
- 如果对某个类型为T1的对象o1,都有类型为T2的对象o2,使得以T1定义的所有程序P在所有的对象o1都替换成o2时,程序P的行为没有发生变化,那么类型T2时类型类型T1的子类型,换句话说,所有引用基类的地方必须能透明地使用其子类的对象。
- 在使用继承时,遵循里氏替换原则,在子类中尽量不要重写父类的方法
- 里氏替换原则告诉我们,继承实际上让两个类耦合性增强了,在适合的情况下,可以通过聚合,组合,依赖来解决问题。
package replacement;
/**
* Created with IntelliJ IDEA.
* 里氏替换原则
* @Date: 2022/05/17/18:37
* @Description:
*/
public class Replacement {
public static void main(String[] args) {
A a = new A();
System.out.println("11+3="+a.sum(11,3));
B b = new B();
System.out.println("11+3="+b.sum1(11,3));
System.out.println("11+3="+b.sum(11,3));
}
}
class A{
public Integer sum(int a,int b){
return a+b;
}
}
class B extends A{
public Integer sum1(int a, int b){
return a+b;
}
public Integer sum(int a,int b){
return a-b;
}
}
开闭原则
- 开闭原则是编程中最基础,最重要的设计原则
- 一个软件实体如类,模块和函数应该对扩展开发,对修改关闭,用抽象构建框架,用实现扩展细节
- 当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化
迪米特法则
- 一个对象应该对其他对象保持最少的了解
- 类与类关系越密切,耦合度越大
- 迪米特法则又叫最少知道原则,即一个类对自己依赖的类知道的越少越好,也就是说,对于被依赖的类不管多么复杂,都尽量将逻辑封装在类的内部。对外除了提供简单的public方法,不对外泄露任何信息
- 迪米特法则还有个更简单的定义:只与直接的朋友通信
- **直接的朋友:**每个对象都会与其他对象有耦合关系,只要两个对象之间有耦合关系。我们就说这两个对象之间是朋友关系。耦合的方式很多,依赖,关联,组合,聚合等。其中,我们称出现成员变量,方法参数,方法返回值中的类为直接的朋友,而出现在局部变量中的类不是直接的朋友。也就是说,陌生的类最好不要以局部变量的形式出现在类的内部
合成复用原则
原则是尽量使用合成/聚合的方式,而不是使用继承
设计者模式类型
设计模式分成三种类型,共23种
- 创建者模式:单例模式、抽象工厂模式、原型模式、建造者模式、工厂模式。
- 结构型模式:适配器模式、桥接模式、装饰模式、组合模式、 外观模式、享元模式、代理模式。
- 行为型模式:模板方法模式、命令模式、访问者模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式、状态模式、策略模式、职责链模式(责任链模式)
单例模式
单例设计模式介绍
所谓类的单例设计模式,就是采取一定的方法保证在整个的软件系统中,对某个类只能存在一个对象实列,并且该类只提供一个取得其对象实例的方法(静态方法)
比如Mybatis的SessionFactory,它充当数据存储源的代理,并负责创建session对象。SessionFactory并不是轻量级的,一般情况下,一个项目通常只需要一个SessionFactory就够,这是就会使用到单列模式。
单例模式有八种方式:
- 饿汉式(静态常量)
- 饿汉式(静态代码块)
- 懒汉式(线程不安全)
- 懒汉式(线程安全,同步方法)
- 懒汉式(线程安全,同步代码块)
- 双重检查
- 静态内部类
- 枚举
饿汉式(静态常量)
步骤如下:
- 构造器私有化(防止new)
- 类的内部创建对象
- 向外暴露一个静态的公共方法。getInstance
- 代码实现
package singleton;
/**
* Created with IntelliJ IDEA.
* 饿汉式(静态常量)
*
* @Date: 2022/05/18/18:55
* @Description:
*/
public class SingletonType1 {
public static void main(String[] args) {
//测试
Singleton instance1 = Singleton.getInstance();
Singleton instance2 = Singleton.getInstance();
System.out.println(instance1 == instance2);
System.out.println(instance1.hashCode());
System.out.println(instance2.hashCode());
}
}
/**
* @Description: 饿汉式(静态常量)
* @Param:
* @return:
* @Date: 2022/5/18
*/
class Singleton {
//1、构造器私有化,外部不能new
private Singleton() {
}
//2、本类内部创建对象实例
private static final Singleton instance = new Singleton();
//3、提供一个公有的静态方法,返回实例对象
public static Singleton getInstance() {
return instance;
}
}
优缺点说明
- 优点:这种写法比较简单,就是在类装载的时候就完成实例化,避免了线程同步问题。
- 缺点:在类装载的时候就完成实例化,没有达到lazy Loading的效果。如果从始至终从未使用这个实例,则会造成内存的浪费
- 这种方式基于classloder机制避免了多线程的同步问题,不过,instance在类装载时就实例化,在单例模式中大多数都是调用getInstance方法,但是导致类装载的原因有很多种,因此不能确定有其他的方式(或者其他的静态方法)导致类装载,这时候初始化instance就没有达到lazy loading的效果
- 结论:这种单例模式可用,可能造成内存浪费
饿汉式(静态代码块)
package singleton.staticcodeblock;
/**
* Created with IntelliJ IDEA.
* 饿汉式(静态代码块)
*
* @Date: 2022/05/18/18:55
* @Description:
*/
public class SingletonType1 {
public static void main(String[] args) {
//测试
Singleton instance1 = Singleton.getInstance();
Singleton instance2 = Singleton.getInstance();
System.out.println(instance1 == instance2);
System.out.println(instance1.hashCode());
System.out.println(instance2.hashCode());
}
}
/**
* @Description: 饿汉式(静态代码块)
* @Param:
* @return:
* @Date: 2022/5/18
*/
class Singleton {
//1、构造器私有化,外部不能new
private Singleton() {
}
//2、本类内部创建对象实例
private static Singleton instance;
//在静态代码块中,创建单例实例化对象
static {
instance = new Singleton();
}
//3、提供一个公有的静态方法,返回实例对象
public static Singleton getInstance() {
return instance;
}
}
优缺点说明:
- 这种方式和上面的方式其实类似,只不过将类实例化的过程放在了静态代码块中,也是在类装载的时候,就执行静态代码块中的代码,初始化类的实例。优缺点和上面是一样的。
- 结论:这种单例模式可用,可能造成内存浪费
懒汉式(线程不安全)
package singleton.lazythreadsarenotsafe;
/**
* Created with IntelliJ IDEA.
* 懒汉式(线程不安全)
*
* @Date: 2022/05/18/18:55
* @Description:
*/
public class SingletonType1 {
public static void main(String[] args) {
//测试
Singleton instance1 = Singleton.getInstance();
Singleton instance2 = Singleton.getInstance();
System.out.println(instance1 == instance2);
System.out.println(instance1.hashCode());
System.out.println(instance2.hashCode());
}
}
/**
* @Description: 懒汉式(线程不安全)
* @Param:
* @return:
* @Date: 2022/5/18
*/
class Singleton {
//1、构造器私有化,外部不能new
private Singleton() {
}
//2、本类内部创建对象实例
private static Singleton instance;
//3、提供一个公有的静态方法,当使用到该方法,才会去创建instance
public static Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
优缺点说明
- 起到lazy loading的效果,但是只能在单线程下使用
- 如果在多线程下,一个线程进入if(instance==null)判断语句块,还未来得及往下执行,另一个线程也通过了这个判断语句,这时便会产生多个实例。所以在多线程环境下不可使用这种方式
- 结论:在实际开发中,不要使用这种方式。
懒汉式(线程安全,同步方法)
package singleton.lazythreadsafety;
/**
* Created with IntelliJ IDEA.
* 懒汉式(线程安全)
*
* @Date: 2022/05/18/18:55
* @Description:
*/
public class SingletonType1 {
public static void main(String[] args) {
//测试
Singleton instance1 = Singleton.getInstance();
Singleton instance2 = Singleton.getInstance();
System.out.println(instance1 == instance2);
System.out.println(instance1.hashCode());
System.out.println(instance2.hashCode());
}
}
/**
* @Description: 懒汉式(线程安全)
* @Param:
* @return:
* @Date: 2022/5/18
*/
class Singleton {
//1、构造器私有化,外部不能new
private Singleton() {
}
//2、本类内部创建对象实例
private static Singleton instance;
//3、提供一个公有的静态方法,加入同步处理代码,使得线程安全
public static synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
优缺点说明:
- 解决了线程不安全问题
- 效率太低了,每个线程在想获得类的实例化时候,执行getInstance()方法都要进行同步。而其实这个方法只执行一次实例化代码就够了,后面的想获得该类实例直接return就行了。方法进行同步效率太低。
- 结论:在实际开发中,不推荐使用这种方式
懒汉式(线程安全,同步代码块)
package singleton.lazythreadsafety;
/**
* Created with IntelliJ IDEA.
* 懒汉式(线程安全,同步代码块)
*
* @Date: 2022/05/18/18:55
* @Description:
*/
public class SingletonType1 {
public static void main(String[] args) {
//测试
Singleton instance1 = Singleton.getInstance();
Singleton instance2 = Singleton.getInstance();
System.out.println(instance1 == instance2);
System.out.println(instance1.hashCode());
System.out.println(instance2.hashCode());
}
}
/**
* @Description: 懒汉式(线程安全,同步代码块)
* @Param:
* @return:
* @Date: 2022/5/18
*/
class Singleton {
//1、构造器私有化,外部不能new
private Singleton() {
}
//2、本类内部创建对象实例
private static Singleton instance;
//3、提供一个公有的静态方法,加入同步处理代码,
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class){
instance = new Singleton();
}
}
return instance;
}
}
优缺点说明
- 这种方式,本意是想对第四种实现方式的改进,因为前面同步方法效率太低,改为同步产生实例化的代码块
- 但是这种同步并不能起到线程同步的作用,跟第三种实现方式遇到的情形一致,假如一个线程进入if(Singleton==null)判断语句,还未来得及往下执行,另一个线程也通过了这个判断语句,这时便会产生多个实例
- 结论:在实际开发中,不能使用这种方式
双重检查
package singleton.doubleinspection;
/**
* Created with IntelliJ IDEA.
* 双重检查
*
* @Date: 2022/05/18/18:55
* @Description:
*/
public class SingletonType1 {
public static void main(String[] args) {
//测试
Singleton instance1 = Singleton.getInstance();
Singleton instance2 = Singleton.getInstance();
System.out.println(instance1 == instance2);
System.out.println(instance1.hashCode());
System.out.println(instance2.hashCode());
}
}
/**
* @Description: 双重检查
* @Param:
* @return:
* @Date: 2022/5/18
*/
class Singleton {
//1、构造器私有化,外部不能new
private Singleton() {
}
//2、本类内部创建对象实例
private static volatile Singleton instance;
//3、提供一个公有的静态方法,加入双重检查代码,解决线程安全问题,同时解决懒加载问题
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
优缺点说明
- Double-Check概念是多线程开发中常使用到的,如代码中所示,我们进行了两次if(instance==null)检查。这样就可以保证线程安全了
- 这样,实例化代码只用执行一次,后面再次访问时,判断if(instance==null),直接return实例化对象,也避免了反复进行方法同步
- 线程安全:延迟加载。效率较高
- 结论:在实际开发中,推荐使用这种单例设计模式
静态内部类
package singleton.staticinternalclass;
/**
* Created with IntelliJ IDEA.
* 静态内部类
*
* @Date: 2022/05/18/18:55
* @Description:
*/
public class SingletonType1 {
public static void main(String[] args) {
//测试
Singleton instance1 = Singleton.getInstance();
Singleton instance2 = Singleton.getInstance();
System.out.println(instance1 == instance2);
System.out.println(instance1.hashCode());
System.out.println(instance2.hashCode());
}
}
/**
* @Description: 静态内部类
* @Param:
* @return:
* @Date: 2022/5/18
*/
class Singleton {
//1、构造器私有化,外部不能new
private Singleton() {
}
//2、本类内部创建对象实例
private static volatile Singleton instance;
//写一个静态内部类,该类中有一个静态属性Singleton
private static class SingletonInstance {
private static final Singleton INSTANCE = new Singleton();
}
//3、提供一个公有的静态方法,直接返回SingletonInstance.INSTANCE
public static Singleton getInstance() {
return SingletonInstance.INSTANCE;
}
}
优缺点说明
- 这种方式采用了类装载的机制来保证初始化实例时只有一个线程。
- 静态内部类方式在Singleton类被装载时并不会立即实例化,而是在需要实例化时,调用getInstance()方法,才会装载SingletonInstance类,从而完成Singleton的实例化
- 类的静态属性只会在第一次加载类的时候初始化,所以在这里,JVM帮助完美保证了线程的安全性,在类进行初始化时,别的线程是无法进入的。
- 优点:避免了线程不安全,利用静态内部类特点实现延迟加载,效率高
- 结论:推荐使用。
枚举
package singleton.enumtype;
/**
* Created with IntelliJ IDEA.
* 枚举
*
* @Date: 2022/05/18/18:55
* @Description:
*/
public class SingletonType1 {
public static void main(String[] args) {
//测试
Singleton instance1 = Singleton.INSTANCE;
Singleton instance2 = Singleton.INSTANCE;
System.out.println(instance1 == instance2);
System.out.println(instance1.hashCode());
System.out.println(instance2.hashCode());
instance1.say();
instance2.say();
}
}
enum Singleton{
INSTANCE; //属性
public void say(){
System.out.println("Hello World");
}
}
优缺点说明
- 这借助JDK1.5中添加的枚举来实现单例模式。不仅能避免多线程同步问题,而且还能防止反序列化重新创建新的对象。
- 这种方式时Effective java作者Josh Bloch提倡的方式
- 结论:推荐使用
单例模式注意事项和细节说明
- 单例模式保证了系统内存中该类只存在一个对象,节省了系统资源,对于一些需要频繁创建销毁的对象,使用单例模式可以提高系统性能
- 当想实例化一个单例类的时候,必须要记住使用相应的获取对象的方法,而不是使用new
- 单例模式使用的场景:需要频繁的进行创建和销毁的对象,创建对象时耗时过多或耗费资源过多(即:重复级对象),但又经常用到的对象(工具类对象、频繁访问数据库或文件的对象(比如数据源、session工厂等)