synchronized与Lock的区别

ゞ浴缸里的玫瑰 2021-12-22 05:39 410阅读 0赞

之前面试的时候经常会被问到一个问题，就是synchronized与Lock有什么区别，当时回答的很模糊，回来之后对这个知识点深入了解了一下，现在给自己总结。

<table> 
 <thead> 
  <tr> 
   <th style="width:73px;">类别</th> 
   <th style="width:379px;">synchronized</th> 
   <th>Lock</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td style="width:73px;">存在层次</td> 
   <td style="width:379px;">Java的关键字，在jvm层面上</td> 
   <td>是一个类</td> 
  </tr> 
  <tr> 
   <td style="width:73px;">锁的释放</td> 
   <td style="width:379px;">会自动释放锁（1、以获取锁的线程执行完同步代码，释放锁 2、线程执行发生异常，jvm会让线程释放锁）</td> 
   <td>需在finally中手工释放锁（unlock()方法释放锁），否则容易造成线程死锁</td> 
  </tr> 
  <tr> 
   <td style="width:73px;">锁的获取</td> 
   <td style="width:379px;">假设A线程获得锁，B线程等待。如果A线程阻塞，B线程会一直等待</td> 
   <td>分情况而定，Lock有多个锁获取的方式，具体下面会说到，大致就是可以尝试获得锁，线程可以不用一直等待</td> 
  </tr> 
  <tr> 
   <td style="width:73px;">锁状态</td> 
   <td style="width:379px;">无法判断</td> 
   <td>可以判断</td> 
  </tr> 
  <tr> 
   <td style="width:73px;">锁类型</td> 
   <td style="width:379px;">可重入、不可中断、非公平</td> 
   <td>可重入、可判断、可公平（两者皆可）</td> 
  </tr> 
  <tr> 
   <td style="width:73px;">性能</td> 
   <td style="width:379px;">适用于少量同步</td> 
   <td>适用于大量同步</td> 
  </tr> 
 </tbody> 
</table>

### 源码 ###

以下是Lock接口的源码，只给大家介绍主要几个方法：

public interface Lock {
    
        /**
         * Acquires the lock.
         */
        void lock();
    
        /**
         * Acquires the lock unless the current thread is
         * {@linkplain Thread#interrupt interrupted}.
         */
        void lockInterruptibly() throws InterruptedException;
    
        /**
         * Acquires the lock only if it is free at the time of invocation.
         */
        boolean tryLock();
    
        /**
         * Acquires the lock if it is free within the given waiting time and the
         * current thread has not been {@linkplain Thread#interrupt interrupted}.
         */
        boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
    
        /**
         * Releases the lock.
         */
        void unlock();
    	
    }

*  lock()：如果获取了锁立即返回，如果别的线程持有锁，当前线程则一直处于休眠状态，直到获取锁；
 *  tryLock()：如果获取了锁立即返回true，如果别的线程正持有锁，立即返回false；
 *  tryLock(long timeout,TimeUnit unit)：如果获取了锁定立即返回true，如果别的线程正持有锁，会等待参数给定的时间，在等待的过程中，如果获取了锁定，就返回true，如果等待超时，返回false；
 *  lockInterruptibly()：如果获取了锁定立即返回，如果没有获取锁定，当前线程处于休眠状态，直到或者锁定，或者当前线程被别的线程中断；
 *  unLock()：释放锁；

前面提到“公平锁”，在这里可以提一下ReentrantLock对于平衡锁的定义，在源码中有这么两段：

