保证线程安全的处理策列

原创于 2024-11-11 10:00:00 发布 · 883 阅读

18 ·

CC 4.0 BY-SA版权

文章标签：

#安全 #java #数据结构 #线程安全

JAVA开发+基础+面试题同时被 2 个专栏收录

87 篇文章

订阅专栏

JAVA开发+JAVA框架-Spring

40 篇文章

订阅专栏

本文主要用于学习，详细参考：聊聊保证线程安全的10个小技巧前言对于从事后端开发的同学来说，线程安全问题是我们每天都需要考虑的问题。线程安全问题通 - 掘金

对于从事后端开发的同学来说，线程安全问题是我们每天都需要考虑的问题。

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

比如：变量a=0，线程1给该变量+1，线程2也给该变量+1。此时，线程3获取a的值有可能不是2，而是1。线程3这不就获取了错误的数据？

线程安全问题会直接导致数据异常，从而影响业务功能的正常使用，所以这个问题还是非常严重的。

那么，如何解决线程安全问题呢？

1、不可变final

如果多线程访问的公共变量是不变的，也就不会存在线程安全的问题。

例如：

public class SafeUtils {

    public static final String NAME = "Guoguo";

    public void add(String param) {
        System.out.println(name);
    }
}

NAME被定义为static final的常量，在多线程情况下，不会被线程修改，也就是线程安全的。

2、无修改权限

如果我们定义了公共变量，但是没有暴露它的修改权限，这样也是线程安全的。

public class SafeUtils {

    public  String name = "Guoguo";

    public String getName() {
        return name;
    }

    public void add(String param) {
        System.out.println(name);
    }
}

这个demo中，我们只暴露了读取的权限，所以就不存在线程安全问题。

3、synchronized

synchronized是Java内部提供的同步机制，可以用于方法或代码块，同步方法的粒度有些大，所以我们优先使用同步代码块。

synchronized修饰方法或者代码块时，锁的是对象，这里有个面试点。

3.1、同步实例方法：锁的是当前的实例对象

public synchronized void add() {
    // some code
}

synchronized修饰实例方法，锁的是当前的实例对象this。

如果多个线程试图调用同一个实例对象的add()方法，那么它们会彼此阻塞，直到前一个线程释放锁。
如果多个线程调用对象的不同实例的add()方法，它们不会互相阻塞，因为锁是加在不同实例上的。

在Spring中，默认情况下创建的bean 是单例的，只有一个，那么如果存在多个线程调用实例的add()方法时，就会存在锁竞争的情况。

3.2、同步静态方法：锁的是整个类的Class对象

public static synchronized void staticAdd() {
    // some code
}

synchronized修饰静态方法，锁的是整个类的Class对象。

如果多线程访问该类的静态同步方法（即使是多实例的情况），它们都在争夺同一个锁（Class对象），同一时刻只有一个线程在执行这个静态同步方法。

这里有个概念，锁的是Class对象（例如：MyClass.class），给锁实例对象不同的是，每个类只有一个Class对象，但是可以有不同的实例。

3.3、同步代码块：可以指定任意对象作为锁

private final Object lock = new Object();

public void add() {
    synchronized(lock) {
        // some code
    }
}

public void increment() {
    synchronized(this) {
        // some code
    }
}

synchronized修饰同步代码块，可以指定任意对象作为锁。

如果使用synchronized(this)，那么这个代码块给synchronized修饰实例方法一样，都是锁的当前实例对象。
如果synchronized(其他对象)，则锁的对象是你指定的对象。多线程执行add()方法时，需要竞争同一个lock对象的锁，同一个时刻，只有一个线程可以进入同步代码块。

如果不同代码块使用了相同的锁对象，会怎么样呢？

例如：

public class MyClass {
    private final Object lock = new Object();
    public void method1() {
        synchronized(lock) {
            // 同步代码块1
        }
    }
    public void method2() {
        synchronized(lock) {
            // 同步代码块2
        }
    }
}

如果一个线程已经持有了lock对象的锁，例如：正在执行method1方法的同步代码块，其他线程尝试进入method1、method2的同步代码块时，会被阻塞，直到前一个线程执行完同步代码块并释放锁。

如果不同代码块涉及不同的操作，可以考虑使用不同的锁对象，这些代码块之间的执行就不会互相影响，这样可以提高并发性，同时确保线程安全。

