Java---Synchronized和Lock简介

骑猪看日落 2023-01-18 02:25 126阅读 0赞

参考文章：[JAVA Synchronized和Lock的区别][JAVA Synchronized_Lock]

## Synchronized和Lock的区别 ##

> synchronized关键字和java.util.concurrent.locks.Lock都能加锁，两者有什么区别呢？
> 
> 1.  **原始构成**：sync是JVM层面的，底层通过monitorenter和monitorexit来实现的。Lock是JDK API层面的。（sync一个enter会有两个exit，一个是正常退出，一个是异常退出）
> 2.  **使用方法**：sync自动上锁和自动释放锁, 不需要手动释放锁，而Lock需要手动释放。
> 3.  **是否可中断**：sync悲观锁, 可重入的锁, 会一直等待对象头锁信息, 阻塞的, 不可中断，除非抛出异常或者正常运行完成。Lock是可中断的，通过调用interrupt()方法。
> 4.  **是否为公平锁**：sync只能是非公平锁，而Lock既能是公平锁，又能是非公平锁。
> 5.  **绑定多个条件**：sync不能，只能随机唤醒。而Lock可以通过Condition来绑定多个条件，精确唤醒。
> 6.  synchronized是重量级锁，不适合大量代码; Lock可以，lock锁的粒度更细,分为读锁写锁等
> 7.

## Synchronized的作用： ##

在JDK1.5之前都是使用synchronized关键字保证同步的

它可以把任意一个非NULL的对象当作锁。

> 1.  作用于方法时，锁住的是对象的实例(this)；
> 2.  当作用于静态方法时，锁住的是Class实例，又因为Class的相关数据存储在永久带PermGen（jdk1.8则是metaspace），永久带是全局共享的，因此静态方法锁相当于类的一个全局锁，会锁所有调用该方法的线程；
> 3.  synchronized作用于一个对象实例时，锁住的是所有以该对象为锁的代码块。

### Synchronized的实现： ###

实现如下图所示；

![这里写图片描述][SouthEast]

它有多个队列，当多个线程一起访问某个对象监视器的时候，对象监视器会将这些线程存储在不同的容器中。

> 1.  Contention List：竞争队列，所有请求锁的线程首先被放在这个竞争队列中；
> 2.  Entry List：Contention List中那些有资格成为候选资源的线程被移动到Entry List中；
> 3.  Wait Set：哪些调用wait方法被阻塞的线程被放置在这里；
> 4.  OnDeck：任意时刻，最多只有一个线程正在竞争锁资源，该线程被成为OnDeck；
> 5.  Owner：当前已经获取到所资源的线程被称为Owner；
> 6.  !Owner：当前释放锁的线程。

ContentionList并不是真正意义上的一个队列。仅仅是一个虚拟队列，它只有Node以及对应的Next指针构成，并没有Queue的数据结构。每次新加入Node会在队头进行，通过CAS改变第一个节点为新增节点，同时新增阶段的next指向后续节点，而取数据都在队列尾部进行。

JVM每次从队列的尾部取出一个数据用于锁竞争候选者（OnDeck），但是并发情况下，ContentionList会被大量的并发线程进行CAS访问，为了降低对尾部元素的竞争，JVM会将一部分线程移动到EntryList中作为候选竞争线程。Owner线程会在unlock时，将ContentionList中的部分线程迁移到EntryList中，并指定EntryList中的某个线程为OnDeck线程（一般是最先进去的那个线程）。Owner线程并不直接把锁传递给OnDeck线程，而是把锁竞争的权利交给OnDeck，OnDeck需要重新竞争锁。这样虽然牺牲了一些公平性，但是能极大的提升系统的吞吐量，在JVM中，也把这种选择行为称之为“竞争切换”。

OnDeck线程获取到锁资源后会变为Owner线程，而没有得到锁资源的仍然停留在EntryList中。如果Owner线程被wait方法阻塞，则转移到WaitSet队列中，直到某个时刻通过notify或者notifyAll唤醒，会重新进去EntryList中。

