小菜鸟

Spring 事件监听机制：从原理到实战

Spring 事件监听机制是基于观察者模式的一种实现，用于组件间的解耦通信。通过事件发布者（Publisher）、事件（Event）和事件监听器（Listener）三者的配合，实现了 “发布 - 订阅” 模式，让组件无需直接依赖即可完成交互。本文将详细解析 Spring 事件监听的核心原理、内置事件及自定义事件的实现方式。

Spring 事件监听的核心组件

Spring 事件监听机制包含三个核心角色，它们协同工作完成事件的发布与处理：

三者关系如下：

1. 事件发布者通过 publishEvent() 方法发布事件；
2. Spring 容器将事件传递给所有订阅该事件的监听器；
3. 监听器通过 onApplicationEvent() 方法处理事件。

Spring 内置事件

Spring 框架自带了 5 种标准事件，用于监听容器生命周期和 Web 请求等场景，这些事件均继承自 ApplicationEvent：

HashSet 源码深度解析（基于 JDK 8）

HashSet 是 Java 集合框架中最常用的 Set 实现类，基于 HashMap 实现，具有无序性、不可重复性和高效性的特点。本文将从继承关系、核心实现、方法原理及使用场景等方面，全面解析 HashSet 的工作机制。

HashSet 核心特性与继承关系

核心特性

• 无序性：元素存储顺序与插入顺序无关（由哈希值决定存储位置）。
• 不可重复性：不允许存储重复元素（通过 equals() 和 hashCode() 判断重复）。
• 高效性：添加、删除、查找元素的平均时间复杂度为 O(1)。
• 支持 null 元素：允许存储一个 null（因不可重复）。
• 非线程安全：多线程并发修改可能导致数据不一致（需手动同步或使用 ConcurrentHashMap 构建的 Set）。

继承关系

1
2
3

public class HashSet<E>
    extends AbstractSet<E>
    implements Set<E>, Cloneable, java.io.Serializable

• 继承 AbstractSet：复用了 Set 接口的部分默认实现（如 size()、isEmpty() 等）。
• 实现 Set：遵循 Set 接口规范，确保元素不可重复。
• 实现 Cloneable：支持克隆（浅拷贝，底层 HashMap 被复制，但元素对象本身不复制）。
• 实现 Serializable：支持序列化，通过自定义序列化方法优化性能。

核心结构：基于 HashMap 的封装

HashSet 本身没有独立的底层结构，而是通过封装 HashMap 实现功能：

应用层简析：用户与网络的交互接口

应用层是 OSI 七层模型和 TCP/IP 四层模型中最贴近用户的一层，它直接面向用户需求，定义了各类网络应用的通信规则。应用层协议通过调用传输层（TCP 或 UDP）提供的服务，实现不同主机上应用程序之间的信息交换，其核心作用是将用户的操作转化为网络可识别的通信指令。

应用层的核心定位

• 交互对象：仅与下层的传输层（TCP/UDP）通信，无需关心底层的网络层、数据链路层等细节。
• 核心功能：
  • 定义应用程序之间的数据格式（如 HTTP 的请求 / 响应报文结构）。
  • 规定通信的时序和规则（如 FTP 的连接建立与文件传输流程）。
  • 处理用户交互逻辑（如邮件发送、网页浏览的具体实现）。
• 用户视角：我们日常使用的浏览器、邮件客户端、文件传输工具等，其底层都是通过应用层协议实现网络通信的。

常见应用层协议及功能

1. HTTP（超文本传输协议）

• 作用：用于浏览器与 Web 服务器之间的超文本（如 HTML、图片、视频）传输，是万维网（WWW）的基础协议。
• 特点：
  • 基于 TCP 传输（可靠连接），默认端口 80。
  • 采用 “请求 - 响应” 模式：客户端发送请求（如 GET、POST），服务器返回响应（如 200 成功、404 未找到）。
  • 无状态：服务器不保留客户端的历史信息，每次请求独立处理（通过 Cookie、Session 解决状态保持问题）。
