几乎所有使用 AWT 或 Swing 编写的画图程序都需要多线程
但多线程程序会造成许多困难
刚开始编程的开发者常常会发现他们被一些问题所折磨
例如不正确的程序行为或死锁
在本文中我们将探讨使用多线程时遇到的问题并提出那些常见陷阱的解决方案
线程是什么？
一个程序或进程能够包含多个线程这些线程可以根据程序的代码执行相应的指令多线程看上去似乎在并行执行它们各自的工作就像在一台计算机上运行着多个处理机一样在多处理机计算机上实现多线程时它们确实可以并行工作和进程不同的是线程共享地址空间也就是说多个线程能够读写相同的变量或数据结构
编写多线程程序时你必须注意每个线程是否干扰了其他线程的工作可以将程序看作一个办公室如果不需要共享办公室资源或与其他人交流所有职员就会独立并行地工作某个职员若要和其他人交谈当且仅当该职员在听且他们两说同样的语言此外只有在复印机空闲且处于可用状态（没有仅完成一半的复印工作没有纸张阻塞等问题）时职员才能够使用它在这篇文章中你将看到在 Java 程序中互相协作的线程就好像是在一个组织良好的机构中工作的职员
在多线程程序中线程可以从准备就绪队列中得到并在可获得的系统 CPU 上运行操作系统可以将线程从处理器移到准备就绪队列或阻塞队列中这种情况可以认为是处理器挂起了该线程同样Java 虚拟机 （JVM） 也可以控制线程的移动在协作或抢先模型中从准备就绪队列中将进程移到处理器中于是该线程就可以开始执行它的程序代码
协作式线程模型允许线程自己决定什么时候放弃处理器来等待其他的线程程序开发员可以精确地决定某个线程何时会被其他线程挂起允许它们与对方有效地合作缺点在于某些恶意或是写得不好的线程会消耗所有可获得的 CPU 时间导致其他线程饑饿
在抢占式线程模型中操作系统可以在任何时候打断线程通常会在它运行了一段时间（就是所谓的一个时间片）后才打断它这样的结果自然是没有线程能够不公平地长时间霸占处理器然而随时可能打断线程就会给程序开发员带来其他麻烦同样使用办公室的例子假设某个职员抢在另一人前使用复印机但打印工作在未完成的时候离开了另一人接着使用复印机时该复印机上可能就还有先前那名职员留下来的资料抢占式线程模型要求线程正确共享资源协作式模型却要求线程共享执行时间由于 JVM 规范并没有特别规定线程模型Java 开发员必须编写可在两种模型上正确运行的程序在了解线程以及线程间通讯的一些方面之后我们可以看到如何为这两种模型设计程序
线程和 Java 语言
为了使用 Java 语言创建线程你可以生成一个 Thread 类（或其子类）的对象并给这个对象发送 start（） 消息（程序可以向任何一个派生自 Runnable 接口的类对象发送 start（） 消息）每个线程动作的定义包含在该线程对象的 run（） 方法中run 方法就相当于传统程序中的 main（） 方法线程会持续运行直到 run（） 返回为止此时该线程便死了
上锁
大多数应用程序要求线程互相通信来同步它们的动作在 Java 程序中最简单实现同步的方法就是上锁为了防止同时访问共享资源线程在使用资源的前后可以给该资源上锁和开锁假想给复印机上锁任一时刻只有一个职员拥有钥匙若没有钥匙就不能使用复印机给共享变量上锁就使得 Java 线程能够快速方便地通信和同步某个线程若给一个对象上了锁就可以知道没有其他线程能够访问该对象即使在抢占式模型中其他线程也不能够访问此对象直到上锁的线程被唤醒完成工作并开锁那些试图访问一个上锁对象的线程通常会进入睡眠状态直到上锁的线程开锁一旦锁被打开这些睡眠进程就会被唤醒并移到准备就绪队列中
在 Java 编程中所有的对象都有锁线程可以使用 synchronized 关键字来获得锁在任一时刻对于给定的类的实例方法或同步的代码块只能被一个线程执行这是因为代码在执行之前要求获得对象的锁继续我们关于复印机的比喻为了避免复印沖突我们可以简单地对复印资源实行同步如同下列的代码例子任一时刻只允许一位职员使用复印资源通过使用方法（在 Copier 对象中）来修改复印机状态这个方法就是同步方法只有一个线程能够执行一个 Copier 对象中同步代码因此那些需要使用 Copier 对象的职员就必须排队等候
class CopyMachine {
public synchronized void makeCopies（Document d int nCopies） {
// only one thread executes this at a time
}
public void loadPaper（） {
// multiple threads could access this at once!
synchronized（this） {
// only one thread accesses this at a time
// feel free to use shared resources overwrite members etc
}
}
}
Finegrain 锁
在对象级使用锁通常是一种比较粗糙的方法为什么要将整个对象都上锁而不允许其他线程短暂地使用对象中其他同步方法来访问共享资源？如果一个对象拥有多个资源就不需要只为了让一个线程使用其中一部分资源就将所有线程都锁在外面由于每个对象都有锁可以如下所示使用虚拟对象来上锁
class FineGrainLock {
MyMemberClass x y;
Object xlock = new Object（） ylock = new Object（）
public void foo（） {
synchronized（xlock） {
// access x here
}
// do something here but dont use shared resources
synchronized（ylock） {
// access y here
}
}
public void bar（） {
synchronized（this） {
// access both x and y here
}
// do something here but dont use shared resources
}
}
若为了在方法级上同步不能将整个方法声明为 synchronized 关键字它们使用的是成员锁而不是 synchronized 方法能够获得的对象级锁
信号量
通常情况下可能有多个线程需要访问数目很少的资源假想在服务器上运行着若干个回答客户端请求的线程这些线程需要连接到同一数据库但任一时刻只能获得一定数目的数据库连接你要怎样才能够有效地将这些固定数目的数据库连接分配给大量的线程？一种控制访问一组资源的方法（除了简单地上锁之外）就是使用众所周知的信号量计数 （counting semaphore）信号量计数将一组可获得资源的管理封装起来信号量是在简单上锁的基础上实现的相当于能令线程安全执行并初始化为可用资源个数的计数器例如我们可以将一个信号量初始化为可获得的数据库连接个数一旦某个线程获得了信号量可获得的数据库连接数减一线程消耗完资源并释放该资源时计数器就会加一当信号量控制的所有资源都已被占用时若有线程试图访问此信号量则会进入阻塞状态直到有可用资源被释放
信号量最常见的用法是解决消费者生产者问题当一个线程进行工作时若另外一个线程访问同一共享变量就可能产生此问题消费者线程只能在生产者线程完成生产后才能够访问数据使用信号量来解决这个问题就需要创建一个初始化为零的信号量从而让消费者线程访问此信号量时发生阻塞每当完成单位工作时生产者线程就会向该信号量发信号（释放资源）每当消费者线程消费了单位生产结果并需要新的数据单元时它就会试图再次获取信号量因此信号量的值就总是等于生产完毕可供消费的数据单元数这种方法比采用消费者线程不停检查是否有可用数据单元的方法要高效得多因为消费者线程醒来后倘若没有找到可用的数据单元就会再度进入睡眠状态这样的操作系统开销是非常昂贵的
尽管信号量并未直接被 Java 语言所支持却很容易在给对象上锁的基础上实现一个简单的实现方法如下所示
class Semaphore {
private int count;
public Semaphore（int n） {
unt = n;
}
public synchronized void acquire（） {
while（count == ） {
try {
wait（）
} catch （InterruptedException e） {
// keep trying
}
}
count;
}
public synchronized void release（） {
count++;
notify（） // alert a thread thats blocking on this semaphore
}
}
常见的上锁问题
不幸的是使用上锁会带来其他问题让我们来看一些常见问题以及相应的解决方法
死锁死锁是一个经典的多线程问题因为不同的线程都在等待那些根本不可能被释放的锁从而导致所有的工作都无法完成假设有两个线程分别代表两个饑饿的人他们必须共享刀叉并轮流吃饭他们都需要获得两个锁共享刀和共享叉的锁假如线程 A 获得了刀而线程 B 获得了叉线程 A 就会进入阻塞状态来等待获得叉而线程 B 则阻塞来等待 A 所拥有的刀这只是人为设计的例子但尽管在运行时很难探测到这类情况却时常发生虽然要探测或推敲各种情况是非常困难的但只要按照下面几条规则去设计系统就能够避免死锁问题
让所有的线程按照同样的顺序获得一组锁这种方法消除了 X 和 Y 的拥有者分别等待对方的资源的问题
将多个锁组成一组并放到同一个锁下前面死锁的例子中可以创建一个银器对象的锁于是在获得刀或叉之前都必须获得这个银器的锁
将那些不会阻塞的可获得资源用变量标志出来当某个线程获得银器对象的锁时就可以通过检查变量来判断是否整个银器集合中的对象锁都可获得如果是它就可以获得相关的锁否则就要释放掉银器这个锁并稍后再尝试
最重要的是在编写代码前认真仔细地设计整个系统多线程是困难的在开始编程之前详细设计系统能够帮助你避免难以发现死锁的问题
Volatile 变量 volatile 关键字是 Java 语言为优化编译器设计的以下面的代码为例
class VolatileTest {
public void foo（） {
boolean flag = false;
if（flag） {
// this could happen
}
}
}
一个优化的编译器可能会判断出 if 部分的语句永远不会被执行就根本不会编译这部分的代码如果这个类被多线程访问flag 被前面某个线程设置之后在它被 if 语句测试之前可以被其他线程重新设置用 volatile 关键字来声明变量就可以告诉编译器在编译的时候不需要通过预测变量值来优化这部分的代码
无法访问的线程 有时候虽然获取对象锁没有问题线程依然有可能进入阻塞状态在 Java 编程中 IO 就是这类问题最好的例子当线程因为对象内的 IO 调用而阻塞时此对象应当仍能被其他线程访问该对象通常有责任取消这个阻塞的 IO 操作造成阻塞调用的线程常常会令同步任务失败如果该对象的其他方法也是同步的当线程被阻塞时此对象也就相当于被冷冻住了其他的线程由于不能获得对象的锁就不能给此对象发消息（例如取消 IO 操作）必须确保不在同步代码中包含那些阻塞调用或确认在一个用同步阻塞代码的对象中存在非同步方法尽管这种方法需要花费一些注意力来保证结果代码安全运行但它允许在拥有对象的线程发生阻塞后该对象仍能够响应其他线程
为不同的线程模型进行设计
判断是抢占式还是协作式的线程模型取决于虚拟机的实现者并根据各种实现而不同因此Java 开发员必须编写那些能够在两种模型上工作的程序
正如前面所提到的在抢占式模型中线程可以在代码的任何一个部分的中间被打断除非那是一个原子操作代码块原子操作代码块中的代码段一旦开始执行就要在该线程被换出处理器之前执行完毕在 Java 编程中分配一个小于 位的变量空间是一种原子操作而此外象 double 和 long 这两个 位数据类型的分配就不是原子的使用锁来正确同步共享资源的访问就足以保证一个多线程程序在抢占式模型下正确工作
而在协作式模型中是否能保证线程正常放弃处理器不掠夺其他线程的执行时间则完全取决于程序员调用 yield（） 方法能够将当前的线程从处理器中移出到准备就绪队列中另一个方法则是调用 sleep（） 方法使线程放弃处理器并且在 sleep 方法中指定的时间间隔内睡眠
正如你所想的那样将这些方法随意放在代码的某个地方并不能够保证正常工作如果线程正拥有一个锁（因为它在一个同步方法或代码块中）则当它调用 yield（） 时不能够释放这个锁这就意味着即使这个线程已经被挂起等待这个锁释放的其他线程依然不能继续运行为了缓解这个问题最好不在同步方法中调用 yield 方法将那些需要同步的代码包在一个同步块中里面不含有非同步的方法并且在这些同步代码块之外才调用 yield
另外一个解决方法则是调用 wait（） 方法使处理器放弃它当前拥有的对象的锁如果对象在方法级别上使同步的这种方法能够很好的工作因为它仅仅使用了一个锁如果它使用 finegrained 锁则 wait（） 将无法放弃这些锁此外一个因为调用 wait（） 方法而阻塞的线程只有当其他线程调用 notifyAll（） 时才会被唤醒
线程和AWT/Swing
在那些使用 Swing 和/或 AWT 包创建 GUI （用户图形界面）的 Java 程序中AWT 事件句柄在它自己的线程中运行开发员必须注意避免将这些 GUI 线程与较耗时间的计算工作绑在一起因为这些线程必须负责处理用户时间并重绘用户图形界面换句话来说一旦 GUI 线程处于繁忙整个程序看起来就象无响应状态Swing 线程通过调用合适方法通知那些 Swing callback （例如 Mouse Listener 和 Action Listener ） 这种方法意味着 listener 无论要做多少事情都应当利用 listener callback 方法产生其他线程来完成此项工作目的便在于让 listener callback 更快速返回从而允许 Swing 线程响应其他事件
如果一个 Swing 线程不能够同步运行响应事件并重绘输出那怎么能够让其他的线程安全地修改 Swing 的状态？正如上面提到的Swing callback 在 Swing 线程中运行因此他们能修改 Swing 数据并绘到屏幕上
但是如果不是 Swing callback 产生的变化该怎么办呢？使用一个非 Swing 线程来修改 Swing 数据是不安全的Swing 提供了两个方法来解决这个问题invokeLater（） 和 invokeAndWait（）为了修改 Swing 状态只要简单地调用其中一个方法让 Runnable 的对象来做这些工作因为 Runnable 对象通常就是它们自身的线程你可能会认为这些对象会作为线程来执行但那样做其实也是不安全的事实上Swing 会将这些对象放到队列中并在将来某个时刻执行它的 run 方法这样才能够安全修改 Swing 状态
总结
Java 语言的设计使得多线程对几乎所有的 Applet 都是必要的特别是IO 和 GUI 编程都需要多线程来为用户提供完美的体验如果依照本文所提到的若干基本规则并在开始编程前仔细设计系统包括它对共享资源的访问等你就可以避免许多常见和难以发觉的线程陷阱
