聊天室软件源码的并发高，可能是什么问题引发的？

最新推荐文章于 2024-03-21 16:56:32 发布

云豹科技程序猿

最新推荐文章于 2024-03-21 16:56:32 发布

阅读量120

点赞数

分类专栏：语音社交系统源码文章标签：音视频性能优化语音识别

原文链接：https://my.oschina.net/u/4526289/blog/5319119

版权

语音社交系统源码专栏收录该内容

57 篇文章 2 订阅

订阅专栏

CPU为了对聊天室软件源码进行优化，会对聊天室软件源码的指令进行重排序，此时聊天室软件源码的执行顺序和代码的编写顺序不一定一致，这就可能会引起有序性问题。

有序性

有序性是指：按照聊天室软件源码的既定顺序执行。

说的通俗一点，就是聊天室软件源码会按照指定的顺序执行，例如，按照程序编写的顺序执行，先执行第一行代码，再执行第二行代码，然后是第三行代码，以此类推。如下图所示。
在这里插入图片描述

指令重排序

编译器或者解释器为了优化聊天室软件源码的执行性能，有时会改变程序的执行顺序。但是，编译器或者解释器对程序的执行顺序进行修改，可能会导致意想不到的问题！

在单线程下，指令重排序可以保证最终执行的结果与聊天室软件源码顺序执行的结果一致，但是在多线程下就会存在问题。

如果发生了指令重排序，则程序可能先执行第一行代码，再执行第三行代码，然后执行第二行代码，如下所示。

在这里插入图片描述

例如下面的三行代码。

int x = 1; 
int y = 2;
int z = x + y;

CPU发生指令重排序时，能够保证x=1和y = 2这两行代码在z = x + y这行代码的上面，而x = 1和 y = 2的顺序就不一定了。在单线程下不会出现问题，但是在多线程下就不一定了。

有序性问题

CPU为了对聊天室软件源码进行优化，会对聊天室软件源码的指令进行重排序，此时程序的执行顺序和代码的编写顺序不一定一致，这就可能会引起有序性问题。

在Java程序中，一个经典的案例就是使用双重检查机制来创建单例对象。例如，在下面的代码中，在getInstance()方法中获取对象实例时，首先判断instance对象是否为空，如果为空，则锁定当前类的class对象，并再次检查instance是否为空，如果instance对象仍然为空，则为instance对象创建一个实例。

package io.binghe.concurrent.lab01;

/**
 * @author binghe
 * @version 1.0.0
 * @description 测试单例
 */
public class SingleInstance {

    private static SingleInstance instance;

    public static SingleInstance getInstance(){
        if(instance == null){
            synchronized (SingleInstance.class){
                if(instance == null){
                    instance = new SingleInstance();
                }
            }
        }
        return instance;
    }
}

如果编译器或者解释器不会对上面的程序进行优化，整个代码的执行过程如下所示。

在这里插入图片描述

注意：为了让大家更加明确流程图的执行顺序，我在上图中标注了数字，以明确线程A和线程B执行的顺序。

假设此时有线程A和线程B两个线程同时调用getInstance()方法来获取对象实例，两个线程会同时发现instance对象为空，此时会同时对SingleInstance.class加锁，而JVM会保证只有一个线程获取到锁，这里我们假设是线程A获取到锁。则线程B由于未获取到锁而进行等待。接下来，线程A再次判断instance对象为空，从而创建instance对象的实例，最后释放锁。此时，线程B被唤醒，线程B再次尝试获取锁，获取锁成功后，线程B检查此时的instance对象已经不再为空，线程B不再创建instance对象。

上面的一切看起来很完美，但是这一切的前提是编译器或者解释器没有对聊天室软件源码进行优化，也就是说CPU没有对程序进行重排序。而实际上，这一切都只是我们自己觉得是这样的。

在真正高并发环境下运行上面的代码获取instance对象时，创建对象的new操作会因为编译器或者解释器对聊天室软件源码的优化而出现问题。也就是说，问题的根源在于如下一行代码。