AQS学习2

栏目: Java · 发布时间: 6年前

内容简介:AQS学习2

简介

synchronized关键字

java 5.0之前,使线程安全的执行临界区代码,会用到synchronized关键字,可以达到以下效果:

  1. 如果临界区没被其它线程占用,则执行代码。
  2. 如果临界区被占用,则阻塞当前线程。

那么问题来了,如何实现synchronized关键字的效果呢?

  1. 如何标记临界区被占用?
  2. 临界区被占用后,当前线程如何被阻塞?
  3. 临界区被释放后,如何通知被阻塞的线程?
  4. 很明显,我们需要一个存储被阻塞线程的数据结构,这个数据结构是什么样子的?

为什么提出一种新的锁方案

java5.0之后有了新的接口Lock,提供了一种无条件的,可轮询的,定时的以及可中断的锁获取操作,所有加锁和解锁的方法都是显式的。为什么有了内置锁,还要提供一种新的加锁方式呢?

  1. 效率问题

    1. synchronized是通过MonitorEnter和MonitorExit专用字节码指令来实现。因为java线程是靠操作系统原生线程实现的,挂起线程还涉及到内核态与用户态的转换(还要劳烦OS介入)。加锁时,使用synchronized并不是高效的办法,其配套的同步手段wait和notify也不是(提高效率可用Condition,这不是本文的重点)。
    2. 在java.util.concurrent包中的一些方法通过 结合使用Java代码和使用sun.misc.Unsafe的实现本地调用。这样,同步的大部分工作可以由JVM线程内部解决
  2. 内置锁不够灵活,比如取消、设置进入临界区的线程数量等

    比如内置锁无法中断一个正在获取锁的线程,(正在获取锁的线程)在得不到锁时会无限等待下去。而Lock接口可以为我们提供更丰富的选择。

    public interface Lock {

    void lock();
         void lockInterruptibly() throws InterruptedException;
         boolean tryLock();
         boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
         void unlock();
         Condition newCondition();
     }

锁与同步器Synchronizer的关系

java的并发,锁其中一个很重要的工具。同时,编写复杂的并发程序,仅用锁是远远不够的,还需Semaphore,CountDownLatch和FutureTask等。在锁和各种同步 工具 类背后,有一个“看不见的手”:AbstractQueuedSynchronizer。

借用 AbstractQueuedSynchronizer的介绍和原理分析 中的描述:锁的API是面向使用者的,它定义了与锁交互的公共行为。但锁的实现是依托给同步器来完成; 同步器面向的是线程访问和资源控制,它定义了线程对资源是否能够获取以及线程的排队等操作。 锁和同步器很好的隔离了二者所需要关注的领域,严格意义上讲,同步器可以适用于除了锁以外的其他同步设施上。

AbstractQueuedSynchronizer作为一个同步器,显式的处理了上节提到的几个问题。

AbstractQueuedSynchronizer

AbstractQueuedSynchronizer的java类介绍:

Provides a framework for implementing blocking locks and related synchronizers (semaphores, events, etc) that rely on first-in-first-out (FIFO) wait queues. This class is designed to be a useful basis for most kinds of synchronizers that rely on a single atomic value to represent state. Subclasses must define the protected methods that change this state, and which define what that state means in terms of this object being acquired or released. Given these, the other methods in this class carry out all queuing and blocking mechanics. Subclasses can maintain other state fields, but only the atomically updated value manipulated using methods , and is tracked with respect to synchronization.

可以看到,AbstractQueuedSynchronizer并没有包办一切(否则就不会以Abstract开头了),而是通过继承的方式将同步器的工作划分成两个部分,在父类和子类中分别完成。

共享变量的值,对于不同的子类意味着不同的状态

  1. 对于ReentrantLock,它是所有者线程已经重复获取该锁的次数
  2. Semaphore,它表示剩余的许可数量
  3. FutureTask,它表示任务的状态(尚未开始,正在运行,已完成以及已取消)

父类和子类的工作分别是

  1. 子类负责修改共享变量(a single atomic value to represent state),其操作必须是原子的(通过getState()、setState()和compareAndSetState()方法),根据返回值影响父类的行为(是否挂起当前线程,是否恢复被阻塞线程)。
  2. AbstractQueuedSynchronizer负责线程阻塞队列(FIFO)的维护,根据预留给子类的方法的返回值判断线程阻塞和唤醒(queuing and blocking mechanics)

