- 如果一个共享资源被多个线程同时访问,可能会遭到破坏。举个例子说明这个问题,假设创建并启动100个线程,每个线程都往同一个账户中添加一个便士,代码如下:
1 import java.util.concurrent.ExecutorService; 2 import java.util.concurrent.Executors; 3 4 public class AccountWithSync { 5 6 private static Account account = new Account(); 7 8 public static void main(String[] args) { 9 ExecutorService executor = Executors.newCachedThreadPool(); 10 11 //用线程池executor创建并启动100个线程 12 for(int i=0; i<100; i++) { 13 executor.execute(new AddAPennyTask()); 14 } 15 16 executor.shutdown(); 17 18 //线程全部结束前执行此循环 19 while(!executor.isTerminated()) { 20 } 21 22 System.out.println("What is balance?" + account.getBalance()); 23 } 24 25 private static class AddAPennyTask implements Runnable { 26 @Override 27 public void run() { 28 account.deposit(1); 29 } 30 } 31 32 private static class Account { 33 private int balance = 0; //账户余额 34 35 public int getBalance() { 36 return balance; 37 } 38 39 public void deposit(int amount) { 40 int newBalance = balance + amount; 41 42 //设置这种延迟是为了加大数据的破坏程度让结果更加明显 43 try { 44 Thread.sleep(5); 45 } catch (InterruptedException e) { 46 } 47 48 balance = newBalance; 49 } 50 } 51 }
该账户中的初始余额为0,当所有线程都结束时,余额应该为100,但是运行上面程序得到的结果却是不可预测的,如下图所示。它演示了当所有线程同时访问同一个数据时,就会出现数据破坏的问题。
那么,究竟是什么导致了程序的错误?下面给出一个可能的情况。
步骤 | 余额 | 任务1 | 任务2 |
---|---|---|---|
1 | 0 | newBalance = balance + 1; | |
2 | 0 | newBalance = balance + 1; | |
3 | 1 | balance = newBalance; | |
4 | 1 | balance = newBalance; |
在步骤1中,任务1从账户中获取余额数目。在步骤2中,任务2从账户中获取同样数目的余额。在步骤3中,任务1向账户写入一个新余额。在步骤4中任务2也向该账户写入一个新余额。这就导致任务1什么也没做,因为任务2覆盖了任务1的结果。
这是多线程程序中一个普遍的问题,称为竞争状态。如果一个类的对象在多线程程序中没有导致竞争状态,则称这样的类为线程安全的。
- 为了解决上面的问题,应该防止多个线程同时进入程序的某一个特定部分(程序中的这部分称为临界区),也就是将这部分同步化。下面介绍三种解决方法:
1.使用关键字synchronized
通过在程序的deposit方法中添加关键字synchronized,使Account类成为线程安全的,如下:
1 public synchronized void deposit(double amount)
一个同步方法在执行前需要加锁。对于实例方法,要给调用该方法的对象加锁。对于静态方法,要给这个类加锁。如果一个线程调用一个对象上的同步实例方法(静态方法),首先给该对象(类)加锁,然后执行该方法,最后解锁。在解锁之前,另一个调用那个对象(类)中方法的线程将被阻塞,直到解锁。
因为deposit方法被同步化,如果任务1开始进入deposit方法,任务2就会被阻塞,直到任务1完成该方法的运行。
2.利用加锁同步
使用关键字synchronized的代码块在执行前都隐式地需要一个锁。还可以通过显示地加锁解决上面的问题。
一个锁是一个Lock接口的实例,它定义了加锁和释放锁的方法,如下:
1 +lock():void 加锁 2 +unlock():void 释放锁 3 +newCondition():Condition 返回绑定到Lock实例的新的Condition实例
ReentrantLock是为了创建相互排斥的锁的Lock的具体实现。可以创建具有特定的公平策略的锁。真正的公平策略确保等待时间最长的线程首先获得锁。假的公平策略将锁给任意一个在等待的线程。被多个线程访问的使用公正锁的程序,齐整体性能可能比那些使用默认设置的程序差,但是在获取锁且避免资源缺乏时变化很小。
1 +ReentrantLock() 等价于ReentrantLock(false) 2 +ReentrantLock(fair:boolean) 创建具有给定公平策略的锁。当公平性为true时,等待时间最长的线程将获得锁;否则没有特定的获得顺序
使用显示锁修改程序中的Account类如下:
1 private static class Account { 2 private int balance = 0; 3 private static Lock lock = new ReentrantLock(); //创建一个锁 4 5 public int getBalance() { 6 return balance; 7 } 8 9 //使用显示加锁避免竞争状态 10 public void deposit(int amount) { 11 lock.lock(); //获得锁 12 13 try { 14 int newBalance = balance + amount; 15 Thread.sleep(5); 16 balance = newBalance; 17 } catch (InterruptedException e) { 18 }finally { 19 lock.unlock(); //释放锁 20 } 21 } 22 }
在对lock()的调用之后紧随一个try-catch块并且在finally子句中释放这个锁是一个很好的习惯
通常使用synchronized方法或语句比使用排斥的显示锁简单些。然而,使用显示锁对同步具有状态的线程更加直观和灵活。
3.使用信号量
信号量可以用来限制访问共享资源的线程数。在访问资源之前,线程必须从信号量获取许可。在访问完资源之后,这个线程必须将许可返回给信号量。任务一旦获取许可,信号量中可用许可的总数量减1,一旦许可被释放,信号量中许可的总数加1.
1 +Semaphore(numberOfPermits:int) 创建一个带指定数目许可的信号量。公平策略为false 2 +Semaphore(numberOfPermits:int, fair:boolean) 创建一个带指定数目许可和公平策略的信号量 3 +acquire():void 获取这个信号量的许可。如果无许可可用,线程就被锁住直到有可用许可为止 4 +release():void 释放一个许可给该信号量
只有一个许可的信号量可以用来模拟一个相互排斥的锁。修改程序中的Account类,确保同一时间只有一个线程访问deposit方法从而解决了上面的问题,代码如下。
1 private static class Account { 2 private int balance = 0; 3 private static Semaphore semaphore = new Semaphore(1); //创建只有一个许可的信号量 4 5 public int getBalance() { 6 return balance; 7 } 8 9 //使用只有一个许可的信号量避免竞争状态 10 public void deposit(int amount) { 11 try { 12 semaphore.acquire(); // 获得许可 13 14 int newBalance = balance + amount; 15 Thread.sleep(5); 16 balance = newBalance; 17 } catch (InterruptedException e) { 18 } finally { 19 semaphore.release(); //释放许可 20 } 21 } 22 }