要编写线程安全的代码,其核心在于要对状态访问操作进行管理,特别是对共享的(Shared)和可变的(Mutable)状态的访问。
一个对象是否需要是线程安全的,取决于它是否被多个线程访问。这指的是在程序中访问对象的方式,而不是对象要实现的功能。**要使得对象是线程安全的,需要采用同步机制来协同对对象可变状态的访问。**如果无法实现协同,那么可能会导致数据破坏以及其他不该出现的结果。
当多个线程访问某个状态变量并且其中有一个线程执行写入操作时,必须采用同步机制来协同这些线程对变量的访问。
Java中的主要同步机制是关键字synchronized,它提供了一种独占的加锁方式。但“同步”这个术语还包括volatile类型的变量,显示锁(Explicit Lock)以及原子变量。
如果当多个线程访问同一个可变的状态变量时没有合适的同步,那么程序就会出现错误。有三种方式可以修复这个问题:
- 不在线程之间共享该状态变量
- 将状态变量修改为不可变的变量
- 在访问状态变量时使用同步
在任何情况中,只有当类中仅包含自己的状态时,线程安全类才是有意义的。
2.1什么是线程安全性
线程安全性:当多个线程访问某个类时,这个类始终都能表现出正确的行为,那么就称这个类是线程安全的。
由于单线程也可以看成是一个多线程程序,如果某个类在单线程环境中都不是正确的,那么它肯定不会是线程安全的。
来看一个Servlet从请求中提取出数值,执行因数分解,然后将结果封装到Servlet的响应中。
@ThreadSafe
public class StatelessFactorizer implements Servlet{
public void service(ServletRequest req, ServletResponse resp){
//从request域中拿到这个数据
BigInteger i = extractFromRequest(req);
//将这个数字因式分解,结果保存在factors数组中
BigInteger[] factors = factor(i);
encodeIntoResponse(resp,factors);
}
}
与大多数Servlet相同,StatelessFactorizer是无状态的:它既不包含任何域,也不包含任何对其他类中域的引用。
计算过程中的临时状态仅存在于线程栈上的局部变量中,并且只能由正在执行的线程访问。
访问StatelessFactorizer的线程不会影响另一个访问同一个StatelessFactorizer的线程的计算结果,因为这两个线程并没有共享状态,就好像它们都在访问不同的实例。
由于线程访问无状态对象的行为并不会影响其他线程中操作的正确性,因此无状态对象是线程安全的。
无状态对一定是线程安全的。
大多数Servlet都是无状态的,从而极大地降低了在实现Servlet线程安全性时的复杂性。只有当Servlet在处理请求时需要保存一些信息,线程安全性才会成为一个问题。
2.2 原子性
假设我们希望增加一个“命中计数器(Hit Counter)”来统计所处理的请求数量。
@NotThreadSafe
public class UnsafeCountingFactorizer implements Servlet{
private long count = 0 ;
public long getCount() { return count; }
public void service(ServletRequest req, ServletResponse resp){
//从request域中拿到这个数据
BigInteger i = extractFromRequest(req);
//将这个数字因式分解,结果保存在factors数组中
BigInteger[] factors = factor(i);
++count;
encodeIntoResponse(resp,factors);
}
}
UnsafeCountingFactorizer这个类并非线程安全。
虽然递增操作++count是一种紧凑的语法,使其看上去只是一个操作,但这个操作并非原子的,因而它并不会作为一个不可分割的操作来执行。
实际上,它包含了三个独立的操作:读取count的值,将值加1,然后将计算结果写入count。这是一个“读取-修改-写入”的操作序列,并且其结果状态依赖于之前的状态。
在并发编程中,这种由于不恰当的执行时序而出现不正确的结果是一种非常重要的情况,它有一个正式的名字:竞态条件(Race Condition)。
2.2.1竞态条件
在UnsafeCountingFactorizer中在存多个竞态条件,从而使结果变得不可靠。当某个计算的正确性取决于多个线程的交替执行时序时,那么就会发生竞态条件。最常见的竞态条件类型就是“先检查后执行(Check-Then-Act)”操作,即通过一个可能失效的观测结果来决定下一步的动作。
2.2.2 示例:延迟初始化中的竞态条件
使用“先检查后执行”的一种常见情况就是延迟初始化。延迟初始化的目的就是将对象的初始化操作推迟到实际被使用时才进行,同时要确保只被初始化一次。
@NotThreadSafe
public class LazyInitRace{
private ExpensiveObject instance = null;
public ExpensiveObject getInstance(){
if(instance == null){
instance = new ExpensiveObject();
}
return instance;
}
}
以上代码LazyInitRace类便说明了这种延迟初始化情况。当然依然存在竞态条件:可能两个线程都判断instacne==null然后得到的两个instance就不一致。
2.2.3复合操作
UnsafeCountingFactorizer和LazyInitRace都包含一组需要以原子方式执行(或者说不可分割)的操作。
要避免竞态条件问题,就必须在某个线程修改该变量时,通过某种方式防止其他线程使用这个变量,从而确保其他线程只能在修改操作完成之前或之后读取和修改状态,而不是在修改状态的过程中。
原子操作是指,对于访问同一个状态的所有操作(包括该操作本身)来说,这个操作是一个以原子方式执行的操作。
为了确保线程安全性,“先检查后执行”(例如延迟初始化)和“读取-修改-写入”(例如递增运算)等操作必须是原子的。
我们将“先检查后执行”(例如延迟初始化)和“读取-修改-写入”(例如递增运算)等操作统称为复合操作:包含了一组必须以原子方式执行的操作以确保线程安全性。
之后的2.3节,将介绍加锁机制,这是Java中用于确保原子性的内置机制。就目前而言,我们先采用另一种方式来修复这个问题,即使用一个现有的线程安全类。
@ThreadSafe
public class CountingFactorizer implements Servlet{
private final AtomicLong count = new AtomicLong(0);
public long getCount(){ return count.get(); }
public void service(ServletRequest req, ServletResponse resp){
BigInteger i = extractFromRequest(req);
BigInteger[] factors = factor(i);
count.incrementAndGet();
encodeIntoResponse(resp, factors);
}
}
在java.util.concurrent.atomic包中包含了一些原子变量类,用于实现在数值和对象引用上的原子状态转换。**通过用AtomicLong来代替long类型的计数器,能够确保所有对计数器状态的访问操作都是原子的。**由于Servlet的状态就是计数器的状态,并且计数器是线程安全的,因此这里的Servlet也是线程安全的。
我们再因数分解的Servlet中增加了一个计数器,并通过使用线程安全类AtomicLong来管理计数器的状态,从而确保了代码的线程安全性。
当在无状态的类中添加一个状态时,如果该状态完全由线程安全的对象来管理,那么这个类仍然是线程安全的。
然而,在2.3节中你将看到当状态变量的数量由一个变为多个时,并不会像状态变量由零个变为一个那样简单。
在实际情况中,应尽可能地使用现有的线程安全对象(例如AcomicLong)来管理类的状态。与非线程安全的对象相比,判断线程安全对象的可能状态及其状态转换情况更为容易,从而也更容易维护和验证线程安全性。
2.3加锁机制
当在Servlet中添加一个状态变量时,可以通过线程安全的对象来管理Servlet的状态以维护Servlet的线程安全性。但如果想在Servlet中添加更多的状态,那么是否只需要添加更多的线程安全状态变量就足够了?
假设我们希望提升Servlet的性能:将最近的计算结果缓存起来,当两个连续的请求对相同的数值进行因数分解时,可以直接使用上一次的计算结果,而无须重新计算。(这并非一种有效的缓存策略,5.6节将给出一种更好的策略。)要实现该缓存策略,需要保存两个状态:最近执行因数分解的数值,以及分解结果。
@NotThreadSafe
public class UnsafeCachingFactorizer implements Servlet {
//上一次的数
private final AtomicReference<BigInteger> lastNumber
= new AtomicReference<BigInteger>();
//上一次的数的因数分解的结果
private final AtomicReference<BigInteger[]> lastFactors
= new AtomicReference<BigInteger[]>();
public void service(ServletRequest req, ServletResponse resp){
BigInteger i = extractFromRequest(req);
if(i.equals(lastNumber.get())){
encodeIntoResponse(resp, lastFactors.get());
}else{
BigInteger[] factors = factor(i);
lastNumber.set(i);
lastFactors.set(factors);
encodeIntoResponse(resp,factors);
}
}
}
然而,这种方法并不正确,尽管这些原子引用本身都是线程安全的,但在UnsafeCachingFactorizer中存在着竞态条件,这可能产生错误的结果。
2.3.1内置锁
Java提供了一种内置的锁机制来支持原子性:同步代码块(Synchronized)。
同步代码块包括两部分:
- 一个是作为锁的对象引用
- 一个作为由这个锁保护的代码块
以关键字synchronized来修饰的方法就是一种横跨整个方法体的同步代码块,其中该同步代码块的锁就是方法调用所在的对象。静态的synchronized方法以Class对象作为锁。
synchronized{
//访问或修改由锁保护的共享状态
}
每个Java对象都可以用做一个实现同步的锁,这些锁被称为内置锁(Intrinsic Lock)或监视器锁(Monitor Lock)。线程在进入同步代码块前会自动获得锁,并且在退出同步代码块时自动释放锁,而无论是通过正常的控制路径退出,还是通过从代码块中抛出异常退出。获得内置锁的唯一途径就是进入由这个锁保护的同步代码块或方法。
==Java的内置锁相于一种互斥体(或互斥锁),这意味着最多只有一个线程能持有这种锁。==当线程A尝试获取一个由线程B持有的锁时,线程A必须等待或者阻塞,直到线程B释放这个锁。如果B永远不释放锁,那么A也将永远地等下去。
这种同步机制使得要确保因数分解Servlet的线程安全性变得更简单。
@ThreadSafe
public class SynchronizedFactorizer implements Servlet{
@GuardedBy("this") private BigInteger lastNumber;
@GuardedBy("this") private BigInteger[] lastFactors;
public synchronized void service(ServletRequest req,
ServletResponse resp){
BigInteger i = extractFromRequest(req);
if(i.equals(lastNumber)){
encodeIntoResponse(resp,lastFactors);
}else{
BigInteger[] factors = factor(i);
lastNumber = i;
lastFactors = factors;
encodeIntoResponse(resp,factors);
}
}
}
2.3.2 重入
当某个线程请求一个由其他线程持有的锁时,发出请求的线程就会阻塞。然而,由于内置锁是可重入的,因此如果某个线程试图获得一个已经由它自己持有的锁,那么这个请求就会成功。
“重入”意味着获取锁的操作的粒度是“线程”,而不是“调用”。
重入的一种实现方法是,为每个锁关联一个获取计数值和一个所有者线程。当计数值为0时,这个锁就被认为是没有被任何线程持有。当线程请求一个未被持有的锁时,计数值将递增,而当线程退出同步代码块时,计数器会相应地递减。当计数值为0时,这个锁将被释放。
public class Widget{
public synchronized void doSomething(){
...
}
}
public class LoggingWidget extends Widget{
public synchronized void doSomething(){
System.out.println(toString() + ": calling doSomething");
super.doSomething();
}
}
如上代码,子类改写了父类的synchronized方法,然后调用父类中的方法,此时如果没有可重入的锁,那么这段代码将产生死锁。
2.4用锁来保护状态
由于锁能使其保护代码路径以串行形式来访问,因此可以通过锁来构造一些协议以实现对共享状态的独占访问。
然而,仅仅将复合操作封装到一个同步代码块中不够的。
如果用同步来协调对某个变量的访问,那么在访问这个变量的所有位置上都需要使用同步。而且,当使用锁来协调对某个变量的访问时,在访问变量的所有位置上都要使用同一个锁。
每个共享的和可变的变量都应该只由一个锁来保护,从而使维护人员知道是哪一个锁。
一种常见的加锁约定是,将所有的可变状态都封装在对象内部,并通过对象的内置锁对所有访问可变状态的代码路径进行同步,使得在该对象上不会发生并发访问。
在许多线程安全类中都使用了这种模式,例如Vector和其他的同步集合类。
2.5活跃性与性能
在UnsafeCachingFactorizer中,我们通过再因数分解Servlet中引入了缓存机制来提升性能。在缓存中需要使用共享状态,因此需要通过同步来维护状态的完成性。然而,如果使用SynchronizedFactorizer中的同步方式,那么代码的执行性能将非常糟糕。
由于service是一个synchronized方法,因此每次只有一个线程可以执行。这就违背了Servlet框架的初衷,即Servlet需要能同时处理多个请求。
@ThreadSafe
public class CachedFactorizer implements Servlet{
//@GuardedBy("this")意味着被内置锁保护
@GuardedBy("this") private BigInteger lastNumber;
@GuardedBy("this") private BigInteger[] lastFactors;
//命中计数器
@GuardedBy("this") private long hits;
//"缓存命中计数器"
@GuardedBy("this") private long cacheHits;
//这计数器也是共享可变状态的一部分,因此必须在所有访问它们的位置同步
public synchronized long getHits(){ return hists; }
public synchronized double getCacheHitRatio(){
return (double) cacheHits / (double) hits;
}
public void service(ServletRequest req, ServletResponse resp){
BigInteger i = extractFromRequest(req);
BigInteger[] factors = null;
synchronized(this){
++hits;
if(i.equals(lastNumber)){
++cacheHits;
factors = lastFactors.clone();
}
}
if(factors == null){
factors = factor(i);
synchronized(this){
lastNumber = i;
lastFactors = factors.clone();
}
}
encodeIntoResponse(resp, factors);
}
}
当执行时间较长的计算或者可能无法快速完成的操作时(例如,网络I/O或控制台I/O),一定不要持有锁。