不堆概念、换个角度聊多线程并发编程

最新推荐文章于 2024-10-30 18:07:32 发布
最新推荐文章于 2024-10-30 18:07:32 发布
阅读量227 收藏 1
点赞数 1
分类专栏： JAVA细节深究 文章标签： java 后端 面试
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/veezean/article/details/126048598
版权

大家好，又见面了。

在上一篇文档《JAVA基于CompletableFuture的流水线并行处理深度实践，满满干货》中，我们一起探讨了JAVA中并行编码的相关内容，在文中也一起比较了并行与并发的区别。作为姊妹篇，这里我们就再展开聊一聊关于并发相关的内容。

image.png

俗话说，双拳难敌四手。
俗话还说，人多力量大。

在现实生活中，我们通过团队化的方式来获得比单兵作战更高的单位时间内整体产出速度。同样，在编码世界中，为了提升处理效率，并发一直以来都是软件开发设计场景中无法绕过的话题。不管是微观层面的单个进程内多线程处理模式，还是宏观层面整个系统集群化多节点部署策略，为了提升系统的整体并发吞吐量，程序员们可谓是煞费苦心。

image.png

当然，俗话也说，人多眼杂、林子大了什么鸟都有。在现实中，团队中多人一起配合工作的时候，一系列的问题又会显现：

  • 同一个事情，老王和小张都以为还没处理，结果都去处理了，最后造成了成员工作量的浪费、甚至因为重复处理了一遍导致数据错误
  • 两个有关联的事情分别给了老王和翠花，结果老王在等待翠花先给出结果再开始处理自己的事情，翠花也在等待老王先给出结果然后再处理自己的事情，结果两个人就这么一致等下去，事情一直没完成
  • 同一个文档，小张和翠花各自更新的时候，出现相互覆盖的情况
  • …

image.png

编码源于生活、代码世界其实也处处体现着生活中的朴素哲学思维。纵然并发场景存在一些可能的隐患问题，但我们也不必因噎废食，正所谓先了解它、再掌控它。

作为提升吞吐性能的不二良方，下面我们就一起来尝试按照问题解决型的思路一步步推进，换个角度探讨下多线程并发相关的内容，全面了解下多线程并发世界的各种关联，进而更从容优雅的让并发为我们所用，成为我们提升系统性能的神兵利器。

多线程——并发第一步

并发探险的第一关，就是如何支持并发。下面大概列举下常见的几种方式：

⭐️子线程⭐️

一些简单的场景中，我们为了提升主线程的处理性能，会将过程中一些耗时操作放到一个单独的子线程中进行同步处理。在代码中可以通过创建临时子线程的方式来执行即可：

public void buyProduct() {
    int price = getPrice();
    // 子线程同步处理部分操作
    new Thread(this::printTicket).start();
    // 主线程继续处理其它逻辑
    doOtherOperations(price);
}

⭐️线程池⭐️

频繁创建线程、销毁线程的操作属于一种消耗性能的操作，而且创建线程的数量不可控。所以对于一些固定需要在子线程中并行处理的任务场景，我们可以通过创建线程池的方式，固定维护着一批可用线程，循环利用，去处理任务，以实现提升效率与便于管控的诉求：

private ExecutorService threadPool = Executors.newFixedThreadPool(3);

public void testReleaseThreadLocalSafely() {
    // 任务直接放到线程池中进行处理
    threadPool.submit(this::mockServiceOperations);
}

⭐️定时器⭐️

定时器是一种比较特殊的多线程并发场景，也是经常可能会被忽视掉的一种情况。定时器也是在子线程中执行的，多个定时器之间、定时器线程与主线程之间、定时器线程与业务子线程之间都会以多线程的形式并发处理。

@Scheduled(cron = "0 0/10 * * * ?")
public void syncBusinessInfo() {
    // do something here...
}

⭐️Tomcat等容器⭐️

常见的服务运行容器，比如Tomcat等，都是支持并发请求执行的。而常见的基于SpringBoot实现的服务，其service类都是由Spring进行托管的单例对象。这种场景是比较常见的多线程场景。

改为多线程并发执行，虽然效率是提升了，但是问题也来了——数据执行结果不准确。

结果不对，显然是我们无法接受的。所以摆在我们面前的下一难题，就是要保证执行结果数据的准确。

synchronized与lock

在JAVA中提到线程同步，使用最简单、应用频率最高的非synchronized关键字莫属了。它是 Java 内建的一种同步机制，代表了某种内在锁定的概念，当一个线程对某个共享资源加锁后，其他想要获取共享资源的线程必须进行等待，synchronized 也具有互斥和排他的语义。具体用法如下：

  • synchronized 修饰实例方法，相当于是对类的实例(this)进行加锁，进入同步代码前需要获得当前实例的锁
public synchronized void test() {
    //...
}
  • synchronized 修饰代码块，相当于是给对象(syncObject)进行加锁，在进入代码块前需要先获得对象的锁
public void test() {
    synchronized(syncObject) {
        //允许访问控制的代码   
    }
    // 其它操作
}
  • synchronized 修饰静态方法，相当于是对类（LockTest.class）进行加锁
public class LockTest {
    public synchronized static void test() {
        //...
    }
}

