最近被问到一个问题，InnoDB 表，只修改一个字段的名字，定义不修改，是否有快速方案。
这个需求的意义来源于，在表设计初期可以预留一些字段，但在预留字段投入使用时，最好能够赋予一个有意义的名字以方便使用。
复现
以下实验基于 5.1.48 版本。
创建一个简单表

| CREATE TABLE t (
c1 int(11) DEFAULT NULL,
c2 int(11) DEFAULT NULL

插入 10w 条数据。将字段 c2 改名为 c3.

| mysql> alter table t change c2 c3 int(11) default null;
Query OK, 100000 rows affected (4.29 sec)

可以看到，虽然只是简单修改了字段名，在实验机器上耗时达到 4.2s，显然重做了所有数据。由于这个表没有索引，数据量也比较小，如果对于更大数据的表，则需要更长的操作时间。
分析
我们知道，在
Innodb_file_per_table 参数下，每个 InnoDB 表有两个文件 t.frm 和 t.ibd. 实际上，表字段信息只保存于 t.frm。这个文件保存了表的定义信息，只有 8k。 仅修改字段名，实际上不需要重作数据，如果能够只对 t.frm 做修改，则可以加快上面这个 alter 语句的执行速度。
源码相关
可以想象 MySQL 框架中应该是调用了 InnoDB 引擎的某个函数，用于判断是否需要重做数据。
我们追踪一下 alter table 语句的执行流程，在 mysql_alter_table（sql_table.cc）函数中，我们看到这个局部变量 need_copy_table，它有三个可能的取值。
ALTER_TABLE_METADATA_ONLY= 0,
ALTER_TABLE_DATA_CHANGED= 1,
ALTER_TABLE_INDEX_CHANGED= 2
显然这个取值的判断结果，决定了后面的执行流程。
mysql_alter_table 中调用了 compare_tables 用于判断 alter 前后的表做了多大的改动，后者在这个语句中修改了 need_copy_table 的值。

| /_ Check if changes are compatible with current handler without a copy _/
if (table->file->check_if_incompatible_data(create_info, changes))
{
*need_copy_table= ALTER_TABLE_DATA_CHANGED;
DBUG_RETURN(0);

这个 check_if_incompatitble_table 的函数实现在 handler/ha_innodb.cc 中。这个函数的返回值可能是 COMPATIBLE_DATA_NO 表示表改动前后不兼容（需要重做数据）或 COMPATIBLE_DATA_YES 兼容（不需要重做）。
该函数有如下片段

| if (check_column_being_renamed(table, NULL)) {
return COMPATIBLE_DATA_NO;

其实现逻辑是，如果有任何一个字段名被修改，则返回 COMPATIBLE_DATA_NO。
简单修改
有了上述分析，要做到快速修改表字段名，只需要把调用 check_column_being_renamed 的这三行注释掉即可。重新编译发布后，执行结果如下。

| mysql> alter table t change c2 c3 int(11) default null;
Query OK, 0 rows affected (0.01 sec)

可以看到，这回执行基本不需要时间. 对比修改前后的 t.ibd 的 MD5，没有修改，而 t.frm 中只是将 c2 的字段名改为 c3，其他不变。
问题！！
这里的问题是，这个修改，是否会有副作用？虽然我们知道修改字段名应该是对数据时没有影响的，但 MySQL 就是这么实现了。
更深入的调查带来了“坏消息“。 在 MySQL 5.1.45 版本中，就没有这个字段名的判断，也就是说在 5.1.45 中仅修改字段名是只修改 frm 文件的。
在新版本中特别加入的判断，是否有什么原因？这是撰写本文的意图。若有与此相关的 bug 或者文章说明，请回复或站内私信我。
延伸
实际上，关于这个问题，还可以继续深入，这里抛砖引玉。

1. 如果上述修改有副作用，副作用是什么，是否可以通过简单修改 ibd 文件，仍达到快速修改的目的?

前言

MAT 作为开发者分析堆栈快照信息的常用工具，本文介绍了在 MBP M1 中安装指南。

下载

首先去https://www.eclipse.org/mat/downloads.php下载 MAT 的安装包

异常

下载完打开会出现错误提示，如果没有异常，可以跳过。

安装 jdk11

在https://www.azul.com/downloads/?package=jdk#download-openjdk下载 jdk11

验证

1
2
3
4

duansg@DuansiguodeMacBook-Pro zulu-8.jdk % java -version
openjdk version "11.0.16.1" 2022-07-19 LTS
OpenJDK Runtime Environment Zulu11.58+23-CA (build 11.0.16.1+1-LTS)
OpenJDK 64-Bit Server VM Zulu11.58+23-CA (build 11.0.16.1+1-LTS, mixed mode)

环境配置

1
2

# 编辑配置文件
vim ~/.bash_profile

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

# 配置JDK路径
export JAVA_8_HOME=/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home
export JAVA_11_HOME=/Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home
export JAVA_17_HOME=/Library/Java/JavaVirtualMachines/jdk-17.0.1.jdk/Contents/Home

CLASSPATH=$JAVA_HOME/lib/tools.jar:$JAVA_HOME/lib/dt.jar:.

# 设置默认JDK版本
export JAVA_HOME=$JAVA_11_HOME

# 配置alias命令可以动态切换JDK版本
alias jdk8="export JAVA_HOME=$JAVA_8_HOME"
alias jdk11="export JAVA_HOME=$JAVA_11_HOME"
alias jdk17="export JAVA_HOME=$JAVA_17_HOME"

export JAVA_HOME
export PATH
export CLASSPATH


# maven配置
export MAVEN_HOME=/Users/itzhuzhu/Desktop/Java/maven/apache-maven-3.8.4
export PATH=$PATH:$MAVEN_HOME/bin

1

source ~/.bash_profile

验证环境

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

duansg@DuansiguodeMacBook-Pro JavaVirtualMachines % java -version
openjdk version "1.8.0_312"
OpenJDK Runtime Environment (Zulu 8.58.0.13-CA-macos-aarch64) (build 1.8.0_312-b07)
OpenJDK 64-Bit Server VM (Zulu 8.58.0.13-CA-macos-aarch64) (build 25.312-b07, mixed mode)
duansg@DuansiguodeMacBook-Pro JavaVirtualMachines % jdk11
duansg@DuansiguodeMacBook-Pro JavaVirtualMachines % java -version
openjdk version "11.0.16.1" 2022-07-19 LTS
OpenJDK Runtime Environment Zulu11.58+23-CA (build 11.0.16.1+1-LTS)
OpenJDK 64-Bit Server VM Zulu11.58+23-CA (build 11.0.16.1+1-LTS, mixed mode)
duansg@DuansiguodeMacBook-Pro JavaVirtualMachines % jdk8
duansg@DuansiguodeMacBook-Pro JavaVirtualMachines % java -version
openjdk version "1.8.0_312"
OpenJDK Runtime Environment (Zulu 8.58.0.13-CA-macos-aarch64) (build 1.8.0_312-b07)
OpenJDK 64-Bit Server VM (Zulu 8.58.0.13-CA-macos-aarch64) (build 25.312-b07, mixed mode)
duansg@DuansiguodeMacBook-Pro JavaVirtualMachines %

MAT 配置修改

在 MAT 包的目录下找到 MemoryAnalyzer.ini，编辑 MemoryAnalyzer.ini

1
2
3
4
5
6
7
8
9
10

-vm
/Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home/bin
-startup
../Eclipse/plugins/org.eclipse.equinox.launcher_1.6.400.v20210924-0641.jar
--launcher.library
../Eclipse/plugins/org.eclipse.equinox.launcher.cocoa.macosx_1.2.400.v20211117-0650
-vmargs
-Xmx1024m
-Dorg.eclipse.swt.internal.carbon.smallFonts
-XstartOnFirstThread

验证 MAT

前言

Mybaits 作为国内大流行的“伪”ORM 框架，它也是不少大厂的“御用框架”，可想而知其地位举足轻重。究其原因，国内很多互联网公司早期大部分都是基于面向数据库(表)编程，而 java 对象只是作为数据的载体，数据模型的 CRUD 都设计在一张表上，而业务逻辑就是不同表的 CRUD 集合。所以开发者需要它做的就是将 SQL 自动封装映射成 java 对象，没有其他花里胡哨的功能，这也是它流行原因之一。

Mybaits 组件简要流程图

Configuration

• Configuration：MyBatis 所有的主配置信息都在 Configuration 里面，MyBatis 通过 Configuration 对象获取各种配置，例如：启动加载的 MappedStatement、TypeHandler、类型别名、插件等等。
• MappedStatement：它封装了就是大家经常编写的 XxxxMapper.xml 文件里面、、、节点。

  SqlSession

  

  • SqlSession：它作为 MyBatis 提供的面向开发者的核心顶层 API，表示和数据库交互时的会话对象，是 MyBatis 执行持久化操作的关键对象，它的底层封装了 JDBC 连接，用于完成数据库的增删改查功能。还有一点需要注意的是它不是线程安全的。
  • SqlSessionFactory：它是一个接口，它的定义就是创建 SqlSession 的工厂，Mybatis 底层可以通过 SqlSessionFactoryBuilder 对象，加载 xml 配置文件或一个预设定的 Configuration 的实例构建出具体的工厂类的实例。
  • DefaultSqlSessionFactory：它是 SqlSessionFactory 默认实现类。它通过 Configuration 来创建，其重载了很多 openSession 方法(根据 Configuration、执行器、自动提交创建等等)来创建 SqlSession。
  • Configuration：主配置信息，详情见第一小节。
  • DefaultSqlSession：它是 SqlSession 接口的默认实现类，它不仅实现了 SqlSession 的核心方法，还维护主配置信息与执行器(Executor)信息。它的类注释上标注了此类不是一个线程安全的，为什么线程不安全？其实也很好理解，因为 SqlSession 的最终执行只会产生一次 Connection，假设在两个线程通过同一个 SqlSession 来执行操作，那么就有可能，A 线程开始执行，但是由于 B 线程执行操作比较快，B 线程先关闭了链接，从而造成 A 线程的逻辑不被成功执行。
  • SqlSessionManager：可以看出 SqlSessionManager 既实现了 SqlSessionFactory，也实现了 SqlSession。所以它具备生产 SqlSession 的能力，也具备 SqlSession 的能力，SqlSession 的作用是执行具体的 Sql 语句。但是需要说明的是，SqlSessionManager 是线程安全的，因为它内部维护了一个 sqlSessionProxy，其重写的 SqlSession 的方法，都是通过 sqlSessionProxy 来执行的，而 sqlSessionProxy 是一个动态代理的对象，其 SqlSession 是通过 localSqlSession 来获取的，这个属性其实就是一个 ThreadLocal 类，到这其实也就明白了，它为每一个线程分配一个副本对象，保证了 Connection 对象线程的安全性。
  • Executor：详情见下一小节。

  Executor

  

  • Executor：通过上面几个关系图，不难看出一个 SqlSession 对应一个 Executor 对象，而 Executor 是 MyBatis 的内部 SQL 执行器，它负责调用 StatementHandler 操作数据库进行增删改查的具体操作，并把结果集通过 ResultSetHandler 进行自动映射。
  • BaseExecutor：BaseExecutor 是一个抽象类，它采用模板方法的方式实现了 Exeutor 接口，除了默认实现的方法之外，它提供了额外的抽象方法由不同功能的实现类实现不同的功能，其中它的实现类有 SimpleExecutor、ReuseExecutor、BatchExecutor、ClosedExecutor，需要额外说明的是 Mybatis 的一级缓存的功能也是其实现的。
  • CachingExecutor：它其实是 Executor 的装饰器，它内部维护了一个 Executor 的属性，并为这个属性增加了二级缓存的功能。因为这个属性的类型是 Executor，所以这个属性可以是 BaseExeutor 具体实现的执行器的任何一个，它的处理逻辑可以大致列为：它先从缓存中查询结果，如果存在则就返回。倘若不存在，则交由 BaseExecutor 的具体的实现类去进行操作，并把结果缓存起来。
  • SimpleExecutor：从它的名字也能看出它是一个简单的执行器，其核心的方法都在其父类 BaseExecutor 中，它与其他执行器的区别是，它每执行一次，就创建一个 Statement 对象，用完立刻关闭 Statement 对象。
  • BatchExecutor：专门用于执行批量 sql 操作。它维护了多个 Statement，通过 Statement.addBatch()添加到批处理，当所有参数都设置完，通过 Statement.executeBatch()方法执行操作。
  • ClosedExecutor：它是一个内部类，外部无法使用，调用其方法会抛出异常。它是一个表示已经关闭的执行器，并没有实际的功能。
  • ReuseExecutor：它是可复用的执行器，它会重用 Statement 执行 sql 操作，在执行操作的时候，会以 sql 作为 key 去查找 Statement，有就使用，没有就创建，使用完不会关闭，会暂存起来，以供下次使用。

  StatementHandler

  

  • StatementHandler：它是 MyBatis 操作数据库执行 sql 脚本的对象，也叫 sql 语法构建处理器，sql 它封装了对 JDBC 的 Statement 对象的操作，其作用是：sql 声明、填参、执行、获取结果。需要额外说明的是它的填参和获取结果的过程，因为它涉及参数映射、结果集映射、1 对 N、循环引用等复杂逻辑的处理。对于这种复杂性 MyBatis 做法就是使用参数处理器(ParameterHandler)、结果集处理器(ResultSetHandler)分别实现处理的。
  • BaseStatementHandler：它是 StatementHandler 的默认实现类，它也是一个抽象的基类，它有点类似于 Executor，它同样采用模板方法的方式实现了 StatementHandler 接口，除了默认实现的方法之外，它提供了额外的抽象方法由不同功能的实现类实现不同的功能。
  • RoutingStatementHandler：它通过静态代理的模式，实现了“路由器”的功能，它主要功能是实现了此下三个处理器的路由，它没有实际操作处理，只是负责 BaseStatementHandler 相关具体的实现 StatementHandler 的创建及调用。
  • SimpleStatementHandler：它是一个简单的处理器，它对应着 JDBC Statement 对象的处理，处理不带动态参数运行的 sql。
  • PrepareStatementHandler：它是能够解决 sql 注入的一种推荐处理器，它同样也对应 java.sql.PrepareStatement 对象的处理，负责处理 sql 中的占位符动态参数赋值操作预编译 SQL 的接口处理器。
  • CallableStatementHandler：它实际就是使用 CallableStatement 来执行 SQL 语句，只不过它执行的是存储过程。

  ParameterHandler

  

  • ParameterHandler：它是 Mybatis 的 sql 实参处理器，它主要负责将传递的参数转换成 JDBC 的 Statement 所需要的参数，它是 MyBatis 实现 sql 参数设置的接口对象。
  • DefaultParameterHandler：它是 ParameterHandler 的默认实现类，它主要是给 PreparedStatement 设置参数，将传入的 BoundSql 语句中的”?”占位符进行实参替换。MyBatis 在解析 xml 文件中 sql 标签节点时，会将#{}参数解析为 ParameterMapping 对象，通过它就可以知道参数的名称、JavaType、JdbcType 等等信息。再根据参数名称去 ParamMap 中解析出参数值，根据参数的 JavaType 找到对应的 TypeHandler，再通过 TypeHandler 去设置对应类型的参数，

  ResultSetHandler

  

  • ResultSetHandler：它封装了将 JDBC 返回的 ResultSet 结果集对象的操作。当执行 SQL 类型为 SELECT 语句时，ResultSetHandler 用于将查询结果转换成 Java 对象。（ResultSet 接口是 JDBC-API 中比较重要的组件，提供了检索和操作 sql 执行结果的方法）
  • DefaultResultSetHandler：它是 ResultSetHandler 的默认实现类，它具体的作用就是将 Statement 执行后的结果集，按照 Mapper 文件中定义返回结果的 ResultType/ResultMap 来封装成对应的对象，最后将封装的对象返回。

  TypeHandler

  

  • TypeHandler：它是 MyBatis 中的类型处理器，它负责 java 数据类型和 JDBC 数据类型之间的映射和转换，它的作用主要是能够根据 java 类型，在 StatementHandler 调用 ParameterHandler 或 ResultSetHandler 时，为对应的 set/get 方法为对象设值。
  • BaseTypeHandler：它是 TypeHandler 接口的默认实现类，它提供了 4 个抽象方法由具体的子类去实现相关的转换功能，而我们在实现自定义的转换器的时候，可以通过继承它实现相关功能。

  总结

  Sqlsession 作为 Mybaits 开发者层面的顶层 API，实际上是 Executor 组件的门面接口，其主要目的是为了提供更友好的数据库操作接口，这也是设计模式中外观模式的典型应用。真正执行 sql 操作的是 Executor 的 sql 执行器，它会通过 StatementHandler 组件对 JDBC 的 Statement 对象进行操作，它通过 ParameterHandler 组件对 sql 参数占位符赋值。ParameterHandler 组件中会根据 java 类型找到对应的 TypeHandler 对象，TypeHandler 中会通过 Statement 对象提供的 set()方法为 Statement 对象中的参数占位符设置值。同样，当 StatementHandler 组件完成与数据库交互后，在通过 ResultSetHandler 组件从 Statement 对象中获取 ResultSet 对象，然后将 ResultSet 对象转换为对应的 java 对象。

  展开全文 >>

  深入浅出Mybatis拦截器(已收录)

  2022-09-12

  

  前言

  在正式使用拦截器之前，首先要抛出几个问题，我们平时所谈的拦截器与过滤器有什么区别？我们在使用 Mybatis 时候，如果想动态的改写 sql 如何实现？倘若在多租户的系统中，如何依据当前的线程上下文中的请求租户信息，动态的改写 sq 设置租户信息？又或者如何增加 sql 的执行耗时或者信息摘要呢？

  拦截器与过滤器

  • 过滤器(Filter)：见名知意我们使用过滤器的目的，无非就是用来做过滤操作的。比如对请求前置过滤掉一些信息，或者前置设置某些参数，然后在从 Controller 根据这些业务特征进行对应的逻辑操作。通常用的场景是：ip 白名单、用户信息的过滤、敏感信息的过滤等等。
  • 拦截器（Interceptor）：从名称看来它类似于 AOP 实现了某些拦截操作，其就是在某些方法前/后，执行某些特殊的业务逻辑。而动态代理就是拦截器的简单实现，在调用方法前/后做其它业务逻辑的操作，也可以在抛出异常的时候做某些特殊的业务逻辑操作。

  Mybatis 拦截器使用姿势

  先不谈 Mybatis 如何实现的拦截器加载原理，我们直接上手去配置拦截器。但是为了方便下个小节查看源码，这里使用原生的拦截器配置方式，更多的配置方式，可以去查下相关资料。

  首先配置拦截器分为以下几步

  1. 继承 org.apache.ibatis.plugin.Interceptor 接口、配置@Intercepts 与@Signature 组合注解。(详情见下个小节)

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

  /** * @author Duansg * @date 2022-10-08 11:45 下午 */ @Intercepts(value = { @Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class, CacheKey.class, BoundSql.class}), @Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class})} ) public class ExampleInterceptor implements Interceptor { @Override public Object intercept(Invocation invocation) throws Throwable { System.err.println("晓断测试Interceptor"); return invocation.proceed(); } @Override public Object plugin(Object target) { return Plugin.wrap(target, this); } @Override public void setProperties(Properties properties) { System.err.println("晓断测试Interceptor-Properties" + JSON.toJSONString(properties)); } }

  2. 在 mybatis-config.xml 中配置拦截器

  1 2 3 4 5 6 7 8 9 10 11 12 13

  <?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE configuration PUBLIC "-//mybatis.org//DTD Config 3.0//EN" "http://mybatis.org/dtd/mybatis-3-config.dtd"> <configuration> ..... <plugins> <plugin interceptor="com.xxx.xxx.xxx.ExampleInterceptor"> <property name="someProperty" value="100"/> </plugin> </plugins> ..... </configuration>

  3. 验证拦截器是否生效

  1 2 3 4

  00:05:51.099 [main] DEBUG org.apache.ibatis.logging.LogFactory - Logging initialized using 'class org.apache.ibatis.logging.slf4j.Slf4jImpl' adapter. 晓断测试Interceptor-Properties{"someProperty":"100"} 00:05:51.231 [main] DEBUG org.apache.ibatis.datasource.pooled.PooledDataSource - PooledDataSource forcefully closed/removed all connections. 晓断测试Interceptor

  Mybatis 拦截器@Intercepts 与@Signature todo

  在谈这些配置之前，可以翻阅一下笔者发布的 Mybatis 核心组件的文章，以下为简要信息。在下图中，Mybatis 拦截器的拦截点有 4 种，分别为 Executor(执行器)、StatementHandler(sql 语法构建处理器)、ParameterHandler(参数处理器)、ResultSetHandler(结果处理器)。
  

  • @Intercepts：它用于标识当前的对象是一个拦截器，其配置值是一个@Signature 的集合。
  • @Signature：它用于标识需要拦截的接口、方法、对应的参数列表。

  Mybatis 拦截器实现原理

  上个小节提到 Mybatis 拦截器的拦截点有 4 种，但是他们是如何加载拦截并执行的呢？直接上代码

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

  // 大家经常见到的mybatis的用法 public static void main(String[] args) throws IOException { SqlSession session = null; try { // ①：加载Mybatis配置文件 InputStream inputStream = Resources.getResourceAsStream("mybatis-config.xml"); // ②：构建SqlSessionFactory SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream); // ③：获取SqlSession并获取代理对象查询 session = sqlSessionFactory.openSession(); ProductDao mapper = session.getMapper(ProductDao.class); System.out.println(mapper.findById(100001L)); } finally { if (!ObjectUtils.isEmpty(session)) { session.close(); } } }

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

  /** * @author Duansg * @date 2022-10-08 11:45 下午 */ @Intercepts(value = { @Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class, CacheKey.class, BoundSql.class}), @Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class})} ) public class ExampleInterceptor implements Interceptor { @Override public Object intercept(Invocation invocation) throws Throwable { System.err.println("晓断测试Interceptor"); return invocation.proceed(); } @Override public Object plugin(Object target) { return Plugin.wrap(target, this); } @Override public void setProperties(Properties properties) { System.err.println("晓断测试Interceptor-Properties" + JSON.toJSONString(properties)); } }

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

  <!--mybatis-config.xml --> <?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE configuration PUBLIC "-//mybatis.org//DTD Config 3.0//EN" "http://mybatis.org/dtd/mybatis-3-config.dtd"> <configuration> <plugins> <plugin interceptor="cn.**.**.test.ExampleInterceptor"/> <property name="someProperty" value="100"/> </plugin> </plugins> <environments default="development"> <environment id="development"> <transactionManager type="JDBC"/> <dataSource type="POOLED"> <property name="driver" value="com.mysql.jdbc.Driver"/> <property name="url" value="****"/> <property name="username" value="****"/> <property name="password" value="****"/> </dataSource> </environment> </environments> <mappers> <mapper resource="ProductsMapper.xml"/> </mappers> </configuration>

  源码解析

  通过此上代码，① 跟 ② 这一步没什么问题，前者就是直接根据配置文件获取输入流，后者获取

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

  // new SqlSessionFactoryBuilder().build(inputStream); public SqlSessionFactory build(InputStream inputStream, String environment, Properties properties) { try { // ①：XMLConfigBuilder它主要负责解析mybatis-config.xml配置文件，它会初始化configuration对象。 XMLConfigBuilder parser = new XMLConfigBuilder(inputStream, environment, properties); // ②：parse()方法是解析mybatis-config.xml配置文件的入口。详见下一步 return build(parser.parse()); } catch (Exception e) { throw ExceptionFactory.wrapException("Error building SqlSession.", e); } finally { ErrorContext.instance().reset(); try { inputStream.close(); } catch (IOException e) { // Intentionally ignore. Prefer previous error. } } }

  1 2 3 4 5 6 7 8 9 10

  // parser.parse(); public Configuration parse() { if (parsed) { throw new BuilderException("Each XMLConfigBuilder can only be used once."); } parsed = true; // ①：具体的解析过程，对应的就是mybatis-config.xml中的整个configuration节点，详见下一步 parseConfiguration(parser.evalNode("/configuration")); return configuration; }

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

  // parseConfiguration(parser.evalNode("/configuration")); // 看到这个方法你可能就熟悉了，这里解析的配置不都是我们在configuration中配置的节点么。 // 本期不讨论其他配置的加载,直接看plugins节点的解析 private void parseConfiguration(XNode root) { try { Properties settings = settingsAsPropertiess(root.evalNode("settings")); //issue #117 read properties first propertiesElement(root.evalNode("properties")); loadCustomVfs(settings); typeAliasesElement(root.evalNode("typeAliases")); // ①：拦截器加载。详见下一步 pluginElement(root.evalNode("plugins")); objectFactoryElement(root.evalNode("objectFactory")); objectWrapperFactoryElement(root.evalNode("objectWrapperFactory")); reflectionFactoryElement(root.evalNode("reflectionFactory")); settingsElement(settings); // read it after objectFactory and objectWrapperFactory issue #631 environmentsElement(root.evalNode("environments")); databaseIdProviderElement(root.evalNode("databaseIdProvider")); typeHandlerElement(root.evalNode("typeHandlers")); mapperElement(root.evalNode("mappers")); } catch (Exception e) { throw new BuilderException("Error parsing SQL Mapper Configuration. Cause: " + e, e); } }

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

  // pluginElement(root.evalNode("plugins")); private void pluginElement(XNode parent) throws Exception { if (parent != null) { // 这个parent就是plugins整个节点，getChildren就是获取它的子节点plugin节点 for (XNode child : parent.getChildren()) { // ①：获取plugin中的interceptor属性， String interceptor = child.getStringAttribute("interceptor"); // ②：解析property节点的name、value Properties properties = child.getChildrenAsProperties(); // ③：实例化配置的Interceptor Interceptor interceptorInstance = (Interceptor) resolveClass(interceptor).newInstance(); // ④：设置自定义的属性配置 interceptorInstance.setProperties(properties); // ⑤※：添加到configuration中，详见下一步。 configuration.addInterceptor(interceptorInstance); } } }

  1 2 3 4 5

  // interceptorChain就是拦截器链，它在configuration初始化创建,其内部维护这一个空的list类型的Interceptor集合 public void addInterceptor(Interceptor interceptor) { // ①：添加到拦截器链中，详见下一步。 interceptorChain.addInterceptor(interceptor); }

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

  /** * @author Clinton Begin */ public class InterceptorChain { private final List<Interceptor> interceptors = new ArrayList<Interceptor>(); /* ②：加载所有拦截器方法，它会在创建Executor、StatementHandler、 ParameterHandler、ResultSetHandler时加载。可以去这些拦截点创建的地方查看。 例如Executor创建：org.apache.ibatis.session.Configuration#newExecutor(org.apache.ibatis.transaction.Transaction, org.apache.ibatis.session.ExecutorType) */ // 需要注意的是，这个target就是那4个拦截点的对象，不过多赘述。 public Object pluginAll(Object target) { for (Interceptor interceptor : interceptors) { // ③：调用每个拦截器的plugin方法，用于封装拦截点对象的，通过该方法返回一个拦截点的代理对象。详见下一步 // 这个plugin方法就是我们在实现拦截器的时候返回的return Plugin.wrap(target, this); target = interceptor.plugin(target); } return target; } // ①：书接上回，就是将这个拦截器添加到集合中 public void addInterceptor(Interceptor interceptor) { interceptors.add(interceptor); } }

  1 2 3 4 5

  @Override public Object plugin(Object target) { // ①：生成拦截点的代理对象，详见下一步。 return Plugin.wrap(target, this); }

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

  public class Plugin implements InvocationHandler { private Object target; private Interceptor interceptor; private Map<Class<?>, Set<Method>> signatureMap; private Plugin(Object target, Interceptor interceptor, Map<Class<?>, Set<Method>> signatureMap) { this.target = target; this.interceptor = interceptor; this.signatureMap = signatureMap; } public static Object wrap(Object target, Interceptor interceptor) { // ①：解析我们拦截器配置的@Intercepts跟@Signature注解配置。 // k：@Signature配置的type具体拦截点类型， // v：@Signature配置的method具体的拦截方法 Map<Class<?>, Set<Method>> signatureMap = getSignatureMap(interceptor); // ②：获取拦截点的class Class<?> type = target.getClass(); // ③：校验获取此拦截器是否拦截了这个拦截点。 Class<?>[] interfaces = getAllInterfaces(type, signatureMap); if (interfaces.length > 0) { // ④：如果有拦截，生成这个拦截点的代理对象。 return Proxy.newProxyInstance( type.getClassLoader(), interfaces, new Plugin(target, interceptor, signatureMap)); } return target; } @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { try { // ⑤：获取拦截器配置的需要拦截的方法 Set<Method> methods = signatureMap.get(method.getDeclaringClass()); // ⑥：如果没有拦截，或者当前拦截方法中没有拦截点对象中的方法，直接执行。 if (methods != null && methods.contains(method)) { // ⑦：如果有，执行我们自定义拦截器中的intercept方法。 return interceptor.intercept(new Invocation(target, method, args)); } return method.invoke(target, args); } catch (Exception e) { throw ExceptionUtil.unwrapThrowable(e); } } // ..... }

  通过此上分析，我们在执行 Executor、StatementHandler、ParameterHandler、ResultSetHandler 时的方法的时候，其实调用的都是代理对象，而代理对象通过方法增强的方式，在调用方法执行前判断是否需要拦截，并执行相关的自定义拦截逻辑的。

  Mybatis 拦截点加载顺序

  不知道客官有没有考虑过 Mybatis 这 4 种拦截点的加载顺序？它一定是按照组件的调用顺序拦截的吗？答案是不一定的，网上很多有说的顺序是 Executor -> ParameterHandler -> ResultHandler -> StatementHandler，其实这也不全对。

  拦截点顺序验证

  代码就不展示了，没什么营养，就是配置了 4 种拦截点的拦截器。验证下来，结论就是：Executor 首先执行的是没有问题的。ParameterHandler -> ResultHandler 的先后顺序也没有问题，一进一出嘛。问题就是 StatementHandler 的顺序。

  • 如果你拦截的是 StatementHandler.query()方法，那么顺序是 Executor -> ParameterHandler -> StatementHandler -> ResultHandler。
  • 如果你拦截的是 StatementHandler.prepare()方法，那么顺序是 Executor -> StatementHandler-> ParameterHandler -> ResultHandler。

    源码解析

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

  // 我们在拦截Executor的query方法的时候,最终都会走到doQuery的方法逻辑中， // Executor拦截query肯定首先执行没有问题， @Override public <E> List<E> doQuery(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) throws SQLException { Statement stmt = null; try { Configuration configuration = ms.getConfiguration(); StatementHandler handler = configuration.newStatementHandler(wrapper, ms, parameter, rowBounds, resultHandler, boundSql); // ①：关键在于这个预编译的过程中，详见下一步。 stmt = prepareStatement(handler, ms.getStatementLog()); // ②：此处就是拦截的StatementHandler.query()方法。记住这里 return handler.<E>query(stmt, resultHandler); } finally { closeStatement(stmt); } }

  1 2 3 4 5 6 7 8 9

  private Statement prepareStatement(StatementHandler handler, Log statementLog) throws SQLException { Statement stmt; Connection connection = getConnection(statementLog); // ①：这个就是拦截的StatementHandler.prepare()方法。 stmt = handler.prepare(connection, transaction.getTimeout()); // ②：这个底层就是调用的ParameterHandler中的setParameters方法。 handler.parameterize(stmt); return stmt; }

  从上面两段代码中不难看出，如果是拦截的 StatementHandler.prepare()方法，那么它的执行时机是在 ParameterHandler 执行之前的，所有 StatementHandler 会先执行拦截。相反，如果是 StatementHandler.query()方法，它要等预编译之后在进行查询，所以到这里就能说明”也不全对”的言论了。

  Mybatis 拦截器应用场景

  • Sql 摘要统计/监控
  • 动态分页
  • 多租户
  • 脱敏
  • 加解密
  • 冗余字段新增
  • …….等等

  全剧终

  通过本篇文章，相信你肯定会对 Mybatis 的拦截器有一个充分的认知，但文中屏蔽掉了许多细节，这些细节还需要你根据源码依照文中对应的注释去串一下自己的逻辑，也欢迎你指出文章中的错误信息，以便笔者及时改正，以免误人子弟，因排版问题，可能阅读起来不是很通顺，也欢迎来指正说明。

  展开全文 >>

  浅析ThreadLocal

  2022-09-12

  http://www.javashuo.com/article/p-fzjstmal-ws.html

  展开全文 >>

  浅析MAT(Memory Analyer Tool)

  2022-09-12

  前言

  MAT（Memory Analyer Tool），它是一个快速、功能丰富的 Java Heap 的分析工具，它可以帮助我们查找内存泄漏和排查问题，而且还有丰富的报表统计等等。我们可以通过插件的形式运行还可以单独下载。官方地址：https://www.eclipse.org/mat/

  MAT 用法

  展开全文 >>

  Docker爱之初体验

  2022-09-12

  https://mp.weixin.qq.com/s?__biz=MzI4NDY1MDI2Mg==∣=2247489006&idx=3&sn=db704acae7277f69e864b63e4054c7cd&chksm=ebf96b97dc8ee281f6bfc84e55a6846ab40ab402ccbe11a2321fe8055312c09291b103ee4a8b&scene=21#wechat_redirect

  展开全文 >>

  必须理解的JavaSPI机制

  2022-09-12

  前言

  在开源的框架、项目中，会有很多地方使用到了 JavaSPI 的机制，例如数据库驱动、Dubbo、日志框架等等，这种可扩展的编程机制，不仅方便服务的扩展，还可以实现插拔式的替换组件。

  什么是 JavaSPI?

  SPI 的全名为 Service Provider Interface，英文不错的童鞋可以去官方看一下(https://docs.oracle.com/javase/tutorial/sound/SPI-intro.html))，用白话文去说就是(基于接口编程+策略模式+配置文件)，其实这种机制，在某种层度上类似于 java.util.Collections 中的 sort 等方法，我们传入的除了数据集合，还有实现了 Comparator 接口的具体排序规则方法，这种情况下就实现了针对接口定制化开发实现，并动态可插拔的思想。但是不同的是，JavaSPI 规定了在提供了服务接口的实现之后，在静态资源目录下创建 services 目录，(META-INF/services/)，其中 services 目录里同时创建一个以服务接口命名的文件，文件内容为服务实现类的全路径。

  https://mp.weixin.qq.com/s?__biz=MzUyODQ3OTYyNQ==∣=2247483887&idx=1&sn=39894d1bcd98458af914a101ac1d7f76&chksm=fa6ee509cd196c1f17a9aab846074dacf39edd8f02b22d42624b9cd2ba48fdd5cbb7eb4513e0&token=746151531⟨=zh_CN#rd

  展开全文 >>

  源码浅析SpringMVC请求的流转过程(已收录)

  2022-09-12

  前言

  Spring MVC 框架使用了其”模型-视图-控制器”( Model-View-Controller )架构方式，用于开发灵活且松散耦合的 Web 应用程序。我们都使用过 SpringMVC 来处理信息，并渲染视图到 Browser。但需要注意的是，在现在的架构中，大都采用了前后端分离的情况，而我们在使用 SpringMVC 的时候，只需要关注 M(Model)，C(Controller)这两个部分，而视图渲染的部分则交给了前端。

  流程图

  

  源码解析

  (1):用户向服务发送 HTTP 请求，DispatcherServlet 捕获请求。
  (2):DispatcherServlet 根据 URL，调用 HandlerMapping 获得该 Handler 对象以及所对应的拦截器，其返回的是 HandlerExecutionChain 对象，这个对象中就包含了 Handler 对象以及这个 Handler 所对应的拦截器。
  
  (3):DispatcherServlet 根据获得的 Handler，选择一个合适的 HandlerAdapter 。（附注：如果成功获得 HandlerAdapter 后，此时将开始执行拦截器的 preHandler 方法），然后获取 Request 请求数据，填充 Handler，执行 Handler。
  (4):上一步获取到 HandlerAdapter 后，会执行 Handler，并返回 ModelAndView
  
  (5):根据返回的 ModelAndView ，选择一个适合的 ViewResolver（必须是已经注册到 Spring 容器中的 ViewResolver),解析出 View 对象,然后返回给 DispatcherServlet。
  
  (6):ViewResolver 通过 render()方法结合 Model 和 View，来渲染视图。
  
  (7):ViewResolver 通过 render()方法写回给 Browser。
  

  流程详解

  看完以上没有看过源码的童靴可能会一脸懵逼，此上也是围绕流程图进行了部分截取，方便大家理解，下面我们来搭建一个测试 Demo 来进一步了解。

  (1):测试 Controller(模拟用户真实情况)
  
  (2):在解析 DispatcherServlet 之前，我们先来看一下 DispatcherServlet 的父类 FrameworkServlet。
  
  (3):通过上图我们不难看到一些敏感内容，如 doGet(…)、doPost(…)、doPut(…)、doDelete(…)等等，我们通过这些方法可以看到，这些方法都指向了同一个方法，processRequest(…)
  
  (4):我们来看一下 FrameworkServlet 的 service(…)方法。

  1 2 3 4 5 6 7 8

  protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { String method = request.getMethod();//获取请求方法 if (method.equalsIgnoreCase(RequestMethod.PATCH.name())) {//判断请求方法 this.processRequest(request, response); } else { super.service(request, response);//调用父类的service(…)方法 } }

  (5):我们来看一下父类 HttpServlet 所包含的方法。
  
  (6):通过 service(…)我们可以看出，此方法是根据方法类型，分发请求的。
  
  (7):我们继续跟进方法，就不难发现这些请求处理的方法就回到了(3)中所示。
  
  (8):我们重点关注一下，processRequest(…)方法，(代码已作删减)

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

  protected final void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { try { //线程绑定 /** *封装Locale对象、属性到LocaleContextHolder *封装Locale对象、属性到RequestContextHolder */ … this.doService(request, response);//请求处理 } catch (ServletException var17) { failureCause = var17; throw var17; } catch (IOException var18) { failureCause = var18; throw var18; } catch (Throwable var19) { failureCause = var19; throw new NestedServletException("Request processing failed", var19); } finally { //解除绑定 //…… this.publishRequestHandledEvent(request, response, startTime, (Throwable)failureCause); } }

  (9):通过上述代码，请求处理 doService(…)方法。我们可以看到父类中是一个抽象方法，Spring 中很多地方运用了这种方法，由父类抽象流程，交由子类在实现具体的方法，看到这里也就明白了，这个地方就是 DispatcherServlet 的入口方法，
  
  (10):DispatcherServlet 中 doService(…)方法

  1 2 3 4 5 6 7 8 9 10 11 12

  protected void doService(HttpServletRequest request, HttpServletResponse response) throws Exception { //DEBUG日志输出 //封装属性 //… try { this.doDispatch(request, response);//请求处理分发 } finally { if (!WebAsyncUtils.getAsyncManager(request).isConcurrentHandlingStarted() && attributesSnapshot != null) { this.restoreAttributesAfterInclude(request, attributesSnapshot); } } }

  (11):请求处理，DispatcherServlet 核心方法。

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

  protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception { HttpServletRequest processedRequest = request; //核心对象，包含处理器，以及拦截器数组等等。 HandlerExecutionChain mappedHandler = null; boolean multipartRequestParsed = false; WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request); try { try { ModelAndView mv = null; Exception dispatchException = null; try { //校验是否是文件上传请求 processedRequest = this.checkMultipart(request); multipartRequestParsed = processedRequest != request; //获取处理器、拦截器数组对象。 mappedHandler = this.getHandler(processedRequest); if (mappedHandler == null || mappedHandler.getHandler() == null) { //获取不到，异常处理。 this.noHandlerFound(processedRequest, response); return; } //获取当前处理器所对应的HandlerAdapter对象。 HandlerAdapter ha = this.getHandlerAdapter(mappedHandler.getHandler());//获取 String method = request.getMethod(); boolean isGet = "GET".equals(method); if (isGet || "HEAD".equals(method)) { long lastModified = ha.getLastModified(request, mappedHandler.getHandler()); if (this.logger.isDebugEnabled()) { this.logger.debug("Last-Modified value for [" + getRequestUri(request) + "] is: " + lastModified); } if ((new ServletWebRequest(request, response)).checkNotModified(lastModified) && isGet) { return; } } if (!mappedHandler.applyPreHandle(processedRequest, response)) { return; } //调用处理器目标方法，并返回视图对象。 mv = ha.handle(processedRequest, response, mappedHandler.getHandler()); if (asyncManager.isConcurrentHandlingStarted()) { return; } //如果有视图，则从响应中获取视图，如果没有，则使用默认视图 this.applyDefaultViewName(processedRequest, mv); mappedHandler.applyPostHandle(processedRequest, response, mv); } catch (Exception var19) { dispatchException = var19; } //处理结果(包括异常）,渲染视图等等， this.processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException); } catch (Exception var20) { this.triggerAfterCompletion(processedRequest, response, mappedHandler, var20); } catch (Error var21) { this.triggerAfterCompletionWithError(processedRequest, response, mappedHandler, var21); } } finally { if (asyncManager.isConcurrentHandlingStarted()) { if (mappedHandler != null) { mappedHandler.applyAfterConcurrentHandlingStarted(processedRequest, response); } } else if (multipartRequestParsed) { this.cleanupMultipart(processedRequest); } } }

  展开全文 >>

  CPU100%居然找不到问题?

  2022-09-12

  前言

  在线上环境中你一定遇到过 java 程序停顿、CPU100%、死锁等疑难杂症，作为一名 java 外科手术师，怎么分析问题成了关键，就跟去医院看病一样，如何给 java 程序拍个 X 光片呢?

  Java 线程状态机

  

  jstack 概述

  jstack 用于生成 JVM 当前时刻的线程快照。线程快照是当前 java 虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等。线程出现停顿的时候可以通过 jstack 来查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做什么事情，或者等待什么资源。

  jstack 用法

  jstack [ option ] PID

  基本参数：

  • -F 当 jstack [-l] PID 没有响应的时候强制打印栈信息。
  • -l 长列表，打印关于锁的附加信息,例如属于 java.util.concurrent 的 ownable synchronizers 列表。
  • -m 打印 java 和 native c/c++框架的所有栈信息， -h | -help 打印帮助信息
  • PID 需要被打印配置信息的 java 进程 id，可以用 jps 工具查询。

  arthas

  展开全文 >>
  • 所有文章
  • 友链
  • 关于我