Synchronized和Lock和volatile对比

点击上方“罗晓胜”，马上关注，您的支持对我帮助很大

 

上期文章

 

 

• 线程池工作原理与底层实现

• 3强盗3商人过河问题

 

/   前言   /

 

我们可能都知道加锁要使用Synchronized，或者还知道有Lock这个东西，但是你知道它们有什么不同吗，他们又分别适用于什么样的场景，本篇文章咱们来探讨一下。

 

/   正文   /

 

Synchronized

锁的等级：

• 方法锁

• 对象锁

• 类锁

在并发编程中，多线程同时并发访问的资源叫做临界资源，当多个线程同时访问对象并要求操作相同资源时，分割了原子操作就有可能出现数据的不一致或数据不完整的情况，为避免这种情况的发生，我们会采取同步机制，以确保在某一时刻，方法内只允许有一个线程。

• 互斥锁

  • 采用synchronized修饰符实现的同步机制叫做互斥锁机制，它所获得的锁叫做互斥锁。

  • 每个对象都有一个monitor(锁标记)，当线程拥有这个锁标记时才能访问这个资源，没有锁标记便进入锁池。

  • 任何一个对象系统都会为其创建一个互斥锁，这个锁是为了分配给线程的，防止打断原子操作。

  • 每个对象的锁只能分配给一个线程，因此叫做互斥锁。

• 这里就使用同步机制获取互斥锁的情况，进行几点说明：

  1. 如果同一个方法内同时有两个或更多线程，则每个线程有自己的局部变量拷贝。

  2. 类的每个实例都有自己的对象级别锁。当一个线程访问实例对象中的synchronized同步代码块或同步方法时，该线程便获取了该实例的对象级别锁，其他线程这时如果要访问synchronized同步代码块或同步方法，便需要阻塞等待，直到前面的线程从同步代码块或方法中退出，释放掉了该对象级别锁。

  3. 访问同一个类的不同实例对象中的同步代码块，不存在阻塞等待获取对象锁的问题，因为它们获取的是各自实例的对象级别锁，相 互之间没有影响。

  4. 持有一个对象级别锁不会阻止该线程被交换出来，也不会阻塞其他线程访问同一示例对象中的非synchronized代码。当一个线程A持有一个对象级别锁（即进入了synchronized修饰的代码块或方法中）时，线程也有可能被交换出去，此时线程B有可能获取执行该对象中代码的时间，但它只能执行非同步代码（没有用synchronized修饰），当执行到同步代码时，便会被阻塞，此时可能线程规划器又让A线程运行，A线程继续持有对象级别锁，当A线程退出同步代码时（即释放了对象级别锁），如果B线程此时再运行，便会获得该对象级别锁，从而执行synchronized中的代码。

  5. 持有对象级别锁的线程会让其他线程阻塞在所有的synchronized代码外。例如，在一个类中有三个synchronized方法a，b，c，当线程A正在执行一个实例对象M中的方法a时，它便获得了该对象级别锁，那么其他的线程在执行同一实例对象（即对象M）中的代码时，便会在所有的synchronized方法处阻塞，即在方法a，b，c处都要被阻塞，等线程A释放掉对象级别锁时，其他的线程才可以去执行方法a，b或者c中的代码，从而获得该对象级别锁。

  6. 使用synchronized（obj）同步语句块，可以获取指定对象上的对象级别锁。obj为对象的引用，如果获取了obj对象上的对象级别锁，在并发访问obj对象时时，便会在其synchronized代码处阻塞等待，直到获取到该obj对象的对象级别锁。当obj为this时，便是获取当前对象的对象级别锁。

  7. 类级别锁被特定类的所有示例共享，它用于控制对static成员变量以及static方法的并发访问。具体用法与对象级别锁相似。

  8. 互斥是实现同步的一种手段，临界区、互斥量和信号量都是主要的互斥实现方式。synchronized关键字经过编译后，会在同步块的前后分别形成monitorenter和monitorexit这两个字节码指令。根据虚拟机规范的要求，在执行monitorenter指令时，首先要尝试获取对象的锁，如果获得了锁，把锁的计数器加1，相应地，在执行monitorexit指令时会将锁计数器减1，当计数器为0时，锁便被释放了。由于synchronized同步块对同一个线程是可重入的，因此一个线程可以多次获得同一个对象的互斥锁，同样，要释放相应次数的该互斥锁，才能最终释放掉该锁。

