多线程三个关键字：volatile、synchronized与Lock

傷城~ 2024-03-31 16:16 84阅读 0赞

参考博客：https://www.cnblogs.com/cg-ww/p/14540450.html  
https://zhuanlan.zhihu.com/p/563597528?utm\_id=0  
synchronized修饰变量，https://blog.csdn.net/dlf123321/article/details/53515756  
详解synchronized关键字，https://zhuanlan.zhihu.com/p/459633288

**1、volatile的作用：关键作用是使变量在多个线程之间可见**  
![在这里插入图片描述][e6e7a28db4a5430882672dc2ec8d6589.png_pic_center]  
![在这里插入图片描述][73ff501c41f74aefbec44a854e374f11.png_pic_center]  
程序并没有因为我修改之后结束运行，因为线程对共享变量具有不可见性，main线程修改布尔值之后，子线程看不到值的修改。因此要想实现线程的可见性这里可以加上volatile关键字修饰公共变量

**volatile关键字的作用：使线程在强制公共内存中读取变量值，保证可见性**  
增加volatile字段后：  
![在这里插入图片描述][22e1c242aacd42b592936fdbb240228c.png_pic_center]  
![在这里插入图片描述][bd4b1ff4af444ce2999a9805740495d2.png_pic_center]  
**2、volatile非原子特性**  
![在这里插入图片描述][2a4a8d2a2bff490db16fea913506cdf1.png_pic_center]  
无序，无规律：  
![在这里插入图片描述][497b886590b64dada7d48ae0e0aaeb58.png_pic_center]

加入volatile关键字：  
![在这里插入图片描述][524c1039f38247218eee71ea817041ac.png_pic_center]  
![在这里插入图片描述][02bad2a06e0946f88613853d0908a010.jpeg_pic_center]  
**按道理输出1000的整数倍数才对，但是变量在自增的过程中没有更新到又被读取再修改，因此volatile不具备原子性，正确办法将方法加上synchronized关键字**  
![在这里插入图片描述][c64ce4613fd145c39953de6573a4e95e.png_pic_center]  
![在这里插入图片描述][799bd70b7619474f99d77943ad798235.png_pic_center]  
**3、volatile与synchronized比较**

*  volatile关键字是线程同步的轻量级实现，所以volatile性能肯定比synchronized要好，volatile只能修饰变量，而synchronized可以修饰方法代码块，在开发中使用synchronized比例还是挺大的。
 *  **多线程访问volatile变量不会发生阻塞，而synchronized可能会阻塞。**
 *  **volatile能保证数据的可见性，但是不能保证原子性，而synchronized可以保证原子性，也可以保证可见性**，因为synchronized会将线程的工作内存和主内存进行同步
 *  volatile关键字保证多个线程之间的可见性，synchronized关键字解决线程访问公共资源的同步性。

<table> 
 <thead> 
  <tr> 
   <th>区别</th> 
   <th>synchronized</th> 
   <th>volatile</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>使用上</td> 
   <td>只能用于修饰方法、代码块、静态成员变量、非静态成员变量</td> 
   <td>只能修饰实例变量或者类关键字</td> 
  </tr> 
  <tr> 
   <td>原子性保证</td> 
   <td>能保证，排它方式使同步代码串行</td> 
   <td>无法保证</td> 
  </tr> 
  <tr> 
   <td>可见性保证</td> 
   <td>能保证，排它方式使同步代码串行</td> 
   <td>能保证，可以读取公共变量</td> 
  </tr> 
  <tr> 
   <td>有序性保证</td> 
   <td>能保证，在同步串行的时候</td> 
   <td>能保证，禁止JVM以及处理器进行排序</td> 
  </tr> 
  <tr> 
   <td><strong>阻塞情况</strong></td> 
   <td><strong>会发生阻塞</strong></td> 
   <td><strong>不会发生阻塞</strong></td> 
  </tr> 
 </tbody> 
</table>

