设计线程安全的类
前边我们对线程安全性的分析都停留在一两个可变共享变量的基础上,真实并发程序中可变共享变量会非常多,在出现安全性问题的时候很难准确定位是哪块儿出了问题,而且修复问题的难度也会随着程序规模的扩大而提升(因为在程序的各个位置都可以随便使用可变共享变量,每个操作都可能导致安全性问题的发生)。比方说我们设计了一个这样的类:
public class Increment { private int i; public void increase() { i++; } public int getI() { return i; } }
然后有很多客户端程序员在多线程环境下都使用到了这个类,有的程序员很聪明,他在调用increase方法时使用了适当的同步操作:
public class RightUsageOfIncrement { public static void main(String[] args) { Increment increment = new Increment(); Thread[] threads = new Thread[20]; //创建20个线程 for (int i = 0; i < threads.length; i++) { Thread t = new Thread(new Runnable() { @Override public void run() { for (int i = 0; i < 100000; i++) { synchronized (RightUsageOfIncrement.class) { // 使用Class对象加锁 increment.increase(); } } } }); threads[i] = t; t.start(); } for (int i = 0; i < threads.length; i++) { try { threads[i].join(); } catch (InterruptedException e) { throw new RuntimeException(e); } } System.out.println(increment.getI()); } }
在调用 Increment
的 increas
e方法的时候,使用 RightUsageOfIncrement.class
这个对象作为锁,有效的对 i++
操作进行了同步,的确不错,执行之后的结果是:
可是并不是每个客户端程序员都会这么聪明,有的客户端程序员压根儿不知道啥叫个同步,所以写成了这样:
public class WrongUsageOfIncrement { public static void main(String[] args) { Increment increment = new Increment(); Thread[] threads = new Thread[20]; //创建20个线程 for (int i = 0; i < threads.length; i++) { Thread t = new Thread(new Runnable() { @Override public void run() { for (int i = 0; i < 100000; i++) { increment.increase(); //没有进行有效的同步 } } }); threads[i] = t; t.start(); } for (int i = 0; i < threads.length; i++) { try { threads[i].join(); } catch (InterruptedException e) { throw new RuntimeException(e); } } System.out.println(increment.getI()); } }
没有进行有效同步的执行结果是(每次执行都可能不一样):
其实对于 Increment
这个类的开发者来说,本质上是把对 可变共享变量的必要同步操作转嫁给客户端程序员处理
。有的情况下我们希望自己设计的类可以让客户端程序员们不需要使用额外的同步操作就可以放心的在多线程环境下使用,我们就把这种类成为 线程安全类
。其实就是类库设计者把一些在多线程环境下可能导致安全性问题的操作封装到类里边儿,比如 Increment
的 increase
方法,我们可以写成这样:
public synchronized void increase() { i++; }
也就是说把对可变共享变量 i
可能造成多线程安全性问题的 i++
操作在 Increment
类内就 封装
好,其他人直接调用也不会出现安全性问题。使用封装也是无奈之举: 你无法控制其他人对你的代码调用,风险始终存在,封装使无意中破坏设计约束条件变得更难
。
封装变量访问
设计线程安全类的第一步就是要找出所有的字段,这里的字段包括静态变量也包括成员变量,然后再分析这些字段是否是共享并且可变的。
首先辨别一下字段是否是共享的。由于 我们无法控制客户端程序员以怎样的方式来使用这个类
,所以我们可以通过 访问权限
,也就是 public权限
、 protected权限
、 默认权限
以及 private权限
来控制哪些代码是可以被客户端程序员调用的,哪些是不可以调用的。一般情况下,我们 需要把所有字段都声明为 private 的,把对它们的访问都封装到方法中,对这些方法再进行必要的同步控制
,也就是说我们只暴露给客户端程序员一些可以调用的方法来间接的访问到字段,因为如果直接把字段暴露给客户端程序员的话,我们无法控制客户端程序员如何使用该字段,比如他可以随意的在多线程环境下对字段进行累加操作,从而不能保证把所有同步逻辑都封装到类中。所以如果一个字段是可以通过对外暴露的方法访问到,那这个字段就是共享的。
然后再看一下字段是否是可变的。如果该字段的类型是基本数据类型,可以看一下类所有对外暴露的方法中是否有修改该字段值的操作,如果有,那这个字段就是可变的。如果该字段的类型是非基本数据类型的,那这个字段可变就有两层意思了,第一是在对外暴露的方法中有直接修改引用的操作,第二是在对外暴露的方法中有直接修改该对象中字段的操作。比如一个类长这样:
public class MyObj { private List<String> list; public void m1() { list = new ArrayList<>(); //直接修改字段指向的对象 } public void m2() { list[0] = "aa"; //修改该字段指向对象的字段 } }
代码中的 m1
和 m2
都可以算做是修改字段 list
,如果类暴露的方法中有这两种修改方式中的任意一种,就可以算作这个字段是可变的。
小贴士:是不是把字段声明成final类型,该字段就不可变了呢? 如果该字段是基本数据类型,那声明为final的确可以保证在程序运行过程中不可变,但是如果该字段是非基本数据类型,那么需要让该字段代表的对象中的所有字段都是不可变字段才能保证该final字段不可变。
所以在使用字段的过程中, 应该尽可能的让字段不共享或者不可变
,不共享或者不可变的字段才不会引起安全性问题哈哈。
这让我想起了一句老话:只有死人才不会说话~
确定了哪些字段必须是共享、可变的之后,就要分析在哪些对外暴露的方法中访问了这些字段,我们需要 在所有的访问位置都进行必要的同步处理
,这样才可以保证这个类是一个 线程安全类
。通常,我们会使用 锁
来保证多线程在访问共享可变字段时是串行访问的。
但是 一种常见的错误就是:只有在写入共享可变字段时才需要使用同步
,就像这样:
public class Test { private int i; public int getI() { return i; } public synchronized void setI(int i) { this.i = i; } }
为了使 Test类
变为 线程安全类
,也就是需要保证共享可变字段 i
在所有外界能访问的位置都是线程安全的,而上边 getI
方法可以访问到字段 i
,却没有进行有效的同步处理,由于内存可见性问题的存在,在调用 getI方法
时仍有可能获取的是旧的字段值。所以再次强调一遍: 我们需要在所有的访问位置都进行必要的同步处理
。
还有一点需要强调的是: 如果使用锁来保护共享可变字段的访问的话,对于同一个字段来说,在多个访问位置需要使用同一个锁。
我们知道如果多个线程竞争同一个锁的话,在一个线程获取到锁后其他线程将被阻塞,如果是使用多个锁来保护同一个共享可变字段的话,多个线程并不会在一个线程访问的时候阻塞等待,而是会同时访问这个字段,我们的保护措施就变得无效了。
一般情况下,在一个线程安全类中,我们使用同步方法,也就是使用this对象作为锁来保护字段的访问就OK了~。
虽然面向对象技术封装了安全性,但是打破这种封装也没啥不可以,只不过安全性会更脆弱,增加开发成本和风险。也就是说你把字段声明为public访问权限也没人拦得住你,当然你也可能因为某种性能问题而打破封装,不过对于我们实现业务的人来说,还是建议先使代码正确运行,再考虑提高代码执行速度吧~。
不变性条件
现实中有些字段之间是有实际联系的,比如说下边这个类:
public class SquareGetter { private int numberCache; //数字缓存 private int squareCache; //平方值缓存 public int getSquare(int i) { if (i == numberCache) { return squareCache; } int result = i*i; numberCache = i; squareCache = result; return result; } public int[] getCache() { return new int[] {numberCache, squareCache}; } }
这个类提供了一个很简单的 getSquare
功能,可以获取指定参数的平方值。但是它的实现过程使用了缓存,就是说如果指定参数和缓存的 numberCache
的值一样的话,直接返回缓存的 squareCache
,如果不是的话,计算参数的平方,然后把该参数和计算结果分别缓存到 numberCache
和 squareCache
中。
从上边的描述中我们可以知道, squareCache
不论在任何情况下都是 numberCache
平方值,这就是 SquareGetter
类的一个不变性条件,如果违背了这个 不变性条件
的话,就可能会获得错误的结果。
在单线程环境中, getSquare
方法并不会有什么问题,但是在多线程环境中, numberCache
和 squareCache
都属于共享的可变字段,而 getSquare
方法并没有提供任何同步措施,所以可能造成错误的结果。假设现在 numberCache
的值是2, squareCache
的值是3,一个线程调用 getSquare(3)
,另一个线程调用 getSquare(4)
,这两个线程的一个可能的执行时序是:
两个线程执行过后,最后 numberCache
的值是4,而 squareCache
的值竟然是9,也就意味着 多线程会破坏不变性条件
。为了保持 不变性条件
, 我们需要把保持不变性条件的多个操作定义为一个原子操作,即用锁给保护起来
。
我们可以这样修改getSquare方法的代码:
public synchronized int getSquare(int i) { if (i == numberCache) { return squareCache; } int result = i*i; numberCache = i; squareCache = result; return result; }
但是不要忘了将代码都放在同步代码块是会造成阻塞的, 能不进行同步,就不进行同步
,所以我们修改一下上边的代码:
public int getSquare(int i) { synchronized(this) { if (i == numberCache) { // numberCache字段的读取需要进行同步 return squareCache; } } int result = i*i; //计算过程不需要同步 synchronized(this) { // numberCache和squareCache字段的写入需要进行同步 numberCache = i; squareCache = result; } return result; }
虽然 getSquare
方法同步操作已经做好了,但是别忘了 SquareGetter类
的 getCache方法
也访问了 numberCache
和 squareCache
字段,所以对于每个包含多个字段的不变性条件,其中涉及的所有字段都需要被同一个锁来保护,所以我们再修改一下 getCache方法
:
public synchronized int[] getCache() { return new int[] {numberCache, squareCache}; }
这样修改后的 SquareGetter类
才属于 一个线程安全类
。
使用锁来保护共享可变字段虽然好,但是开销大。使用 volatile
修饰字段来替换掉锁是一种可能的考虑,但是一定要记住 volatile
是不能保证一系列操作的原子性的,所以只有我们的业务场景符合下边这两个情况的话,才可以考虑:
比方说下边的这个类:
public class VolatileDemo { private volatile int i; public int getI() { return i; } public void setI(int i) { this.i = i; } }
VolatileDemo
中的字段 i
并不和其他字段组成不变性条件,而且对于可以访问这个字段的方法 getI
和 setI
来说,并不需要以来i的当前值,所以可以使用 volatile
来修饰字段 i
,而不用在 getI
和 setI
的方法上使用锁。
避免this引用逸出
我们先来看一段代码:
public class ExplicitThisEscape { private final int i; public static ThisEscape INSTANCE; public ThisEscape() { INSTANCE = this; i = 1; } }
在构造方法中就把 this
引用给赋值到了静态变量 INSTANCE
中,而别的线程是可以随时访问 INSTANCE
的, 我们把这种在对象创建完成之前就把this引用赋值给别的线程可以访问的变量的这种情况称为 this引用逸出,这种方式是极其危险的!
,这意味着在 ThisEscape
对象创建完成之前,别的线程就可以通过访问 INSTANCE
来获取到 i字段
的信息,也就是说别的线程可能获取到字段 i
的值为 0
,与我们期望的 final
类型字段值不会改变的结果是相违背的。所以 千万不要在对象构造过程中使this引用逸出
。
上边的 this
引用逸出是通过显式将 this
引用赋值的方式导致逸出的,也可能通过内部类的方式神不知鬼不觉的造成 this
引用逸出:
public class ImplicitThisEscape { private final int i; private Thread t; public ThisEscape() { t = new Thread(new Runnable() { @Override public void run() { // ... 具体的任务 } }); i = 1; } }
虽然在 ImplicitThisEscape
的构造方法中并没有显式的将 this
引用赋值,但是由于 Runnable
内部类的存在,作为外部类的 ImplicitThisEscape
,内部类对象可以轻松的获取到外部类的引用,这种情况下也算 this引用逸出
。
this引用逸
出意味着创建对象的过程是不安全的,在对象尚未创建好的时候别的线程就可以来访问这个对象。虽然我们不确定客户端程序员会怎么使用这个逸出的this引用,但是风险始终存在,所以强烈建议 千万不要在对象构造过程中使this引用逸出
。
总结