对于被锁的目标对象而言，锁是具有排他性的，也就是同一个对象上的多个带锁方法，同一时刻只有1个线程可以抢到锁，其余都会被阻塞住。比如下面的代码，线程A和线程B分别同时请求method1和method2，虽然调用的是不同的方法，但是两个线程其实是在争夺同一把锁：

public class LockTest {
    public synchronized void method1() {
        // ...   
    }
    public synchronized void method2() {
        // ...
    }
}

image.png

由于synchronized属于JVM关键字，属于一种比较重量级的锁。在JDK中还提供了个Lock类，提供了众多不同类型的锁，供各种不同场景诉求使用。

public void test() {
    Lock lock = ...;
    lock.lock();
    try{
         // ...
    }catch(Exception ex){
         // ...
    }finally{
        // ...
        lock.unlock(); 
    }
}

与synchronized不同，使用Lock的时候需要特别注意最后一定要可靠的释放掉占用的锁。

到这里，再测试会发现，多线程并发执行，数据结果也对，似乎是没什么问题——但是这样真的就结束了吗？

如果并发编程仅仅就这么点内容，那显然对不上它在编码界的地位。我们接着往下看。

死锁——不期而遇的小惊吓

经过前面的内容，我们知道了使用多线程的方式来实现并发处理，也知晓了可以通过加锁的方式来保证对共享数据编辑的顺序性与准确性。而加了锁之后稍不留神间，也许就会出现死锁。

image.png

一个线程A已经持有一个锁的情况下同时又去请求调用另一个加锁的对象或者代码块，而这个被请求的对象又被另一个线程B所持有，而这个线程B，又恰好在等待此时被线程A所持有的加锁资源或代码块，于是两个线程都在沉默中无限等待下去，便会出现死锁。

看一个实际业务场景：

一个运维管理系统，用于维护虚拟机资源以及部署的业务进程信息，且支持按照虚拟机维度和业务进程维度进行分别查看相关信息。即：

  1. 查看虚拟机VM信息，需要一并获取到上面部署的Process信息
  2. 查看Process信息，需要一并获取其所位于的虚拟机的信息。

假定基于SpringBoot框架进行代码实现，DeployedProcessService与VmService实例由Spring框架进行托管，为单例对象，然后彼此自动注入对方实例。假定由于业务逻辑需要，对两个服务类的执行方法进行了加锁处理。部署进程管理服务DEMO代码如下：

@Service
public class DeployedProcessService {
    @Autowired
    VmService vmService;
    
    public synchronized void manageDeployedProcessInfo() {
        // 获取进程信息
        collectProcessInfo();
        // 获取进程所在VM信息
        vmService.manageVmInfo(this);
    }    
}

@Service
public class VmService {
    @Autowired
    DeployedProcessService deployedProcessService;

    public synchronized void manageVmInfo() {
        // 获取此VM基础信息
        collectVmBasicInfo();
        // 获取此VM上已部署的进程信息
        deployedProcessService.manageDeployedProcessInfo(this);
    }
}

我们使用两个独立进程同时分别去查询VM信息以及Process信息，模拟并发操作的场景，会发现永远等不到结果。为啥呀？因为死锁了！

我们可以通过jstack命令来看下此时的JVM内线程堆栈情况，会发现有提示Found one Java-level deadlock，然后可以看到死锁的堆栈：

Found one Java-level deadlock:
=============================
"ForkJoinPool.commonPool-worker-2":
  waiting to lock monitor 0x000000001cf532b8 (object 0x000000076c29bf28, a com.veezean.skills.lock.VmService),
  which is held by "ForkJoinPool.commonPool-worker-1"
"ForkJoinPool.commonPool-worker-1":
  waiting to lock monitor 0x000000001fce9f88 (object 0x000000076c29f460, a com.veezean.skills.lock.DeployedProcessService),
  which is held by "ForkJoinPool.commonPool-worker-2"

Java stack information for the threads listed above:
===================================================
"ForkJoinPool.commonPool-worker-2":
        at com.veezean.skills.lock.VmService.manageVmInfo(VmService.java:14)
        - waiting to lock <0x000000076c29bf28> (a com.veezean.skills.lock.VmService)
        at com.veezean.skills.lock.DeployedProcessService.manageDeployedProcessInfo(DeployedProcessService.java:19)
        - locked <0x000000076c29f460> (a com.veezean.skills.lock.DeployedProcessService)
        at com.veezean.skills.lock.Main.lambda$main$1(Main.java:19)
"ForkJoinPool.commonPool-worker-1":
        at com.veezean.skills.lock.DeployedProcessService.manageDeployedProcessInfo(DeployedProcessService.java:15)
        - waiting to lock <0x000000076c29f460> (a com.veezean.skills.lock.DeployedProcessService)
        at com.veezean.skills.lock.VmService.manageVmInfo(VmService.java:18)
        - locked <0x000000076c29bf28> (a com.veezean.skills.lock.VmService)
        at com.veezean.skills.lock.Main.lambda$main$0(Main.java:18)

Found 1 deadlock.

关于死锁的产生原因，网上或者书中给出的答案无外乎就是说如下四个原因要同时成立，就会死锁：

  1. 互斥
  2. 占有并等待
  3. 非抢占
  4. 循环等待