synchromized缺陷

• synchronized是java中的一个关键字，也就是说是java语言的内置的特性。如果一个代码块被synchronized修饰，当一个线程获取了对应的锁，并执行代码块时，其他线程只能一直等待，等待获取锁的线程释放锁，而这里获取锁的线程释放锁只会有两种情况：

  1. 获取锁的线程执行完了改代码块，然后线程释放对锁的占有

  2. 线程执行发生异常，此时JVM会让线程自动释放锁。

• 例子1：

　　如果这个获取锁的线程由于要等待IO或者其他原因（比如调用sleep方法）被阻塞了，但是又没有释放锁，其他线程便只能干巴巴地等待，试想一下，这多么影响程序执行效率。　　因此就需要有一种机制可以不让等待的线程一直无期限地等待下去（比如只等待一定的时间或者能够响应中断），通过Lock就可以办到。

• 例子2：

  当有多个线程读写文件时，读操作和写操作会发生冲突现象，写操作和写操作会发生冲突现象，但是读操作和读操作不会发生冲突现象。但是采用synchronized关键字来实现同步的话，就会导致一个问题：如果多个线程都只是进行读操作，当一个线程在进行读操作时，其他线程只能等待无法进行读操作。因此就需要一种机制来使得多个线程都只是进行读操作时，线程之间不会发生冲突，通过Lock就可以办到。

• 通过Lock可以知道线程有没有成功获取到锁。这个是synchronized无法办到的。总的来说，也就是说Lock提供了比synchronized更多的功能。

---

Lock

lock和synchronized的区别

• lock不是java语言内置的，synchronized是java语言的关键字，因此是内置特性。lock是一个类，通过这个类可以实现同步访问；

• lock和synchronized有一点非常大的不同，采用synchronized不需要用户手动的去释放锁，当synchronized方法或者代码块执行完毕之后，系统会自动的让线程释放对锁的占有，而lock则必须要用户去手动释放锁，如果没有主动的释放锁，就会可能导致出现死锁的现象

Lock用法

• 首先要说明的就是，通过查看LOCK 的源码可知道，lock是一个接口

• lock接口中每个方法的使用：

  • 获取锁：lock()、tryLock（）、tryLock(long time, TimeUnit unit)、lockInterruptibly()

  • 释放锁：unLock()

Lock四个获取锁方法的区别：

1. lock（）方法时平常使用的最多的一个方法，就是用来获取锁的，如果锁已经被其他线程获取，则进行等待。由于在前面讲到如果采用lock，必须主动去释放锁，并且在发生异常时，不会自动释放锁。因此一般来说，使用lock必须在try{}catch{}块中进行，并且将释放锁的操作放在finally块中进行，以保证锁一定被释放掉，防止死锁的发生。

2. tryLock（）方法是有返回值的，他表示用来尝试获取锁，如果获取成功，则返回true，如果获取失败（即锁已经被其他线程获取），则返回false，也就说这个方法无论如何都会立即返回。在拿不到锁时不会一直在哪里等待

3. tryLock(long time, TimeUnit unit)方法和tryLock（）方法时类似的，只不过区别在于这个方法在拿不到锁时会等待一定时间，在时间限制之内如果还是拿不到锁，就返回false。如果一开始就拿到锁或者在等待期间内拿到了锁，则就返回true。

4. lockinterruptibly（）方法比较特殊，当通过这个方法区获取锁时，如果线程正在等待获取锁，则这个线程能够相应中断，即中断线程的等待状态。也就是说，当一个线程同时通过lock.lockinterruputibly（）向获取某个锁时，假如此时线程A获取到了锁，而线程B只有等待，那么对线程调用threadB.interrupt()方法能够中断线程B的等待过程。