**4、常用原子类进行自增自减操作（原理是无锁的CAS操作，线程安全）**  
i++不是原子操作，除了使用synchronized进行同步，也可以使用AtomicInteger/AtomicLong进行实现  
**4.1 非静态成员变量，无论synchronized是否修饰该成员变量，每个线程都打印输出1000**  
![在这里插入图片描述][963d9985deea4c5b9d688cacbce65e42.png_pic_center]  
![在这里插入图片描述][19707cd749db4b5795c0da3b84eb96ed.png_pic_center]

**4.2 静态成员变量，没有synchronized修饰该成员变量，无论AddCount是否是静态方法，每个线程不一定打印出整千数，没有实现线程安全。**  
count被不同的线程执行，某一线程打印的时候其他线程刚好正在对count进行自增到7984，此时打印出7984这个数  
![在这里插入图片描述][9a58dfcbd6034df08a036abc898df69d.png_pic_center]  
打印结果：  
![在这里插入图片描述][fc0ed6ed5f1e4b8ca2594d55885ff5bf.png_pic_center]  
**4.3 静态成员变量，有synchronized修饰该成员变量（synchronized修饰代码块），无论AddCount是否是静态方法，每个线程打印出整千数**  
![在这里插入图片描述][18d697c704084cfaa5a87f2e016dd5f3.png_pic_center]  
![在这里插入图片描述][57b0d6861fcd497493bc763f127c0afa.png_pic_center]

**4.4 静态成员变量，有synchronized修饰该类，无论AddCount是否是静态方法，每个线程打印出整千数**  
![在这里插入图片描述][8af98cb3884c4868b0f3bf36a76387f0.png_pic_center]

**synchronized(object)表示必须拿到key对象的锁才能执行synchronized代码块，凡是进入该同步代码块中的线程都必须先获得锁。synchronized(class)表示必须拿到class的锁才能执行synchronized代码块，同一个类下所有实例的线程都会受到影响。  
拿到锁才能执行，相当于串行运行**

打印结果：  
![在这里插入图片描述][f9ea930734574894ba481ac52857a28b.png_pic_center]  
**4.5 静态成员变量，有synchronized修饰this，无论AddCount是否是静态方法，每个线程不一定打印出整千数，没有实现线程安全**  
![在这里插入图片描述][eaa28fe46b27445aafb78ed34506eadd.png_pic_center]  
打印结果：  
![在这里插入图片描述][e4a686c0b20e4d4c90721cacc5c2dcf8.png_pic_center]  
**synchronized在修饰this的时候，只能确保同一个实例下所有线程之间的同步代码块互斥（线程安全），而不同实例的线程是不受影响的（线程不安全）**

**4.6 有synchronized修饰局部变量是包装类或new生成的对象、赋值操作，无论AddCount是否是静态方法，每个线程不一定打印出整千数，没有实现线程安全。有synchronized修饰局部变量是字符串常量，无论AddCount是否是静态方法，可以实现线程安全**  
![在这里插入图片描述][64cad1daa02245cc90add2b0677abda3.png_pic_center]  
打印结果：  
![在这里插入图片描述][cc55f0578a144e31ab1fd2fbc468a783.png_pic_center]  
![在这里插入图片描述][3c74b44501494a5db2b91840038968ac.png_pic_center]  
此时可以实现线程安全

**如果key是局部变量，这种情况也是可以的，但是需要注意的是，局部变量能够产生的效果最多也就和this差不多，并不适用于不同实例的场景**

**总结：**  
1、synchronized在修饰不同类型数据的时候，锁的粒度（互斥范围）也是不同的（这里只说最大粒度），简单总结就是：方法 > object > class > this。

this只会影响当前实例的线程访问；class会影响当前类所有实例的线程访问；而object会影响所有访问同步代码的访问；在方法上加synchronize关键字影响范围就更大了，会影响所有当前方法的访问，所以，其中最重的就是修饰方法时候，其次是修饰object，然后才是class和this。

当然object在一些特殊操作之下，也可以达到和class、this类似的效果。  
2、  
synchronized在修饰object的时候，必须是**不可变的对象或静态对象**（也就是钥匙必须唯一），否则是起不到阻塞（锁）的作用的。