不知道大家看到上面这个解释是啥感觉？懂还是不懂？反正我的经历是：在我懂之后，看这4点中的每一点都很在理；而我不懂时，我依旧不知道啥原因导致的死锁。其实，用白话解释死锁的产生原因，就是两个或者多个线程各自拿到了一个锁，然后自己依赖别人的锁，别人依赖自己的锁，然后彼此都在相互等待，永远没有办法等到。

那么应该如何解决呢？

还是以上面代码为例，一个最简单的方式，就是两个Service类的加锁方法不要相互调用，各自Service类中独立实现所有逻辑即可。

小提示：

一个好的经验，就是加锁的方法嵌套调用另一个加锁的方法时，多留个心眼，看看会不会出现相互依赖或者循环依赖的情况。

锁优化思想——降低锁的影响

规避了可能存在的死锁问题之后，另一个问题又出现在我们面前——性能。我们采用多线程并发编程的初衷，是为了尽可能的提升整体的处理性能，但是加锁之后，加锁的地方反而成为了整个并发处理的一个堵点，导致整个多线程并发的效果大打折扣。

image.png

所以，如何降低锁对多线程并发处理的影响，成为飘在程序员面前的一团新的乌云。为此也衍生出了多种处理与应对策略，比如_降低锁的范围以减少锁持有时间_、缩小锁粒度以降低夺锁竞争、_利用读写锁减少加锁场景_等等。

降低锁范围

这个其实很好理解，因为加锁范围越大，意味着持锁执行的时间就会越久，那么其他线程阻塞等待的时间就会越久，这样整个系统的堵点就会越发明显。而如果能够将一些并不需要放到同步锁内执行的逻辑放到外部去并行执行，这样就会降低锁内逻辑的处理时长，其余线程阻塞等待时间也就会缩短。

image.png

举个例子。假如现在有个更新文章内容的需求，其处理逻辑如下：

  1. 校验当前用户是否有权更新
  2. 校验文章内容重复度
  3. 检查文章中是否有违禁词
  4. 更新到数据库中
  5. 加载到ES中

为了保证并发更新操作的准确性，对方法添加synchronized同步锁，保证多线程顺序执行：

public synchronized void updateArticle() {
    verifyAuthorInfo();
    checkArticleDuplication();
    checkBlackWords();
    saveToDb();
    loadToEs();
}

但是实际分析下，其实几个操作其实只有一个环节需要做同步锁处理，其余的操作其实并不会有任何的同步问题，因此我们按照缩小锁范围的优化策略，可以将synchronized锁范围缩小：

public void updateArticle() {
    verifyAuthorInfo();
    checkArticleDuplication();
    checkBlackWords();
    saveToDb();
    loadToEs();
}

private synchronized void saveToDb() {
    // ...
}

缩小锁粒度

锁的粒度越大，多线程请求的时候对锁的竞争压力越大，对性能的影响越大。如果将锁的粒度拆分小一些，这样同时请求到同一把锁的概率就会降低，这样线程间争夺锁的竞争压力就会降低。

可以看下下面的示意图，4个线程请求同一锁时，其中1个线程可以抢到锁，其余三个线程将处于等待；而将锁拆分为3个子锁的时候，这样4个线程中只有1个线程处于等待：

image.png

上面演示的就是分段锁的概念。在JAVA7之前，面试的时候经常会遇到的一个问题就是ConcurrentHashMap与HashTable都是线程安全的，为啥ConcurrentHashMap的性能上会更好些呢？其实就是因为ConcurrentHashMap使用了分段锁（Segment）的方式实现的：

image.png

⭐️补充一下⭐️

上面为啥要强调是JAVA7之前呢？因为JAVA7开始，ConcurrentHashMap的线程安全策略变了，改为了基于CAS的策略了。

细化锁场景

对于同一个共享数据的各种操作，很多时候并不是所有多线程操作都会出数据错乱问题，一般情况下只有写操作才会改变数据的内容，而多个线程同时执行读取操作的时候并不会对数据产生影响，所以这个_读取的场景其实无需和写操作使用相同的同步锁逻辑_。所以为了满足此场景，出现了读写锁。

image.png

读写锁的特点就是，针对读操作和写操作，提供了不同的加锁同步策略，具体而言：

  1. 读读不互斥
  2. 读写互斥
  3. 写写互斥

在 Java 中，读写锁是使用 ReentrantReadWriteLock 类来实现的，其中：

  • **ReentrantReadWriteLock.ReadLock **表示读锁，它提供了 lock 方法进行加锁、unlock 方法进行解锁。
  • **ReentrantReadWriteLock.WriteLock **表示写锁，它提供了 lock 方法进行加锁、unlock 方法进行解锁。

代码示例如下。 创建读写锁，然后通过readLock和writeLock方法，可以分别获取到读锁和写锁：

// 创建读写锁
final ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock();
// 获得读锁
final ReentrantReadWriteLock.ReadLock readLock = readWriteLock.readLock();
// 获得写锁
final ReentrantReadWriteLock.WriteLock writeLock = readWriteLock.writeLock();

在读取操作的场景，直接使用读锁，使用完成后需要可靠释放锁：

