Java多线程编程中的并发安全问题及解决方法

Java
320
0
0
2023-05-10
Java多线程编程基石ThreadPoolExecutor示例详解
上一篇
一文掌握Spring的创建与使用
下一篇
标签   Java多线程 Java并发
目录
  • 线程安全性
  • 死锁
  • 定义
  • 实现一个死锁
  • 查看死锁
  • 解决死锁
  • 其他线程安全问题
  • 单例模式

线程安全性

线程安全是指我们所写的代码在并发情况下使用时，总是能表现出正确的行为；反之，未实现线程安全的代码，表现的行为是不可预知的，有可能正确，

实现线程安全的方式：

线程封闭

就是把对象封装到一个线程里，只有这一个线程能看到此对象。实现线程封闭的方式如下：

栈封闭

这里是指每个线程自己的线程栈，方法的局部变量就是在线程栈中的，对于其他线程是不可见的

ThreadLocal

各个线程Thread对象维护了一份Map，对于其他线程是不可见的

无状态的类

没有任何成员变量的类，就叫无状态的类，这种类一定是线程安全的。

让类不可变

没有成员变量的类毕竟是少数，我们还可以让类的成员变量不可变，给他们加上final关键字

如果成员变量是一个对象，final不能保证类的安全性，因为虽然对象的引用不会变，但是在堆上的对象实例可能被多个线程同时修改，没有正确处理的情况下，对象实例在堆中的数据是不可预知的。

加锁或CAS

synchronized、显示锁Look、原子Atomic操作、CAS机制等等

死锁

定义

是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁。

  • 死锁是必然发生在多操作者（M>=2 个）争夺多个资源（N>=2 个，且 N<=M） 才会发生这种情况。
  • 争夺资源的顺序不对，如果争夺资源的顺序是一样的，也不会产生死锁；
  • 争夺者对拿到的资源不放手，也不能被掠夺。

学术化的定义。死锁的发生必须具备以下四个必要条件。

  • 互斥条件：指进程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源，则请求者只能等待， 直至占有资源的进程用毕释放。
  • 请求和保持条件：指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己已获得的其它资源保持不放。
  • 不剥夺条件：指进程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放。
  • 环路等待条件：指在发生死锁时，必然存在一个进程——资源的环形链， 即进程集合{P0，P1，P2，···，Pn}中的 P0 正在等待一个 P1 占用的资源；P1 正在等待 P2 占用的资源，……，Pn 正在等待已被 P0 占用的资源。

只要打破四个必要条件之一就能有效预防死锁的发生。

  • 打破互斥条件：改造独占性资源为虚拟资源，大部分资源已无法改造。
  • 打破不可抢占条件：当一进程占有一独占性资源后又申请一独占性资源而无 法满足，则退出原占有的资源。
  • 打破占有且申请条件：采用资源预先分配策略，即进程运行前申请全部资源， 满足则运行，不然就等待，这样就不会占有且申请。
  • 打破循环等待条件：实现资源有序分配策略，对所有设备实现分类编号，所有进程只能采用按序号递增的形式申请资源。

避免死锁常见的算法有有序资源分配法、银行家算法。

实现一个死锁

/**
 * @Description: 实现一个简单的死锁程序
 */
public class DeadLookTest {
    private static Object o1 = new Object();
    private static Object o2 = new Object();
    public void fastLock() throws InterruptedException {
        synchronized(o1){
            Thread.sleep(2000);
            System.out.println("fast");
            synchronized (o2){
                System.out.println("----");
            }
        }
    }
    public void postLock() throws InterruptedException {
        synchronized(o2){
            Thread.sleep(2000);
            System.out.println("post");
            synchronized (o1){
                System.out.println("----");
            }
        }
    }
    public static void main(String[] args) throws InterruptedException {
        DeadLookTest deadlook = new DeadLookTest();
        // 新开一个线程去调用其中一个方法
        new Thread(() -> {
            try {
                deadlook.postLock();
            } catch (InterruptedException e) {
            }
        }).start();
        deadlook.fastLock();
    }
}

查看死锁

使用jstack命令查看死锁结果

C:\Users\Administrator>jps
4784 DeadLookTest
9808 RemoteMavenServer36
2052 Launcher
2692 Jps
8572
C:\Users\Administrator>jstack 4784
......
Found one Java-level deadlock:
=============================
"Thread-0":
 waiting to lock monitor 0x0000025d5a58fd88 (object 0x0000000716edb910, a java.lang.Object),
 which is held by "main"
"main":
 waiting to lock monitor 0x0000025d5a58e998 (object 0x0000000716edb920, a java.lang.Object),
 which is held by "Thread-0"
Java stack information for the threads listed above:
===================================================
"Thread-0":
    at cn.tulingxueyuan.safe.dl.DeadLookTest.postLock(DeadLookTest.java:30)
    - waiting to lock <0x0000000716edb910> (a java.lang.Object)
    - locked <0x0000000716edb920> (a java.lang.Object)
    at cn.tulingxueyuan.safe.dl.DeadLookTest.lambda$main$0(DeadLookTest.java:39)
    at cn.tulingxueyuan.safe.dl.DeadLookTest$$Lambda$1/2003749087.run(Unknown Source)
    at java.lang.Thread.run(Thread.java:748)
