小菜鸟

MyBatis 拦截器（插件）深度解析：从原理到实战扩展

MyBatis 拦截器（又称插件）是 MyBatis 最强大的扩展机制，允许开发者在不修改 MyBatis 核心源码的前提下，通过动态代理对 SQL 执行流程中的关键节点进行拦截，插入自定义逻辑（如日志记录、性能监控、SQL 改写、参数加密等）。从 “核心定位→接口设计→拦截原理→实战开发” 四个维度，彻底拆解 MyBatis 拦截器的工作机制。

拦截器核心定位与拦截对象

MyBatis 拦截器的核心是 “拦截四大核心对象的方法调用”，这四大对象是 MyBatis 执行 SQL 的关键组件，覆盖 “SQL 执行→参数处理→结果映射” 全流程。

四大可拦截对象与拦截点

MyBatis 仅允许拦截以下四类核心对象的特定方法，其他对象无法通过拦截器扩展：

注意：拦截器只能拦截上述对象的特定方法（需通过 @Signature 精确匹配方法名和参数列表），无法拦截对象的所有方法。

拦截器的核心价值

• 无侵入扩展：无需修改 MyBatis 核心代码，通过配置即可接入自定义逻辑；
• 粒度可控：可精确指定拦截的对象、方法和参数，避免全局影响；
• 责任链模式：支持多个拦截器叠加，形成拦截链，按配置顺序执行。

拦截器核心接口与注解

MyBatis 为拦截器定义了统一的接口规范（Interceptor）和注解（@Intercepts/@Signature），开发者需遵循该规范实现自定义拦截器。

1. Interceptor 接口：拦截器的标准定义

Interceptor 是所有自定义拦截器的顶层接口，定义了三个核心方法，分别对应 “拦截逻辑”“代理生成” 和 “参数初始化”：

Kafka 监控详解：基于 Yammer Metrics 与 JMX 的监控体系

Kafka 内置了完善的监控机制，核心依赖 Yammer Metrics 框架收集和报告集群与客户端的运行指标（metrics），并默认通过 JMX（Java Management Extensions） 暴露这些指标，便于通过工具（如 JConsole、VisualVM）或监控系统（如 Prometheus + Grafana）进行可视化和告警。本文将详细介绍 Kafka 的监控体系、核心指标及常用监控工具。

监控基础：Yammer Metrics 与 JMX

Yammer Metrics 框架

Yammer Metrics 是一个 Java 性能监控库，Kafka 用它来定义和收集各类指标，支持多种指标类型：

• Gauge：瞬时值（如当前连接数）。
• Counter：计数器（如总消息数）。
• Meter：吞吐量（如每秒请求数）。
• Timer：耗时统计（如请求延迟分布）。
• Histogram：分布统计（如消息大小分布）。

这些指标被分类存储在 Kafka 的各个组件中（如 Broker、生产者、消费者），形成层次化的指标体系。

JMX 暴露指标

Kafka 默认通过 JMX 暴露所有指标，无需额外配置。JMX 是 Java 平台的标准监控接口，允许外部工具通过 MBean（Managed Bean）访问指标。

• 启用 JMX 端口：启动 Kafka 时，通过 JMX_PORT 环境变量指定端口（如 9010），否则使用随机端口：

  1 2	# 启动 Broker 并指定 JMX 端口 JMX_PORT=9010 ./kafka-server-start.sh ../config/server.properties

• JMX 指标路径：指标以层次化命名，格式为 kafka.<组件>.<指标名>，例如：

  • kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec（每秒入站消息数）。
  • kafka.consumer:type=ConsumerFetcherManager,name=FetchRateAndTimeMs（消费者拉取速率）。

核心监控指标

Kafka 的监控指标可分为 Broker 指标、生产者指标、消费者指标 和 主题 / 分区指标，以下是关键指标：

1. Broker 核心指标

Tomcat 中的默认 Servlet：DefaultServlet 与 JspServlet

在 Tomcat 的 conf/web.xml 配置文件中，定义了两个核心的默认 Servlet：DefaultServlet 和 JspServlet。它们是 Tomcat 处理请求的基础组件，分别负责静态资源和 JSP 页面的处理。理解这两个 Servlet 的作用和配置，有助于更好地掌握 Tomcat 的请求处理流程。

DefaultServlet：静态资源的默认处理器

DefaultServlet 是 Tomcat 的核心默认 Servlet，其 url-pattern 配置为 /，意味着当客户端请求无法匹配任何其他 Servlet 时，将由它来处理。它的主要职责是处理静态资源（如 HTML、CSS、JS、图片等），并提供基础的目录列表功能。

配置详解

conf/web.xml 中对 DefaultServlet 的默认配置如下：

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

<servlet>
    <servlet-name>default</servlet-name>
    <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
    <init-param>
        <param-name>debug</param-name>
        <param-value>0</param-value> <!-- 调试级别，0 表示关闭调试输出 -->
    </init-param>
    <init-param>
        <param-name>listings</param-name>
        <param-value>false</param-value> <!-- 是否允许目录列表 -->
    </init-param>
    <load-on-startup>1</load-on-startup> <!-- 启动优先级：1（较高） -->
</servlet>

<servlet-mapping>
    <servlet-name>default</servlet-name>
    <url-pattern>/</url-pattern> <!-- 匹配所有未被其他 Servlet 处理的请求 -->
</servlet-mapping>

核心功能

子线程获取 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 是延迟操作的 “管理者”，负责延迟操作的注册、监视、触发和清理，避免单个操作的管理逻辑分散。