当前位置: 首页 > news >正文

网站建设就问山东聚搜网络f/酒店网络营销方式有哪些

网站建设就问山东聚搜网络f,酒店网络营销方式有哪些,企业营销型网站系统,第一ppt网免费模板Java单例模式可能是最简单也是最常用的设计模式,一个完美的单例需要做到哪些事呢? 单例(这不是废话吗)延迟加载线程安全没有性能问题防止序列化产生新对象防止反射攻击可以看到,真正要实现一个完美的单例是很复杂的&am…

Java单例模式可能是最简单也是最常用的设计模式,一个完美的单例需要做到哪些事呢?

  1. 单例(这不是废话吗)
  2. 延迟加载
  3. 线程安全
  4. 没有性能问题
  5. 防止序列化产生新对象
  6. 防止反射攻击

可以看到,真正要实现一个完美的单例是很复杂的,那么,让我这个司机带大家看一看正确姿势的单例。

最佳实践单例之枚举

没错,直接就上最佳实践,就是这么任性

这货长这样:

[java] view plaincopy
在CODE上查看代码片派生到我的代码片
  1. public enum Singleton{  
  2.     INSTANCE;  
  3. }  

如果你不熟悉枚举,可能会说:这货是啥?!

这种方式的好处是:

  1. 利用的枚举的特性实现单例
  2. 由JVM保证线程安全
  3. 序列化和反射攻击已经被枚举解决

调用方式为Singleton.INSTANCE, 出自《Effective Java》第二版第三条: 用私有构造器或枚举类型强化Singleton属性。

关于单例最佳实践的讨论可以看Stackoverflow:what-is-an-efficient-way-to-implement-a-singleton-pattern-in-java

下面将会介绍更为常见的单例模式,但是均未处理反射攻击,如果想了解更多可以看这篇文章:如何防止单例模式被JAVA反射攻击

最简单的单例之饿汉式

[java] view plaincopy
在CODE上查看代码片派生到我的代码片
  1. public class Singleton {  
  2.     private static final Singleton INSTANCE = new Singleton();  
  3.     // 私有化构造函数  
  4.     private Singleton(){}  
  5.   
  6.     public static Singleton getInstance(){  
  7.         return INSTANCE;  
  8.     }  
  9. }  

这种单例的写法最简单,但是缺点是一旦类被加载,单例就会初始化,没有实现懒加载。而且当实现了Serializable接口后,反序列化时单例会被破坏。

实现Serializable接口需要重写readResolve,才能保证其反序列化依旧是单例:

[java] view plaincopy
在CODE上查看代码片派生到我的代码片
  1. public class Singleton implements Serializable {  
  2.     private static final Singleton INSTANCE = new Singleton();  
  3.     // 私有化构造函数  
  4.     private Singleton(){}  
  5.   
  6.     public static Singleton getInstance(){  
  7.         return INSTANCE;  
  8.     }  
  9.   
  10.     /** 
  11.      * 如果实现了Serializable, 必须重写这个方法 
  12.      */  
  13.     private Object readResolve() throws ObjectStreamException {  
  14.         return INSTANCE;  
  15.     }  
  16. }  

OK,反序列化要注意的就是这一点,下面的内容中就不再复述了。

最体现技术的单例之懒汉式

懒汉式即实现延迟加载的单例,为上述饿汉式的优化形式。而因其仍需要进一步优化,往往成为面试考点,让我们一起来看看坑爹的“懒汉式”

懒汉式的最初形式是这样的:

[java] view plaincopy
在CODE上查看代码片派生到我的代码片
  1. public class Singleton {  
  2.     private static Singleton INSTANCE;  
  3.     private Singleton (){}  
  4.   
  5.     public static Singleton getInstance() {  
  6.      if (INSTANCE == null) {  
  7.          INSTANCE = new Singleton();  
  8.      }  
  9.      return INSTANCE;  
  10.     }  
  11. }  