当代码块执行完之后，JVM底层就会自动的释放锁。

面试题：那如果在执行synchronized代码块的过程中，发生了异常，会释放锁吗？

会的，Java的synchronized机制保证了同步代码块中抛出异常，当前线程持有的锁也会在异常抛出后自动释放。

面试官又问：你了解synchronized底层的实现原理吗？

我emo了......回头搞它。感兴趣的小伙伴也可以自行学习下。

4、Lock锁

除了使用synchronized实现同步功能外，Java还提供了Lock锁。

通常我们会使用ReentrantLock锁，它是java.util.concurrent.locks包里的一个类，它是一种显式锁，我们需要在程序代码中显式获取或者释放锁（例如调用lock()或者unlock()）。

例如：

public class ExplicitLockExample {
    private final Lock lock = new ReentrantLock();

    public void criticalSection() {
        lock.lock(); // 显式获取锁
        try {
            // 临界区代码
        } finally {
            lock.unlock(); // 确保释放锁
        }
    }
}

ReentrantLock显示锁提供了更高级的功能：

尝试锁（tryLock）：tryLock()方法尝试获取锁，但如果锁不可用，则不会堵塞线程，可以执行超时时间，如果在超时时间内没有获取到锁，则方法返回false
```
if (lock.tryLock(100, TimeUnit.MILLISECONDS)) {
    try {
        // 临界区代码
    } finally {
        lock.unlock();
    }
}
```

中断支持（lockInterruptibly）: 允许线程在等待锁时响应中断。

公平性策略（公平锁、非公平锁）：可以配置为公平锁或非公平锁。公平锁按照线程请求锁的顺序来获取锁。

ReentrantLock fairLock = new ReentrantLock(true); // 创建公平锁
ReentrantLock unfairLock = new ReentrantLock(false); // 创建非公平锁

5、分布式锁

如果我们在单机的情况下，使用synchronized 和Lock处理线程安全是没问题的，如果是分布式环境的话，多个节点之间的线程安全就没法保证了。

这就需要使用：分布式锁了，例如我们可以使用redis分布式锁，或者Redisson。

@Autowired
    private StringRedisTemplate redisTemplate;

    public String deductStock() {
        String key = "lock_key";
        String value = "ID_PREFIX" + Thread.currentThread().getId();
        try {
            //key 要锁住的key；value 值；Duration.ofSeconds(60) 过期时间，单位：秒
            Boolean success = redisTemplate.opsForValue().setIfAbsent(key, value, Duration.ofSeconds(60));
            if (success) {
                //获取到锁
            }
        } finally {
            //currentValue.equals(value) 解决请求释放锁的时候，释放掉的不是自己锁的问题
            String currentValue = redisTemplate.opsForValue().get(key);
            if (currentValue != null && currentValue.equals(value)) {
                //释放锁
                redisTemplate.delete(key);
            }
        }

        return "success";
    }

和ReentrantLock一样，我们需要在finaly中手动释放锁。

有关redis或者Redisson的详细描述，可以翻阅《SpringBoot中如何使用Redis实现分布式锁？》。

6、volatile

有时候我们的需求场景可能比较简单，只需要多线程之间共享变量可见，此时我们就可以选择volatile。

例如：

private volatile boolean flag = true;

注意点：

volatile修饰的共享变量不能保证操作的原子性。

7、ThreadLocal

除了以上几种方案外，JDK还提供了另外一种空间换时间的思路：ThreadLocal。

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

public class ThreadLocalService {
    private static ThreadLocal<Integer> threadLocal = new ThreadLocal<>();

    public void add(int i) {
        Integer integer = threadLocal.get();
        threadLocal.set(integer == null ? 0 : integer + i);
    }
}

ThreadLocal 变量通常被private static修饰。当一个线程结束时，它所使用的所有 ThreadLocal 相对的实例副本都可被回收。

为什么要使用static修饰变量ThreadLocal呢？

可以共享同一个ThreadLocal实例

static修饰符使得ThreadLocal变量在整个类中只有一个实例，这就意味对象多实例的情况也都会共享同一个ThreadLocal变量。

在上述示例中，无论创建多少个ThreadLocalService，threadLocal变量都是共享的，但每个线程都有自己独立的副本。
避免对象的每个实例都创建ThreadLocal实例，减少了资源的浪费和重复创建