public String readObject() {
    // 读锁使用
    readLock.lock();
    try {
        // 业务代码...
    } finally {
        readLock.unlock();
    }
}

在写操作的场景使用写锁，使用完成后同样需要可靠释放锁：

public void writeObject() {
    // 写锁使用
    writeLock.lock();
    try {
        // 业务代码...
    } finally {
        writeLock.unlock();
    }
}

其它策略

除了上述介绍的各种锁优化策略，还有很多不同类型的锁，整体思路大体相同，此处不再展开描述，具体可以参见这篇文章：《不可不说的JAVA“锁”事》：

image.png

无锁胜有锁——就是要站着还把钱挣了

为了保证多线程的数据安全，我们引入了同步锁；为了降低同步锁的影响，我们绞尽脑汁去降低锁竞争几率。但是勤劳的程序员永远不会满足眼前的结果、不然头顶也不会这么早的锃光瓦亮。于是，一个灵魂拷问又飘了出来：能不能既使用多线程并发处理、又不用加同步锁？

image.png

于是乎，一些无锁解决方案开始在某些特定的并发场景内崭露头角。

ThreadLocal空间换时间

很多时候，编码世界汇总对程序性能的优化，无外乎是时间与空间的权衡。当系统更关注服务的处理响应时长，就会使用一些缓存的策略，降低CPU的重复计算，以此来提升性能。

回到我们多线程的场景，为了保证多个线程对同一个共享内存对象的访问安全，所以通过同步锁的方式来保证串行访问，这样就会造成CPU的排队等待，性能受阻。那么，如果各个内存不去访问这个统一的共享对象，而是访问自己独享的对象，这样不就互不干扰、无需阻塞等待了吗？

比如下面图中的收费站场景，多条路最后需要经由同一个收费站，所以导致收费站这里会出现堵塞。而如果每条路都建一个自己的收费站，这样就有效避免了堵塞的状况。

image.png

image.png

仿照相同的原理，ThreadLocal便出现了。它通过冗余副本的方式，使得某个内存共享对象在各个线程上都有自己的拷贝副本。在尝试去了解ThreadLocal结构与原理前，可以先看下ThreadLocal的set方法实现源码：

public void set(T value) {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null)
        map.set(this, value);
    else
        createMap(t, value);
}

翻译成白话文，先获取到当前线程信息，然后获取到当前线程对应的ThreadLocalMap对象，然后将当前对象以及要存储的内容值存到Map中。也就是说：ThreadLocal只是一个方法封装，具体的数据实际存储在ThreadLocalMap中，而这个ThreadLocalMap是每个线程都有自己专属副本，里面存储着这个线程执行过程中使用的所有ThreadLocal对象以及对应数值（代码里面可能会new多个不同的ThreadLocal对象，比如有的用于存储当前用户，有的用于存储当前token信息之类的）。

image.png

从ThreadLocal的实现原理中，我们可以发现_其适用的场景是有限的_，即只适用于需要在单个线程内全局共享的场景，而不适用于需要在多个线程间做数据交互共享的场景。

⭐️适用场景举例⭐️**：**

一个SpringBoot构建的后端服务系统，对外以Controller方式提供诸多Restful接口方法供客户端调用。客户端调用的时候会携带token信息，然后鉴权逻辑中根据token获取到具体用户信息并缓存到内存中，后续的业务处理逻辑中有多处会需要获取该用户信息。

这是ThreadLocal使用的一个典型场景，在通过token鉴权完成后，将用户信息设置到ThreadLocal对象中，这样后续所有需要用的地方，直接从ThreadLocal中获取就行了。

为了方便后续使用，我们先封装一个工具类，提供些静态方法，便于对ThreadLocal进行操作：

public class CurrentUserHolder{
    private static final ThreadLocal<UserDetail> CURRENT_USER = ThreadLocal.withInitial(() -> null);
    
    public static void cacheUserDetail(UserDetail userDetail) {
        CURRENT_USER.set(userDetail);
    }
    
    public static UserDetail getCurrentUser() {
        CURRENT_USER.get();
    }
    
    public static void clearCache() {
        CURRENT_USER.remove();
    }
}

在业务处理开始之前先统一设置下用户的缓存信息。因为是基于SpringBoot项目来讲解，所以我们实现一个HandlerInyerceptor的实现类，并在preHandle方法中根据token获取到用户详情并缓存到ThreadLocal中：

public class AuthorityInterceptor implements HandlerInterceptor {
    private static final ThreadLocal<UserDetail> CURRENT_USER = ThreadLocal.withInitial(() -> null);
    
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
        log.info("request IN, url: {}", request.getRequestURI());
        try {
            UserDetail userDetail = userAuthService.authUser(request.getHeader("token"));
            // 校验通过，缓存用户信息
            CurrentUserHolder.cacheUserDetail(userDetail);
            return true;
        } catch (Exception e) {
            // 校验没通过，清理线程数据
            CurrentUserHolder.clearCache();
            return false;
        }
    }
}

因为鉴权通过之后，会将当前的用户信息添加到缓存中，并进入到后续的业务实际处理代码中，所以业务处理的时候如果需要获取当前登录用户信息的时候，可以直接从CurrentUserHolder中获取即可。