**5、CAS**  
CAS（Compare And Swap）是由硬件实现的，  
CAS可以将read（读）-modify（修改）-write（写）转化为原子操作  
i++自增过程：  
**从主内存调取i变量值  
对i值加1  
再把加1过后的值保存到主内存**  
**CAS原理：在把数据更新到主内存时，再次读取主内存变量的值，如果现在变量的值与期望的值一样就更新。**  
![在这里插入图片描述][44abc78bb90f4760ada185d9f7cf1d61.jpeg_pic_center]  
参考博客：AQS和CAS原理  
https://blog.csdn.net/qq\_35222843/article/details/114062071  
**6、Lock和ReadWriteLock**  
![在这里插入图片描述][8ff5036ca25f47f4bb5035b4c778edc5.jpeg_pic_center]  
Lock：代表实现类是ReentrantLock（可重入锁）  
ReadWriteLock（读写锁）：代表实现类是ReentrantReadWriteLock

*  **synchronized**：  
    java关键字  
    不需要用户去手动释放锁，当synchronized方法或者synchronized代码块执行完之后，系统会自动让线程释放对锁的占用
 *  **Lock**：  
    一个类  
    Lock则必须要用户去手动释放锁，如果没有主动释放锁，就有可能导致出现死锁现象
 *  **synchronized 的局限性 与 Lock 的优点**  
    如果一个代码块被synchronized关键字修饰，当一个线程获取了对应的锁，并执行该代码块时，其他线程便只能一直等待直至占有锁的线程释放锁。事实上，占有锁的线程释放锁一般会是以下三种情况之一：

1：占有锁的线程执行完了该代码块，然后释放对锁的占有；

2：占有锁线程执行发生异常，此时JVM会让线程自动释放锁；

3：占有锁线程进入 WAITING 状态从而释放锁，例如在该线程中调用wait()方法等。

试考虑以下三种情况：

Case 1 ：

在使用synchronized关键字的情形下，假如占有锁的线程由于要等待IO或者其他原因（比如调用sleep方法）被阻塞了，但是又没有释放锁，那么其他线程就只能一直等待，别无他法。这会极大影响程序执行效率。因此，就需要有一种机制可以不让等待的线程一直无期限地等待下去（比如只等待一定的时间 (解决方案：tryLock(long time, TimeUnit unit)) 或者 能够响应中断 (解决方案：lockInterruptibly())），这种情况可以通过 Lock 解决。

Case 2 ：

我们知道，当多个线程读写文件时，读操作和写操作会发生冲突现象，写操作和写操作也会发生冲突现象，但是读操作和读操作不会发生冲突现象。但是如果采用synchronized关键字实现同步的话，就会导致一个问题，即当多个线程都只是进行读操作时，也只有一个线程在可以进行读操作，其他线程只能等待锁的释放而无法进行读操作。因此，需要一种机制来使得当多个线程都只是进行读操作时，线程之间不会发生冲突。同样地，Lock也可以解决这种情况 (解决方案：ReentrantReadWriteLock) 。

Case 3 ：

我们可以通过Lock得知线程有没有成功获取到锁 (解决方案：ReentrantLock) ，但这个是synchronized无法办到的。

上面提到的三种情形，我们都可以通过Lock来解决，但 synchronized 关键字却无能为力。事实上，Lock 是 java.util.concurrent.locks包 下的接口，Lock 实现提供了比 synchronized 关键字 更广泛的锁操作，它能以更优雅的方式处理线程同步问题。也就是说，Lock提供了比synchronized更多的功能。

*  **Lock接口实现类的使用**  
    Lock接口有6个方法：  
    ![在这里插入图片描述][fc476a5714174242ac8d048b2a93016a.png_pic_center]  
    下面来逐个分析Lock接口中每个方法。lock()、tryLock()、tryLock(long time, TimeUnit unit) 和 lockInterruptibly()都是用来获取锁的。unLock()方法是用来释放锁的。newCondition() 返回 绑定到此 Lock 的新的 Condition 实例 ，用于线程间的协作，详细内容请查找关键词：线程间通信与协作。  
    1). lock()