处于ContentionList、EntryList、WaitSet中的线程都处于阻塞状态，该阻塞是由操作系统来完成的（Linux内核下采用pthread\_mutex\_lock内核函数实现的）。该线程被阻塞后则进入内核调度状态，会导致系统在用户和内核之间进行来回切换，严重影响锁的性能。为了缓解上述性能问题，JVM引入了自旋锁(上边已经介绍过自旋锁)。原理非常简单，如果Owner线程能在很短时间内释放锁资源，那么哪些等待竞争锁的线程可以稍微等一等（自旋）而不是立即阻塞，当Owner线程释放锁后可立即获取锁，进而避免用户线程和内核的切换。但是Owner可能执行的时间会超过设定的阈值，争用线程在一定时间内还是获取不到锁，这是争用线程会停止自旋进入阻塞状态。基本思路就是先自旋等待一段时间看能否成功获取，如果不成功再执行阻塞，尽可能的减少阻塞的可能性，这对于占用锁时间比较短的代码块来说性能能大幅度的提升！

Synchronized在线程进入ContentionList时，等待的线程会先尝试自旋获取锁，如果获取不到就进入ContentionList，这明显对于已经进入队列的线程是不公平的，还有一个不公平的事情就是自旋获取锁的线程还可能直接抢占OnDeck线程的锁资源。

## Lock锁简介： ##

> 与synchronized不同的是，Lock锁是纯Java实现的，与底层的JVM无关。在java.util.concurrent.locks包中有很多Lock的实现类，常用的有ReentrantLock、ReadWriteLock（实现类ReentrantReadWriteLock），其实现都依赖java.util.concurrent.AbstractQueuedSynchronizer类（简称AQS）

### **Lock****的实现：** ###

> **获取锁**：首先判断当前状态是否允许获取锁，如果是就获取锁，否则就阻塞操作或者获取失败，也就是说如果是独占锁就可能阻塞，如果是共享锁就可能失败。另外如果是阻塞线程，那么线程就需要进入阻塞队列。当状态位允许获取锁时就修改状态，并且如果进了队列就从队列中移除。

// 获取锁
    while (synchronization state does not allow acquire) {
        enqueue current thread if not already queued;
        possibly block current thread;
     
    }
    dequeue current thread if it was queued;

> **释放锁**:这个过程就是修改状态位，如果有线程因为状态位阻塞的话，就唤醒队列中的一个或者更多线程。

// 释放锁
    update synchronization state;
     
    if (state may permit a blocked thread to acquire) {
        unlock one or more queued threads;
    }

>  阻塞和唤醒，JDK1.5之前的API中并没有阻塞一个线程，然后在将来的某个时刻唤醒它（wait/notify是基于synchronized下才生效的，在这里不算），JDK5之后利用JNI在LockSupport 这个类中实现了相关的特性！

想知道Lock和sychornized的区别的可以看[这一篇博客][Link 1]

参考博客：

[https://www.cnblogs.com/longshiyVip/p/5213771.html][https_www.cnblogs.com_longshiyVip_p_5213771.html]

[https://blog.csdn.net/zqz\_zqz/article/details/70233767][https_blog.csdn.net_zqz_zqz_article_details_70233767]

[JAVA Synchronized_Lock]: https://blog.csdn.net/luweibin19/article/details/106250051
[SouthEast]: /images/20221021/f45ccc45ba4942e593a7a7957abce63f.png
[Link 1]: http://www.cnblogs.com/nsw2018/p/5821738.html
[https_www.cnblogs.com_longshiyVip_p_5213771.html]: https://www.cnblogs.com/longshiyVip/p/5213771.html
[https_blog.csdn.net_zqz_zqz_article_details_70233767]: https://blog.csdn.net/zqz_zqz/article/details/70233767