Java并发框架：AbstractQueuedSynchronizer深入解析

需积分: 9 24 浏览量更新于2024-07-15 收藏 504KB PDF 举报

"这篇PDF论文是《The java.util.concurrent synchronizer framework》由Doug Lea撰写，详细探讨了Java并发包中的同步器框架，特别是基于AbstractQueuedSynchronizer（AQS）的机制。该框架用于原子性地管理同步状态，阻塞和唤醒线程，并处理队列操作。论文涵盖了设计思路、实现细节、使用方法以及性能分析。" 正文: Java的并发编程在J2SE 5.0版本中引入了一个重要的工具包——java.util.concurrent，它包含了一系列中等级别的并发支持类，这些类是通过Java Community Process (JCP)的Java Specification Request (JSR) 166创建的。在这个包中，最引人注目的是同步器——一种抽象数据类型（ADT）的类，它们内部维护了同步状态。 Doug Lea的这篇论文深入剖析了这个同步器框架，其中核心是AbstractQueuedSynchronizer（AQS）。AQS是一个基础组件，它提供了一种通用的方法来原子化地管理同步状态。这意味着线程在访问共享资源时，能够保证在并发环境下的正确性，避免数据竞争。AQS通过内部的队列管理等待的线程，当资源可用时，能够有效地唤醒并调度这些线程。论文首先介绍了引入AQS的背景和动机，即在并发编程中对高效、灵活且可扩展的同步机制的需求。然后，它详细阐述了AQS的设计理念，包括其如何使用一个整型变量来表示同步状态，以及如何利用CAS（Compare and Swap）原语来无锁地更新这个状态。在实现部分，论文讨论了AQS如何维护一个FIFO（先进先出）等待队列，这个队列由等待获取锁或者等待条件满足的线程组成。线程在被阻塞时会被添加到队列中，当它们的同步条件满足时，会从队列中移除并恢复执行。此外，AQS还提供了适配器方法，使得开发者可以轻松地构建自定义的同步器，如锁和屏障。论文的使用部分给出了如何基于AQS创建自定义同步器的指导，包括如何继承AQS并重写必要的方法来定义特定的同步行为。同时，它也提醒开发者注意正确地处理中断和超时等异常情况。最后，论文对AQS框架的性能进行了分析，这部分可能包括基准测试和实际应用的性能比较。通过这些测试，我们可以理解在不同工作负载下AQS的效率和响应时间，这对于优化并发应用程序的性能至关重要。这篇论文对于理解Java并发包中的同步机制，特别是AQS的工作原理及其在实际开发中的应用，具有极高的价值。它不仅提供了理论知识，还给出了实践经验，对于任何想要深入学习Java并发编程的开发者来说，都是一份宝贵的参考资料。

296 D. Lea / Science of Computer Programming 58 (2005) 293–309

Support for these operations requires the coordination of three basic components: (1)

Atomically managing synchronization state; (2) Blocking and unblocking threads; and

(3) Maintaining queues. It might be possible to create a framework that allows each of

these three pieces to vary independently. However, this would neither be very efﬁcient

nor usable. For example, the information kept in queue nodes must mesh with that

needed for unblocking, and the signatures of exported methods depend on the nature of

synchronization state.

The central design decision in the synchronizer framework was to choose a concrete

implementation of each of these three components, while still permitting a wide range of

options in how they are used. This intentionally limits the range of applicability, but pro-

vides efﬁcient enough support that there is practically never a reason not to use the frame-

work (and instead build synchronizers from scratch) in those cases where it does apply.

3.1. Synchronization state

Class AbstractQueuedSynchronizer maintains synchronization state using only a

single (32-bit) int,and exports getState, setState,andcompareAndSetState operations

to access and update this state. These methods in turn rely on java.util.concurrent.atomic

support providing JSR133 (Java Memory Model [10]) compliant volatile semantics on

reads and writes, and access to native compare-and-swap or load-linked/store-conditional

instructions to implement compareAndSetState,thatatomically sets state to a given new

value only if it holds a given expected value.

Restricting synchronizationstate to a 32-bit int was a pragmatic decision. While JSR166

also provides atomic operations on 64-bit long ﬁelds, these must still be emulated using

internal locks on enough platforms that the resulting synchronizerswould not perform well.

In the future, it seems likely that a second base class, specialized for use with 64-bit state

(i.e., with long control arguments), will be added. However, there is not now a compelling

reason to include it in the package. Currently, 32 bits sufﬁce for most applications. Only

one java.util.concurrent synchronizer class, CyclicBarrier,would require more bits to

maintain state, so instead uses locks (as do most higher-level utilities in the package).

Concrete classes based on AbstractQueuedSynchronizer must deﬁne methods

tryAcquire and tryRelease in terms of these exported state methods in order to control the

acquire and release operations.The tryAcquire method must return true if synchronization

was acquired, and the tryRelease method must return true if the new synchronization

state may allow future acquires. These methods accept a single int argument that can be

used to communicate desired state; for example in a re-entrant lock, to re-establish the

recursion count when re-acquiring the lock after returning from a condition wait. Many

synchronizers do not need such an argument, and so just ignore it.

3.2. Blocking

Until JSR166, there was no Java API available to block and unblock threads for

purposes of creating synchronizers that are not based on built-in monitors. The only

candidates were Thread.suspend and Thread.resume,which are unusable because they

encounter an unsolvable race problem: If an unblocking thread invokes resume before the

blocking thread has executed suspend,theresume operation will have no effect.

剩余16页未读，继续阅读

E_N_T_J

粉丝: 18
资源: 3

Java并发框架：AbstractQueuedSynchronizer深入解析

The java.util.concurrent Synchronizer Framework

The java.util.concurrent synchronizer framework.pdf

import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock; import java.util.regex.Matcher; 这段代码的意思

java import java.util.concurrent.BlockingQueue; 这句错误The import java.util.concurrent.BlockingQueue cannot be resolved

java.util.concurrent.rejectedexecutionexception: task java.util.concurrent.f

最新资源