线程安全的分析--finalstatic单例线程安全

Posted 2020-07-02 赛艇队长

我的代码中已经多次使用了线程，然后还非常喜欢使用据说是线程不安全的静态方法，然后又看到很多地方最容易提的问题就是这个东西线程不安全

 

于是我不免产生了以下几个亟待解决的问题：

1. 什么样的代码是天生线程安全的？而不用加锁
2. 线程是否安全的本质是什么？
3. 什么是快速把一段代码变成线程安全的通用方法
4. final static 单例 线程安全 之间的关系

 

1、首先我们知道，如果线程只是执行自己内部的代码（其实也是使用一些对象的方法，但是是局部变量，那么就线程安全），那一定是线程安全的

1. 这句话严格一些说可以是这样：线程使用在run( )方法中实例化的局部变量的方法，是线程安全的

 

2、那下一个问题就是，一个线程能调用哪些代码，或者说能访问到哪些东西？访问这些东西的安全性如何？

一个线程能访问哪些东西，应该是跟它创建的环境有关，线程启动从这个意义上有两个方式

1. 继承并重写一个Thread类，然后在使用的时候实例化这个类，最后调用这个对象实例的start方法启动
   1. 这种方式的run方法中，其实能调用的东西就很少了
      1. 你在继承时加的成员变量。（完全不会有线程是否安全的问题，因为这个类就一个run()方法是多线程方法，就跟在run()中实例化的局部变量一样）
      2. 通过构造方法从外面传入的变量。（这种方式需要警惕！因为传递的是引用，如果你在线程中对这个引用指向的内容进行修改，那么会影响到原来的东西！）
      3. 使用其他的代码段（方法）
         1. 静态方法（类似单例模式）
         2. 实例方法——通过实例对象
      4. 使用其他的对象
         1. 静态对象
         2. 实例对象
      5. （两面两大点中，使用实例方法和实例对象都是线程安全的。而使用静态方法和静态对象时，是一定会冲突的）
   2. 所以总结一下，这种方式中
      1. 线程安全的有
         1. 在继承时加的成员变量
         2. 实例化其他对象，使用这个对象，或者使用这个对象的方法
      2. 不安全的有
         1. 通过构造方法从外面传入的变量
         2. 静态方法
         3. 静态对象
2. 使用匿名内部类
   1. 这种方式，在上一种方式的继承上，只少了构造方法的方式，然后多了好几种危险的方式， 需要注意
      1. 所处方法中的局部变量
         1. 这个值得一提，本来这项是肯定会线程不安全，而且非常常用，所以危险指数五颗星的，但是JAVA特地为此限定了一条规则，就是这样的局部变量必须是final的，不能修改，于是这个就变得非常安全了
         2. 但这条其实可以通过引用类型绕过，就是另一回事了，其实也说明了它的不安全
      2. 所处类中的属性
      3. 所处类中的方法

 

另外，经过查阅资料，上面提到的所有跟方法有关的可能线程不安全的情况，其实都不是完全不安全

方法是否线程安全取决于方法中是否使用了全局变量，方法本身是在JAVA中是线程安全的，每个线程会有一个副本

 

总结一下，线程是否安全总的来说情况比较复杂，但是有这些特点

1. 静态的对象或者方法容易出问题
2. 方法本身不会有问题，问题的根源是方法使用了变量（相对全局变量，或者说叫可共享变量）
3. 匿名类中更加危险，要谨慎调用

 

3、线程是否安全的本质是什么？什么是快速把一段代码变成线程安全的通用方法？

而所谓的线程安全性具体又指的是什么

1. 不能同时被多个线程调用
   1. 这个是最普通的，也是常规上我们的线程安全的含义
   2. 这个问题可以通过加锁解决
2. 不能被多个线程调用（不同时也不行）
   1. 这个在第一类的程度上有所增加，不是常用的情况，可能你不仅是要使用变量，你还需要记录变量的值
   2. 这个问题一般是把相关变量变成ThreadLocal的
3. 不能被超过一次地调用
   1. 这个的情况更加特殊
   2. 一般使用单例模式解决

 

4、final static 单例 线程安全 之间的关系

1. final
   1. 意思是，这个对象的值（基本类型就是值，引用类型是引用地址），不会再被改变
   2. 与线程安全的关系，如上文，一定程度上能使某些变量强制变得线程安全
2. static
   1. 意思是，这个对象是一个全局变量了，你可以在多个地方，多个线程中调用到它，而且调用的是同一个它
   2. 与线程安全的关系，一般这种的变量很容易造成线程不安全的情况
3. 单例
   1. 这首先是一种特殊的需求，就是某个类的实例在JVM中只能存在一个，跟前面的static，线程安全都不一样
   2. 与线程安全的关系。实现单例需要考虑复杂的多线程的情况，这个东西需要线程安全

 

5、举个例子

常被说的SimpleDateFormat是非线程安全的，为什么线程不安全，来分析一下

1. 因为创建一个 SimpleDateFormat实例的开销比较昂贵，解析字符串时间时频繁创建生命周期短暂的实例导致性能低下
   1. 在程序中我们应当尽量少的创建SimpleDateFormat 实例，因为创建这么一个实例需要耗费很大的代价。在一个读取数据库数据导出到excel文件的例子当中，每次处理一个时间信息的时候，就需要创建一个SimpleDateFormat实例对象，然后再丢弃这个对象。大量的对象就这样被创建出来，占用大量的内存和 jvm空间。
2. 于是，就很容易想到，将 SimpleDateFormat定义为静态类变量，貌似能解决这个问题
3. 于是这就引出了，SimpleDateFormat是非线程安全的，这样的使用方式可能引发并发线程安全问题

那为什么会有这个问题呢？来看看SimpleDateFormat本身

1. SimpleDateFormat类内部有一个Calendar对象引用,它用来储存和这个SimpleDateFormat对象（叫sdf）相关的日期信息,例如sdf.parse(dateStr), sdf.format(date)
2. 诸如此类的方法参数传入的日期相关String, Date等等, 都是交友Calendar引用来储存的
3. 这样就会导致一个问题：如果你的sdf是个static的, 那么多个thread 之间就会共享这个sdf, 同时也是共享这个Calendar引用, 并且, 观察 sdf.parse() 方法,你会发现有如下的调用：
   1. Date parse() {
   2.   calendar.clear(); // 清理calendar
   3.   ... // 执行一些操作, 设置 calendar 的日期什么的
   4.   calendar.getTime(); // 获取calendar的时间
   5. }
4. 这里会导致的问题就是：如果 线程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

上边是复杂的具体的原因，而这个原因简单说就是，在线程中调用了一个static对象，这个对象存储值的变量被多个线程同时使用（修改），造成了混乱