• 注意：当一个线程获取了锁之后，是不会被interrupt（）方法中断的 因此当通过lockinterruptibly（）方法获取某个锁时，如果不能获取到，只有进行等待的情况下，是可以相应中断的 而用synchronized修饰的话，当一个线程处于等待某个锁的状态，是无法被中断的，只有一直等待下去。

ReentrantLock

• 直接使用lock接口的话，我们需要实现很多方法，不太方便，ReentrantLock是唯一实现了Lock接口的类，并且ReentrantLock提供了更多的方法，ReentrantLock，意思是“可重入锁”。

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

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

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

LOCK和SYNCHRONIZED的选择

1. lock是一个接口，而synchronized是java的关键字，synchronized是内置的语言实现；

2. synchronized在发生异常时，会自动释放线程占有的锁，因此不会导致死锁现象发生；而lock在发生异常时，如果没有主动通过unlock（）去释放锁，则很可能造成死锁现象，因此使用lock（）时需要在finally块中释放锁；

3. lock可以让等待锁的线程响应中断，而synchronized却不行，使用synchronized时，等待的线程会一直等待下去，不会响应中断

4. 通过lock可以知道有没有成功获取锁，而synchronized却无法办到

5. lock可以提高多个线程进行读操作的效率

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

---

volatile

volatile作用

• 在JDK1.2之前，Java的类型模型实现总是从主存(即共享内存)读取变量，是不需要进行特别的注意的。而随着JVM的成熟和优化，现在在多线程环境下volatile关键字的使用变的非常重要。

• 在当前的Java内存模型下，线程可以把变量保存在本地内存(比如机器的寄存器)中，而不是直接在主存中进行读写。这就可能造成一个线程在主存中修改了一个变量的值，而另一个线程还在继续使用它在寄存器中的变量值的拷贝，造成数据的不一致。

• 要解决这个问题，就需要把变量声明为volatile，这就指示JVM，这个变量是不稳定的，每次使用它都到主存中进行读取。一般来说，多任务环境下，各任务间共享的变量都应该加volatile修饰符。

volatile特性

• volatile修饰的成员变量在每次被线程访问时，都强迫从共享内存中重读该成员变量的值。

• 而且，当成员变量发生变化时，强迫线程将变化值回写到共享内存。

• 这样在任何时刻，两个不同的线程总是看到某个成员变量的同一个值。

• Java语言规范中指出：为了获得最佳速度，允许线程保存成员变量的私有拷贝，而且只当线程进入或者离开同步代码块时才将私有拷贝与共享内存中的原始值进行比较。这样当多个线程同时与某个对象交互时，就必须注意到要让线程及时的得到共享成员变量的变化。而volatile关键字就是提示JVM：对于这个成员变量，不能保存它的私有拷贝，而应直接与共享成员变量交互。

volatile和synchronized比较

• volatile是一种稍弱的同步机制，在访问volatile变量时不会执行加锁操作，也就不会执行线程阻塞，因此volatilei变量是一种比synchronized关键字更轻量级的同步机制。

volatile使用建议

• 在两个或者更多的线程需要访问的成员变量上使用volatile。

• 当要访问的变量已在synchronized代码块中，或者为常量时，或者为常量时，没必要使用volatile。

• 由于使用volatile屏蔽掉了JVM中必要的代码优化，所以在效率上比较低，因此一定在必要时才使用此关键字。

• 当该变量的值由自身的上一个决定时，volatile的作用就将失效，这是由volatile关键字的性质所决定的。

ThreadLocal

• ThreadLocal是一个线程的局部变量(其实就是一个Map),ThreadLocal会为每个使用该变量的线程提供独立的变量副本，所以每一个线程都可以独立地改变自己的副本，而不会影响其它线程所对应的副本。

• 这样做其实就是以空间换时间的方式(与synchronized相反)，以耗费内存为代价，单大大减少了线程同步(如synchronized)所带来性能消耗以及减少了线程并发控制的复杂度。

---

内存可见性

