从IO操作与多线程的思考到Redis-6.0

IO操作->线程阻塞->释放CPU资源->多线程技术提升CPU利用率

在没有涉及磁盘操作和网络请求的程序中，通常不会出现线程等待状态。线程等待状态通常是由于线程需要等待某些事件的发生，比如I/O操作完成、网络请求返回等。如果程序只是进行计算或者简单的逻辑处理，并且没有明显的阻塞点，那么线程通常会一直运行而不会被挂起等待。

然而，即使是在纯计算的程序中，也可能出现线程等待状态。例如，当一个线程尝试获取一个已经被其他线程获取的锁时，它会进入等待状态，直到锁可用为止。另外，有些程序可能会使用线程间的通信机制（比如 wait/notify 或者 CountDownLatch），这些机制也可能导致线程进入等待状态。

总的来说，在没有涉及磁盘和网络操作的程序中，线程等待状态的出现取决于程序本身的设计和实现，以及是否涉及到需要线程等待的场景。

从多线程到Redis

综上，如果在一台没用多线程技术的单核CPU上执行一个程序，程序没有IO操作，那么使用多线程进行程序处理其实收益就不大了。此时使用多线程技术，还需考虑资源并发安全、线程调度切换开销，会比使用单线程处理程序更慢。比如，两个逻辑每个都需要cpu执行1000ms，如果使用2个线程并行处理，那么两个逻辑都执行完毕的总时长可能大于2000ms。

从上述现象上看，也能理解为何Redis6.0之前主流逻辑都采用单线程，也明白了为何6.0以后，在网络数据处理上使用了多线程模型。

6.0 关于线程数的设置，官方的建议是如果为 4 核的 CPU，建议线程数设置为 2 或 3，如果为 8 核 CPU 建议线程数设置为 6，线程数一定要小于机器核数，线程数并不是越大越好。

虽然 Redis 的主要工作（网络 I/O 和执行命令）一直是单线程模型，但是在 Redis 6.0 版本之后，也采用了多个 I/O 线程来处理网络请求，这是因为随着网络硬件的性能提升，Redis 的性能瓶颈有时会出现在网络 I/O 的处理上（网络通道性能提升了，但是碍于之前的单线程串行读写太少）。所以为了提高网络请求处理的并行度，Redis 6.0 对于网络请求采用多线程来处理。但是对于命令执行，Redis 仍然使用单线程来处理。

Redis-server ：Redis的主线程，主要负责执行命令；
bio_close_file、bio_aof_fsync、bio_lazy_free：三个后台线程，分别异步处理关闭文件任务、AOF刷盘任务、释放内存任务；
io_thd_1、io_thd_2、io_thd_3：三个 I/O 线程，io-threads 默认是 4 ，所以会启动 3（4-1）个 I/O 多线程，用来分担 Redis 网络 I/O 的压力。