public void collectBookToMySpace(Book book) {
    UserDetail user = CurrentUserHolder.getCurrentUser();
    // 其他逻辑省略
}

借助ThreadLocal可以让我们实现在线程内部共享对象，以此规避多线程间的同步等待处理，但是使用完毕之后，还需要保证清除掉当前线程的缓存数据值。为什么要这么做呢？拿线程池举个例子：

既然是为每个线程拷贝一份独立的副本，对于同一个线程而言拿到的数据是同一个，那么对于使用线程池来处理多任务的场景，线程都是重复利用的，这样会导致同一个线程中正在处理的任务可能会拿到上一个任务设置的共享值。对于业务处理而言可能会得到非预期结果。

当然，除了可能会导致业务处理的时候前后任务缓存数据错乱，使用完毕不清理缓存，有些时候还容易导致内存泄漏的问题。所以编码的时候、尤其涉及内存资源使用的时候，用完回收始终会是一个好习惯。

⭐️可靠清除线程副本⭐️

既然知道在使用完成之后需要可靠的清理掉当前线程的ThreadLocal副本数据，但是对于一些流程比较长、或者逻辑比较复杂的系统，其线程任务的退出分支可能有很多条，那么怎么样才能做到可靠清理、避免有分支遗漏呢？

  1. 如果是自己实现的线程池或者线程分发操作，在子线程的调用顶层位置通过try...finally...包裹调用逻辑，并在finally中进行释放操作。
public void testReleaseThreadLocalSafely() {
    threadPool.submit(() -> {
        try {
            // 设置token信息
            TOKEN.set("123456");
            // 执行业务处理操作
            mockServiceOperations();
        } finally {
            // finally分支中可靠清除当前线程的ThreadLocal副本
            TOKEN.remove();
        }
    });
}
  1. 基于一些框架系统实现的场景，比如SpringBoot项目，可以定制个Interceptor并在afterCompletion等退出前回调方法中，添加上对应的清理逻辑。
@Override
public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, @Nullable Exception ex) {
    CurrentUserHolder.clearCurrentThreadCache();
}

volatile保证可见性

与synchronized保证数据同步处理的原理不一样，volatile主要解决的是数据在多线程之间的可见性问题，但是不保证数据操作的原子性。volatile用于修饰变量，可以保证每个共享此变量数据的线程都可以第一时间拿到此值的真实值。

image.png

当把变量声明为volatile类型后，编译器与运行时都会注意到这个变量是共享的，因此不会将该变量上的操作与其他内存操作一起重排序。volatile变量不会被缓存在寄存器或者对其他处理器不可见的地方，因此在读取volatile类型的变量时总会返回最新写入的值。

但是因为它不保证原子操作，所以如果有多个线程同时来修改变量的值时，还是可能会出现问题。所以，volatile适合那种单个线程去修改值内容，但是多个线程会共享读取变量结果的场景。

image.png

比如项目代码中，我们需要支持系统配置属性的动态变更，我们可以将系统参数使用volatile修饰，然后使用固定一个线程进行系统属性值的维护，其余业务线程负责从内存中读取即可。

发布订阅模式

在并发编程中使用发布订阅模式能够解决绝大多数并发问题。

多线程协同配置的场景下，可以借助MQ实现发布订阅模式，可以保证每个任务都分配给不同的消费者进行处理，这样就不会出现重复处理的问题、也减少了线程或者进程间资源争夺的风险，正可谓是“无锁胜有锁、四两拨千斤”的典型。

image.png

对于MQ的选型，如果是单进程内多线程间的使用，可以使用BlockingQueue来实现，而用于分布式系统内时，可以选用一些消息队列中间件，比如RabbitMQ、Kakfa等。

CAS乐观锁策略

所谓CAS，也即Compare And Swap，也即在对数据执行写操作前，先比较下数据是否有变更，没有变更的情况下才去执行写操作，否则重新读取最新记录并重新执行计算后，再执行比对操作，直到数据写入完成。CAS是一种典型的乐观锁策略，其与常规的加同步锁的处理策略有很大的不同，属于一种比较经典的无锁机制：

image.png

并发场景对公共存储（比如MySQL）中的数据进行更新的时候，经常会需要考虑并发更新某个记录的情况，尤其是一些界面编辑更新的场景更是常见。这个场景下使用CAS机制可以有效解决问题。

先看个问题场景：

有个需求任务跟踪管理系统，团队内的成员可以编辑团队内的待办需求事项的进展描述，如果团队内有两个人都打开了某一个需求页面进行编辑进展说明，那么第一个人改动完成存储的内容，会被第二个人保存改动时直接覆盖掉。

image.png

使用CAS的思路来解决上面场景提及的更新覆盖问题，我们可以对DB中的记录数据增加一个version字段，更新的时候必须保证version字段值与自己最初拿到的version值一致时才能更新成功，同时在每次update的时候更新下version字段，这样问题就解决啦，看下过程：

image.png

代码实现起来也很简单：

public void updateItem(Item  item) {
    int updateResult = updateContentByIdAndVersion(item.getContent(), item.getId(), item.getVersion());
    if (updateResult == 0) {
        // 没有更新成功任何记录，说明version比对失败已经有别人更新了
        // 要么放弃处理，要么重试
    }
}