• 加锁（synchronized同步）的功能不仅仅局限于互斥行为，同时还存在另外一个重要的方面：内存可见性。

• 我们不仅希望防止某个线程正在使用对象状态而另一个线程在同时修改该状态，而且还希望确保当一个线程修改了对象状态后，其他线程能够看到该变化。而线程的同步恰恰也能够实现这一点。

• 内置锁可以用于确保某个线程以一种可预测的方式来查看另一个线程的执行结果。为了确保所有的线程都能看到共享变量的最新值，可以在所有执行读操作或写操作的线程上加上同一把锁。下图示例了同步的可见性保证。

当线程A执行某个同步代码块时，线程B随后进入由同一个锁保护的同步代码块，这种情况下可以保证，当锁被释放前，A看到的所有变量值（锁释放前，A看到的变量包括y和x）在B获得同一个锁后同样可以由B看到。换句话说，当线程B执行由锁保护的同步代码块时，可以看到线程A之前在同一个锁保护的同步代码块中的所有操作结果。如果在线程A unlock M之后，线程B才进入lock M，那么线程B都可以看到线程A unlock M之前的操作，可以得到i=1，j=1。如果在线程B unlock M之后，线程A才进入lock M，那么线程B就不一定能看到线程A中的操作，因此j的值就不一定是1。

现在考虑如下代码：

public class  MutableInteger
{
    private int value;
  
    public int get(){
        return value;
    }
    public void set(int value){
        this.value = value;
    }
}

以上代码中，get和set方法都在没有同步的情况下访问value。如果value被多个线程共享，假如某个线程调用了set，那么另一个正在调用get的线程可能会看到更新后的value值，也可能看不到。

通过对set和get方法进行同步，可以使MutableInteger成为一个线程安全的类，如下：

public class  SynchronizedInteger
{
    private int value;
  
    public synchronized int get(){
        return value;
    }
    public synchronized void set(int value){
        this.value = value;
    }
}

对set和get方法进行了同步，加上了同一把对象锁，这样get方法可以看到set方法中value值的变化，从而每次通过get方法取得的value的值都是最新的value值。

并发编程中实现内存可见的两种方法：加锁和volatile变量

1. volatile变量是一种稍弱的同步机制在访问volatile变量时不会执行加锁操作，因此也就不会使执行线程阻塞，因此volatile变量是一种比synchronized关键字更轻量级的同步机制。

2. 从内存可见性的角度看，写入volatile变量相当于退出同步代码块，而读取volatile变量相当于进入同步代码块。

3. 在代码中如果过度依赖volatile变量来控制状态的可见性，通常会比使用锁的代码更脆弱，也更难以理解。仅当volatile变量能简化代码的实现以及对同步策略的验证时，才应该使用它。一般来说，用同步机制会更安全些。

4. 加锁机制（即同步机制）既可以确保可见性又可以确保原子性，而volatile变量只能确保可见性，原因是声明为volatile的简单变量如果当前值与该变量以前的值相关，那么volatile关键字不起作用，也就是说如下的表达式都不是原子操作：“count++”、“count = count+1”。

• 当且仅当满足以下所有条件时，才应该使用volatile变量：

  1. 对变量的写入操作不依赖变量的当前值，或者你能确保只有单个线程更新变量的值。

  2. 该变量没有包含在具有其他变量的不变式中。

• 总结：在需要同步的时候，第一选择应该是synchronized关键字，这是最安全的方式，尝试其他任何方式都是有风险的。尤其在、jdK1.5之后，对synchronized同步机制做了很多优化，如：自适应的自旋锁、锁粗化、锁消除、轻量级锁等，使得它的性能明显有了很大的提升。

 

/   总结   /

 

本文主要讲了Synchronized和Lock和volatile对比分析，这也是我们讲java并发中非常重要的内容，不但工作中经常会用到，面试中也经常用来考量面试者的水平。

 

 

往期推荐：

如何入门做软件开发

为什么我不推荐入行程序员

做全栈开发很难吗

关注我的公众号，学习技术或投稿

长按上图，识别图中二维码即可关注