/**
         * Sync object for non-fair locks
         */
        static final class NonfairSync extends Sync {
            private static final long serialVersionUID = 7316153563782823691L;
    
            /**
             * Performs lock.  Try immediate barge, backing up to normal
             * acquire on failure.
             */
            final void lock() {
                if (compareAndSetState(0, 1))
                    setExclusiveOwnerThread(Thread.currentThread());
                else
                    acquire(1);
            }
    
            protected final boolean tryAcquire(int acquires) {
                return nonfairTryAcquire(acquires);
            }
        }
    
        /**
         * Sync object for fair locks
         */
        static final class FairSync extends Sync {
            private static final long serialVersionUID = -3000897897090466540L;
    
            final void lock() {
                acquire(1);
            }
    
            /**
             * Fair version of tryAcquire.  Don't grant access unless
             * recursive call or no waiters or is first.
             */
            protected final boolean tryAcquire(int acquires) {
                final Thread current = Thread.currentThread();
                int c = getState();
                if (c == 0) {
                    if (!hasQueuedPredecessors() &&
                        compareAndSetState(0, acquires)) {
                        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;
            }
        }

从以上源码可以看出在ReentrantLock中可以自己控制锁是否公平，而且默认的是非公平锁，以下是ReentrantLock的构造函数：

public ReentrantLock() {
           sync = new NonfairSync();//默认非公平锁
       }
    
       public ReentrantLock(boolean fair) {
           sync = fair ? new FairSync() : new NonfairSync();
       }

### 锁类型 ###

*  可重入锁：synchronized和Look都是可重入锁，锁的可重入性标明了锁是针对线程分配方式而不是针对方法。例如调用synchronized方法A中可以调用synchronized方法B，而不需要重新申请锁。
 *  读写锁：对资源读取和写入的时候拆分为2部分处理，读的时候可以多线程一起读，写的时候必须同步地写。ReadWriteLock是一个读写锁，通过readLock()获取读锁，通过writeLock()获取写锁。
 *  可中断锁：可中断是指锁是可以被中断的，synchronized内置锁是不可中断锁，Lock可以通过lockInterruptibly方法中断显性锁。例如线程B在等待等待线程A释放锁，但是线程B由于等待时间太久，可以主动中断等待锁。
 *  公平锁：公平锁是指尽量以线程的等待时间先后顺序获取锁，等待时间最久的线程优先获取锁。synchronized隐性锁是非公平锁，它无法保证等待的线程获取锁的顺序，ReentrantLook可以自己控制是否公平锁。

### synchronized和Lock性能区别 ###

synchronized是托管给JVM执行的，而Lock是java写的控制锁的代码。

在Java1.5中，synchronize是性能低效的。因为这是一个重量级操作，需要调用操作接口，导致有可能加锁消耗的系统时间比加锁以外的操作还多。相比之下使用Java提供的Lock对象，性能更高一些。

但是到了Java1.6，发生了变化。synchronize在语义上很清晰，可以进行很多优化，有适应自旋，锁消除，锁粗化，轻量级锁，偏向锁等等。导致在Java1.6上synchronize的性能并不比Lock差。官方也表示，他们也更支持synchronize，在未来的版本中还有优化余地。

### 两种锁的底层实现 ###

**synchronized**：底层使用指令码方式来控制锁的，**采用的是CPU悲观锁机制，即线程获得的是独占锁。**独占锁意味着其他线程只能依靠阻塞来等待线程释放锁。而在CPU转换线程阻塞时会引起线程上下文切换，当有很多线程竞争锁的时候，会引起CPU频繁的上下文切换导致效率很低。

*  同步代码块映射成字节码指令就是增加了两个指令：monitorenter和monitorexit。当线程执行遇到monitorenter指令时会尝试获取内置锁，如果获取锁则锁计数器+1，如果没有获取锁则阻塞；当遇到monitorexit指令时锁计数器-1，如果计数器为0则释放锁。
 *  同步方法则是通过检查ACC\_SYNCHRONIZED标示符是否被设置，如果设置了，执行线程将先获取monitor，获取成功之后才能执行方法体，方法执行完后再释放monitor。在方法执行期间，其他任何线程都无法再获得同一个monitor对象。

**Lock**：**底层是CAS乐观锁**，依赖AbstractQueuedSynchronizer类，把所有的请求线程构成一个CLH队列。而对该队列的操作均通过Lock-Free（CAS）操作。

### synchronized和Lock如何选择 ###

synchronized和ReentrantLock在一般情况下没有什么区别，但是在非常复杂的同步应用中，请考虑使用ReentrantLock，特别是遇到下面几种需求的时候。

1.  某个线程在等待一个锁的控制权的这段时间需要中断
2.  需要分开处理一些wait-notify，ReentrantLock里面的Condition应用，能够控制notify哪个线程
3.  具有公平锁功能，每个到来的线程都将排队等候

参考：

[https://www.cnblogs.com/iyyy/p/7993788.html][https_www.cnblogs.com_iyyy_p_7993788.html]

[https://blog.csdn.net/u012403290/article/details/64910926][https_blog.csdn.net_u012403290_article_details_64910926]

[https://blog.csdn.net/hefenglian/article/details/82383569][https_blog.csdn.net_hefenglian_article_details_82383569]

[https_www.cnblogs.com_iyyy_p_7993788.html]: https://www.cnblogs.com/iyyy/p/7993788.html
[https_blog.csdn.net_u012403290_article_details_64910926]: https://blog.csdn.net/u012403290/article/details/64910926
[https_blog.csdn.net_hefenglian_article_details_82383569]: https://blog.csdn.net/hefenglian/article/details/82383569