"main":
    at cn.tulingxueyuan.safe.dl.DeadLookTest.fastLock(DeadLookTest.java:20)
    - waiting to lock <0x0000000716edb920> (a java.lang.Object)
    - locked <0x0000000716edb910> (a java.lang.Object)
    at cn.tulingxueyuan.safe.dl.DeadLookTest.main(DeadLookTest.java:43)
Found 1 deadlock.

解决死锁

我们现在通过上面的命令找到了产生死锁的位置，那么如何取解决死锁嘞？我们知道产生死锁的原因如下：

  • 死锁是必然发生在多操作者（M>=2 个）争夺多个资源（N>=2 个，且 N<=M） 才会发生这种情况。
  • 争夺资源的顺序不对，如果争夺资源的顺序是一样的，也不会产生死锁；
  • 争夺者对拿到的资源不放手，也不能被掠夺。

第一个条件一般都是业务必须要，那么打破死锁就要从下面的两个条件去解决

  • 保证争夺锁资源的顺序一样。

在实际的开发中可能会存在比较隐蔽的加锁顺序，比如锁对象作为方法参数传递，如下所示

private static void businessDo(Object first,Object second) throws InterruptedException {
    String threadName = Thread.currentThread().getName();
    synchronized (first){
        System.out.println(threadName + " get first");
        Thread.sleep(1000);
        synchronized (second){
            System.out.println(threadName + " get second");
        }
    }
}
// 然后两个线程，在调用的时候传递的参数顺序却不一样
businessDo(No1,No2);
businessDo(No2,No1);

解决上面这种问题的方式是：在加锁前，在方法中做一个内部的排序

public class SafeOperate {
    private static Object No13 = new Object();//第一个锁
    private static Object No14 = new Object();//第二个锁
    private static Object tieLock = new Object();//第三把锁
    public void transfer(Object first,Object second) throws InterruptedException {
        int firstHash = System.identityHashCode(first);
        int secondHash = System.identityHashCode(second);
        if(firstHash<secondHash){
            synchronized (first){
                System.out.println(Thread.currentThread().getName()+" get "+first);
                Thread.sleep(100);
                synchronized (second){
                    System.out.println(Thread.currentThread().getName()+" get "+second);
                }
            }
        }else if(secondHash<firstHash){
            synchronized (second){
                System.out.println(Thread.currentThread().getName()+" get"+second);
                Thread.sleep(100);
                synchronized (first){
                    System.out.println(Thread.currentThread().getName()+" get"+first);
                }
            }
        }else{
            // 万一两个对象的hash值一样，那么就引入第三把锁，谁先抢到第三把锁就去进行前两两把锁的加锁
            synchronized (tieLock){
                synchronized (first){
                    synchronized (second){
                        System.out.println(Thread.currentThread().getName()+" get"+first);
                        System.out.println(Thread.currentThread().getName()+" get"+second);
                    }
                }
            }
        }
    }
}

对拿到的锁资源尝试释放

这种方式对于synchronized是不适用的，因为它不拿到锁誓不罢休。使用ReentrantLock，使用其中的tryLock(long time, TimeUnit unit)方法，在指定的时间中如果还没有拿到锁就去进行释放的逻辑

大致是实现逻辑如下所示

while(true){
    if(No13.tryLock()){
        System.out.println(threadName +" get 13");
        // 如果没有拿到No14的锁，那么No13的锁也释放
        try{
            if(No14.tryLock()){
                try{
                    System.out.println(threadName  +" get 14");
                    System.out.println("zhouYuDo do work------------");
                    break;
                }finally{
                    No14.unlock();
                }
            }
        }finally {
            No13.unlock();
        }
    }
    // 如果不加休眠机制，那么就比较容易产生活锁
    Thread.sleep(1000);
}

其他线程安全问题

活锁

两个线程在尝试拿锁的机制中，发生多个线程之间互相谦让，不断发生同一个线程总是拿到同一把锁，在尝试拿另一把锁时因为拿不到，而将本来已经持有的锁释放的过程。

解决办法：每个线程休眠随机数，错开拿锁的时间。

线程饥饿

低优先级的线程，总是拿不到执行时间

单例模式

  • DCL双重检测机制
  • volatile关键字禁止指令重排
public class HungrySingleton {
    //创建 SingletonHungry 的一个对象
    private static volatile HungrySingleton instance;
    // 让构方法私有，这样该类就不会被其它类实例化
    private HungrySingleton() {
    }
    //获取唯一可用的对象
    public static HungrySingleton getInstance() {
        if(null == instance) { 
            synchronized{
                if(null == instance) { 
                    instance = new LazySingleton();
                }
            }
        }
    	return instance;
    }
}
Java多线程编程基石ThreadPoolExecutor示例详解
上一篇
一文掌握Spring的创建与使用
下一篇