如何保证集合是线程安全的?

Posted 2023-03-18

1、不可变

在java语言中，不可变的对象一定是线程安全的，无论是对象的方法实现还是方法的调用者，都不需要再采取任何的线程安全保障措施。如final关键字修饰的数据不可修改，可靠性最高。

2、绝对线程安全

绝对的线程安全完全满足Brian GoetZ给出的线程安全的定义，这个定义其实是很严格的，一个类要达到“不管运行时环境如何，调用者都不需要任何额外的同步措施”通常需要付出很大的代价。

3、相对线程安全

相对线程安全就是我们通常意义上所讲的一个类是“线程安全”的。

它需要保证对这个对象单独的操作是线程安全的，我们在调用的时候不需要做额外的保障措施，但是对于一些特定顺序的连续调用，就可能需要在调用端使用额外的同步手段来保证调用的正确性。

在java语言中，大部分的线程安全类都属于相对线程安全的，例如Vector、HashTable、Collections的synchronizedCollection（）方法保证的集合。

4、线程兼容

线程兼容就是我们通常意义上所讲的一个类不是线程安全的。

线程兼容是指对象本身并不是线程安全的，但是可以通过在调用端正确地使用同步手段来保证对象在并发环境下可以安全地使用。Java API中大部分的类都是属于线程兼容的。如与前面的Vector和HashTable相对应的集合类ArrayList和HashMap等。

5、线程对立

线程对立是指无论调用端是否采取了同步错误，都无法在多线程环境中并发使用的代码。由于java语言天生就具有多线程特性，线程对立这种排斥多线程的代码是很少出现的。

