小菜鸟

子线程获取 Request 对象：ThreadLocal 继承与 Spring 解决方案

在 Web 开发中，我们常通过 RequestContextHolder 获取当前请求（HttpServletRequest），但在子线程中直接调用时往往返回 null。这一问题的核心是 ThreadLocal 的线程隔离性，而 Spring 提供了基于可继承 ThreadLocal 的解决方案。本文将详细解析原理及实现方式。

问题根源：ThreadLocal 的线程隔离性

RequestContextHolder 是 Spring 提供的用于存储当前请求上下文的工具类，其内部通过 ThreadLocal 实现线程隔离：

1
2
3
4
5
6

// RequestContextHolder 核心代码
private static final ThreadLocal<RequestAttributes> requestAttributesHolder =
    new NamedThreadLocal<>("Request attributes"); // 普通 ThreadLocal

private static final ThreadLocal<RequestAttributes> inheritableRequestAttributesHolder =
    new NamedInheritableThreadLocal<>("Request context"); // 可继承的 ThreadLocal

ThreadLocal 的核心特性是 “线程私有”：每个线程的 ThreadLocal 数据存储在自身的 threadLocals 变量中，其他线程（包括子线程）无法直接访问。因此：

• 主线程将请求信息存入 ThreadLocal 后，子线程默认无法获取；
• 直接在子线程中调用 RequestContextHolder.getRequestAttributes() 会返回 null。

解决方案：使用可继承的 ThreadLocal

Spring 提供了通过 可继承 ThreadLocal 让子线程共享主线程请求信息的机制，核心是 NamedInheritableThreadLocal（继承自 InheritableThreadLocal）。

Kafka 延迟操作组件详解：异步协作的核心机制

Kafka 中存在许多需要 “等待特定条件满足后再执行” 的场景（如等待副本同步完成、消费组所有成员加入），这些场景通过延迟操作组件实现。延迟操作组件以 DelayedOperation 为核心，配合管理类 DelayedOperationPurgatory 及具体实现类（如 DelayedProduce、DelayedFetch），实现了高效的异步协作，既保证了数据可靠性，又优化了系统性能。本文将深入解析这些组件的设计与工作机制。

核心抽象：DelayedOperation

DelayedOperation 是所有延迟操作的基类，定义了延迟操作的通用框架：需等待特定条件满足或超时后执行，本质是一个带超时机制的 TimerTask。

核心特性

1. 状态管理：通过 completed 原子变量标记操作是否完成，确保 onComplete 仅执行一次。
2. 条件触发：子类需实现 tryComplete() 方法，定义 “操作可执行” 的条件（如 “所有副本同步完成”）。
3. 超时处理：若超时仍未满足条件，执行 onExpiration() 方法（如返回超时错误）。
4. 强制完成：forceComplete() 方法可主动触发操作完成（如条件提前满足时）。

关键方法

延迟操作管理器：DelayedOperationPurgatory

DelayedOperationPurgatory 是延迟操作的 “管理者”，负责延迟操作的注册、监视、触发和清理，避免单个操作的管理逻辑分散。

Kafka 协调器详解：消费组与任务的 “调度中心”

Kafka 中的协调器是实现分布式协作的核心组件，主要包括消费者协调器（ConsumerCoordinator）、组协调器（GroupCoordinator） 和任务管理协调器（WorkerCoordinator）。它们分别负责客户端消费组协作、服务端消费组管理和分布式任务调度，共同保障 Kafka 集群的高效协同。本文将逐一解析这三类协调器的功能、机制及交互流程。

消费者协调器（ConsumerCoordinator）：客户端的 “联络员”

消费者协调器（ConsumerCoordinator） 是 Kafka 消费者客户端（KafkaConsumer）的内置组件，每个消费者实例都会初始化一个，负责与服务端的组协调器（GroupCoordinator） 通信，处理消费组的加入、离开、重平衡及偏移量提交等操作。

核心功能

1. 消费组交互：
   向组协调器发送 JoinGroup（加入组）、Heartbeat（心跳）、LeaveGroup（离开组）等请求，维护消费者在组内的身份。
2. 偏移量管理：
   负责向组协调器提交消费偏移量（同步 commitSync 或异步 commitAsync），确保消费进度被持久化。
3. 重平衡协调：
   当消费组成员变化或主题分区变更时，配合组协调器完成重平衡（Rebalance），接收新的分区分配方案并执行。

工作流程

以 “消费者加入消费组” 为例，ConsumerCoordinator 的交互流程如下：

1. 发现组协调器：
   消费者通过哈希消费组 ID（group.id）计算对应的 __consumer_offsets 分区（存储偏移量的内部主题），该分区的 Leader 所在 Broker 即为该消费组的组协调器。
2. 发送 JoinGroup 请求：
   消费者向组协调器发送 JoinGroup 请求，声明自己订阅的主题和支持的分区分配策略（如 RangeAssignor）。