AbstractQueuedSynchronizer留给子类实现的方法,一般以try开头,父类中对应的方法会调用这些方法。类似于操作系统的PV操作,或者说:我们在本文开始提到的synchronized一些问题,acquire和release基本是用来顶替wait和notify的。

  • 排他模式

    protected boolean tryAcquire(int arg)    // 根据当前状态,是否挂起线程(获取操作,还会影响共享变量值)
      protected boolean tryRelease(int arg)    // 新的状态,是否允许唤醒某个线程
      protected boolean isHeldExclusively()
  • 共享模式(允许有限的多个线程同时进入临界区)

    protected int tryAcquireShared(int arg)
      protected boolean tryReleaseShared(int arg)

一般情况下,在tryAcquire中判断state值,判断是否阻塞线程,如果阻塞,cas增加state值,在tryRelease减少state值。

AbstractQueuedSynchronizer实现类示例

在AQS框架下,我们可以自定义一个锁的实现

public class Mutex{
	private final Sync sync = new Sync();
	public void signal(){sync.releaseShared(0);}
	public void await() throws InterruptedException{
		sync.acquireShared(0);
	}
	private class Sync extends AbstractQueuedSynchronizer{
		protected int tryAcquireShared(int ignored){
		    // 共享变量为1表示锁空闲,为0表示锁被占用
			return (getState() == 1) ? 1 : -1;
		}
		protected boolean tryReleaseShared(int ignored){
			setState(1);
			return true;
		}
	}
}

Mutex是面向用户的,用户使用Mutext时只需 mutex.awaitmutex.signal 即可。同步器面向的是线程访问和资源控制,使用时除调用acquire和release方法外,还要设置具体的参数值, 为数据的变化赋予意义 (此处参数是没用的)。

从锁及其它同步工具类中抽取出同步器,这在我们抽象自己的代码时,有很强的借鉴意义。

AbstractQueuedSynchronizer子类的实现比较丰富,除了提供类似pv操作。比如,如果为子类添加成员的话

static final class Sync<V> extends AbstractQueuedSynchronizer{
	private V value;
    private Throwable exception;
    V get() throws xxxException;
    boolean set(V v);
}
Sync<V> sync = new Sync<V>();

此处Sync就可以作为一个类的包装类,ThreadLocal用来做一个线程内(不同方法间)数据传递,此处Sync就可以作为线程间的数据传递。

从队列开始说起

说起队列,笔者的直接反应是“有一个数组,一前一后两个指针,入队出队通过移动指针来解决”(队列的存储结构基于数组方式)。AQS中的队列(并且是一个双向队列)采用链表作为存储结构,通过节点中的next指针维护队列的完整。AbstractQueuedSynchronizer关于队列操作的部分如下:

public abstract class AbstractQueuedSynchronizer{
    private transient volatile Node head;
    private transient volatile Node tail;
    Node {
       int waitStatus;  
       Node prev;
       Node next;
       Node nextWaiter;
       Thread thread;
    }
    // 在队列尾部插入节点,中间一些操作用到CAS以保证原子性
     private Node addWaiter(Node mode){}  
    // 将一个Node的相关指向置为空,并不再让其它节点指向它,即可(GC)释放该节点
}

AbstractQueuedSynchronizer.acquire和Object.wait对比

AbstractQueuedSynchronizer.acquire

在排他模式下,线程执行一次acquire所需要经历的过程

AQS学习2

上图中的循环过程就是完成了自旋的过程,也正是有了这个循环,为支持超时和中断提供了条件。

判断退出队列的条件

  1. 当前线程对应队列节点是首节点。如果是,说明轮到自己了。
  2. 获取“状态”是否成功。如果是,说明上一个首节点已经“忙完了”

节点挂起后,何时被唤醒?前置(首)节点的release操作会唤醒当前节点。共享模式下,前置节点的唤醒也会间接唤醒当前节点。

Object.wait

