如何看待Spring下单例模式与线程安全的矛盾

前言

有多少人在使用Spring框架时，不少时候不知道或者忽视了多线程的问题？

  由于写程序时，或作单元测试时，很难有机会碰到多线程的问题，由于没有那么容易模拟多线程测试的环境。那么当多个线程调用同一个bean的时候就会存在线程安全问题。若是是Spring中bean的建立模式为非单例的，也就不存在这样的问题了。

  但若是不去考虑潜在的漏洞，它就会变成程序的隐形杀手，在你不知道的时候爆发。并且，一般是程序交付使用时，在生产环境下触发，会是很麻烦的事。

---

Spring使用ThreadLocal解决线程安全问题

  咱们知道在通常状况下，只有无状态的Bean才能够在多线程环境下共享，在Spring中，绝大部分Bean均可以声明为singleton做用域。就是由于Spring对一些Bean（如RequestContextHolder、TransactionSynchronizationManager、LocaleContextHolder等）中非线程安全状态采用ThreadLocal进行处理，让它们也成为线程安全的状态，由于有状态的Bean就能够在多线程中共享了。

  通常的Web应用划分为展示层、服务层和持久层三个层次，在不一样的层中编写对应的逻辑，下层经过接口向上层开放功能调用。在通常状况下，从接收请求到返回响应所通过的全部程序调用都同属于一个线程

  ThreadLocal是解决线程安全问题一个很好的思路，它经过为每一个线程提供一个独立的变量副本解决了变量并发访问的冲突问题。在不少状况下，ThreadLocal比直接使用synchronized同步机制解决线程安全问题更简单，更方便，且结果程序拥有更高的并发性。

  若是你的代码所在的进程中有多个线程在同时运行，而这些线程可能会同时运行这段代码。若是每次运行结果和单线程运行的结果是同样的，并且其余的变量的值也和预期的是同样的，就是线程安全的。 或者说:一个类或者程序所提供的接口对于线程来讲是原子操做或者多个线程之间的切换不会致使该接口的执行结果存在二义性,也就是说咱们不用考虑同步的问题。线程安全问题都是由全局变量及静态变量引发的。

  若每一个线程中对全局变量、静态变量只有读操做，而无写操做，通常来讲，这个全局变量是线程安全的；如有多个线程同时执行写操做，通常都须要考虑线程同步，不然就可能影响线程安全。
　　1） 常量始终是线程安全的，由于只存在读操做。
　　2）每次调用方法前都新建一个实例是线程安全的，由于不会访问共享的资源。
　　3）局部变量是线程安全的。由于每执行一个方法，都会在独立的空间建立局部变量，它不是共享的资源。局部变量包括方法的参数变量和方法内变量。

  有状态就是有数据存储功能。有状态对象(Stateful Bean)，就是有实例变量的对象 ，能够保存数据，是非线程安全的。在不一样方法调用间不保留任何状态。

  无状态就是一次操做，不能保存数据。无状态对象(Stateless Bean)，就是没有实例变量的对象 .不能保存数据，是不变类，是线程安全的。

　　有状态对象:

  无状态的Bean适合用不变模式，技术就是单例模式，这样能够共享实例，提升性能。有状态的Bean，多线程环境下不安全，那么适合用Prototype原型模式。Prototype: 每次对bean的请求都会建立一个新的bean实例。

  Struts2默认的实现是Prototype模式。也就是每一个请求都新生成一个Action实例，因此不存在线程安全问题。须要注意的是，若是由Spring管理action的生命周期， scope要配成prototype做用域

---

线程安全案例

  SimpleDateFormat( 下面简称 sdf) 类内部有一个 Calendar 对象引用 , 它用来储存和这个 sdf 相关的日期信息 , 例如 sdf.parse(dateStr), sdf.format(date)  诸如此类的方法参数传入的日期相关 String, Date 等等 ,  都是交友 Calendar 引用来储存的 . 这样就会致使一个问题 , 若是你的 sdf 是个 static 的 ,  那么多个 thread  之间就会共享这个 sdf, 同时也是共享这个 Calendar 引用 ,  而且 ,  观察  sdf.parse()  方法 , 你会发现有以下的调用 :