一个线程对立的例子是Thread类的supend()和resume()方法。如果有两个线程同时持有一个线程对象，一个尝试去中断线程，另一个尝试去恢复线程，如果并发进行的话，无论调用时是否进行了同步，目标线程都有死锁风险。正因此如此，这两个方法已经被废弃啦。 参考技术A 安全生产保证现场的安全 参考技术B 鸡汤买的自行车 参考技术C 本次内容主要线程的安全性、死锁相关知识点。
1、什么是线程安全性
1.1 线程安全定义
前面使用8个篇幅讲到了Java并发编程的知识，那么我们有没有想过什么是线程的安全性？在《Java并发编程实战》中定义如下：当多个线程访问某个类时，不管运行时环境采用何种调度方式或者这些线程将如何交替执行，并且在调用代码中不需要任何额外的同步或者协同，这个类都能表现出正确的行为，那么就称这个类是线程安全的。
1.2 无状态类
没有任何成员变量的类，就叫无状态类，这种类一定是线程安全的。但是有一种情况是，这个类方法的参数中用到了对象，看下面的代码：
此时这个类还是线程安全的吗？那肯定也是，为什么呢？因为多线程下的使用，固然user这个对象的实例会不正常，但是对于StatelessClass这个类的对象实例来说，它并不持有User的对象实例，它自己并不会有问题，有问题的是User这个类，而非StatelessClass本身。
1.2 volatile
并不能保证类的线程安全性，只能保证类的可见性，最适合一个线程写，多个线程读的情景。
1.3 锁和CAS
我们最常使用的保证线程安全的手段，使用synchronized关键字，使用显式锁，使用各种原子变量，修改数据时使用CAS机制等等。
1.4 ThreadLocal
ThreadLocal是实现线程封闭的最好方法。关于ThreadLocal如何保证线程的安全性，请阅读《java线程间的共享》，里面有详细的介绍。
1.5 安全的发布
1）类中持有的成员变量，如果是基本类型，发布出去，并没有关系，因为发布出去的其实是这个变量的一个副本。看下面的代码：
从程序输出可以看到，number的值并没被改变，因为result只是一个副本，这样的成员变量发布出去是安全的。
2）如果类中持有的成员变量是对象的引用，如果这个成员对象不是线程安全的，通过get等方法发布出去，会造成这个成员对象本身持有的数据在多线程下不正确的修改，从而造成整个类线程不安全的问题。看下面代码：
从程序输出可以看到，user对象的内容发生了改变，如果多个线程同时操作，user对象在堆中的数据是不可预知的。
那么这个问题应该怎么处理呢？我们在发布这对象出去的时候，就应该用线程安全的方式包装这个对象。对于我们自己使用或者声明的类，JDK自然没有提供这种包装类的办法，但是我们可以仿造这种模式或者委托给线程安全的类，当然，对这种通过get等方法发布出去的对象，最根本的解决办法还是应该在实现上就考虑到线程安全问题。对上面的代码进行改造：
2、死锁
2.1 死锁定义
死锁的发生必须具备以下四个必要条件：
1）互斥条件：指进程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源，则请求者只能等待，直至占有资源的进程用毕释放。
2）请求和保持条件：指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己已获得的其它资源保持不放。
3）不剥夺条件：指进程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放。
4）环路等待条件：指在发生死锁时，必然存在一个进程——资源的环形链，即进程集合P0，P1，P2，···，Pn中的P0正在等待一个P1占用的资源；P1正在等待P2占用的资源，……，Pn正在等待已被P0占用的资源。
举个例子来说明：
老王和老宋去大保健，老王抢到了1号技师，擅长头部按摩，老宋抢到了2号技师，擅长洗脚。但是老王和老宋都想同时洗脚和头部按摩，于是互不相让，老王抢到了1号，还想要2号，老宋抢到了2号，还想要1号。在洗脚和头部按摩这个事情上老王和老宋就产生了死锁，怎么样可以解决这个问题呢？
方案1：老板了解到情况，派3号技师过来，3号技师擅长头部按摩，老王只有一个头，所以3号只能给老宋服务，这个时候死锁就被打破。
方案2：大保健会所的老板比较霸道，规定了只能先头部按摩，再洗脚。这种情况下，老王和老宋谁先抢到1号，谁就先享受，另一个没抢到的就等着，这种情况也不会产生死锁。
对死锁做一个通俗易懂的总结：
死锁是必然发生在多个操作者（M>=2）情况下，争夺多个资源（N>=2，且M>=N）才会发生这种情况。很明显，单线程不会有死锁，只有老王一个去，1号2号都归他，没人跟他抢。单资源呢？只有1号，老王和老宋也只会产生激烈竞争，打得不可开交，谁抢到就是谁的，但不会产生死锁。同时，死锁还有两个重要的条件，争夺资源的顺序不对，如果争夺资源的顺序是一样的，也不会产生死锁，另一个条件就是，争夺者拿到资源后不放手。
2.2 死锁的危害
一旦程序中出现了死锁，危害是非常致命的，大致有以下几个原因：
1）线程不工作了，但是整个程序还是活着的。
2）没有任何的异常信息可以供我们检查。
3）程序发生了发生了死锁，是没有任何的办法恢复的，只能重启程序，对生产平台的程序来说，这是个很严重的问题。
2.3 死锁的例子
上面讲了那么多关于死锁的概念，现在直接撸一段死锁代码看看。
程序输出可以看到，老宋抢到了2号，老王抢到了1号，因为产生了死锁，程序没有结束，但是并没有往下执行。
2.4 死锁的定位
通过JDK的jps查看应用的id，再使用jstack查看应用持有锁的情况。
可以看到"laowang"这个线程持有了<0x000000076b393b78>锁，还想获得<0x000000076b393b88>锁；"laosong"这个线程持有了<0x000000076b393b88>锁，还想获取<0x000000076b393b78>锁。
2.5 死锁的解决方案
1）保证拿锁的顺序一致，内部通过顺序比较，确定拿锁的顺序。
2）采用尝试拿锁的机制。
我们分别用这2种解决方案来改造上面死锁的代码，先看方案1：
从程序输出可以看到，通过顺序拿锁的方式，2个人都完成了大保健，解决了死锁问题。
再看方案2，使用ReentrantLock采用尝试获取锁的方式，如果对ReentrantLock不熟悉，欢迎阅读《java之AQS和显式锁》。
从程序输出可以看到，laowang线程抢到了NO2这把锁，但是在获取NO1的时候失败了，所以把NO2也释放了。这样做就使得2个线程都可以获取到锁，不会有死锁问题产生。
3、结语
本篇幅就介绍这么多内容，希望大家看了有收获。Java并发编程专题要分享的内容到此就结束了，下一个专题将介绍Java性能优化和JVM相关内容，阅读过程中如发现描述有误，请指出，谢谢。