J.U.C 之AQS

J.U.C 之AQS

AbstractQueuedSynchronizer - AQS

image

实现原理

• 使用Node实现FIFO队列，可以用于构建锁获者其他同步装置的基础框架
• 利用了一个int类型表示状态
• 使用方法是继承
• 子类通过继承并通过实现它的方法管理其状态{acquire和release}的方法操纵状态
• 可以同时实现排它锁和共享锁模式(独占、共享)

AQS同步组件

• CountDownLatch - 闭锁 (通过计数来保证线程是否一直阻塞)
• Semaphore(可以控制同一时间并发线程的数目)
• CyclicBarrier(和CountDownLatch类似)
• ReetrantLock
• Condition
• FutureTask

CountDownLatch

介绍

• 主要功能同步辅助类，可以阻塞当前线程的功能，简单来说就是一个线程或多个线程一直等待，直到其他线程执行的操作完成(通过原子操作的计数器来实现)

应用场景

• 并行计算

方法

• CountDown(int count)构造器：给定当前执行的线程数量
• countdown方法:如果当前计数大于零，则递减。 如果新计数为零，则重新启用所有等待线程以进行线程调度。
• await()/await(int,timeType)方法:如果当前计数为零，则此方法立即返回，确保线程执行完毕或者线程在给定时间内执行完毕

Semapthore

• 信号量控制，可以通过同步机制来控制某个资源可被同时访问的个数
• acquire() :获取一个许可，如果没有就等待
• release()：操作完成后释放一个许可
• tryAcquire()/tryAcquire(int)：尝试获取一个许可，或者多个许可
• tryAcquire(long,timeType):尝试获取不超过某个时间下的许可(一秒内许可)
• tryAcquire(int permit,long,timeType):获取该时间内的许可次数
  • 数据库并发连接数控制

ConditionCyclicBarrier

• 和CountDownLatch的区别
  • CountDownLatch计数器只能使用一次，CyclicBarrier可以使用使用reset方法重置，循环使用
  • CountDownLatch主要是实现或者等待其他线程完成某项操作之后，才能往下执行，描述的是一个获n个线程等待其他线程的关系；而CyclicBarrier是实现多个线程相互等待，知道所有线程都满足了之后才能执行后续的操作，描述的是各个线程之间相互等待的关系

ReentrantLock 与 锁

• ReentrantLock (可重入锁)和synchronized 区别
  • 可重入性(基本一直)
  • 锁的实现
    • synchronized是基于jvm实现的，ReentrantLock是jdk实现(简单来说就是操作系统和自己写代码的区别)
  • 性能区别(现在性能差不多，syn后来采用cas优化)
  • 功能功能
    • syn自动加锁和释放锁，reentrantLock自己手动加锁和释放锁
  • ReentrantLock独有功能
    • 可指定是公平锁还是非公平锁(syn只能指定非公平锁，公平锁指先获得锁先执行，后获得所后执行)
    • 提供了一个Condition类，可以分组唤醒需要唤醒的线程
    • 提供能够中断等待锁的线程的机制，通过lock.lockInterruptibly()实现(通过循环调用CAS来加锁实现)
• api
  • tryLock()：只有在调用时没有被另一个线程持有时才获取锁
  • tryLock(long,timeType):如果在给定时间内没有被另一个线程持有且当前线程没有被中断，则获取锁
  • lockInterruptibly(): 如果当前线程没有被中断，那么就获取当前锁，如果已经中断则抛出异常
  • isLocked():查询此锁是否由任何线程持有。此方法设计用于监视系统状态，不用于同步控制
  • isHeldByCurrentThread()：查询当前线程是否保持锁定状态
  • hasQueuedThread(Thread)：查询是否有线程在等待获取此锁(监控中使用)
  • hasQueuedThreads():查询是否有任意的线程正在等待获取此锁(监控中使用)
  • getHoldCount()：查询当前线程被此锁锁定的数量(也就是调用lock方法的个数)

ReentrantReadWriteLock

• 在没有任何读写锁的时候才可以取得写入锁
• 悲观读取 (在写入锁执行的时候不能有读锁在执行)，读多写少的情况下，写锁会产生饥饿

StampedLock （java 8）

• 写、读、乐观读

• StampedLock是java8在java.util.concurrent.locks新增的一个API。

  • ReentrantReadWriteLock 在沒有任何读写锁时，才可以取得写入锁，这可用于实现了悲观读取。然而，如果读取很多，写入很少的情况下，使用 ReentrantReadWriteLock 可能会使写程遭遇饥饿问题，也就是写入线程无法竞争到锁定而一直处于等待状态。
    ​ StampedLock有三种模式的锁，用于控制读取/写入访问。StampedLock的状态由版本和模式组成。锁获取操作返回一个用于展示和访问锁状态的票据（stamp）变量，它用相应的锁状态表示并控制访问，数字0表示没有写锁被授权访问。在读锁上分为悲观锁和乐观锁。锁释放以及其他相关方法需要使用邮编（stamps）变量作为参数，如果他们和当前锁状态不符则失败，这三种模式为：
    ​ • 写入：方法writeLock可能为了获取独占访问而阻塞当前线程，返回一个stamp变量，能够在unlockWrite方法中使用从而释放锁。也提供了tryWriteLock。当锁被写模式所占有，没有读或者乐观的读操作能够成功。
    ​ • 读取：方法readLock可能为了获取非独占访问而阻塞当前线程，返回一个stamp变量，能够在unlockRead方法中用于释放锁。也提供了tryReadLock。
    ​ • 乐观读取：方法tryOptimisticRead返回一个非0邮编变量，仅在当前锁没有以写入模式被持有。如果在获得stamp变量之后没有被写模式持有，方法validate将返回true。这种模式可以被看做一种弱版本的读锁，可以被一个写入者在任何时间打断。乐观读取模式仅用于短时间读取操作时经常能够降低竞争和提高吞吐量。

FutureTaskhjaha

• Callable和Runable接口对比

• Furure接口

  • 可以得到别的线程任务方法的返回值

• FutureTask类(实现Callble和Runable接口)