十五年前，多处理器系统是高度专用系统，要花费数十万美元（大多数具有 两个到四个处理器）。现在，多处理器系统很便宜，而且数量很多，几乎每个主 要微处理器都内置了多处理支持，其中许多系统支持数十个或数百个处理器。
要使用多处理器系统的功能，通常需要使用多线程构造应用程序。但是正如 任何编写并发应用程序的人可以告诉你的那样，要获得好的硬件利用率，只是简 单地在多个线程中分割工作是不够的，还必须确保线程确实大部分时间都在工作 ，而不是在等待更多的工作，或等待锁定共享数据结构。
问题：线程之间的协调
如果线程之间 不需要协调，那么几乎没有任务可以真正地并行。以线程池为 例，其中执行的任务通常相互独立。如果线程池利用公共工作队列，则从工作队 列中删除元素或向工作队列添加元素的过程必须是线程安全的，并且这意味着要 协调对头、尾或节点间链接指针所进行的访问。正是这种协调导致了所有问题。
标准方法：锁定
在 Java 语言中，协调对共享字段的访问的传统方法是使用同步，确保完成 对共享字段的所有访问，同时具有适当的锁定。通过同步，可以确定（假设类编 写正确）具有保护一组给定变量的锁定的所有线程都将拥有对这些变量的独占访 问权，并且以后其他线程获得该锁定时，将可以看到对这些变量进行的更改。弊 端是如果锁定竞争太厉害（线程常常在其他线程具有锁定时要求获得该锁定）， 会损害吞吐量，因为竞争的同步非常昂贵。（Public Service Announcement： 对于现代 JVM 而言，无竞争的同步现在非常便宜。
基于锁定的算法的另一个问题是：如果延迟具有锁定的线程（因为页面错误 、计划延迟或其他意料之外的延迟），则 没有要求获得该锁定的线程可以继续 运行。
还可以使用可变变量来以比同步更低的成本存储共享变量，但它们有局限性 。虽然可以保证其他变量可以立即看到对可变变量的写入，但无法呈现原子操作 的读-修改-写顺序，这意味着（比如说）可变变量无法用来可靠地实现互斥（互 斥锁定）或计数器。
使用锁定实现计数器和互斥
假如开发线程安全的计数器类，那么这将暴露 get()、 increment() 和 decrement() 操作。清单 1 显示了如何使用锁定（同步）实现该类的例子。注 意所有方法，甚至需要同步 get()，使类成为线程安全的类，从而确保没有任何 更新信息丢失，所有线程都看到计数器的最新值。
清单 1. 同步的计数器类
public class SynchronizedCounter {
private int value;
public synchronized int getValue() { return value; }
public synchronized int increment() { return ++value; }
public synchronized int decrement() { return --value; }
}
increment() 和 decrement() 操作是原子的读-修改-写操作，为了安全实现 计数器，必须使用当前值，并为其添加一个值，或写出新值，所有这些均视为一 项操作，其他线程不能打断它。否则，如果两个线程试图同时执行增加，操作的 不幸交叉将导致计数器只被实现了一次，而不是被实现两次。（注意，通过使值 实例变量成为可变变量并不能可靠地完成这项操作。）
许多并发算法中都显示了原子的读-修改-写组合。清单 2 中的代码实现了简 单的互斥， acquire() 方法也是原子的读-修改-写操作。要获得互斥，必须确 保没有其他人具有该互斥（ curOwner = Thread.currentThread()），然后记录 您拥有该互斥的事实（ curOwner = Thread.currentThread()），所有这些使其 他线程不可能在中间出现以及修改 curOwner field。
清单 2. 同步的互斥类
public class SynchronizedMutex {
private Thread curOwner = null;
public synchronized void acquire() throws InterruptedException {
if (Thread.interrupted()) throw new InterruptedException ();
while (curOwner != null)
wait();
curOwner = Thread.currentThread();
}
public synchronized void release() {
if (curOwner == Thread.currentThread()) {
curOwner = null;
notify();
} else
throw new IllegalStateException("not owner of mutex");
}
}
清单 1 中的计数器类可以可靠地工作，在竞争很小或没有竞争时都可以很好 地执行。然而，在竞争激烈时，这将大大损害性能，因为 JVM 用了更多的时间 来调度线程，管理竞争和等待线程队列，而实际工作（如增加计数器）的时间却 很少。您可以回想 上月专栏中的图，该图显示了一旦多个线程使用同步竞争一 个内置监视器，吞吐量将如何大幅度下降。虽然该专栏说明了新的 ReentrantLock 类如何可以更可伸缩地替代同步，但是对于一些问题，还有更好 的解决方法。