这种写法就轻松实现了单例的懒加载,只有调用了getInstance方法才会初始化。但是这样的写法出现了新的问题--线程不安全。当多个线程调用getInstance方法时,可能会创建多个实例,因此需要对其进行同步。

如何使其线程安全呢?简单,加个synchronized关键字就行了

[java] view plaincopy
在CODE上查看代码片派生到我的代码片
  1. public static synchronized Singleton getInstance() {  
  2.     if (INSTANCE == null) {  
  3.         INSTANCE = new Singleton();  
  4.     }  
  5.     return INSTANCE;  
  6. }  

可是...这样又出现了性能问题,简单粗暴的同步整个方法,导致同一时间内只有一个线程能够调用getInstance方法。

因为仅仅需要对初始化部分的代码进行同步,所以再次进行优化:

[java] view plaincopy
在CODE上查看代码片派生到我的代码片
  1. public static Singleton getSingleton() {  
  2.     if (INSTANCE == null) {               // 第一次检查  
  3.         synchronized (Singleton.class) {  
  4.             if (INSTANCE == null) {      // 第二次检查  
  5.                 INSTANCE = new Singleton();  
  6.             }  
  7.         }  
  8.     }  
  9.     return INSTANCE ;  
  10. }  

执行两次检测很有必要:当多线程调用时,如果多个线程同时执行完了第一次检查,其中一个进入同步代码块创建了实例,后面的线程因第二次检测不会创建新实例。

这段代码看起来很完美,但仍旧存在问题,以下内容引用自黑桃夹克大神的如何正确地写出单例模式

这段代码看起来很完美,很可惜,它是有问题。主要在于instance = new Singleton()这句,这并非是一个原子操作,事实上在 JVM 中这句话大概做了下面 3 件事情。

  1. 给 instance 分配内存
  2. 调用 Singleton 的构造函数来初始化成员变量
  3. 将instance对象指向分配的内存空间(执行完这步 instance 就为非 null 了)

但是在 JVM 的即时编译器中存在指令重排序的优化。也就是说上面的第二步和第三步的顺序是不能保证的,最终的执行顺序可能是 1-2-3 也可能是 1-3-2。如果是后者,则在 3 执行完毕、2 未执行之前,被线程二抢占了,这时 instance 已经是非 null 了(但却没有初始化),所以线程二会直接返回 instance,然后使用,然后顺理成章地报错。

我们只需要将 instance 变量声明成 volatile 就可以了。

[java] view plaincopy
在CODE上查看代码片派生到我的代码片
  1. public class Singleton {  
  2.     private volatile static Singleton INSTANCE; //声明成 volatile  
  3.     private Singleton (){}  
  4.   
  5.     public static Singleton getSingleton() {  
  6.         if (INSTANCE == null) {                           
  7.             synchronized (Singleton.class) {  
  8.                 if (INSTANCE == null) {         
  9.                     INSTANCE = new Singleton();  
  10.                 }  
  11.             }  
  12.         }  
  13.         return INSTANCE;  
  14.     }  
  15.   
  16. }  
使用 volatile 的主要原因是其另一个特性:禁止指令重排序优化。也就是说,在 volatile 变量的赋值操作后面会有一个内存屏障(生成的汇编代码上),读操作不会被重排序到内存屏障之前。比如上面的例子,取操作必须在执行完 1-2-3 之后或者 1-3-2 之后,不存在执行到 1-3 然后取到值的情况。从「先行发生原则」的角度理解的话,就是对于一个 volatile 变量的写操作都先行发生于后面对这个变量的读操作(这里的“后面”是时间上的先后顺序)。
但是特别注意在 Java 5 以前的版本使用了 volatile 的双检锁还是有问题的。其原因是 Java 5 以前的 JMM (Java 内存模型)是存在缺陷的,即时将变量声明成 volatile 也不能完全避免重排序,主要是 volatile 变量前后的代码仍然存在重排序问题。这个 volatile 屏蔽重排序的问题在 Java 5 中才得以修复,所以在这之后才可以放心使用 volatile。

