synchronized和lock怎样选择

1.synchronized和lock区别

• 底层实现的区别：synchronized是基于jvm底层的数据同步，而lock是基于Java编写一个类，主要通过硬件依赖CPU指令实现数据同步；
• 释放锁的方式区别：synchronized是在同步代码块执行完毕或出现异常时，jvm会让线程释放锁，而lock必须手工释放
• 获取锁的方式区别：synchronized中，假如A线程获取到了锁或处于阻塞状态，则B线程一直处于等待状态。而lkLock有多个锁获取的方式，可以尝试获得锁，线程可以不用一直等待
• 锁状态判断的区别：synchronized无法判断，而lock可以
• 锁类型区别：synchronized中可重入 不可中断 非公平，而lock可重，可判断 可公平（两者皆可）
• 性能区别：synchronized少量同步，而Lock大量同步

2.synchronized缺点

• 由于我们没办法设置synchronized关键字在获取锁的时候等待时间，所以synchronized可能会导致线程为了加锁而无限期地处于阻塞状态。
• 使用synchronized关键字等同于使用了互斥锁，即其他线程都无法获得锁对象的访问权。这种策略对于读多写少的应用而言是很不利的，因为即使多个读者看似可以并发运行，但他们实际上还是串行的，并将最终导致并发性能的下降。

总结：虽然synchronized已经作为一个关键字被固化在Java语言中了，但它只提供了一种相当保守的线程安全策略，且该策略开放给程序员的控制能力极弱。

2.java.util.concurrent.locks包下常用的类

2.1 java.util.concurrent.locks.lock的源码可知，Lock是一个接口：

1 2 3 4 5 6 7 8

public interface Lock {     void lock();     void lockInterruptibly() throws InterruptedException;     boolean tryLock();     boolean tryLock(long time, TimeUnit unit) throws InterruptedException;     void unlock();     Condition newCondition(); }

• 首先lock()方法是平常使用得最多的一个方法，就是用来获取锁。如果锁已被其他线程获取，则进行等待

• tryLock()方法是有返回值的，它表示用来尝试获取锁，如果获取成功，则返回true，如果获取失败（即锁已被其他线程获取），则返回false，也就说这个方法无论如何都会立即返回。在拿不到锁时不会一直在那等待。;tryLock(long time, TimeUnit unit)方法和tryLock()方法是类似的，只不过区别在于这个方法在拿不到锁时会等待一定的时间，在时间期限之内如果还拿不到锁，就返回false。如果如果一开始拿到锁或者在等待期间内拿到了锁，则返回true

• lockInterruptibly()方法比较特殊，当通过这个方法去获取锁时，如果线程正在等待获取锁，则这个线程能够响应中断，即中断线程的等待状态。也就使说，当两个线程同时通过lock.lockInterruptibly()想获取某个锁时，假若此时线程A获取到了锁，而线程B只有在等待，那么对线程B调用threadB.interrupt()方法能够中断线程B的等待过程

2.2 java.util.concurrent.locks.ReentrantLock可重入锁

• 如果锁具备可重入性，则称作为可重入锁。像synchronized和ReentrantLock都是可重入锁，可重入性在我看来实际上表明了锁的分配机制：基于线程的分配，而不是基于方法调用的分配。举个简单的例子，当一个线程执行到某个synchronized方法时，比如说method1，而在method1中会调用另外一个synchronized方法method2，此时线程不必重新去申请锁，而是可以直接执行方法method2。

　　看下面这段代码就明白了：

1 2 3 4 5 6 7 8 9

class MyClass {     public synchronized void method1() {         method2();     }           public synchronized void method2() {               } }

 　　上述代码中的两个方法method1和method2都用synchronized修饰了，假如某一时刻，线程A执行到了method1，此时线程A获取了这个对象的锁，而由于method2也是synchronized方法，假如synchronized不具备可重入性，此时线程A需要重新申请锁。但是这就会造成一个问题，因为线程A已经持有了该对象的锁，而又在申请获取该对象的锁，这样就会线程A一直等待永远不会获取到的锁。而由于synchronized和Lock都具备可重入性，所以不会发生上述现象

2.3 java.util.concurrent.locks.ReadWriteLock读写锁

ReadWriteLock也是一个接口，在它里面只定义了两个方法：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

public interface ReadWriteLock {     /**      * Returns the lock used for reading.      *      * @return the lock used for reading.      */     Lock readLock();       /**      * Returns the lock used for writing.      *      * @return the lock used for writing.      */     Lock writeLock(); }