Date parse() {
   calendar.clear(); // 清理calendar
   ... // 执行一些操做, 设置 calendar 的日期什么的
   calendar.getTime(); // 获取calendar的时间
 }

  这里会致使的问题就是 ,  若是 线程 A  调用了  sdf.parse(),  而且进行了 calendar.clear() 后还未执行 calendar.getTime() 的时候 , 线程 B 又调用了 sdf.parse(), 这时候线程 B 也执行了 sdf.clear() 方法 ,  这样就致使线程 A 的的 calendar 数据被清空了 ( 实际上 A,B 的同时被清空了 ).  又或者当  A  执行了 calendar.clear()  后被挂起 ,  这时候 B  开始调用 sdf.parse() 并顺利 i 结束 ,  这样  A  的  calendar 内存储的的 date 变成了后来 B 设置的 calendar 的 date

  这个问题背后隐藏着一个更为重要的问题 -- 无状态：无状态方法的好处之一，就是它在各类环境下，均可以安全的调用。衡量一个方法是不是有状态的，就看它是否改动了其它的东西，好比全局变量，好比实例的字段。 format 方法在运行过程当中改动了SimpleDateFormat 的 calendar 字段，因此，它是有状态的。

  这也同时提醒咱们在开发和设计系统的时候注意下如下三点 :

• 本身写公用类的时候，要对多线程调用状况下的后果在注释里进行明确说明
• 对线程环境下，对每个共享的可变变量都要注意其线程安全性
• 咱们的类和方法在作设计的时候，要尽可能设计成无状态的

---

解决办法

1. 须要的时候建立新实例：

  说明：在须要用到 SimpleDateFormat  的地方新建一个实例，无论何时，将有线程安全问题的对象由共享变为局部私有都能避免多线程问题，不过也加剧了建立对象的负担。在通常状况下，这样其实对性能影响比不是很明显的。

2. 使用同步：同步 SimpleDateFormat 对象

public class DateSyncUtil {
    private static SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
      
    public static String formatDate(Date date)throws ParseException{
        synchronized(sdf){
            return sdf.format(date);
        }  
    }
    
    public static Date parse(String strDate) throws ParseException{
        synchronized(sdf){
            return sdf.parse(strDate);
        }
    } 
}

  说明：当线程较多时，当一个线程调用该方法时，其余想要调用此方法的线程就要block ，多线程并发量大的时候会对性能有必定的影响。

3. 使用 ThreadLocal ：

public class ConcurrentDateUtil {
    private static ThreadLocal<DateFormat> threadLocal = new ThreadLocal<DateFormat>() {
        @Override
        protected DateFormat initialValue() {
            return new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
        }
    };
    public static Date parse(String dateStr) throws ParseException {
        return threadLocal.get().parse(dateStr);
    }
    public static String format(Date date) {
        return threadLocal.get().format(date);
    }
}

  或

ThreadLocal<DateFormat>(); 
 
    public static DateFormat getDateFormat()   
    {  
        DateFormat df = threadLocal.get();  
        if(df==null){  
            df = new SimpleDateFormat(date_format);  
            threadLocal.set(df);  
        }  
        return df;  
    }  
    public static String formatDate(Date date) throws ParseException {
        return getDateFormat().format(date);
    }
    public static Date parse(String strDate) throws ParseException {
        return getDateFormat().parse(strDate);
    }   
}

  说明：使用 ThreadLocal,  也是将共享变量变为独享，线程独享确定能比方法独享在并发环境中能减小很多建立对象的开销。若是对性能要求比较高的状况下，通常推荐使用这种方法。

4. 抛弃 JDK ，使用其余类库中的时间格式化类：

• 使用 Apache commons  里的 FastDateFormat ，宣称是既快又线程安全的SimpleDateFormat,  惋惜它只能对日期进行 format,  不能对日期串进行解析。
• 使用 Joda-Time 类库来处理时间相关问题

  作一个简单的压力测试，方法一最慢，方法三最快，可是就算是最慢的方法一性能也不差，通常系统方法一和方法二就能够知足，因此说在这个点很难成为你系统的瓶颈所在。从简单的角度来讲，建议使用方法一或者方法二，若是在必要的时候，追求那么一点性能提高的话，能够考虑用方法三，用 ThreadLocal 作缓存。

  Joda-Time 类库对时间处理方式比较完美，建议使用。

总结

  回到文章开头的问题：《有多少人在使用Spring框架时，不少时候不知道或者忽视了多线程的问题？》

  其实代码谁都会写，为何架构师写的代码效果和你的天差地别呢？应该就是此类你没考虑到的小问题而架构师都考虑到了。

  架构师知识面更广，见识到的具体状况更多，解决各种问题的经验更丰富。只要你养成架构师的思惟和习惯，那你离架构师还会远吗？