至此,这样的懒汉式才是没有问题的懒汉式。

内部类实现单例

[java] view plaincopy
在CODE上查看代码片派生到我的代码片
  1. public class Singleton {   
  2.     /**  
  3.      * 类级的内部类,也就是静态的成员式内部类,该内部类的实例与外部类的实例没有绑定关系,  
  4.      * 而且只有被调用到才会装载,从而实现了延迟加载  
  5.      */   
  6.     private static class SingletonHolder{   
  7.         /**  
  8.          * 静态初始化器,由JVM来保证线程安全  
  9.          */   
  10.         private static final Singleton instance = new Singleton();   
  11.     }   
  12.     /**  
  13.      * 私有化构造方法  
  14.      */   
  15.     private Singleton(){   
  16.     }   
  17.   
  18.     public static  Singleton getInstance(){   
  19.         return SingletonHolder.instance;   
  20.     }   
  21. }  

使用内部类来维护单例的实例,当Singleton被加载时,其内部类并不会被初始化,故可以确保当 Singleton类被载入JVM时,不会初始化单例类。只有 getInstance() 方法调用时,才会初始化 instance。同时,由于实例的建立是时在类加载时完成,故天生对多线程友好,getInstance() 方法也无需使用同步关键字。

Java单例模式可能是最简单也是最常用的设计模式,一个完美的单例需要做到哪些事呢?

  1. 单例(这不是废话吗)
  2. 延迟加载
  3. 线程安全
  4. 没有性能问题
  5. 防止序列化产生新对象
  6. 防止反射攻击

可以看到,真正要实现一个完美的单例是很复杂的,那么,让我这个司机带大家看一看正确姿势的单例。

最佳实践单例之枚举

没错,直接就上最佳实践,就是这么任性

这货长这样:

[java] view plaincopy
在CODE上查看代码片派生到我的代码片
  1. public enum Singleton{  
  2.     INSTANCE;  
  3. }  

如果你不熟悉枚举,可能会说:这货是啥?!

这种方式的好处是:

  1. 利用的枚举的特性实现单例
  2. 由JVM保证线程安全
  3. 序列化和反射攻击已经被枚举解决

调用方式为Singleton.INSTANCE, 出自《Effective Java》第二版第三条: 用私有构造器或枚举类型强化Singleton属性。

关于单例最佳实践的讨论可以看Stackoverflow:what-is-an-efficient-way-to-implement-a-singleton-pattern-in-java

下面将会介绍更为常见的单例模式,但是均未处理反射攻击,如果想了解更多可以看这篇文章:如何防止单例模式被JAVA反射攻击

最简单的单例之饿汉式

[java] view plaincopy
在CODE上查看代码片派生到我的代码片
  1. public class Singleton {  
  2.     private static final Singleton INSTANCE = new Singleton();  
  3.     // 私有化构造函数  
  4.     private Singleton(){}  
  5.   
  6.     public static Singleton getInstance(){  
  7.         return INSTANCE;  
  8.     }  
  9. }  

这种单例的写法最简单,但是缺点是一旦类被加载,单例就会初始化,没有实现懒加载。而且当实现了Serializable接口后,反序列化时单例会被破坏。

实现Serializable接口需要重写readResolve,才能保证其反序列化依旧是单例:

[java] view plaincopy
在CODE上查看代码片派生到我的代码片
  1. public class Singleton implements Serializable {  
  2.     private static final Singleton INSTANCE = new Singleton();  
  3.     // 私有化构造函数  
  4.     private Singleton(){}  
  5.   
  6.     public static Singleton getInstance(){  
  7.         return INSTANCE;  
  8.     }  
  9.   
  10.     /** 
  11.      * 如果实现了Serializable, 必须重写这个方法 
  12.      */  
  13.     private Object readResolve() throws ObjectStreamException {  
  14.         return INSTANCE;  
  15.     }  
  16. }  

OK,反序列化要注意的就是这一点,下面的内容中就不再复述了。

