NIO vs BIO vs AIO 对比表格
| 特性 | BIO（同步阻塞） | NIO（同步非阻塞） | AIO（异步非阻塞） |
|---|---|---|---|
| 模型 | 一个连接一个线程（阻塞） | 多路复用（单线程处理多连接） | 回调/事件驱动（无需轮询） |
| 吞吐量 | 低（线程切换开销大） | 高（单线程处理多请求） | 高（异步回调无阻塞） |
| 编程复杂度 | 简单（流式读写） | 较复杂（需管理Buffer/Selector） | 复杂（回调嵌套） |
| 适用场景 | 低并发、短连接（如传统HTTP） | 高并发、长连接（如WebSocket） | 超高并发（如文件IO、大规模连接） |
| JDK支持 | Java 1.0+ | Java 1.4+ | Java 7+（NIO.2） |
| 典型应用 | Tomcat BIO模式 | Netty、Kafka | 文件异步读写（如AsynchronousFileChannel） |
-
BIO：简单场景（如内部管理后台）。
-
NIO：主流高并发（如IM、网关）。
-
AIO：文件操作或特殊需求（如Windows的IOCP）。
InnoDB 核心知识点整理（表格版）
1. 存储结构与索引
| 知识点 | 说明 |
|---|---|
| 存储引擎 | MySQL 默认事务型存储引擎，支持ACID、行锁、MVCC。 |
| 表空间 | 数据存储在.ibd文件中（独立表空间）或共享表空间（ibdata1）。 |
| B+树索引 | 主键索引（聚簇索引）直接存储数据，二级索引存储主键值（回表查询）。 |
| 页（Page） | 默认16KB，是InnoDB最小I/O单元，包含行数据、索引、Undo日志等。 |
| 行格式 | COMPACT、DYNAMIC（默认，可变长列溢出页存储）、COMPRESSED（压缩）。 |
2. 事务与锁
| 知识点 | 说明 |
|---|---|
| ACID特性 | 原子性（Undo Log）、一致性（约束+Undo）、隔离性（锁+MVCC）、持久性（Redo Log）。 |
| 隔离级别 | READ UNCOMMITTED → READ COMMITTED → REPEATABLE READ（默认）→ SERIALIZABLE。 |
| MVCC机制 | 通过隐藏字段（DB_TRX_ID、DB_ROLL_PTR）和ReadView实现无锁读。 |
| 锁类型 | 行锁（共享锁S、排他锁X）、意向锁（IS、IX）、间隙锁（Gap Lock，解决幻读）。 |
| 死锁处理 | 检测并回滚代价低的事务（innodb_deadlock_detect=ON）。 |
3. 日志与恢复
| 知识点 | 说明 |
|---|---|
| Redo Log | 物理日志，记录页的修改，用于崩溃恢复（WAL机制，顺序写）。 |
| Undo Log | 逻辑日志，记录事务前的数据镜像，用于回滚和MVCC。 |
| Binlog | 逻辑日志（Server层），主从复制和数据恢复（STATEMENT/ROW/MIXED格式）。 |
| 两阶段提交 | Redo Log（Prepare）→ Binlog → Redo Log（Commit），保证数据一致性。 |
4. 性能优化
| 知识点 | 说明 |
|---|---|
| 缓冲池（Buffer Pool） | 缓存热数据页，减少磁盘I/O（innodb_buffer_pool_size建议设为内存70%~80%）。 |
| Change Buffer | 缓存非唯一索引的变更（Insert/Update/Delete），减少随机I/O。 |
| 自适应哈希索引 | 自动为频繁访问的索引页构建哈希索引（innodb_adaptive_hash_index）。 |
| IO优化 | 异步IO（innodb_use_native_aio=ON）、多线程刷脏（innodb_io_capacity）。 |
5. 参数配置
| 参数 | 作用 |
|---|---|
innodb_file_per_table=ON |
启用独立表空间，便于管理。 |
innodb_flush_log_at_trx_commit=1 |
每次事务提交刷Redo Log到磁盘（保证持久性，性能较低）。 |
innodb_lock_wait_timeout=50 |
行锁等待超时时间（秒）。 |
innodb_read_io_threads=4 |
读线程数（根据CPU核心数调整）。 |
6. 高频面试题
-
为什么用B+树不用B树？
- B+树非叶子节点不存数据，扇出更高，更适合磁盘I/O；叶子节点链表便于范围查询。
-
如何解决幻读？
- 默认隔离级别（RR）下，通过间隙锁（Gap Lock）+ MVCC。
-
Redo Log和Binlog区别？
- Redo Log是InnoDB层物理日志，崩溃恢复用；Binlog是Server层逻辑日志，主从复制用。
拦截器（Interceptor）与过滤器（Filter）对比表格
| 对比项 | 拦截器（Interceptor） | 过滤器（Filter） |
|---|---|---|
| 所属框架 | 通常由框架提供（如Spring MVC的HandlerInterceptor） |
Java Web标准组件（Servlet规范，如javax.servlet.Filter） |
| 作用位置 | 在控制器方法前后执行（Controller层前后） | 在Servlet前后执行（请求到达Servlet前/响应返回前） |
| 依赖关系 | 依赖框架（如Spring容器） | 不依赖框架，基于Servlet API |
| 拦截范围 | 仅拦截Controller的请求方法 | 拦截所有请求（包括静态资源） |
| 实现方式 | 实现HandlerInterceptor接口，重写preHandle、postHandle等 |
实现Filter接口，重写doFilter方法 |
| 执行顺序 | 由框架的拦截器链决定 | 由web.xml或注解的@Order决定 |
| 典型应用 | 权限校验、日志记录、参数预处理 | 字符编码设置、跨域处理、XSS过滤 |
| 是否可终止请求 | 可以（preHandle返回false时终止） |
可以（不调用chain.doFilter()时终止） |
| 获取上下文信息 | 能获取Spring上下文（如@Autowired依赖注入） |
只能获取Servlet API（如ServletRequest、ServletResponse） |
通俗解释
-
过滤器（Filter）：
-
像"大门保安"，所有请求必须经过它（包括静态资源）。
-
功能基础（如统一设置编码、过滤非法字符）。
-
-
拦截器（Interceptor）：
-
像"部门秘书"，只处理Controller的请求。
-
功能更灵活（如校验权限、记录业务日志）。
-
如何选择？
-
用过滤器：处理与业务无关的通用逻辑（如全局编码、跨域）。
-
用拦截器：处理与业务相关的逻辑（如登录验证、参数校验）。
常见组合：
-
过滤器设置请求编码 → 拦截器校验权限 → Controller处理业务。
-
过滤器拦截非法IP → 拦截器记录访问日志 → 返回响应。
volatile 关键字详解
volatile 是 Java 提供的一种轻量级同步机制，用于确保变量的可见性 和有序性 ，但不保证原子性。
1. 核心特性
| 特性 | 说明 |
|---|---|
| 可见性 | 确保多线程对 volatile 变量的修改能立即被其他线程看到，避免读取旧值。 |
| 有序性 | 禁止指令重排序（通过插入内存屏障），保证代码执行顺序符合预期。 |
| 不保证原子性 | volatile 不能替代 synchronized，复合操作（如 i++）仍需加锁或使用原子类。 |
2. 底层原理（JMM + 内存屏障）
（1）Java 内存模型（JMM）
-
普通变量：线程修改后先写入本地缓存（工作内存），再刷回主内存，其他线程可能读取旧值。
-
volatile变量：修改后直接刷回主内存，并强制其他线程重新从主内存读取最新值。
（2）内存屏障（Memory Barrier）
volatile 通过插入以下屏障保证有序性：
| 屏障类型 | 作用 |
|---|---|
| LoadLoad | 禁止读操作重排序到屏障之前。 |
| StoreStore | 禁止写操作重排序到屏障之前。 |
| LoadStore | 禁止读操作重排序到之后的写操作之前。 |
| StoreLoad | 禁止写操作重排序到之后的读操作之前（全能屏障）。 |
3. volatile vs synchronized
| 对比项 | volatile |
synchronized |
|---|---|---|
| 作用范围 | 仅修饰变量 | 修饰方法或代码块 |
| 原子性 | 不保证（适合单一变量的读写） | 保证（适合复合操作） |
| 阻塞 | 非阻塞（轻量级） | 阻塞（重量级） |
| 适用场景 | 状态标志、双重检查锁 | 多步骤操作的线程安全 |