3. 接收分区分配：
   组协调器完成成员注册和 Leader 选举后，通过 SyncGroup 请求向消费者返回分配的分区（如消费者 A 负责分区 0、1，消费者 B 负责分区 2、3）。
4. 维持组成员身份：
   定期发送 Heartbeat 请求（间隔由 heartbeat.interval.ms 控制），证明自身存活；若超过 session.timeout.ms 未发送心跳，会被踢出消费组。

组协调器（GroupCoordinator）：服务端的 “管理者”

组协调器（GroupCoordinator） 是 Kafka 服务端（Broker）的组件，每个 Broker 启动时都会实例化，负责管理多个消费组的元数据、偏移量存储和重平衡协调。它是消费组的 “中央控制器”。

MyBatis 主键生成机制全解析：从原生 JDBC 到 KeyGenerator 适配

在数据库插入操作中，主键回填（获取插入后自动生成的主键）是高频需求（如 MySQL 自增 ID、Oracle 序列等）。MyBatis 基于原生 JDBC 主键回填逻辑，封装了 KeyGenerator 接口及其实现类，统一适配不同数据库的主键生成方式。本文从 “原生 JDBC 原理→MyBatis KeyGenerator 接口→三大实现类源码→实战配置” 逐步展开，彻底讲清 MyBatis 主键生成的底层逻辑与使用方法。

前置知识：原生 JDBC 主键回填

MyBatis 的主键生成机制源于 JDBC 原生支持，理解这一基础能更清晰地把握 MyBatis 的封装逻辑。

核心原理

JDBC 通过 PreparedStatement 的 RETURN_GENERATED_KEYS 标识，告知数据库 “需要返回插入生成的主键”，插入后通过 getGeneratedKeys() 获取主键结果集。

原生代码示例（MySQL）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// 1. 建立数据库连接
Connection connection = DriverManager.getConnection(url, username, password);

// 2. 创建 PreparedStatement，指定 RETURN_GENERATED_KEYS 标识
String sql = "INSERT INTO user (user_name, age) VALUES (?, ?)";
PreparedStatement ps = connection.prepareStatement(sql, Statement.RETURN_GENERATED_KEYS);

// 3. 绑定参数并执行插入
ps.setString(1, "张三");
ps.setInt(2, 20);
ps.executeUpdate(); // 执行插入，返回受影响行数

// 4. 获取生成的主键（结果集仅含主键列）
ResultSet rs = ps.getGeneratedKeys();
if (rs.next()) {
    long userId = rs.getLong(1); // 主键列索引从 1 开始
    System.out.println("插入的用户ID：" + userId); // 输出如 "插入的用户ID：1001"
}

// 5. 关闭资源（省略）

原生方案的局限

• 数据库兼容性差：MySQL 支持自增 +RETURN_GENERATED_KEYS，但 Oracle 需通过序列（seq.nextval）生成主键，无法直接用此方案；
• 代码冗余：每次插入都需重复 “指定标识→获取结果集” 逻辑；
• 批量插入复杂：批量插入时需手动分配主键到每个对象。

Tomcat 嵌入式开发详解

从 Tomcat 7 开始，官方提供了嵌入式支持，允许通过 Java 代码直接创建和启动 Tomcat 服务器，无需手动配置 server.xml 等文件。这种方式广泛应用于开发工具（如 IDEA 内置服务器）、集成测试及轻量级应用部署。本文将详细介绍 Tomcat 嵌入式开发的核心用法和实践案例。

嵌入式 Tomcat 核心组件

嵌入式 Tomcat 的核心类是 org.apache.catalina.startup.Tomcat，它封装了 Tomcat 服务器的创建、配置和启动流程。主要涉及以下组件：

• Tomcat 类：服务器入口，负责初始化和启动整个 Tomcat 实例。
• Context 类：代表一个 Web 应用上下文，对应传统的 <Context> 配置。
• Host 类：虚拟主机，用于管理多个 Context。
• Connector 类：连接器，配置端口、协议等网络参数。

入门示例：快速启动嵌入式 Tomcat

依赖配置

使用 Maven 引入嵌入式 Tomcat 依赖（以 Tomcat 9 为例）：

1
2
3
4
5
6
7
8
9
10

<dependency>
    <groupId>org.apache.tomcat.embed</groupId>
    <artifactId>tomcat-embed-core</artifactId>
    <version>9.0.80</version>
</dependency>
<dependency>
    <groupId>org.apache.tomcat.embed</groupId>
    <artifactId>tomcat-embed-jasper</artifactId> <!-- 支持 JSP 需添加 -->
    <version>9.0.80</version>
</dependency>

映射简单 Servlet

通过代码创建并启动 Tomcat，直接映射一个 Servlet 处理请求：