ReentrantLock & synchronized 比对与原理浅析

1、一开始jdk出的锁是synchronized ,但是是一个重量级的锁,由于某些代码存在并发的问题,我们统一给这些代码加上synchronized 包裹,发现线程之间竞争只是在部分情况下,还有很多情况下线程是交替执行(也就是A线程执行完后B再进来的,没有出现两者希望同时进入)。比如我们的加了synchronized关键字的代码块在90%都是交替执行,10%是竞争执行(需要明白交替和竞争)。那对于前面90%的线程都因为后面的10%而不得不忍受synchronized带来的低效。置于synchronized为啥低效?因为synchronized本身是需要切换到操作系统的内核态。所以存在由用户线程切换为操作系统线程的过程,这个线程切换过程是一个相对比较耗费性能的操作。那么能不能在线程是交替的时候synchronize不生效,而线程竞争的时候再启用synchronized呢?我们的ReentrantLock 就是为了解决这个问题而来的。

2、ReentrantLock是大神Doug Lea在1.5的jdk中提供的。相比于synchronized ,它提供了各种丰富的api,比如公平锁,非公平锁。最关键的是它的设计大大提高了锁的性能。ReentrantLock包裹的代码,在线程进入之前会先走看下队列中有没有在排队等待的其他线程。有则直接进入队列,这个设计让交替执行的线程在java级别就解决了并发问题。下面看下原码

  1. 线程调用锁定:lock.lock();//启动锁定。
  2. public void lock() {
            sync.lock();//AbstractQueuedSynchronizer 的子类
    }
    ReentrantLock的lock方法如上代码所示,实际其调用的又是自身内部属性Sync对象的lock方法。这里ReentrantLock的Sync类实现了AbstractQueuedSynchronizer并且继续扩展出了NonfairSync(非公平锁) & FairSync(非公平锁) 两个下级子类。
  3. 看下FairSync的lock方法,这里如果是非公平锁,则采取直接调用compareAndSetState方法(后面介绍),而公平锁则先调用acquire(1).
  4. 我们看下具体公平锁的------acquire的实现,调用了tryAcquire(1)
  5. protected final boolean tryAcquire(int acquires) {
                final Thread current = Thread.currentThread();
                int c = getState();//返回父类AbstractQueuedSynchronizer,state字段的值
                if (c == 0) {        //认为当前还没有线程修改,0是默认值
                    if (!hasQueuedPredecessors() &&  // 检查是否需要去队列排队
                        compareAndSetState(0, acquires)) {//原子操作,希望state是0,并将state设置为1
                        setExclusiveOwnerThread(current);
                        return true;
                    }
                }
                else if (current == getExclusiveOwnerThread()) {
                    int nextc = c + acquires;
                    if (nextc < 0)
                        throw new Error("Maximum lock count exceeded");
                    setState(nextc);
                    return true;
                }
                return false;
    }

    如果队列还有在排队hasQueuedPredecessors返回ture,或者调用compareAndSetState(0, acquires)失败(说明同时有其他线程已经先一步改变了state的状态)tryAcquire方法都会返回false

  6. 代码就会执行如下两行

    acquireQueued(addWaiter(Node.EXCLUSIVE), arg);//将自己也放到等待队列中,
    selfInterrupt();//成功之后中断自己,让出cpu

猜你喜欢

转载自blog.csdn.net/ygy982883422/article/details/104874051