小菜鸟

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. 建立数据库连接
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 为例）：

<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 处理请求：

Kafka 副本管理器（ReplicaManager）详解：高可用的核心保障

Kafka 的副本机制是实现高可用和数据可靠性的核心，而副本管理器（ReplicaManager）则是副本机制的 “执行者”—— 负责管理集群中所有副本的生命周期、数据同步、状态维护及故障处理。本文将深入解析副本管理器的核心功能、工作机制及关键流程。

副本管理器的核心角色

副本管理器运行在每个 Broker 上，是连接控制器（Controller）、日志管理器（LogManager）与客户端的中间层，主要职责包括：

1. 副本生命周期管理：创建、删除副本，维护副本的状态（Leader/Follower）。
2. 数据同步协调：协调 Follower 副本从 Leader 副本拉取数据，确保数据一致性。
3. ISR 维护：动态更新 In-Sync Replicas（同步副本集），仅保留与 Leader 保持同步的副本。
4. 处理控制器请求：响应控制器发送的 LeaderAndIsrRequest（Leader 选举与 ISR 更新）、StopReplicaRequest（停止副本）等指令。
5. 故障响应：当副本故障（如 Follower 宕机）时，配合控制器进行状态切换和 Leader 重新选举。

核心概念：副本与 ISR

在解析副本管理器前，需明确两个核心概念：

• 副本（Replica）：分区的物理副本，分为 Leader（处理读写请求）和 Follower（从 Leader 同步数据）。每个分区的副本集合称为 AR（Assigned Replicas）。
• ISR（In-Sync Replicas）：与 Leader 副本保持同步的副本集合（包含 Leader 自身）。若 Follower 因网络延迟、故障等原因长期落后于 Leader，会被移出 ISR；恢复同步后可重新加入。

副本管理器的核心功能与流程

副本的创建与初始化

当创建主题或分区重分配时，控制器会向目标 Broker 发送 LeaderAndIsrRequest，副本管理器负责在本地创建副本：

Tomcat 性能测试与调优实践指南

性能测试是评估和优化 Tomcat 服务能力的关键环节，通过模拟不同负载场景，可定位系统瓶颈并针对性调优。本文将详细介绍性能测试的核心类型、工具及分析方法，帮助提升系统稳定性和响应速度。

性能测试的核心类型

性能测试并非单一场景，而是通过多种测试类型全面评估系统能力。根据测试目标不同，主要分为以下四类：

1. 负载测试（Load Testing）

定义：模拟逐步增长的正常用户访问量，观察系统在不同负载下的响应表现。
目的：

• 确定系统随并发用户数增加的响应时间变化趋势。
• 找到系统的最佳负载点（响应时间合理且稳定的最大并发数）。
• 验证系统的伸缩性（是否能通过增加资源提升处理能力）。

典型场景：
从 10 个并发用户开始，每次增加 50 个用户，持续 10 分钟，记录不同阶段的平均响应时间、错误率。

2. 压力测试（Stress Testing）

定义：施加远超正常水平的负载（如正常访问量的 5-10 倍），直至系统崩溃，观察临界状态。
目的：

• 确定系统的极限承载能力（崩溃前的最大并发数 / 吞吐量）。
• 发现极端负载下才会暴露的隐藏 Bug（如死锁、内存泄漏、连接池耗尽）。
• 验证系统崩溃后的恢复能力（重启后是否正常工作）。

典型场景：
以 1000 并发用户开始，每 5 分钟增加 500 用户，直至出现大量超时或错误，记录临界值及错误类型。

3. 持续运行测试（Endurance Testing）

定义：在中等负载下让系统不间断运行数天甚至数周，模拟长期生产环境。
目的：

• 发现长期运行中的累积问题（如内存泄漏、连接未释放、日志文件过大）。
• 验证系统的稳定性（是否在持续负载下逐渐退化）。
• 评估资源消耗趋势（CPU、内存、磁盘空间的长期变化）。

典型场景：
以 200 并发用户持续访问系统 72 小时，每小时记录一次 JVM 内存使用、线程状态、数据库连接数。

4. 并发测试（Concurrency Testing）

定义：聚焦于多用户同时访问同一资源（如抢购、秒杀场景），测试系统的并发控制能力。
目的：

Java 并发同步工具：从信号量到交换器的全面解析

在多线程编程中，除了 synchronized 和 Lock 等基础同步机制，JUC（java.util.concurrent）包还提供了多种高级同步工具，用于解决复杂的线程协作问题。本文将详细介绍 信号量（Semaphore）、闭锁（CountDownLatch）、屏障（CyclicBarrier）、移相器（Phaser）和交换器（Exchanger） 的原理、用法及适用场景。

信号量（Semaphore）：控制并发访问数量

Semaphore 用于控制同时访问某一资源的线程数量，通过维护一个许可计数器实现。线程需要先获取许可（acquire()），访问完成后释放许可（release()）。

核心原理

• 许可计数器：初始化时指定许可数量（如 new Semaphore(5) 允许 5 个线程同时访问）；
• 获取与释放：acquire() 减少许可数（无许可时阻塞），release() 增加许可数；
• 公平性：支持公平模式（按请求顺序分配许可）和非公平模式（默认，允许插队）。

源码关键方法

// 获取 1 个许可（可中断）  
public void acquire() throws InterruptedException {  
    sync.acquireSharedInterruptibly(1);  
}  

// 释放 1 个许可  
public void release() {  
    sync.releaseShared(1);  
}  

// 尝试获取许可（非阻塞）  
public boolean tryAcquire() {  
    return sync.nonfairTryAcquireShared(1) >= 0;  
}

典型应用：限流