Object有内置锁和内置队列,wait,notify和notifyAll作为操作内置队列的api,一次wait(说明当前线程依赖的“状态”还不具备)的主要步骤如下:

  1. 释放当前线程占有的锁
  2. 阻塞当前线程
  3. 等待,直到超时(如果设置了的话),线程被中断,或者被一个notify唤醒
  4. 获取锁(“状态”变量在被判断之前,必须被锁定),判断“状态”是否满足,如果不满足,重复步骤1。

wait方法也有一个循环的过程,在wait和acquire过程中,一个线程可能会被唤醒和挂起多次(只是挂起的手段不同)。

AQS方法简介

AbstractQueuedSynchronizer支持多种工作模式及其组合,包括共享模式、排他模式、是否支持中断、是否超时等。

各个模式对应的方法如下(部分)

  • 排他模式

    public final void acquire(int arg)
      final boolean acquireQueued(final Node node, int arg)
      // 恢复锁的状态(“为0”),唤醒后继节点
      public final boolean release(int arg)
  • 支持中断

    // 每次“干活”前,先检查下当前线程的中断状态,如果当前线程被中断了,就放弃当前操作
      public final void acquireInterruptibly(int arg)
  • 支持超时

    // 每次“干活(循环)”前,先检查下剩余时间,在循环的最后更新下时间
      public final boolean tryAcquireNanos(int arg, long nanosTimeout)
  • 共享模式

    // 如果共享状态获取成功之后会判断后继节点是否是共享模式,如是就直接对其进行唤醒操作,也就是同时激发多个线程并发的运行。
      public final void acquireShared(int arg)
      public final boolean releaseShared(int arg)

线程的阻塞和唤醒,使用LockSupport的park和unpark方法。

小结

2018.1.3 更新,从 Java中synchronized的实现原理与应用 聊聊并发(二)——Java SE1.6中的Synchronized 可以看到:

  1. synchronized 实现中,无锁、偏向锁、轻量级锁、重量级锁(使用操作系统锁)。中间两种锁不是“锁”,而是一种机制,减少获得锁和释放锁带来的性能消耗。

    • JVM中monitor enter和monitor exit字节码依赖于底层的操作系统的Mutex Lock来实现的,但是由于使用Mutex Lock需要将当前线程挂起并从用户态切换到内核态来执行,这种切换的代价是非常昂贵的。所以monitor enter的时候,多个心眼儿,看看能不能不走操作系统。
    • 每一个线程都有一个可用monitor record列表,JVM中创建对象时会在对象前面加上两个字大小的对象头mark word。Mark Word最后3bit是状态位,根据不同的状态位Mark Word中存放不同的内容。有时存储当前占用的线程id,有时存储某个线程monitor record 的地址。
    • 线程会根据自己获取锁的情况更改 mark word的状态位。 mark word 状态位本质上反应了锁的竞争激烈程度 。若一直是一个线程自嗨,mark word存一下线程id即可。若是两个线程虽说都访问,但没发生争抢,或者自旋一下就拿到了,则哪个线程占用对象,mark word就指向哪个线程的monitor record。若是线程争抢的很厉害,则只好走操作系统锁流程了。
  2. AQS和synchronized的实现异同

    • 都考虑一个线程自嗨的情况
    • AQS 基本完全放弃了操作系统锁的使用,自行实现阻塞、队列、唤醒等机制

引用

AbstractQueuedSynchronizer的介绍和原理分析

Java并发包源码学习之AQS框架


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Adobe Flex 大师之路

Adobe Flex 大师之路

2009-5 / 69.80元

《Adobe Flex大师之路》以Flex 3.0为基础,涵盖了Flex技术的核心内容。《Adobe Flex 大师之路》能够帮助您你学习并掌握使用Flex所需的牢靠和全面的知识基础,告诉您你如何把这些知识将之转化为代码,并在实际项目中变通应用。通过学习《Adobe Flex 大师之路》,您你可以利用Flex来构建企业级应用的表现层、改善应用的用户体验、集成企业端的复杂服务。这本书是为所有希望学习......一起来看看 《Adobe Flex 大师之路》 这本书的介绍吧!

HTML 压缩/解压工具
HTML 压缩/解压工具

在线压缩/解压 HTML 代码

随机密码生成器
随机密码生成器

多种字符组合密码

Markdown 在线编辑器
Markdown 在线编辑器

Markdown 在线编辑器