最体现技术的单例之懒汉式

懒汉式即实现延迟加载的单例,为上述饿汉式的优化形式。而因其仍需要进一步优化,往往成为面试考点,让我们一起来看看坑爹的“懒汉式”

懒汉式的最初形式是这样的:

[java] view plaincopy
在CODE上查看代码片派生到我的代码片
  1. public class Singleton {  
  2.     private static Singleton INSTANCE;  
  3.     private Singleton (){}  
  4.   
  5.     public static Singleton getInstance() {  
  6.      if (INSTANCE == null) {  
  7.          INSTANCE = new Singleton();  
  8.      }  
  9.      return INSTANCE;  
  10.     }  
  11. }  

这种写法就轻松实现了单例的懒加载,只有调用了getInstance方法才会初始化。但是这样的写法出现了新的问题--线程不安全。当多个线程调用getInstance方法时,可能会创建多个实例,因此需要对其进行同步。

如何使其线程安全呢?简单,加个synchronized关键字就行了

[java] view plaincopy
在CODE上查看代码片派生到我的代码片
  1. public static synchronized Singleton getInstance() {  
  2.     if (INSTANCE == null) {  
  3.         INSTANCE = new Singleton();  
  4.     }  
  5.     return INSTANCE;  
  6. }  

可是...这样又出现了性能问题,简单粗暴的同步整个方法,导致同一时间内只有一个线程能够调用getInstance方法。

因为仅仅需要对初始化部分的代码进行同步,所以再次进行优化:

[java] view plaincopy
在CODE上查看代码片派生到我的代码片
  1. public static Singleton getSingleton() {  
  2.     if (INSTANCE == null) {               // 第一次检查  
  3.         synchronized (Singleton.class) {  
  4.             if (INSTANCE == null) {      // 第二次检查  
  5.                 INSTANCE = new Singleton();  
  6.             }  
  7.         }  
  8.     }  
  9.     return INSTANCE ;  
  10. }  

执行两次检测很有必要:当多线程调用时,如果多个线程同时执行完了第一次检查,其中一个进入同步代码块创建了实例,后面的线程因第二次检测不会创建新实例。

这段代码看起来很完美,但仍旧存在问题,以下内容引用自黑桃夹克大神的如何正确地写出单例模式

这段代码看起来很完美,很可惜,它是有问题。主要在于instance = new Singleton()这句,这并非是一个原子操作,事实上在 JVM 中这句话大概做了下面 3 件事情。

  1. 给 instance 分配内存
  2. 调用 Singleton 的构造函数来初始化成员变量
  3. 将instance对象指向分配的内存空间(执行完这步 instance 就为非 null 了)

但是在 JVM 的即时编译器中存在指令重排序的优化。也就是说上面的第二步和第三步的顺序是不能保证的,最终的执行顺序可能是 1-2-3 也可能是 1-3-2。如果是后者,则在 3 执行完毕、2 未执行之前,被线程二抢占了,这时 instance 已经是非 null 了(但却没有初始化),所以线程二会直接返回 instance,然后使用,然后顺理成章地报错。

我们只需要将 instance 变量声明成 volatile 就可以了。

[java] view plaincopy
在CODE上查看代码片派生到我的代码片
  1. public class Singleton {  
  2.     private volatile static Singleton INSTANCE; //声明成 volatile  
  3.     private Singleton (){}  
  4.   
  5.     public static Singleton getSingleton() {  
  6.         if (INSTANCE == null) {                           
  7.             synchronized (Singleton.class) {  
  8.                 if (INSTANCE == null) {         
  9.                     INSTANCE = new Singleton();  
  10.                 }  
  11.             }  
  12.         }  
  13.         return INSTANCE;  
  14.     }  
  15.   
  16. }  
