保证线程安全的方法

刺骨的言语ヽ痛彻心扉 2023-10-13 14:05 53阅读 0赞

#### 保证线程安全的方法 ####

*  线程安全问题
 *  保证线程安全的方法
 *   *  无状态
     *  不可变
     *  无修改权限
     *  synchronized
     *  lock
     *  分布式锁
     *  分布式锁的分类
     *  volatile
     *  ThreadLocal
     *  线程安全集合
     *  CAS
     *  数据隔离

## 线程安全问题 ##

主要是在多线程的环境下，不同线程同时读和写公共资源（临界资源）导致的数据异常问题。

## 保证线程安全的方法 ##

### 无状态 ###

我们都知道只有多个线程访问线程资源的时候，才会出现数据安全问题。

那么如果没有公共资源，就不存在线程安全问题了。  
![在这里插入图片描述][f82175f721d64a60af064d5b9034334b.png]  
图中这个例子中NoStatusService没有定义公共资源。换句话说是无状态的，这种场景中，NoStatusService肯定是线程安全的。

### 不可变 ###

如果多个线程访问的公共资源是不可变的，也不会出现数据的安全性问题。  
![在这里插入图片描述][4a629b04f8eb44b2a6e3b36c4cb87264.png]  
图中DEFAULTNAME被定义成了static final的常量，在多线程环境中不会被修改。所以这种情况，也不会出现线程安全问题。

### 无修改权限 ###

我们定义了公共资源，但是该资源只暴露了读取的权限，没有暴露修改的权限。这样也是线程安全的。  
![在这里插入图片描述][81b8aa3c7f654dafb0d2454cc2ec5841.png]  
图中这个例子中没有对外暴露修改name字段的入口，所以不存在线程安全问题。

### synchronized ###

使用JDK内部提供的同步机制，这也是使用比较多的手段，分为同步方法和同步代码块。

我们优先使用同步代码块。因为同步方法的粒度是整个方法。范围太大，相对来说，更消耗代码的性能。  
![在这里插入图片描述][8c94ecd885234309932f19db0239f9b0.png]  
其实，每个对象内部都有一把锁。只有抢到那把锁的线程才被允许进入对应的代码块执行相应的代码。当代码块执行完之后，JVM底层会自动释放那把锁。

### lock ###

Lock除了使用synchronized关键字来实现同步功能之外，JDK还提供了Lock接口。

这种显示锁的方式，通常我们会使用Lock接口的实现类ReentrantLock。它包含了公平锁、非公平锁、可重入锁、读写锁等更多更强大的功能。  
![在这里插入图片描述][00c0dacac8804d80af27204444b18288.png]  
但如果使用ReentrantLock，它也带来了个小问题就是需要在finnally代码块中手动释放锁。

不过，在使用Lock显示锁的方式解决线程安全问题，给开发人员提供了更多的灵活性。

### 分布式锁 ###

分布式锁如果是在单机的情况下，使用synchronized和Lock保证线程安全是没有问题的。

但如果在分布式的环境中，即某个应用如果部署了多个节点，每个节点可以使用synchronized和Lock保证线程安全。但不同的节点之间，没法保证线程安全。

这就需要使用分布式锁了。

### 分布式锁的分类 ###

数据库分布式锁、zookeeper分布式锁、redis分布式锁等。

其中更加推荐使用redis分布式锁。其效率相对来说更高一些。

使用redis分布式锁的伪代码如图所示：  
![在这里插入图片描述][e455ef2863ca4073b42797fbea9f7d01.png]  
同样需要在finally代码块中释放锁。

### volatile ###

有时候，我们有这样的需求，有任意一个线程，把某个开关的状态设置为false，则整个功能停止。

简单的需求分析之后发现，只要求多个线程间的可见性，不要求原子性。如果一个线程修改了状态。其他的所有线程都能获取到最新的状态值。

这样一分析就好办了。使用volatile就能快速满足需求。  
![在这里插入图片描述][189d8e78b0e543e487e1dfee341d3ef7.png]

### ThreadLocal ###

除了上面几种解决思路之外，JDK还提供了另外一种用空间换时间的新思路。  
![在这里插入图片描述][23f277263ac7464c974f368663def370.png]  
当然ThreadLocal并不能完全取代锁，特别是在一些秒杀更新库存中，必须使用锁。

ThreadLocal的核心思想是共享变量在每个线程都有一个副本，每个线程操作的都是自己的副本，对另外的线程没有影响。

