在互联网高并发后端架构中，Redis 是当之无愧的，覆盖缓存加速、分布式锁、实时计算、消息队列、会话共享等几乎所有关键场景。很多开发者虽日常使用，却仅停留在基础 API 调用，对底层数据结构、线程模型、持久化机制、高可用架构理解不足，线上出现性能瓶颈、数据丢失、集群故障时难以快速定位。本文以为框架，全面深入拆解 Redis 核心知识，从本质定位到底层原理，再到分布式架构与实战问题，帮你真正建立体系

可见性：当一个线程修改了共享变量，其他线程能立即、可靠地看到修改后的值。无同步 → 无可见性保证。重排序：编译器、JIT、CPU 为了优化性能，在不改变单线程执行结果的前提下，改变指令实际执行顺序。代码写的：plaintextA;B;C;实际执行可能：plaintextA;C;B;原子性：一个操作是不可分割、不可中断的，要么全部执行成功，要么完全不执行。操作开始 → 必须完整结束中间不能被其他线程

text│wait() vs sleep() 全景对比││所属类:ObjectThread││锁行为:释放锁不释放锁││调用条件:synchronized内任意位置│。

阻塞队列本质上是一个有界缓冲区，可以用生产者-消费者模型建模：text生产者速率（λ）→ [缓冲区（容量C）] → 消费者速率（μ）稳态条件：λ < μ（否则队列会无限增长）关键公式（M/M/1队列模型）：text平均队列长度 = ρ / (1 - ρ)，其中 ρ = λ/μ平均等待时间 = ρ / (μ - λ)实际意义当λ接近μ时，队列长度和等待时间会指数级增长这就是为什么需要有界队列——防止

textJVM面试├── 内存结构（必问）│├── 运行时数据区（私有 vs 共享）│├── 堆分代模型（新生代/老年代/比例）│└── 元空间 vs 永久代├── 垃圾回收（核心）│├── 判断垃圾：可达性分析（GC Roots）│├── 回收算法：复制 / 标记-清除 / 标记-整理│├── 收集器：CMS vs G1 vs ZGC│└── 调优参数：MaxGCPauseMillis、IHOP

原文总结得很好。G1的优点：它的设计目标是“软实时”，即在可控的停顿时间（默认200ms）内，完成尽可能多的垃圾回收。适合堆内存大（4GB+）、要求低延迟的应用。G1的弱点维护成本高：RSet、卡表等元数据占用较多堆外内存。吞吐量稍低：相比于Parallel Scavenge（吞吐量优先），G1由于写屏障和并发标记的开销，整体吞吐量（业务时间/总时间）会低约5%~10%。小堆表现不佳：在堆内存较小

plaintext新对象↓Eden 区分配↓Eden 满 → Minor GC↓存活对象 → S0 / S1（年龄+1）↓S0 ↔ S1 轮换（每次GC年龄+1）↓年龄达标 / 大对象 / Survivor 空间不足↓晋升老年代↓老年代满 → Full GC↓对象被回收 / 永久存活JVM 分代工作流程 =对象出生 → 年轻代轮换 → 晋升老年代 → 最终回收整个流程围绕展开，是理解 GC、OOM

定义：Java 虚拟机（JVM）中用于加载 .class 字节码文件到内存中，并生成对应的对象的组件。核心作用读取本地 / 网络 / 数据库等任意来源的字节码文件确保类的唯一性、安全性实现类的热部署、模块化加载等高级功能当一个类加载器收到类加载请求时：自己不先加载，把请求向上委托给父类加载器所有加载器依次向上委托，直到启动类加载器若父加载器无法加载（找不到类），才由子加载器尝试加载向上委托，向下加

核心基础：Object 是所有 Java 类的父类，11 个方法定义了对象的通用行为；重写核心：toString ()、equals ()、hashCode () 是必重写方法，需严格遵守规则；线程相关：wait ()/notify ()/notifyAll () 是线程同步的核心方法，必须在 synchronized 中调用；避坑关键：equals/hashCode 强绑定、wait 用 whi

IO 模型的核心区分点是「数据准备阶段是否阻塞」和「是否需要用户线程等待 IO 完成」，同步异步关注全程，阻塞非阻塞关注数据准备阶段。BIO 是基础但低效，NIO 多路复用解决了 C10K 问题（主流方案），AIO 理论最优但落地成本高。实际开发无需手写原生 IO 模型，优先选择 Netty 等成熟框架，底层依赖 NIO 多路复用即可满足绝大多数高并发场景。