lock与synchronized区别详解

最新推荐文章于 2025-03-29 22:58:59 发布

HolyCode_

最新推荐文章于 2025-03-29 22:58:59 发布

阅读量1.3k

点赞数 1

本文链接：https://blog.csdn.net/Primary_wind/article/details/79394000

版权

其实日常开发中，大多时间没有使用到lock以及synchronized的场景，导致有些遗忘了，这里再梳理一下。

1.各自优缺点

synchronized其实是java语言中的一个关键字，是内置的特性，这就导致它在使用上有一定的简洁性，如果使用lock，它作为接口的实现类，具备更强大的功能，但是需要自己确保锁的正确释放，各自优缺点如下：

当synchronized块结束时，会自动释放锁，lock一般需要在finally中自己释放。
当synchronized块执行异常时，也会自动释放锁，lock一般需要在finally中自己释放。
synchronized使用起来简单，不需要进行锁的额外处理，当成关键字使用，而lock一般需要创建对象，手动锁住，手动释放。
当synchronized块执行阻塞时，例如等待IO或者sleep方法时，无法中断，并释放锁，lock可以在线程休眠时，执行中断，提高性能。
当synchronized块执行时，只能使用非公平锁，无法实现公平锁，而lock可以通过new ReentrantLock(true)设置为公平锁，从而在某些场景下提高效率。
使用synchronized 无法判断当前线程是否成功获取到锁，lock可以通过trylock进行判断。
另外看资料，synchronized并发是通过阻塞其它线程实现的，线程再进行恢复时，是cpu内核级别的切换，性能较低，后面经过jdk的优化才逐步与lock效率对齐，但是并发场景非常高的情况下，还是lock性能较好。

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

2.1 Lock

其实是一个接口，定义了几个方法：

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

lock方法，其实就是获取锁，如果被其它线程获取，则进行等待。如果采用Lock，必须主动去释放锁，并且在发生异常时，不会自动释放锁。因此一般来说，使用Lock必须在try{}catch{}块中进行，并且将释放锁的操作放在finally块中进行，以保证锁一定被被释放，防止死锁的发生。通常使用Lock来进行同步的话，是以下面这种形式去使用的：
```
Lock lock = new ReentrantLock();
    lock.lock();
    try {
        //处理任务
    } catch (Exception ex) {

    } finally {
        lock.unlock(); //释放锁
    }
```
tryLock()方法是有返回值的，它表示用来尝试获取锁，如果获取成功，则返回true，如果获取失败（即锁已被其他线程获取），则返回false，也就说这个方法无论如何都会立即返回。在拿不到锁时不会一直在那等待。
　tryLock(long time, TimeUnit unit)方法和tryLock()方法是类似的，只不过区别在于这个方法在拿不到锁时会等待一定的时间，在时间期限之内如果还拿不到锁，就返回false。如果如果一开始拿到锁或者在等待期间内拿到了锁，则返回true。所以，一般情况下通过tryLock来获取锁时是这样使用的：
```
Lock lock = new ReentrantLock();
    if (lock.tryLock()) {
        try {
            //处理任务
        } catch (Exception ex) {

        } finally {
            lock.unlock(); //释放锁
        }
    } else {
        //如果不能获取锁，则直接做其他事情
    }
```
lockInterruptibly()方法比较特殊，当通过这个方法去获取锁时，如果线程正在等待获取锁，则这个线程能够响应中断，即中断线程的等待状态。也就使说，当两个线程同时通过lock.lockInterruptibly()想获取某个锁时，假若此时线程A获取到了锁，而线程B只有在等待，那么对线程B调用threadB.interrupt()方法能够中断线程B的等待过程。由于lockInterruptibly()的声明中抛出了异常，所以lock.lockInterruptibly()必须放在try块中或者在调用lockInterruptibly()的方法外声明抛出InterruptedException。一般的使用形式如下：
```
    Lock lock = new ReentrantLock();
    lock.lockInterruptibly();
    try {
        //.....
    }
    finally {
        lock.unlock();
    }
```

　　注意，当一个线程获取了锁之后，是不会被interrupt()方法中断的。因为本身在前面的文章中讲过单独调用interrupt()方法不能中断正在运行过程中的线程，只能中断阻塞过程中的线程。
　　因此当通过lockInterruptibly()方法获取某个锁时，如果不能获取到，只有进行等待的情况下，是可以响应中断的。
　　而用synchronized修饰的话，当一个线程处于等待某个锁的状态，是无法被中断的，只有一直等待下去。

2.2 ReentrantLock

　　ReentrantLock，意思是“可重入锁”，ReentrantLock是唯一实现了Lock接口的类，并且ReentrantLock提供了更多的方法。
详见：java.util.concurrent.locks.ReentrantLock ，不再列举了。

2.3 ReadWriteLock

接口，只定义了两个方法：

    Lock readLock();
    Lock writeLock();

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

2.4 ReentrantReadWriteLock

实现了ReadWriteLock接口。

下面尝试写个例子，表示ReadWriteLock和使用synchronized的区别。

使用synchronized时，读取文件：

public class SynchronizedReadFile {
    public static void main(String[] args) {
        final SynchronizedReadFile synchronizedReadFile = new SynchronizedReadFile();

        new Thread() {
            public void run() {
                synchronizedReadFile.read(Thread.currentThread());
            }
        }.start();

        new Thread() {
            public void run() {
                synchronizedReadFile.read(Thread.currentThread());
            }
        }.start();
    }

    public synchronized void read(Thread thread) {
        long start = System.currentTimeMillis();
        while(System.currentTimeMillis() - start <= 1) {
            System.out.println(thread.getName()+"正在进行读操作");
        }
        System.out.println(thread.getName()+"读操作完毕");
    }

}

结果是 thread0读取完成，才开始读取thread1，其实两个读取操作并不要求互斥，可以同时读取提高效率。
下面是使用reenterantReadWriteLock：

public class ReentrantReadWriteFile {

    private ReadWriteLock readWriteLock = new ReentrantReadWriteLock();

    public static void main(String[] args) {
        final ReentrantReadWriteFile reentrantReadWriteFile = new ReentrantReadWriteFile();

        new Thread() {
            public void run() {
                reentrantReadWriteFile.read(Thread.currentThread());
            }
        }.start();

        new Thread() {
            public void run() {
                reentrantReadWriteFile.read(Thread.currentThread());
            }
        }.start();

    }

    public void read(Thread thread) {
        readWriteLock.readLock().lock();
        try {
            long start = System.currentTimeMillis();
            while (System.currentTimeMillis() - start <= 1) {
                System.out.println(thread.getName() + "正在进行读操作");
            }
            System.out.println(thread.getName() + "读操作完毕");
        } finally {
            readWriteLock.readLock().unlock();
        }
    }
}

可以看到thread-0 和thread-1是交替同时读取的，极大的提高了效率。

不过要注意的是：
1.如果有一个线程已经占用了读锁，则此时其他线程如果要申请写锁，则申请写锁的线程会一直等待释放读锁。

2.如果有一个线程已经占用了写锁，则此时其他线程如果申请写锁或者读锁，则申请的线程会一直等待释放写锁。

3.下面列了一下锁的相关的介绍：

1.可重入锁

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

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都具备可重入性，所以不会发生上述现象。