Java并发工具包中的同步框架解析

需积分: 9 42 浏览量更新于2024-07-16 收藏 496KB PDF 举报

"这篇文档是Doug Lea撰写的一篇关于java.util.concurrent同步框架的文章，发表在2005年的《Science of Computer Programming》杂志上。文章深入探讨了J2SE 5.0版本中java.util.concurrent包中的同步器（如锁、屏障等）的构建基础——AbstractQueuedSynchronizer（AQS）框架。该框架提供了原子性管理同步状态、阻塞和唤醒线程以及队列操作的通用机制。" 正文: Java.util.concurrent同步框架是Java并发编程的重要组成部分，由Doug Lea设计并引入到J2SE 5.0版本中。这个框架的核心是AbstractQueuedSynchronizer（AQS），它是一个抽象基类，用于实现各种同步组件，如锁、信号量、屏障等。AQS通过内部维护一个同步状态，并提供了一套API来原子地操作这个状态。 1. AQS的原理与设计 AQS使用了一个FIFO（先进先出）的等待队列来管理那些因获取同步状态失败而被阻塞的线程。线程通过调用`acquire`方法尝试获取状态，如果失败则被添加到队列尾部。当同步状态释放时，队首的线程会被唤醒并重新尝试获取。 2. 原子操作 AQS的关键在于其提供了原子性的状态更新操作，这通常通过CAS（Compare and Swap）指令实现。这种无锁的并发策略确保了在多线程环境下对同步状态的修改是线程安全的。 3. 状态转移 AQS的状态可以由使用者自定义，通过继承AQS并重写特定的方法，如`tryAcquire`和`tryRelease`，来控制同步状态的获取和释放逻辑。这些方法的实现决定了同步组件的行为。 4. 阻塞与唤醒当线程尝试获取同步状态失败时，AQS会将线程加入等待队列并进入阻塞状态。当同步状态改变，如被其他线程释放时，AQS会自动唤醒队首的线程，使其重新尝试获取。 5. 使用示例 Java中的`ReentrantLock`、`CountDownLatch`、`Semaphore`等类都是基于AQS实现的。它们各自通过定制AQS的状态和获取/释放规则，实现了不同的同步行为。 6. 性能考量文章讨论了AQS框架在性能上的优势，包括其低开销的阻塞和唤醒机制，以及高效的状态管理。通过AQS，开发者可以方便地创建高性能且线程安全的同步组件。 7. 结论 Doug Lea的这篇文章不仅介绍了AQS的设计和实现，还提供了一些使用示例和性能分析，对于理解和使用Java并发库具有很高的参考价值。通过理解AQS，开发者能够更好地利用Java.util.concurrent包，创建高效且可扩展的并发程序。 java.util.concurrent同步框架是Java并发编程的重要工具，它简化了复杂的线程同步问题，使得开发者可以专注于业务逻辑而不是底层的同步细节。AbstractQueuedSynchronizer作为框架的核心，它的设计理念和实现方式对于提升并发程序的性能和可维护性至关重要。

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页未读，继续阅读

WillsGong

粉丝: 3
资源: 1

Java并发工具包中的同步框架解析

The java. util. concurrent synchronizer framework.pdf

The java.util.concurrent Synchronizer Framework

Java并发框架：Synchronizer深度解析

Java并发框架：AbstractQueuedSynchronizer深入解析

Java并发同步框架AQS深入解析

Java并发编程练习与解决方案分享

实战Java高并发编程：源码整理读书笔记

基于C语言课程设计学生成绩管理系统、详细文档+全部资料+高分项目.zip

基于springboot的简历系统源码（java毕业设计完整源码+LW）.zip

“招聘智能化”：线上招聘问答系统的功能开发

最新资源