在Lock中声明了四个方法来获取锁，那么这四个方法有何区别呢？首先，lock()方法是平常使用得最多的一个方法，就是用来获取锁。如果锁已被其他线程获取，则进行等待。在前面已经讲到，如果采用Lock，必须主动去释放锁，并且在发生异常时，不会自动释放锁。因此，一般来说，使用Lock必须在try…catch…块中进行，并且将释放锁的操作放在finally块中进行，以保证锁一定被被释放，防止死锁的发生。通常使用Lock来进行同步的话，是以下面这种形式去使用的：  
![在这里插入图片描述][4d66937bba514f178acc287ab9668b54.png_pic_center]  
2). tryLock() & tryLock(long time, TimeUnit unit)

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

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

一般情况下，通过tryLock来获取锁时是这样使用的：  
![在这里插入图片描述][e2859ae91370410eb72ac37c0c6578aa.png_pic_center]  
3). lockInterruptibly()

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

由于lockInterruptibly()的声明中抛出了异常，所以lock.lockInterruptibly()必须放在try块中或者在调用lockInterruptibly()的方法外声明抛出 InterruptedException，但推荐使用后者，原因稍后阐述。因此，lockInterruptibly()一般的使用形式如下：  
![在这里插入图片描述][9d0ee089dffb4440af1e8766e3d32fc8.png_pic_center]  
注意，当一个线程获取了锁之后，是不会被interrupt()方法中断的。因为interrupt()方法只能中断阻塞过程中的线程而不能中断正在运行过程中的线程。因此，当通过lockInterruptibly()方法获取某个锁时，如果不能获取到，那么只有进行等待的情况下，才可以响应中断的。与 synchronized 相比，当一个线程处于等待某个锁的状态，是无法被中断的，只有一直等待下去。

*  **Lock的实现类 ReentrantLock**

ReentrantLock，即 可重入锁。ReentrantLock是唯一实现了Lock接口的类，并且ReentrantLock提供了更多的方法。下面通过一些实例学习如何使用 ReentrantLock。

构造方法（不带参数 和带参数 true： 公平锁； false: 非公平锁）：  
![在这里插入图片描述][54c0217590f4450593b0c98207abf5b4.png_pic_center]  
打印结果：  
![在这里插入图片描述][52f4367f22cb4b5ebf15cfeaa9a5f7ab.png_pic_center]  
从执行结果可以看出，A线程和B线程同时对资源加锁，A线程获取锁之后，B线程只好等待，直到A线程释放锁B线程才获得锁。  
总结一下，也就是说Lock提供了比synchronized更多的功能。但是要注意以下几点：

1）synchronized是Java语言的关键字，因此是内置特性，Lock不是Java语言内置的，Lock是一个接口，通过实现类可以实现同步访问。

2）synchronized是在JVM层面上实现的，不但可以通过一些监控工具监控synchronized的锁定，而且在代码执行时出现异常，JVM会自动释放锁定，但是使用Lock则不行，**lock是通过代码实现的，要保证锁定一定会被释放，就必须将unLock()放到finally\{\}中**

3）**在资源竞争不是很激烈的情况下，Synchronized的性能要优于ReetrantLock，但是在资源竞争很激烈的情况下，Synchronized的性能会下降几十倍，但是ReetrantLock的性能能维持常态。**

*  **ReadWriteLock锁**　  
    　ReadWriteLock 接口只有两个方法：  
    ![在这里插入图片描述][1d3078adf66a4bc7af3b0fb23c112c6b.png_pic_center]  
    ReadWriteLock 维护了一对相关的锁，一个用于只读操作，另一个用于写入操作。只要没有 writer，读取锁可以由多个 reader 线程同时保持，而写入锁是独占的。  
    【例子】三个线程同时对一个共享数据进行读写  
    ![在这里插入图片描述][cfe2155374704813bdfe31d1902b392e.png_pic_center]  
    ![在这里插入图片描述][c93560a02e0245f699842cdfb9971dcf.png_pic_center]  
    打印结果：  
    ![在这里插入图片描述][e316993490ec42a8b4770e1aae55e7de.png_pic_center]