### 线程安全集合 ###

有时候我们需要使用的公共资源放在某个集合当中，比如ArrayList、HashMap、HashSet等。

如果在多线程环境中，有线程往这些集合中写数据。另外的线程从集合中读数据，就可能会出现线程安全问题。

为了解决集合的线程安全问题，JDK专门给我们提供了能够保证线程安全的集合，比如CopyOnWriteArrayList、ConcurrentHashMap、CopyOnWriteArraySet、ArrayBlockingQueue等等。

在JDK底层或者Spring框架当中，使用ConcurrentHashMap保存加载配置参数的场景非常多。

比较出名的是spring的refresh方法中会读取配置文件，把配置放到很多的ConcurrentHashMap缓存起来。  
![在这里插入图片描述][a9046de3058d46a3952378ca40ebc934.png]

### CAS ###

JDK除了使用锁的机制解决多线程情况下数据安全问题之外，还提供了CAS机制。

这种机制是使用CPU中比较和交换指令的原子性。  
![在这里插入图片描述][5408c09ad49a488ab3edc4b908281c14.png]  
JDK里面是通过Unsafe类实现的，CAS内部包含了四个值。旧数据、期望数据、新数据和地址，比价旧数据期望的数据，如果一样的话，就把旧数据改成新数据。如果不一样的话，当前线程不断自旋，一直到成功为止。

不过使用CAS保证线程安全，可能会出现ABA问题，需要使用AtomicStampedReference**增加版本号**来解决。

其实实际工作中很少直接使用Unsafe类的，一般用atomic包下面的类即可。

### 数据隔离 ###

有时候，我们在操作集合数据时，可以通过数据隔离，来保证线程安全，使用线程池处理用户信息。

每个用户只被线程池中的一个线程处理。不存在多个线程同时处理一个用户的情况，所以这种人为的数据隔离机制也能保证线程安全。  
![在这里插入图片描述][5599f92cd692400eb1476431e3622982.png]  
数据隔离还有另外一个场景，kafka生产者把同一个订单的消息发送到同一个partion中，每个partion都部署一个消费者。在kafaka消费者中，使用单线程接收消息，并且做业务处理。这种场景下，从整体上看，不同的partion是用多线程处理数据的，但同一个partion则是用单线程处理的。

所以也能解决线程安全问题。

**参考资料**：[Java中保证线程安全的11个小技巧][Java_11]

[f82175f721d64a60af064d5b9034334b.png]: https://img-blog.csdnimg.cn/f82175f721d64a60af064d5b9034334b.png
[4a629b04f8eb44b2a6e3b36c4cb87264.png]: https://img-blog.csdnimg.cn/4a629b04f8eb44b2a6e3b36c4cb87264.png
[81b8aa3c7f654dafb0d2454cc2ec5841.png]: https://img-blog.csdnimg.cn/81b8aa3c7f654dafb0d2454cc2ec5841.png
[8c94ecd885234309932f19db0239f9b0.png]: https://img-blog.csdnimg.cn/8c94ecd885234309932f19db0239f9b0.png
[00c0dacac8804d80af27204444b18288.png]: https://img-blog.csdnimg.cn/00c0dacac8804d80af27204444b18288.png
[e455ef2863ca4073b42797fbea9f7d01.png]: https://img-blog.csdnimg.cn/e455ef2863ca4073b42797fbea9f7d01.png
[189d8e78b0e543e487e1dfee341d3ef7.png]: https://img-blog.csdnimg.cn/189d8e78b0e543e487e1dfee341d3ef7.png
[23f277263ac7464c974f368663def370.png]: https://img-blog.csdnimg.cn/23f277263ac7464c974f368663def370.png
[a9046de3058d46a3952378ca40ebc934.png]: https://img-blog.csdnimg.cn/a9046de3058d46a3952378ca40ebc934.png
[5408c09ad49a488ab3edc4b908281c14.png]: https://img-blog.csdnimg.cn/5408c09ad49a488ab3edc4b908281c14.png
[5599f92cd692400eb1476431e3622982.png]: https://img-blog.csdnimg.cn/5599f92cd692400eb1476431e3622982.png
[Java_11]: https://www.bilibili.com/video/BV1Z44y1f7nF/?spm_id_from=333.337.search-card.all.click&vd_source=a1af903e57688df870625021f7f3a7eb