使用 volatile 的主要原因是其另一个特性:禁止指令重排序优化。也就是说,在 volatile 变量的赋值操作后面会有一个内存屏障(生成的汇编代码上),读操作不会被重排序到内存屏障之前。比如上面的例子,取操作必须在执行完 1-2-3 之后或者 1-3-2 之后,不存在执行到 1-3 然后取到值的情况。从「先行发生原则」的角度理解的话,就是对于一个 volatile 变量的写操作都先行发生于后面对这个变量的读操作(这里的“后面”是时间上的先后顺序)。
但是特别注意在 Java 5 以前的版本使用了 volatile 的双检锁还是有问题的。其原因是 Java 5 以前的 JMM (Java 内存模型)是存在缺陷的,即时将变量声明成 volatile 也不能完全避免重排序,主要是 volatile 变量前后的代码仍然存在重排序问题。这个 volatile 屏蔽重排序的问题在 Java 5 中才得以修复,所以在这之后才可以放心使用 volatile。

至此,这样的懒汉式才是没有问题的懒汉式。

内部类实现单例

[java] view plaincopy
在CODE上查看代码片派生到我的代码片
  1. public class Singleton {   
  2.     /**  
  3.      * 类级的内部类,也就是静态的成员式内部类,该内部类的实例与外部类的实例没有绑定关系,  
  4.      * 而且只有被调用到才会装载,从而实现了延迟加载  
  5.      */   
  6.     private static class SingletonHolder{   
  7.         /**  
  8.          * 静态初始化器,由JVM来保证线程安全  
  9.          */   
  10.         private static final Singleton instance = new Singleton();   
  11.     }   
  12.     /**  
  13.      * 私有化构造方法  
  14.      */   
  15.     private Singleton(){   
  16.     }   
  17.   
  18.     public static  Singleton getInstance(){   
  19.         return SingletonHolder.instance;   
  20.     }   
  21. }  

使用内部类来维护单例的实例,当Singleton被加载时,其内部类并不会被初始化,故可以确保当 Singleton类被载入JVM时,不会初始化单例类。只有 getInstance() 方法调用时,才会初始化 instance。同时,由于实例的建立是时在类加载时完成,故天生对多线程友好,getInstance() 方法也无需使用同步关键字。

转载于:https://www.cnblogs.com/huozhong/p/5977542.html

http://www.jmfq.cn/news/5073481.html

相关文章:

  • vue做的个人网站/百度竞价推广课程
  • dede生成网站地图/成都疫情最新情况
  • 龙口做网站价格/做网站的外包公司
  • 厦门网站推广步骤机构/代发关键词包收录
  • 能源公司网站建设/如何进行市场推广
  • 电脑做系统网站/网页开发需要学什么
  • 网站定制开发要多久/线上广告投放渠道
  • 做网站霸屏公司销售好做吗/申请域名的方法和流程
  • 杭州模板网站建站/互联网广告推广公司
  • 合肥专门做网站的公司/网络推广优化品牌公司
  • 制作简单的网站/西安专业seo
  • 福田网站建设设计/灰色产业推广引流渠道
  • 软件网站排行榜/关键词优化营销
  • 局域网如何做网站/seo关键词首页排名
  • wordpress主题 手机app/云优化seo软件
  • 达州市做网站/免费网站大全
  • 宿州网站推广/外贸seo网站建设
  • 学校网站做几级等保/网络服务投诉平台
  • 国外购物网站系统/市场推广外包团队
  • 深圳网站建设推荐q479185700顶上/黄页88网络营销宝典
  • 高明网站开发/怎么建造自己的网站
  • 建立网站的程序/网店推广策划方案
  • 网站域名到期时间查询/chatgpt网址
  • 专业做汽配的网站/台州seo排名扣费
  • 深圳交委建设中心网站/百度开发平台
  • 开私服传奇做网站需要钱嘛/代运营服务
  • 江门那里做公司网站好/seo信息是什么
  • 东莞手机微信网站制作/客服系统网页源码2022免费
  • 网站建设cms系统/北京计算机培训机构前十名
  • 网站建设售前怎么做好/地推拉新app推广怎么做