8、使用原子类

一般用atomic包下面的类即可，例如：AtomicInteger，底层是通过CAS操作保证了原子性，避免了加锁的开销。

AtomicInteger counter = new AtomicInteger(0);
counter.incrementAndGet();

CAS 全称 Compare And Swap（比较与交换），是一种无锁算法。在不使用锁的情况下实现多线程之间的变量同步。

我们进入AtomicInteget源码，看下CAS是如何实现的。

 public class AtomicInteger extends Number implements java.io.Serializable {
      public final int incrementAndGet() {
          return U.getAndAddInt(this, VALUE, 1) + 1;
      }
    }
public final class Unsafe {
    @IntrinsicCandidate
    public final int getAndAddInt(Object o, long offset, int delta) {
        int v;
        do {
            v = getIntVolatile(o, offset);
        } while (!weakCompareAndSetInt(o, offset, v, v + delta));
        return v;
    }
    
    @IntrinsicCandidate
    public final boolean weakCompareAndSetInt(Object o, long offset,
                                              int expected,
                                              int x){
        return compareAndSetInt(o, offset, expected, x);
    }
 }

以上的源码来自JDK17，从源码中可以看出incrementAndGet方法的主要逻辑在Unsafe.getAndAddInt()方法中，该方法的主要逻辑如下：

getIntVolatile()：通过偏移量offset从对象o中获取字段的当前值，赋值给v
weakCompareAndSetInt()：如果该方法返回true，则终止循环，返回当前值v，否则循环获取字段的当前值v，通过weakCompareAndSetInt匹配，直到成功，返回true 终止。

那么weakCompareAndSetInt()到底是干什么呢？为什么返回true，才能结束循环？

我们先来看下weakCompareAndSetInt()方法的几个入参：

o：对象o
offset：偏移量
expected：将当前值v赋值为expected作为期望值
x：v+delta 作为新值，其中入参中delta设置的是1

weakCompareAndSetInt()方法中，通过偏移量offset从对象o中获取字段的当前值，然后比较当前值和传入的期望值是否相等，如果相等，则将字段的值更新为x，返回true，如果不相等，则不会执行更新操作，返回false。

有小伙伴就会有疑问了，你不是才通过getIntVolatile获取过当前值，并且作为了期望值expected传入了weakCompareAndSetInt，那么当前值和期望值肯定相等啊！其实不然。

weakCompareAndSetInt中会再次通过偏移量offset从对象o中获取字段的当前值，如果这期间字段值被其他线程修改，那么此时获取到的当前值就不等于期望值，就不会执行更新操作，只有确保在修改字段值之前，字段的当前值与预期值依然相等，才能执行更新操作，从而确保了原子操作的安全性。

9、线程安全的集合

有时候，我们需要把公共资源放到某个集合中，例如：ArrayList，HashMap。

在多线程环境中，如果A线程正在从集合中读取数据，B线程正在往集合中写数据，这样就可能会出现线程安全问题。

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

public class SafeUtils {
    private static ConcurrentHashMap<String, String> hashMap = new ConcurrentHashMap<>();
    public static void main(String[] args) {
        new Thread(new Runnable() {
            @Override
            public void run() {
                hashMap.put("1","guoguo");
            }
        }).start();
        new Thread(new Runnable() {
            @Override
            public void run() {
                hashMap.put("2","lisan");
            }
        }).start();
        try {
            Thread.sleep(100);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println(hashMap);
    }
}

我们聊ConcurrentHashMap是线程安全的，并能解决多线程并发的安全问题。

例如：在多线程环境中，如果A线程正在从集合中读取get()数据，B线程正在往集合中写put()数据。

这里有个特别注意的点：

ConcurrentHashMap的单个操作（如put，get，remove）是线程安全的，但是多个操作的组合却可能不安全，例如:

if (!map.containsKey(key)) {
    map.put(key, value);
}

如果理解呢？

1、单独操作：上述我们的demo中，出现了两个线程A、B，它们分别调用get()、put()方法，虽然看起来像是在组合操作，但实际上对于单个线程而言，这是单独操作，是线程安全的。
2、组合操作：如果在同一个线程中调用了get()和put()方法，并且它们之间存在逻辑上的依赖关系，那么这些操作就构成了一个组合操作，在多线程环境可能是非原子性的。

如何解决非原子问题？