Redis6.0到底为何引入多线程？(2)-木庄网络博客

我们通过一个例子，看一下多线程场景下发生的诡异现象。看下面的代码：

class MemoryReordering {
  int num = 0;
  boolean flag = false;
   
  public void set() {
    num = 1;     //语句1
    flag = true; //语句2
  }
   
  public int cal() {
    if( flag == true) {    //语句3
      return num + num; //语句4
    }
    
    return -1；
  }
   
}

flag为true时，cal() 方法返回值是多少？很多人会说：这还用问吗！肯定返回2

结果可能会让你大吃一惊！上面的这段代码，由于语句1和语句2没有数据依赖性，可能会发生指令重排序，有可能编译器会把flag=true放到num=1的前面。此时set和cal方法分别在不同线程中执行，没有先后关系。cal方法，只要flag为true，就会进入if的代码块执行相加的操作。可能的顺序是：

语句1先于语句2执行，这时的执行顺序可能是：语句1->语句2->语句3->语句4。执行语句4前，num = 1，所以cal的返回值是2
语句2先于语句1执行，这时的执行顺序可能是：语句2->语句3->语句4->语句1。执行语句4前，num = 0，所以cal的返回值是0

我们可以看到，在多线程环境下如果发生了指令重排序，会对结果造成严重影响。

当然可以在第三行处，给flag加上关键字volatile来避免指令重排。即在flag处加上了内存栅栏，来阻隔flag（栅栏）前后的代码的重排序。当然多线程还会带来可见性问题，死锁问题以及共享资源安全等问题。

1	`boolean volatile flag = false;`

Redis6.0为何引入多线程？

Redis6.0引入的多线程部分，实际上只是用来处理网络数据的读写和协议解析，执行命令仍然是单一工作线程。

从上图我们可以看到Redis在处理网络数据时，调用epoll的过程是阻塞的，也就是说这个过程会阻塞线程，如果并发量很高，达到几万的QPS，此处可能会成为瓶颈。一般我们遇到此类网络IO瓶颈的问题，可以增加线程数来解决。开启多线程除了可以减少由于网络I/O等待造成的影响，还可以充分利用CPU的多核优势。Redis6.0也不例外，在此处增加了多线程来处理网络数据，以此来提高Redis的吞吐量。当然相关的命令处理还是单线程运行，不存在多线程下并发访问带来的种种问题。

性能对比

压测配置:

1 2	`Redis Server: 阿里云 Ubuntu 18.04，8 CPU 2.5 GHZ, 8G 内存，主机型号 ecs.ic5.2xlarge` `Redis Benchmark Client: 阿里云 Ubuntu 18.04，8 2.5 GHZ CPU, 8G 内存，主机型号 ecs.ic5.2xlarge`

多线程版本Redis 6.0，单线程版本是 Redis 5.0.5。多线程版本需要新增以下配置: