Synchronized&Lock&AQS详解
加锁目的:由于线程执行的过程是不可控的,所以需要采用同步机制来协同对对象可变状态的访问。
加锁方式:java锁分为两种–显示锁和隐示锁,本质区别在于显示锁需要的是程序员自己手动的进行加锁与解锁如ReentrantLock需要进行lock与unlock。而隐式锁则是Synchronized,jvm内置锁,jvm进行操作加锁与解锁。
Synchronized关键字
每个对象创建后都会存在一个Monitor(监视器锁),它的实现依赖底层的系统的Mutex Lock(互斥锁)实现,是重量级锁,但是在java1.6版本之后,jvm内置锁进行了一系列的优化,如:锁粗化、锁消除、偏向锁、轻量级锁、重量级锁等。
Synchronized锁编译成字节码后,会发现jvm底层使用了monitorenter与monitorexit来进行加锁与解锁
我们知道synchronized加锁加在对象上,对象是如何记录锁状态的呢?
答案是锁状态是被记录在每个对象的对象头(Mark Word)中,下面我们一起认识一下对象的内存布局
对象的内存布局
HotSpot虚拟机中,对象在内存中存储的布局可以分为三块区域:对象头(Header)、实例数据(Instance Data)和对齐填充(Padding)。
- 对象头:比如 hash码,对象所属的年代,对象锁,锁状态标志,偏向锁(线程)ID,偏向时间,数组长度(数组对象)等
- 实例数据:即创建对象时,对象中成员变量,方法等
- 对齐填充:对象的大小必须是8字节的整数倍
AQS具备特性
- 阻塞等待队列
- 公平/非公平
- 可重入
- 共享/独占
- 允许中断
例如Java.concurrent.util当中同步器的实现如Lock,Latch,Barrier等,都是基于AQS框架实现,一般通过定义内部类Sync继承AQS,将同步器所有调用都映射到Sync对应的方法
1 static final class NonfairSync extends Sync {
2 private static final long serialVersionUID = 7316153563782823691L;
3
4 /**
5 * Performs lock. Try immediate barge, backing up to normal
6 * acquire on failure.
7 */
8 final void lock() {
9 if (compareAndSetState(0, 1))
10 setExclusiveOwnerThread(Thread.currentThread());
11 else
12 acquire(1);
13 }
14
15 protected final boolean tryAcquire(int acquires) {
16 return nonfairTryAcquire(acquires);
17 }
18 }
该NonfairSync为ReentranLock内部类,默认非公平锁,非公平锁与公平锁的区别在于,当正在争抢的锁释放时,谁会抢到锁。我们再看一下 公平锁的lock()方法,就明白了。
1 static final class FairSync extends Sync {
2 private static final long serialVersionUID = -3000897897090466540L;
3
4 final void lock() {
5 acquire(1);
6 }
7
8 /**
9 * Fair version of tryAcquire. Don't grant access unless
10 * recursive call or no waiters or is first.
11 */
12 protected final boolean tryAcquire(int acquires) {
13 final Thread current = Thread.currentThread();
14 int c = getState();
15 if (c == 0) {
16 if (!hasQueuedPredecessors() &&
17 compareAndSetState(0, acquires)) {
18 setExclusiveOwnerThread(current);
19 return true;
20 }
21 }
22 else if (current == getExclusiveOwnerThread()) {
23 int nextc = c + acquires;
24 if (nextc < 0)
25 throw new Error("Maximum lock count exceeded");
26 setState(nextc);
27 return true;
28 }
29 return false;
30 }
31 }
前面看到非公平锁首先去尝试设置state状态是否可以成功,这里的state为Node节点的属性,默认为0就是没有人抢到锁的情况,加一次锁就会state进行CAS操作+1,因为它是可重入的锁没所以每加一次都会state+1,没释放一次都会-1,直到state为0时,才会轮到下一个线程进行抢锁。我们再看一下acquire(1)方法,就明白了。
1 public final void acquire(int arg) {
2 if (!tryAcquire(arg) &&
3 acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
4 selfInterrupt();
5 }
我来讲接一下:tryAcquire(arg)是尝试获取锁,并将state状态由0变为+1,如果失败说明锁已经被别人抢走了,需要下一步操作就是addWaiter
addWaiter()方法就是创建一个双向链表的结构的队列,看到它是一种Node.EXCLUSIVE模式创建的,为独占模式
acquireQueued()方法让第一个节点去争抢锁,如果失败则会将该线程直接中断阻塞,如果当前节点的前一个节点为头结点也就是第一个节点抢到锁了将会把当前节点作为新的头结点并返回值
tryAcquire(arg)公平锁与非公平锁实现不一样,公平锁多判断了一步就是如果我的同步队列也就是等待队列里有其他等待的节点,将不会让当前的新线程去获取锁。
释放锁的时候是一样的逻辑
1 public final boolean release(int arg) {
2 if (tryRelease(arg)) {
3 Node h = head;
4 if (h != null && h.waitStatus != 0)
5 unparkSuccessor(h);
6 return true;
7 }
8 return false;
9 }
也是会改变state值的状态,当变为0时,Node还有一个属性就是exclusiveOwnerThread,它指向的是正在使用锁的线程,state释放为初始状态的时候,exclusiveOwnerThread将会置位null;去唤醒头结点。取消阻塞公平与非公平就在于去抢锁的时候判断是不一样的。
BlockingQueue实现原理
我们以ArrayBlockingQueue为例讲解为什么AQS需要使用同步队列与条件队列两个队列;
1 public ArrayBlockingQueue(int capacity) {
2 this(capacity, false);
3 }
4 public ArrayBlockingQueue(int capacity, boolean fair) {
5 if (capacity <= 0)
6 throw new IllegalArgumentException();
7 this.items = new Object[capacity];
8 lock = new ReentrantLock(fair);
9 notEmpty = lock.newCondition();
10 notFull = lock.newCondition();
11 }
源码中我们创建阻塞队列需要创建容量初始大小以及默认非公平锁,底层看到使用的是独占锁ReentrantLock以及两个条件队列Condition;
1 public void put(E e) throws InterruptedException {
2 checkNotNull(e);
3 final ReentrantLock lock = this.lock;
4 lock.lockInterruptibly();
5 try {
6 while (count == items.length)
7 notFull.await();
8 enqueue(e);
9 } finally {
10 lock.unlock();
11 }
12 }
当我们往队列中添加元数时,则会将元素放入到数组中,并且唤醒阻塞线程;如果数组填满的时候,则会将当前阻塞,我们看看await方法;
1 public final void await() throws InterruptedException {
2 if (Thread.interrupted())
3 throw new InterruptedException();
4 Node node = addConditionWaiter();
5 int savedState = fullyRelease(node);
6 int interruptMode = 0;
7 while (!isOnSyncQueue(node)) {
8 LockSupport.park(this);
9 if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
10 break;
11 }
12 if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
13 interruptMode = REINTERRUPT;
14 if (node.nextWaiter != null) // clean up if cancelled
15 unlinkCancelledWaiters();
16 if (interruptMode != 0)
17 reportInterruptAfterWait(interruptMode);
18 }
我来讲解下上面的方法:
addConditionWaiter:将当前条件队列从后遍历进行删除已经没有用的节点,并且将当前线程添加到条件队列当中;返回当前节点。
fullyRelease:将当前线程的锁全部释放掉,并且当前的独占线程置位null后,唤醒队列的头节点,但是目前我们的队列还没有任何阻塞节点,所以只是释放了锁。
isOnSyncQueue:查看是否当前节点已经在同步队列中。
checkInterruptWhileWaiting:查看点前节点是否被中断,如果没有则将当前节点添加到同步队列当中。
acquireQueued:同步队列中头节点重新获取锁并返回。
unlinkCancelledWaiters:删除条件队列中被中断的节点。
reportInterruptAfterWait:中断当前线程。
我们不难发现,当前节点没有添加成功会先添加到条件队列中,然后释放持有的独占锁,并且判断是否已经加入到了同步队列中去,没有的话线程阻塞到这里。一旦被释放就会
立即添加到同步队列中。然后做一些后续处理。
1 public E take() throws InterruptedException {
2 final ReentrantLock lock = this.lock;
3 lock.lockInterruptibly();
4 try {
5 while (count == 0)
6 notEmpty.await();
7 return dequeue();
8 } finally {
9 lock.unlock();
10 }
11 }
这里的await跟上面的步骤是一样的,只不过他会释放上一个阻塞的线程,让它添加到同步队列中。
由于线程执行的过程是不可控的,所以需要采用同步机制来协同对对象可变状态的访问
- 点赞
- 收藏
- 关注作者
评论(0)