并发安全和死锁
并发安全和死锁。
作者:IT王小二
博客:https://itwxe.com
一、并发安全
1. 什么是线程安全性
当多个线程访问某个类时,不管运行时环境采用何种调度方式或者这些线程将如何交替执行,并且在调用代码中不需要任何额外的同步或者协同,这个类都能表现出正确的行为,那么就称这个类是线程安全的 -- Java并发编程实战
那么怎么实现线程安全呢?可以使用下面的这些方式。
2. 线程封闭
1、实现好的并发是一件困难的事情,所以很多时候我们都想躲避并发。避免并发最简单的方法就是线程封闭。什么是线程封闭呢?
就是把对象封装到一个线程里,只有这一个线程能看到此对象。那么这个对象就算不是线程安全的也不会出现任何安全问题
2、实现线程封闭有哪些方法呢?
- ad-hoc 线程封闭:这是完全靠实现者控制的线程封闭,他的线程封闭完全靠实现者实现。Ad-hoc线程封闭非常脆弱,应该尽量避免使用。
- 栈封闭:栈封闭是我们编程当中遇到的最多的线程封闭。什么是栈封闭呢?简单的说就是局部变量,多个线程访问一个方法,此方法中的局部变量都会被拷贝一份到线程栈中,所以局部变量是不被多个线程所共享的,也就不会出现并发问题,所以能用局部变量就别用全局的变量,全局变量容易引起并发问题。
3. 无状态的类
没有任何成员变量的类,就叫无状态的类,这种类一定是线程安全的。
那么下面这个类的方法参数使用了对象,也是线程安全的吗?
public class StatelessClass {
public int service(int a,int b){
return a + b;
}
public void serviceUser(UserVo user){
}
}
当然也是,这是为什么呢?多线程使用的情况下,这个user对象的实例确实会不正常,但是对于StatelessClass这个类来说,它并不持有UserVo的对象实例,它自己本身并不会出问题,有问题的是UserVo这个类,而非StatelessClass本身。
4. 让类不可变
1、加 final 关键字,对于一个类,所有的成员变量应该是私有的,同样的只要有可能,所有的成员变量应该加上 final 关键字,但是加上final,要注意如果成员变量又是一个对象时,这个对象所对应的类也要是不可变,才能保证整个类是不可变的。
2、根本就不提供任何可供修改成员变量的地方,同时成员变量也不作为方法的返回值。
但是需要注:一旦类的成员变量中有对象,上述的 final 关键字保证不可变并不能保证类的安全性,这是为什么呢?因为在多线程下,虽然对象的引用不可变,但是对象在堆上的实例是有可能被多个线程同时修改的,没有正确处理的情况下,对象实例在堆中的数据是不可预知的,例如:
public class ImmutableClass {
private final int a;
private final int b;
/**
* 加上这个就不保证安全了
*/
private final UserVo user = new UserVo();
public int getA() {
return a;
}
public UserVo getUser() {
return user;
}
public ImmutableClass(int a, int b) {
this.a = a;
this.b = b;
}
public static class User {
private int age;
public int getAge() {
return age;
}
public void setAge(int age) {
this.age = age;
}
}
}
5. volatile
volatile可以说是java虚拟机提供的最轻量级的同步机制,但是并不能保证类的线程安全性,只能保证类的可见性,最适合一个线程写,多个线程读的情景。
6. 加锁和CAS
我们最常使用的保证线程安全的手段,使用 synchronized 关键字,使用显式锁,使用各种原子变量,修改数据时使用 CAS 机制等等。
7. 安全的发布
类中持有的成员变量,如果是基本类型,发布出去,并没有关系,因为发布出去的其实是这个变量的一个副本。
但是如果类中持有的成员变量是对象的引用,如果这个成员对象不是线程安全的,通过 get 等方法发布出去,会造成这个成员对象本身持有的数据在多线程下不正确的修改,从而造成整个类线程不安全的问题。
那么怎么保证发布对象多线程下的安全呢?我们可以参考Collections.synchronizedList
方法来实现我们自己发布对象的安全性,查看源码可以知道是通过synchronized
关键字来实现的:
private List<Integer> list = Collections.synchronizedList(new ArrayList<>(3));
接下来我们就模仿一下发布一个安全的类。
public final class FinalUserVo {
private int age;
public int getAge() {
return age;
}
public void setAge(int age) {
this.age = age;
}
}
public class SafePublicFinalUser {
private final SynFinalUser user;
public SynFinalUser getUser() {
return user;
}
public SafePublicFinalUser(FinalUserVo user) {
this.user = new SynFinalUser(user);
}
public static class SynFinalUser {
private final FinalUserVo userVo;
private final Object lock = new Object();
public SynFinalUser(FinalUserVo userVo) {
this.userVo = userVo;
}
public int getAge() {
synchronized (lock) {
return userVo.getAge();
}
}
public void setAge(int age) {
synchronized (lock) {
userVo.setAge(age);
}
}
}
}
8. TheadLocal
ThreadLocal 是实现线程封闭的最好方法。ThreadLocal 内部维护了一个 Map,Map 的 key 是每个线程的名称,而 Map 的值就是我们要封闭的对象。每个线程中的对象都对应着 Map 中一个值,也就是 ThreadLocal 利用 Map 实现了对象的线程封闭。
其实本质还是可以认为是将ThreadLocal封闭的对象,将副本存储在了每个线程中,还是每个线程的局部变量,互不影响。
9. Servlet 辨析
Servlet不是一个线程安全的类,但是为什么我们用Servlet的时候没有感觉到呢,因为在需求上每个Servlet中很少有共享需求,接收到了请求,处理时都是一个单独的线程来负责。
但是如果 Servlet 中有成员变量,一旦有多线程下的写,就很容易产生线程安全问题。
三、死锁
1. 概念
死锁是指两个或两个以上的进程在执行过程中,由于竞争资源或者由于彼此通信而造成的一种阻塞的现象,若无外力作用,它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等待的进程称为死锁进程 -- 百度百科
你没看错,死锁并不止于线程,说进程也没毛病,因为,死锁往往是各进程之间的线程相互抢夺资源导致的。
总结下来就是:死锁是必然发生在多操作者(M>=2 个)情况下,争夺多个资源(N>=2 个,
且 N<=M)才会发生这种情况。
2. 死锁现象
简单顺序死锁
由于锁顺序定义不一致导致死锁。
示例:
public class SimpleDeadLock {
/**
* 第一个锁
*/
private static Object valueFirst = new Object();
/**
* 第二个锁
*/
private static Object valueSecond = new Object();
/**
* 先拿第一个锁,再拿第二个锁
*/
private static void fisrtToSecond() throws InterruptedException {
String threadName = Thread.currentThread().getName();
synchronized (valueFirst) {
System.out.println(threadName + " 拿到了第一把锁");
Thread.sleep(100);
synchronized (valueSecond) {
System.out.println(threadName + " 拿到了第二把锁");
}
}
}
/**
* 先拿第二个锁,再拿第一个锁
*/
private static void SecondToFisrt() throws InterruptedException {
String threadName = Thread.currentThread().getName();
synchronized (valueSecond) {
System.out.println(threadName + " 拿到了第二把锁");
Thread.sleep(100);
synchronized (valueFirst) {
System.out.println(threadName + " 拿到了第一把锁");
}
}
}
private static class TestThread extends Thread {
private String name;
public TestThread(String name) {
this.name = name;
}
@Override
public void run() {
Thread.currentThread().setName(name);
try {
SecondToFisrt();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
public static void main(String[] args) {
Thread.currentThread().setName("TestDeadLock");
TestThread testThread = new TestThread("SubTestThread");
testThread.start();
try {
fisrtToSecond();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
这种简单的顺序死锁看到代码一眼就可以看出来,解决办法也很简单,只要把锁的顺序保持一致就行了。
动态顺序死锁
顾名思义也是和获取锁的顺序有关,但是比较隐蔽,不像简单顺序死锁,往往从代码一眼就看出获取锁的顺序不对。
比如:两个银行账户之间在同一时间相互转账,下面仅为转账动作代码。
/**
* 转账动作代码,省略判断银行账户剩余金额
* @param from 转出银行账户
* @param to 转入银行账户
* @param amount 转账金额
* @throws InterruptedException 中断异常
*/
public void transfer(UserAccount from, UserAccount to, int amount)
throws InterruptedException {
// 锁定from账号
synchronized (from) {
System.out.println(Thread.currentThread().getName() + " get" + from.getName());
Thread.sleep(100);
// 锁定to账号
synchronized (to) {
System.out.println(Thread.currentThread().getName() + " get" + to.getName());
// from转出金额
from.flyMoney(amount);
// to转入金额
to.addMoney(amount);
}
}
}
线程A从X账户向Y账户转账,线程B从账户Y向账户X转账,这时候问题就产生了,两线程想要获取转入账户的锁,但是分别被其他线程持有,这时候死锁就产生了。
那么怎么解决呢?
有两种解决方案(思路仅供参考),当然不排除大佬们有更好的解决方案。
- 第一种,使用hash值来确定执行顺序,如果hash值相等的话就用第三把锁来确定持有锁的顺序。
- 第二种,使用显式锁,在 UserAccount 中定义 Lock,然后在转账方法中使用 tryLock() 尝试拿 form的锁,如果拿到了那么就再次尝试拿 to的锁,如果全部拿到了那么自然执行转账,如果没有拿到则释放自己拿到的锁。
3. 如果实际中出现了死锁怎么解决
死锁的危害
1、线程不工作了,但是整个程序还是活着的 。
2、没有任何的异常信息可以供我们检查。
3、一旦程序发生了发生了死锁,是没有任何的办法恢复的,只能重启程序,对生产平台的程序来说,这是个很严重的问题。
实际工作中的死锁
在实际工作中,如果测试没有并发测试,大多数情况下可能死锁无法复现,那如果真的出现了死锁要怎么排查解决呢?
解决办法
以上述的简单顺序死锁案例为例
1、首先使用 jps
命令来查询应用id,然后通过 jstack id
来 定位 锁的持有情况。
2、定位到了问题了,那么就要 修正 了,通常都是保证拿锁的顺序一致,通常两种解决方案。
- 通过内部比较,确定拿锁的顺序。
- 采用尝试拿锁的机制。
4. 其他的概念
活锁
两个线程在尝试拿锁的机制中,发生多个线程之间互相谦让,不断发生同一个线程总是拿到同一把锁,在尝试拿另一把锁时因为拿不到,而将本来已经持有的锁释放的过程(例如上面修正方案中说的尝试拿锁机制)。
解决办法:每个线程休眠随机数,错开拿锁的时间。
线程饥饿
低优先级的线程,总是拿不到执行时间。
5. 线程安全的单例模式
饿汉模式
在声明的时候就 new 这个类的实例,因为在 JVM 中,对类的加载和类初始化,由虚拟机保证线程安全。
懒汉模式
饿汉模式下双重检查锁定能够保证安全吗?假设代码如下:
public class SingleHungry {
private static SingleHungry singleHungry;
private UserVo userVo;
// 私有化
private SingleHungry(){
}
public static SingleHungry getInstance(){
if (singleHungry == null){
// 第一次检查,不加锁
synchronized(SingleHungry.class){
// 加锁
if (singleHungry == null){
// 第二次检查,加锁情况下
singleHungry = new SingleHungry();
}
}
}
return singleHungry;
}
}
咋一看上去,没什么毛病,稳得很,我以前也一直都这么用过来的,后来看了JVM后相关知识发现并不对。。。
为什么不对呢?
就我目前的认知来说,可以从 jvm对象的创建过程 和 重排序 的两个层面来说明这个问题。
- 我就从 jvm对象的创建过程 来说明这个问题,两个线程同时来获取这个单例的实例时,比如A线程已经执行到了new SingleHungry() 。
- 对象创建过程包括:检查加载 -> 分配内存 -> 内存空间初始化 -> 设置 -> 对象的初始化。
- 当执行new关键字的时候首先给这个对象执行了
检查加载 -> 分配内存 -> 内存空间初始化 -> 设置
,此时,singleHungry 已经有了指向引用不为null了,但是他的属性(比如示例中的user)此时还未初始化,还是为null 。 - 这时,B线程执行 getInstance() 方法后发现实例不为空了,然后获取到了 singleHungry 使用,然后 singleHungry.getUser().getName(),发现报 NullPointException 了。
解决办法:
1、使用饿汉模式。
2、或者懒汉模式的 singleHungry 加上 volatile
关键字。
都读到这里了,来个 点赞、评论、关注、收藏 吧!