[e6e7a28db4a5430882672dc2ec8d6589.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/28d09d5a41ff471798c34af86b290d38.png
[73ff501c41f74aefbec44a854e374f11.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/eaac0cd0cade4384aa36987ccf87da66.png
[22e1c242aacd42b592936fdbb240228c.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/b18e23883da1486580c3bc57c4f00e7f.png
[bd4b1ff4af444ce2999a9805740495d2.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/3978ee9d5a6b4047be228de34d7e2299.png
[2a4a8d2a2bff490db16fea913506cdf1.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/a3b4ebea12d949b9b0726e45dad2bf2e.png
[497b886590b64dada7d48ae0e0aaeb58.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/a2a2282683814d40805e8dd1441b100f.png
[524c1039f38247218eee71ea817041ac.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/02cfa8c646d947d2b62dbfdd0009189d.png
[02bad2a06e0946f88613853d0908a010.jpeg_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/729fb7a1aada4da0b5c8911db37cb48e.jpeg
[c64ce4613fd145c39953de6573a4e95e.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/2f6bfe37e4fa4d6a82549f45d7afbb13.png
[799bd70b7619474f99d77943ad798235.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/a9a363e5a557417b89d6836356971ecd.png
[963d9985deea4c5b9d688cacbce65e42.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/c367ae9f365d40329ac043627ffbde41.png
[19707cd749db4b5795c0da3b84eb96ed.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/bfc0dad08d19454faf7c168b8818b5a4.png
[9a58dfcbd6034df08a036abc898df69d.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/53cc925679fd44f5ae416c5bd7dc7edc.png
[fc0ed6ed5f1e4b8ca2594d55885ff5bf.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/e606f172ed7742b6bc748ff87c96666d.png
[18d697c704084cfaa5a87f2e016dd5f3.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/5795a60b8a494bb3830d033690c4567e.png
[57b0d6861fcd497493bc763f127c0afa.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/4342726e7b0c43c184d9b04fa98d3634.png
[8af98cb3884c4868b0f3bf36a76387f0.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/9171775fa95842009a4cc916f23b944b.png
[f9ea930734574894ba481ac52857a28b.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/3aec8002037b4f998264c6dc3fed0da3.png
[eaa28fe46b27445aafb78ed34506eadd.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/8afd7bfe39f443ff9363a0123a170af3.png
[e4a686c0b20e4d4c90721cacc5c2dcf8.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/57ba7c5cd9f149088e94400bec91f864.png
[64cad1daa02245cc90add2b0677abda3.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/f34c89cb2c384201b7ce1d7d50465998.png
[cc55f0578a144e31ab1fd2fbc468a783.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/97a053fed3e9413c830bb1c2e9094aeb.png
[3c74b44501494a5db2b91840038968ac.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/3f46f46de0344003993664775dc0e098.png
[44abc78bb90f4760ada185d9f7cf1d61.jpeg_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/ee97f39ac4814074883eef82f48ee56f.jpeg
[8ff5036ca25f47f4bb5035b4c778edc5.jpeg_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/f546f5ccf71d4f80a0398255168e9e33.jpeg
[fc476a5714174242ac8d048b2a93016a.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/8f1ad6e07a0f4fd383e68bafec17d8c3.png
[4d66937bba514f178acc287ab9668b54.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/c565048d2b9d4023b860ec116705b178.png
[e2859ae91370410eb72ac37c0c6578aa.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/2425888a190e43d9b4534cf0f5a50db5.png
[9d0ee089dffb4440af1e8766e3d32fc8.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/4470b3915fdb4fe5998d6a750dff430a.png
[54c0217590f4450593b0c98207abf5b4.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/1f7cf141cff742b5ad51b8a696fe4a2c.png
[52f4367f22cb4b5ebf15cfeaa9a5f7ab.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/295352ae9dbc4d5c8e9662ce0c7dfd26.png
[1d3078adf66a4bc7af3b0fb23c112c6b.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/926ad26dafe440e8b34fe02003dbcb59.png
[cfe2155374704813bdfe31d1902b392e.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/8ad4260d636746fbbea8d219cd07ed75.png
[c93560a02e0245f699842cdfb9971dcf.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/baa50c0f7e904de2971082d69742d806.png
[e316993490ec42a8b4770e1aae55e7de.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/ff8d58a64be146a8a133dacb0852018b.png