CAS始终按照无锁的策略进行数据的处理、处理失败则重试或放弃。在竞争不是很激烈的并发场景下，可以有效的提升整体的处理效率，因为大部分的场景下都会执行成功，只有在少量的请求出现并发冲突的时候，才会进入自旋重试。但当竞争很激烈的场景下，会导致写入操作高频率失败进入自旋，这要会大大的浪费CPU资源，且因为自旋其实就是线程不停的循环，所以大量自旋可能会使得CPU的占用比较高。

image.png

补充说明：

在单进程内的多线程间使用CAS机制保证并发的时候，需要结合volatile一起使用，以此来保证原子性与可见性。

另外，我们在前面有提到JAVA7之前ConcurrentHashMap使用的是分段锁的技术，而从JAVA7之后，ConcurrentHashMap线程安全保护的实现逻辑是改为了CAS+synchronized的方式来实现，以此来获取更好的性表现。

分布式锁——跨越进程的相逢

前面介绍了单进程内的一些多线程高并发场景的应对方案。但高并发的场景，除了单线程内的多线程间的并发之外，还有分布式系统集群内的多个进程之间的并发。所以分布式锁应运而生。

举个例子：

数据库有一张“热议话题”表，表中每条记录有个“当前热度”字段，热度计算服务需要每隔5分钟执行一次计算，然后更新表中每条记录的热度字段。

为了保证系统的高可用，热度计算服务部署了多个进程节点，由定时器触发，每隔5分钟计算一次。

image.png

分布式锁的实现，有多种方式，比较常见的是基于Redis或者MySQL来实现。分布式锁在实现以及使用的时候，需要关注几个要点;

  • 客户端请求锁的整体操作需要是个原子操作，即需要保证锁分配结果的唯一性
  • 客户端获取到锁之后进行自身业务逻辑处理，处理完成之后必须要主动释放锁（需要注意判断下是否是自己所持有的锁）
  • 锁要有兜底退出机制，防止某个客户端获取到锁之后出现宕机等异常情况，导致锁被持有后无法释放，其它客户端也无法继续申请

image.png

比如基于Redis实现分布式锁的时候，使用示意如下：

// 获取锁
public boolean accuireLock(String lockName) {
    return stringRedisTemplate.opsForValue().setIfAbsent(lockName, "", 1L, TimeUnit.MINUTES);
}

// 释放锁
public void releaseLock(String lockName) {
    stringRedisTemplate.delete(lockName);
}

上面代码中，简单的使用setNx命令来实现分布式锁的申请，又设置了redis的超时时间，一旦在设定的时间内依旧没有主动释放锁，则redis将主动释放锁，供其余客户端再来请求。

在上面归纳的分布式锁实现与使用的注意要点中，在提及业务处理完成之后要主动释放锁的时候，有特别补充了一个要求：需要判断下是否是自己的锁，只能释放自己的锁！为什么一定要强调这一点呢？以上述代码为例，看一种可能的情况：

image.png

从上图可以看出，Client-1申请到了_锁1_，但是Client-1执行超时导致_锁1_被强制释放掉了，而Client-2随后获取到了_锁2_并开始执行处理逻辑。此时Client-1的任务终于执行完成了，然后去释放了锁（Client-1自己不知道自己超时，还是按照正常逻辑去释放锁），结果_Client-3_此时又申请到了_锁3_，然后开始执行自己的任务。这个时候就会出现了Client-2和Client-3同时执行的异常情况了。

整个问题出现的原因就是释放锁的时候没有校验是否是自己的锁，所以出现了越权释放了别人的锁的情况。为了避免此情况的发生，我们对前面的分布式锁实现使用逻辑稍加改动即可：

首先是申请分布式锁的时候，可以生成个随机UUID作为锁的value值，如果申请成功，则直接返回此锁的UUID唯一标识：

/**
 * 获取锁，如果获取成功，则返回锁的value值（UUID随机）
 */
public String accuireLock(String lockName) {
    String uuid = UUID.randomUUID().toString();
    Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockName, uuid, 1L,
            TimeUnit.MINUTES);
    if (result == null || !result) {
        throw new RuntimeException("获取锁失败");
    }
    return uuid;
}

锁释放的时候，需要同时提供锁名称与锁的唯一UUID标识值，先根据锁名称尝试获取下已存在的锁，然后比对下锁value值是否一致，如果一致，则表名当前的锁是自己锁持有的这把锁，然后将其释放即可：

/**
 * 释放锁，先比对锁value一致，才会释放
 */
public void releaseLock(String lockName, String lockUuid) {
    String lockValue = stringRedisTemplate.opsForValue().get(lockName);
    if (!StringUtils.equals(lockValue, lockUuid)) {
        throw new RuntimeException("锁释放失败，锁不存在");
    }
    stringRedisTemplate.delete(lockName);
}

当然啦，我们这里举例是使用的Redis的setNx命令来实现的，此实现可以轻松的应对大部分的使用场景。但是，上述的释放锁实现代码中可以看出，由于获取锁内容、比对锁内容、释放锁内容三个操作是独立分开的，存在无法保证操作原子性的弊端。如果项目的要求级别较高，可以考虑使用LUA脚本封装为原子命令操作来解决，或者使用redis官方提供的redission来实现。