• 一个用来获取读锁，一个用来获取写锁。也就是说将文件的读写操作分开，分成2个锁来分配给线程，从而使得多个线程可以同时进行读操作。下面的ReentrantReadWriteLock实现了ReadWriteLock接口。

2.4 java.util.concurrent.locks.ReentrantReadWriteLock可重入锁

• ReentrantReadWriteLock里面提供了很多丰富的方法，不过最主要的有两个方法：readLock()和writeLock()用来获取读锁和写锁

3.synchronized与lock选择

• 在性能上来说，如果竞争资源不激烈，两者的性能是差不多的，而当竞争资源非常激烈时（即有大量线程同时竞争），此时Lock的性能要远远优于synchronized。所以说，在具体使用时要根据适当情况选择。

4.相关概念

1.可重入锁

　　如果锁具备可重入性，则称作为可重入锁。像synchronized和ReentrantLock都是可重入锁，可重入性在我看来实际上表明了锁的分配机制：基于线程的分配，而不是基于方法调用的分配。举个简单的例子，当一个线程执行到某个synchronized方法时，比如说method1，而在method1中会调用另外一个synchronized方法method2，此时线程不必重新去申请锁，而是可以直接执行方法method2。

　　看下面这段代码就明白了：

1 2 3 4 5 6 7 8 9

class MyClass {     public synchronized void method1() {         method2();     }           public synchronized void method2() {               } }

 　　上述代码中的两个方法method1和method2都用synchronized修饰了，假如某一时刻，线程A执行到了method1，此时线程A获取了这个对象的锁，而由于method2也是synchronized方法，假如synchronized不具备可重入性，此时线程A需要重新申请锁。但是这就会造成一个问题，因为线程A已经持有了该对象的锁，而又在申请获取该对象的锁，这样就会线程A一直等待永远不会获取到的锁。

　　而由于synchronized和Lock都具备可重入性，所以不会发生上述现象。

　　2.可中断锁

　　可中断锁：顾名思义，就是可以相应中断的锁。

　　在Java中，synchronized就不是可中断锁，而Lock是可中断锁。

　　如果某一线程A正在执行锁中的代码，另一线程B正在等待获取该锁，可能由于等待时间过长，线程B不想等待了，想先处理其他事情，我们可以让它中断自己或者在别的线程中中断它，这种就是可中断锁。

　　在前面演示lockInterruptibly()的用法时已经体现了Lock的可中断性。

　　3.公平锁

　　公平锁即尽量以请求锁的顺序来获取锁。比如同是有多个线程在等待一个锁，当这个锁被释放时，等待时间最久的线程（最先请求的线程）会获得该所，这种就是公平锁。

　　非公平锁即无法保证锁的获取是按照请求锁的顺序进行的。这样就可能导致某个或者一些线程永远获取不到锁。

　　在Java中，synchronized就是非公平锁，它无法保证等待的线程获取锁的顺序。

　　而对于ReentrantLock和ReentrantReadWriteLock，它默认情况下是非公平锁，但是可以设置为公平锁。

　　看一下这2个类的源代码就清楚了：

　　

　　在ReentrantLock中定义了2个静态内部类，一个是NotFairSync，一个是FairSync，分别用来实现非公平锁和公平锁。

　　我们可以在创建ReentrantLock对象时，通过以下方式来设置锁的公平性：

1	ReentrantLock lock = new ReentrantLock(true);

 　　如果参数为true表示为公平锁，为fasle为非公平锁。默认情况下，如果使用无参构造器，则是非公平锁。

　　

　　另外在ReentrantLock类中定义了很多方法，比如：

　　isFair()        //判断锁是否是公平锁

　　isLocked()    //判断锁是否被任何线程获取了

　　isHeldByCurrentThread()   //判断锁是否被当前线程获取了

　　hasQueuedThreads()   //判断是否有线程在等待该锁

　　在ReentrantReadWriteLock中也有类似的方法，同样也可以设置为公平锁和非公平锁。不过要记住，ReentrantReadWriteLock并未实现Lock接口，它实现的是ReadWriteLock接口。

　　4.读写锁

　　读写锁将对一个资源（比如文件）的访问分成了2个锁，一个读锁和一个写锁。

　　正因为有了读写锁，才使得多个线程之间的读操作不会发生冲突。

　　ReadWriteLock就是读写锁，它是一个接口，ReentrantReadWriteLock实现了这个接口。

　　可以通过readLock()获取读锁，通过writeLock()获取写锁。