墨痕未定，片语已生春。
Redis网络模型（io多路复用） 阻塞IO(Blocking IO) 假设服务端只开启一个线程处理请求，第一个请求到来，开始调用内核read函数，然后就会发生阻塞，第二个请求到来时服务端将无法处理，只能等第一个请求读取完成。这种方式的缺点很明显，每次只能处理一个请求，无法发挥cpu多核优势，性能低下。 为了解决这个问题，我们可以引入多线程，这样就可以同时处理多个请求了，但服务端可能同时有成千上万
HotSpot 垃圾收集器 HotSpot 虚拟机提供了多种垃圾收集器，每种收集器都有各自的特点，虽然我们要对各个收集器进行比较，但并非为了挑选出一个最好的收集器。我们选择的只是对具体应用最合适的收集器。 新生代垃圾收集器 Serial 垃圾收集器（单线程） 只开启一条 GC 线程进行垃圾回收，并且在垃圾收集过程中停止一切用户线程，即 Stop The World。 一般客户端应用所需内存较小，不
Redis的压缩列表ziplist到紧凑列表listpack ziplist 的结构（老版本用的） 大概长这样： 每个 里： - ：前一个 entry 的长度（1 或 5 字节） - ：当前 entry 是字符串还是整数，长度是多少 - ：真正的数据 listpack 的结构（新版本用的） 大概长这样： 每个 里： 注意两点变化： 1. 没有 prevlen 了（不再依赖“记录前一个元素长度”来反
MySqL事务隔离级别 事务的特性： 原子性：事务要么全部提交成功要么全部失败 一致性：事务操作前和操作后具有完整性约束，数据库保持一致性状态 隔离性：事务执行时相互隔离互不影响，可以防止多个事务并发执行由于交叉执行导致的不一致 持久性：事务操作结束后修改是永久性的，即使关机故障也不会消失 MySQL InnoDB 引擎通过什么技术来保证事务的这四个特性的呢？ - 持久性是通过 redo log
SpringMVC执行流程 请求先到 DispatcherServlet（前端控制器），它负责调度 HandlerMapping → HandlerAdapter → Controller → ViewResolver → View。 Spring MVC 采用前端控制器模式，所有请求先进入 DispatcherServlet。DispatcherServlet 通过 HandlerMapping
MVCC多版本并发控制 MVCC 的目标：让读操作尽量不阻塞写操作，写操作也尽量不阻塞读操作。 核心机制： MVCC主要依赖以下机制实现： 数据库行记录中的隐藏字段：最近修改本行数据的事务id、回滚指针指向本行数据的上个版本（其实是指向undo，通过undo计算上一个版本） •undo log：回滚日志，在insert、delete、update时产生，记载了与操作相反的操作，比如delete操作
类加载机制/类加载器 类加载的完整流程（生命周期） 类从加载到卸载经历 5 个阶段，其中加载、验证、准备、初始化、卸载的顺序是固定的，解析阶段可能与初始化交叉进行： 1. 加载（Loading） - 任务：通过类的全限定名（如 ）获取其字节码数据，并生成 对象。 - 来源：字节码可来自本地文件、网络、数据库、动态生成（如 CGLib）等。 - 关键组件：类加载器（ClassLoader）负责此阶段
垃圾收集器（CMS-G1-ZGC） CMS 垃圾收集器 JDK1.5时引入，JDK9被标记弃用，JDK14被移除 CMS（Concurrent Mark Sweep，并发标记清除）收集器是以获取最短回收停顿时间为目标的收集器（追求低停顿），它在垃圾收集时使得用户线程和 GC 线程并发执行，因此在垃圾收集过程中用户也不会感到明显的卡顿。 - 初始标记：Stop The World，仅使用一条初始标记
MySQL锁 全局锁： flush tables with read lock，执行此条命令，整个数据库处于只读状态 unlock tables， 释放全局锁，会话断开时，也会自动释放全局锁 一般用来全库逻辑备份 表级锁：MySQL 里面表级别的锁有这几种： - - 表锁：通过lock tables 语句可以对表加表锁，表锁除了会限制别的线程的读写外，也会限制本线程接下来的读写操作。 - 元数据锁
cookie、session、token cookie 服务端发给客户端，交给客户端保存的数据，每次请求，客户端带上这些数据，服务端就读取这些数据，鉴别身份。 完全由客户端存储，和域名绑定，且不可跨域。 数据大小一般有限制。 容易被伪造，且客户端清除数据就丢失了 session 服务端将客户端的信息保存在服务端，然后将一个sessionId传给客户端，客户端保存起来，下次请求携带sessionId