补充：并发与并行

本文主要讨论了多线程并发编程相关的内容，提到并发，往往还有个容易混淆的概念，叫并行。关于并行的具体介绍与实现策略，以及并发与并行的详细区别，可以参见我的另一个文档《JAVA基于CompletableFuture的流水线并行处理深度实践，满满干货》，此处不述。

综合而言：

  1. 如果业务处理逻辑是CPU密集型的操作，优先使用基于线程池实现并发处理方案（可以避免线程间切换导致的系统性能浪费）。
  2. 如果业务处理逻辑中存在较多需要阻塞等待的耗时场景、且相互之间没有依赖，比如本地IO操作、网络IO请求等等，这种情况优先选择使用并行处理策略（可以避免宝贵的线程资源被阻塞等待）。

总结

好啦，关于多线程并发场景常见问题的相关应对策略，这里就探讨到这里啦。那么看到这里，相信您应该有所收获吧？那么你是否有实际应对过多线程并发场景的开发呢？那你是如何处理的呢？是否有发现过什么问题呢？评论区一起讨论下吧、我会认真对待您的每一个评论~~

此外：

我是悟道，聊技术、又不仅仅聊技术~

如果觉得有用，请点赞 + 关注让我感受到您的支持。也可以关注下我的公众号【架构悟道】，获取更及时的更新。

期待与你一起探讨，一起成长为更好的自己。

