手机网站制作优化,专题网页设计流程,制作网站需要的软件,安徽安庆网站建设公司单例设计模式 2.1 孤独的太阳盘古开天#xff0c;造日月星辰。2.2 饿汉造日2.3 懒汉的队伍2.4 大道至简 读《秒懂设计模式总结》 单例模式(Singleton)是一种非常简单且容易理解的设计模式。顾名思义#xff0c;单例即单一的实例#xff0c;确切地讲就是指在某个系统中只存在… 单例设计模式 2.1 孤独的太阳盘古开天造日月星辰。2.2 饿汉造日2.3 懒汉的队伍2.4 大道至简 读《秒懂设计模式总结》 单例模式(Singleton)是一种非常简单且容易理解的设计模式。顾名思义单例即单一的实例确切地讲就是指在某个系统中只存在一个实例同时提供集中、统一的访问接口以使系统行为保持协调一致。singleton一词在逻辑学中指“有且仅有一个元素的集合”这非常恰当地概括了单例的概念也就是“一个类仅有一个实例”。
2.1 孤独的太阳盘古开天造日月星辰。
从“夸父逐日”到“后羿射日”太阳对于我们的先祖一直具有着神秘的色彩与非凡的意义。随着科学的不断发展我们逐渐揭开了太阳系的神秘面纱。我们可以把太阳系看作一个庞大的系统其中有各种各样的对象存在丰富多彩的实例造就了系统的美好。这个系统里的某些实例是唯一的如我们赖以生存的恒星太阳。 与其他行星或卫星不同的是太阳是太阳系内唯一的恒星实例它持续提供给地球充足的阳光与能量离开它地球就不会有今天的勃勃生机但倘若天上有9个太阳那么将会带来一场灾难。太阳东升西落循环往复不多不少仅此一例。
2.2 饿汉造日
既然太阳系里只有一个太阳我们就需要严格把控太阳实例化的过程。我们从最简单的开始先来写一个Sun类。请参看代码 。
public class Sun {}
太阳类Sun中目前什么都没有。接下来我们得确保任何人都不能创建太阳的实例否则一旦程序员调用代码“new Sun()”天空就会出现多个太阳便又需要“后羿”去解决了。有些读者可能会疑惑我们并没有写构造器为什么太阳还可以被实例化呢这是因为Java可以自动为其加上一个无参构造器。为防止太阳实例泛滥将世界再次带入灾难我们必须禁止外部调用构造器请参看代码
public class Sun {private void Sun(){} // 构造器私有化
}
我们在第3行将太阳类Sun的构造方法设为private使其私有化如此一来太阳类就被完全封闭了起来实例化工作完全归属于内部事务任何外部类都无权干预。既然如此那么我们就让它自己创建自己并使其自有永有
public class Sun {private static final Sun sun new Sun();public Sun() {} // private constructor
}代码第3行中“private”关键字确保太阳实例的私有性、不可见性和不可访问性而“static”关键字确保太阳的静态性将太阳放入内存里的静态区在类加载的时候就初始化了它与类同在也就是说它是与类同时期且早于内存堆中的对象实例化的该实例在内存中永生内存垃圾收集器(Garbage Collector, GC)也不会对其进行回收“final”关键字则确保这个太阳是常量、恒量它是一颗终极的恒星引用一旦被赋值就不能再修改最后“new”关键字初始化太阳类的静态实例并赋予静态常量sun。这就是“饿汉模式”(eager initialization)即在初始阶段就主动进行实例化并时刻保持一种渴求的状态无论此单例是否有人使用。单例的太阳对象写好了可一切皆是私有的外部怎样才能访问它呢正如同程序入口的静态方法main()它不需要任何对象引用就能被访问我们同样需要一个静态方法getInstance()来获取太阳的单例对象同时将其设置为“public”以暴露给外部使用
public class Sun {private static final Sun sun new Sun();public Sun() {} // private constructorpublic static Sun getInstance(){return sun;}
}
太阳单例类的雏形已经完成了对外部来说只要调用Sun.getInstance()就可以得到太阳对象了并且不管谁得到或是得到几次得到的都是同一个太阳实例这样就确保了整个太阳系中恒星太阳的唯一合法性他人无法伪造。当然读者还可以添加其他功能方法如发光和发热等此处就不再赘述了。
2.3 懒汉的队伍
至此我们已经学会了单例模式的“饿汉模式”让太阳一开始就准备就绪随时供应免费日光。然而如果始终没人获取日光那岂不是白造了太阳一块内存区域被白白地浪费了这正类似于商家货品滞销的情况货架上堆放着商品却没人买白白浪费空间。因此商家为了降低风险规定有些商品必须提前预订这就是“懒汉模式”(lazy initialization)。沿着这个思路我们继续对太阳类进行改造
public class Sun {private static Sun sun new Sun();public Sun() {} // private constructorpublic static Sun getInstance(){if (null sun) {sun new Sun(); //沒有sun才构造}return sun;}
}可以看到我们一开始并没有造太阳所以去掉了关键字final只有在某线程第一次调用第9行的getInstance()方法时才会运行对太阳进行实例化的逻辑代码之后再请求就直接返回此实例了。这样的好处是如无请求就不实例化节省了内存空间而坏处是第一次请求的时候速度较之前的饿汉初始化模式慢因为要消耗CPU资源去临时造这个太阳即使速度快到可以忽略不计。这样的程序逻辑看似没问题但其实在多线程模式下是有缺陷的。试想如果是并发请求的话程序第10行的判空逻辑就会同时成立这样就会多次实例化太阳并且对sun进行多次赋值覆盖操作这违背了单例的理念。我们再来改良一下把请求方法加上synchronized同步锁让其同步如此一来某线程调用前必须获取同步锁调用完后会释放锁给其他线程用也就是给请求排队一个接一个按顺序来
public class Sun {private static Sun sun new Sun();public Sun() {} // private constructorpublic static synchronized Sun getInstance(){if (null sun) {sun new Sun(); //沒有sun才构造}return sun;}
}我们将太阳类Sun中第9行的getInstance()改成了同步方法如此可避免多线程陷阱。然而这样的做法是要付出一定代价的试想线程还没进入方法内部便不管三七二十一直接加锁排队会造成线程阻塞资源与时间被白白浪费。我们只是为了实例化一个单例对象而已犯不上如此兴师动众使用synchronized让所有请求排队等候。所以要保证多线程并发下逻辑的正确性同步锁一定要加得恰到好处其位置是关键所在
public class Sun {private volatile static Sun sun new Sun();public Sun() {} // private constructorpublic static Sun getInstance(){if (null sun) {synchronized (Sun.class) {if(null sun){sun new Sun(); //沒有sun才构造,只有第一次才构造 保证线程安全}}}return sun;}
}我们在太阳类Sun中第3行对sun变量的定义不再使用find关键字这意味着它不再是常量而是需要后续赋值的变量而关键字volatile对静态变量的修饰则能保证变量值在各线程访问时的同步性、唯一性。需要特别注意的是对于第9行的getInstance()方法我们去掉了方法上的关键字synchronized使大家都可以同时进入方法并对其进行开发。请仔细阅读每行代码的注释有些人线程起早就是为了观看日出那么这些人会通过第10行的判空逻辑进入观日台。而在第11行我们又加上了同步块以防止多个线程进入这就类似于观日台是一个狭长的走廊大家排队进入。随后在第12行我们又进行一次判空逻辑这就意味着只有队伍中的第一个人造了太阳有幸看到了日出的第一缕阳光而后面的人则统统离开直到第17行得到已经造好的太阳 随后发生的事情我们就可以预见了太阳高高升起实例化操作完毕起晚的人们都无须再进入观日台直接获取太阳实例就可以了阳光普照大地将温暖洒向人间。大家注意到没有我们一共用了2个嵌套的判空逻辑这就是懒加载模式的“双检锁”外层放宽入口保证线程并发的高效性内层加锁同步保证实例化的单次运行。如此里应外合不仅达到了单例模式的效果还完美地保证了构建过程的运行效率一举两得。
2.4 大道至简
相比“懒汉模式”其实在大多数情况下我们通常会更多地使用“饿汉模式”原因在于这个单例迟早是要被实例化占用内存的延迟懒加载的意义并不大加锁解锁反而是一种资源浪费同步更是会降低CPU的利用率使用不当的话反而会带来不必要的风险。越简单的包容性越强而越复杂的反而越容易出错。我们来看单例模式的类结构如图2-3所示。单例模式的角色定义如下。 ■ Singleton单例包含一个自己的类实例的属性并把构造方法用private关键字隐藏起来对外只提供getInstance()方法以获得这个单例对象。
除了“饿汉”与“懒汉”这2种单例模式其实还有其他的实现方式。但万变不离其宗它们统统都是由这2种模式发展、衍生而来的。我们都知道Spring框架中的IoC容器很好地帮我们托管了业务对象如此我们就不必再亲自动手去实例化这些对象了而在默认情况下我们使用的正是框架提供的“单例模式”。诚然究其代码实现当然不止如此简单但我们应该追本溯源抓住其本质的部分理解其核心的设计思想再针对不同的应用场景做出相应的调整与变动结合实践举一反三。
