redis 6.0+的多线程仅用于网络io（socket读写和协议解析），命令执行始终由单线程完成，确保原子性、无锁竞争和lua脚本一致性；性能优势源于epoll事件驱动、精简数据结构及零冗余设计。
Redis主线程不处理网络IO，6.0+才启用多线程读写
很多人误以为“Redis 6.0 多线程 = 命令执行变多线程”，其实不是。Redis 的 command execution（命令解析、键查找、数据结构操作、返回组装）**始终由单个主线程完成**。6.0 引入的多线程只负责：socket read、socket write 和协议解析（如 RESP 解包），做完就扔给主线程处理。
这意味着：GET、SET、HGETALL 等所有命令的逻辑仍是串行执行；并发安全无需加锁；Lua 脚本原子性依然成立。如果你在压测中发现 latency spikes，大概率不是线程模型问题，而是某条慢命令阻塞了主线程。
- 配置开关在
redis.conf中：io-threads 4（默认 1，即关闭多线程 IO） - 必须同时开启：
io-threads-do-reads yes，否则只用于 write - 线程数建议 ≤ CPU 核心数，且为偶数（epoll 分发更均衡）
- 注意：AOF fsync、RDB fork、key 过期扫描等仍由后台线程或子进程处理，与主线程解耦
为什么单线程反而避免了性能内耗
不是“单线程天生快”，而是 Redis 把“上下文切换”和“锁竞争”这两块高成本开销直接砍掉了。比如 Java 应用里 50 个线程争抢一个 ConcurrentHashMap 的 segment 锁，大量线程在 park/unpark 上空转——而 Redis 主线程永远只有一个，没有 synchronized、没有 ReentrantLock、没有 CAS 自旋，自然没这些损耗。
但代价也很明确：任何阻塞操作都会拖垮整个实例。所以你绝不能在 Redis 里执行：KEYS *、长时间运行的 Lua 脚本、或自定义阻塞命令（除非用 MODULE 显式注册异步回调）。
立即学习“Java免费学习笔记（深入）”；