是Vzn呀
关注
专栏目录
C++多线程并发（一）--- 线程创建与管理
流云
03-16 2万+
一、何为并发 简单来说，并发指的是两个或多个独立的活动在同一时段内交替发生。与并发相近的另一个概念是并行，并行则强调的是多个独立的活动在同一时刻点同时发生。 二、为什么使用并发 在应用程序中使用并发的原因主要有两个：关注点分离和性能。事实上，甚至可以说它们差不多是使用并发的唯一原因；当你观察的足够仔细时，一切其他因素都可以归结到这两者之一（或者可能是二者兼有）。
C/C++多线程并行编程
qq_30003797的博客
06-01 2435
需要引入thread库 创建线程： thread thr = thread(fun_name, argvs());//参数列表 当线程被创建以后，就会自动开始执行线程函数fun_name，函数的参数中如果有引用，需要用ref()函数，不能用&符号 创建线程数组： thread* th = new thread[thr_num]; //新建一个线程数组 for(int i=0;i<thr_num;i++){ //对每个线程进行初始化 th[i] = thread(函数名称, 参数列表);
万字长文主讲介绍CSharp多线程、多进程并行开发
XiaoCai
01-11 3134
1 前言 要说多线程 我们明确几个概念 1.1 名词 1.1.1 操作系统 操作系统是计算机系统中的一个系统软件，是一些程序模块的集合 它们能以尽量有效、合理的方式组合和管理计算机的软硬资源 系统效率，资源利用率 CPU利用率充足与否？I/O设备是否忙碌？ 合理地组织计算机的工作流程，控制程序的执行并向用户提供各种服务功能 各种软硬件资源的管理是否公平合理 如果不公平、不合理、则可能产生问题 两种角度：用户界面 与 编程接口 使得用户能够灵活、方便地使用 计算机，使得整个计算机系统高效运行
C/C++开发，无可避免的多线程（篇一）.跨平台并发编程姗姗来迟
技术需要分享
03-01 1399
C/C++开发，无可避免的多线程（篇一）并发编程姗姗来迟，介绍如何搭建支持c++11以上版本的编译器，并阐述c/c++多线程内容以及c/c++在c++11标准前pthread函数集及c++11标准后thread类对于多线程编程的不同应用及案例，并阐述了c++20标准提出的std::jthread类。
并发编程面试题（2020最新版）
热门推荐
ThinkWon的博客
03-14 36万+
文章目录基础知识并发编程的优缺点为什么要使用并发编程（并发编程的优点）并发编程有什么缺点并发编程三要素是什么？在 Java 程序中怎么保证多线程的运行安全？并行和并发有什么区别？什么是多线程，多线程的优劣？线程和进程区别什么是线程和进程?进程与线程的区别什么是上下文切换?守护线程和用户线程有什么区别呢？如何在 Windows 和 Linux 上查找哪个线程cpu利用率最高？什么是线程死锁形成死锁的...
2024年JAVA多线程并发编程面试题（持续更新）
GEEK-BANANA
02-18 6011
这里写目录标题并发编程基础blocked 和 waiting 的区别线程的 run()和 start()有什么区别？为什么我们调用 start() 方法时会执行 run() 方法，为什么我们不能直接调用 run() 方法？说说线程的生命周期及五种基本状态？Java 中用到的线程调度算法是什么？线程同步以及线程调度相关的方法。sleep() 和 wait() 有什么区别？线程的 sleep()方法和 yield()方法有什么区别？同步方法和同步块，哪个是更好的选择？如果你提交任务时，线程池队列已满，这时会发生
Java 多线程 并发编程 整理
CWS_chen
04-09 3850
一、多线程 1、操作系统有两个容易混淆的概念，进程和线程。 进程：一个计算机程序的运行实例，包含了需要执行的指令；有自己的独立地址空间，包含程序内容和数据；不同进程的地址空间是互相隔离的；进程拥有各种资源和状态信息，包括打开的文件、子进程和信号处理。 线程：表示程序的执行流程，是CPU调度执行的基本单位；线程有自己的程序计数器、寄存器、堆栈和帧。同一进程中的线程共用相同的地址空间，同时共享进...
多线程与高并发笔记
牧小农
09-13 3983
1. 创建线程的三种方式 实现Runnable 重写run方法 继承Thread 重写run方法 线程池创建 Executors.newCachedThreadPool() 2. Thread线程操作方法 Thread.sleep([mills]) 当前线程睡眠指定mills毫秒 Thread.yield() 当前线程优雅让出执行权 join 例如Thread t1, t2 在t2的run方法中调用t1.join(),线程t2将等待t1完成后执行 3. Thread状态
Java进程和线程的区别以及并发编程的基本概念
终生学习践行者
03-11 2322
本文详细介绍了Java进程和线程的区别以及并发编程的基本概念
Java 多线程 并发编程
escaflone的专栏
08-28 17万+
一、多线程 1、操作系统有两个容易混淆的概念，进程和线程。 进程：一个计算机程序的运行实例，包含了需要执行的指令；有自己的独立地址空间，包含程序内容和数据；不同进程的地址空间是互相隔离的；进程拥有各种资源和状态信息，包括打开的文件、子进程和信号处理。 线程：表示程序的执行流程，是CPU调度执行的基本单位；线程有自己的程序计数器、寄存器、堆栈和帧。同一进程中的线程共用相同的地址空间，同时共享进
多线程并发编程-同步与互斥-原⼦变量-并发和⽆锁 数据结构
12-30
多线程并发编程-同步与互斥-原子变量-并发和无锁数据结构 多线程并发编程是提高认程序性能的核心技术，但它也增加了编程的复杂性。因此，系统理解和掌握多线程并发编程的技巧变得尤为重要。本章将从多线程编程的...
深入理解Java多线程与并发编程
08-26
深入理解Java多线程与并发编程 Java多线程与并发编程是Java开发中非常重要的一部分，它涉及到多线程的创建、同步、通信、死锁等问题。下面我们将详细介绍Java多线程与并发编程的相关知识点。 一、多线程三大特性 ...
多线程与高并发编程笔记、源码等
09-05
在IT领域，多线程和高并发编程是构建高性能、响应迅速的应用程序的关键技术。这份压缩包中的资源，包括笔记和源码，旨在帮助开发者深入理解这些概念，并掌握实际应用技巧。 标题“多线程与高并发编程笔记、源码等”...
服务器虚拟化
最新发布
Hellc007的博客
10-30 458
服务器虚拟化是一种将物理服务器的计算资源分割为多个独立虚拟环境的技术，通过软件层将底层硬件资源抽象化并在上层构建多个虚拟机（Virtual Machine, VM）。每个虚拟机运行独立的操作系统和应用程序，相互之间不受干扰，具备类似于物理服务器的功能。这种技术使得一台物理服务器能够承担多台虚拟服务器的角色，从而极大地提升了硬件资源的利用率。服务器虚拟化的概念最早可追溯到20世纪60年代IBM大型机时代，当时虚拟化被用来将大型机的资源分配给多个任务，使得企业在有限的资源下能够同时运行多个应用。
（1）Java 编程基础概览：数据类型、常量、变量、标识符与运算符
码界领航的Cherry Yang的博客
10-28 961
8 位，占1个字节，有符号的，范围 -128（-2^7）至 127（2^7-1）。32 位，占4个字节，范围 -2,147,483,648（-2^31）至 2,147,483,647（2^31 - 1）。Java 提供了六种数字类型，其中四个为整数类型，两个为浮点类型，还有字符类型，以及布尔型。16 位，占2个字节，范围 -32768（-2^15）至 32767（2^15 - 1）64 位，占8个字节，范围 -2^63 至 2^63 - 1。16 位 Unicode 字符，占 2 个字节。
java_方法递归调用
HHppGo的博客
10-27 453
简单的说: 递归就是方法自己调用自己,每次调用时传入不同的变量.递归有助于编程者解决复杂问题,同时可以让代码变得简洁。
Java Web开发教程：从入门到精通
孤客科技
10-25 1090
Java Web开发是一个充满挑战和机遇的领域。通过本文的学习，您应已掌握Java Web开发的基础知识和实践技巧。不断实践、深入学习，将使您在这个领域越走越远。希望您能在未来的开发旅程中创造出更多精彩的Web应用！如有任何问题或想法，欢迎在评论区留言讨论！期待您的参与与分享！
Java复习24（PTA)
2301_79272475的博客
10-30 229
Java复习24（PTA)：多种排序的book类*
Python并发编程详解：多线程、多进程与协程
本文旨在从性能角度出发，帮助读者初识并发编程，通过简单易懂的方式解释相关概念，并通过代码示例对比单线程、多线程和多进程的执行效果。 在并发编程中，首先要了解的是基本概念。串行是指程序在某一时刻只能执行...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

是Vzn呀

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值