• 衍生协议：HTTPS（HTTP+SSL/TLS 加密），默认端口 443，用于敏感信息传输（如支付、登录）。

2. FTP（文件传输协议）

• 作用：实现本地主机与远程服务器之间的文件上传、下载和管理（如上传网站代码、下载资源包）。
• 特点：
  • 基于 TCP 传输，使用两个连接：控制连接（端口 21，用于发送指令）和数据连接（端口 20，用于传输文件）。
  • 支持匿名登录（无需账号密码）和权限控制（通过用户名 / 密码限制操作）。
  • 数据传输模式：文本模式（传输文本文件）和二进制模式（传输图片、压缩包等非文本文件）。

MyBatis MappedStatement 深度解析：Mapper 节点的 “配置容器” 与 SQL 执行的 “元数据核心”

在 MyBatis 中，MappedStatement 是 Mapper 配置（XML / 注解）与 SQL 执行之间的关键桥梁—— 它将 Mapper 中单个 SQL 节点（如 <select>、<insert>）的所有配置（SQL 语句、参数映射、结果映射、缓存策略等）封装为一个可执行的 “元数据对象”，是 MyBatis 解析配置、生成 SQL、执行查询的核心依据。从 “核心定位→属性解析→生命周期→实战关联” 四个维度，彻底拆解 MappedStatement 的作用与价值。

MappedStatement 核心定位：SQL 节点的 “配置容器”

MyBatis 启动时，会扫描所有 Mapper 接口和 XML 文件，将每个 SQL 节点（如 <select id="selectUserById">） 解析为一个 MappedStatement 对象，存储在 Configuration 的 mappedStatements 集合中（key 为 namespace + id，如 com.example.UserMapper.selectUserById）。

MappedStatement 的核心作用是：

1. 配置聚合：集中管理单个 SQL 节点的所有配置（SQL 语句、参数、结果、缓存等），避免配置分散；
2. 元数据提供：为 Executor（执行器）、StatementHandler（SQL 处理器）等组件提供执行所需的全部元数据；
3. 一致性保障：确保 SQL 执行过程中，参数绑定、结果映射、缓存策略等配置的一致性。

MappedStatement 核心属性解析

MappedStatement 的属性与 Mapper 节点的配置一一对应，每个属性都直接影响 SQL 的执行逻辑。按 “核心功能分组” 解析关键属性：

MyBatis 详细执行过程：从源码视角拆解核心流程

MyBatis 的执行过程本质是 “配置解析→核心对象创建→SQL 执行→结果封装” 的闭环，涉及 Configuration、SqlSession、Executor、StatementHandler 等核心组件的协同工作。本文结合 MyBatis 3.5.x 源码，将执行过程拆解为 7 个关键步骤，每个步骤深入核心源码与组件职责，帮你彻底理解 MyBatis 的运行机制。

核心执行流程总览

MyBatis 从初始化到执行 SQL 的完整流程可概括为：
配置加载 → 创建 SqlSessionFactory → 创建 SqlSession → 获取 Mapper 代理 → 执行 SQL（Executor 调度） → 数据库交互（StatementHandler） → 结果封装（ResultSetHandler）

先通过一张简化的组件协作图理解核心关系：

详细执行步骤（结合源码）

步骤 1：加载配置文件，初始化 Configuration 对象

MyBatis 启动时，首先解析 全局配置文件（mybatis-config.xml） 和 所有 Mapper 映射文件（XxxMapper.xml），将配置信息统一封装到 Configuration 对象中（Configuration 是 MyBatis 的 “配置中心”，全局唯一）。

核心源码：SqlSessionFactoryBuilder.build()

SqlSessionFactoryBuilder 是创建 SqlSessionFactory 的入口，其核心逻辑是解析配置文件生成 Configuration：