小菜鸟

MyBatis 逆向工程全指南：从配置到高级定制（含 IDEA 实战与避坑）

MyBatis 逆向工程（MyBatis Generator，简称 MBG）是 MyBatis 官方提供的代码生成工具，可根据数据库表自动生成 实体类、Mapper 接口、Mapper XML 文件，大幅减少重复的 CRUD 代码编写工作。 依赖优化、高级配置（如分页 / 注释 / 逻辑删除）、IDEA 快捷配置、常见问题解决方案 及 工程化最佳实践，帮助你高效落地逆向工程。

逆向工程核心依赖与版本选型

1. Maven 依赖配置

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

<dependencies>
    <!-- MyBatis 核心依赖 -->
    <dependency>
        <groupId>org.mybatis</groupId>
        <artifactId>mybatis</artifactId>
        <version>3.5.16</version>
    </dependency>

    <!-- MyBatis 逆向工程核心包 -->
    <dependency>
        <groupId>org.mybatis.generator</groupId>
        <artifactId>mybatis-generator-core</artifactId>
        <version>1.4.2</version> <!-- 最新稳定版，修复旧版bug -->
        <scope>provided</scope> <!-- 仅编译期使用，避免打包到生产环境 -->
    </dependency>

    <!-- MySQL 驱动（需与数据库版本匹配，8.0+用8.x版本） -->
    <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <version>8.0.33</version>
        <scope>runtime</scope>
    </dependency>

    <!-- 日志依赖（便于查看逆向工程执行日志，可选） -->
    <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-api</artifactId>
        <version>1.7.36</version>
    </dependency>
    <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-simple</artifactId>
        <version>1.7.36</version>
        <scope>test</scope>
    </dependency>
</dependencies>

<!-- 可选：配置 Maven 插件，通过命令行执行逆向工程 -->
<build>
    <plugins>
        <plugin>
            <groupId>org.mybatis.generator</groupId>
            <artifactId>mybatis-generator-maven-plugin</artifactId>
            <version>1.4.2</version>
            <configuration>
                <!-- 逆向工程配置文件路径 -->
                <configurationFile>src/main/resources/generatorConfig.xml</configurationFile>
                <!-- 执行后是否覆盖已有文件（建议开发期设为true） -->
                <overwrite>true</overwrite>
                <!-- 打印执行日志 -->
                <verbose>true</verbose>
            </configuration>
            <dependencies>
                <!-- 插件依赖的数据库驱动（避免版本冲突） -->
                <dependency>
                    <groupId>mysql</groupId>
                    <artifactId>mysql-connector-java</artifactId>
                    <version>8.0.33</version>
                </dependency>
            </dependencies>
        </plugin>
    </plugins>
</build>

逆向工程配置文件深度解析

1. 完整配置文件（generatorConfig.xml）

Spring Security 核心过滤器详解：过滤器链的工作机制与职责分工

Spring Security 的本质是一个过滤器链，所有 Web 安全功能（认证、授权、CSRF 防护等）均通过不同职责的过滤器协同实现。每个过滤器专注于单一功能，按特定顺序组成链，确保请求在到达业务代码前完成安全校验。从 “职责定义→工作流程→关键源码→使用场景” 四个维度，彻底讲透每个过滤器的作用与协作逻辑。

过滤器链的整体执行顺序

在分析单个过滤器前，需先明确过滤器链的默认执行顺序（Spring Security 自动维护，顺序不可随意调整），这是理解安全流程的基础：

注：实际项目中可能存在更多过滤器（如 RememberMeAuthenticationFilter、OAuth2 相关过滤器），但上述 8 个是最核心的基础过滤器。

核心过滤器详解

1. SecurityContextPersistenceFilter：安全上下文的 “管家”

核心职责：在请求开始时创建 SecurityContext（存储用户认证信息），在请求结束时清空 SecurityContextHolder（避免 ThreadLocal 内存泄漏），是整个安全流程的 “基础保障”。

工作流程

1. 请求到达时：
   • 从 HttpSession 中读取 SecurityContext（若存在，说明用户已登录）；
   • 若不存在，创建新的 SecurityContext；
   • 将 SecurityContext 存入 SecurityContextHolder（ThreadLocal 存储，供后续过滤器使用）。
2. 请求结束时：
   • 若 SecurityContext 有变化（如用户刚登录），将其写入 HttpSession；
   • 调用 SecurityContextHolder.clearContext()，清空当前线程的 SecurityContext。

关键源码

红黑树：自平衡二叉查找树的高效实现

红黑树是一种自平衡的二叉查找树，通过一套特定的规则（颜色约束和旋转操作）保证树的高度始终维持在O(logn)级别，解决了普通二叉查找树在极端情况下退化为链表（查询效率降至O(n)）的问题。它广泛应用于 Java 的TreeMap、C++ 的map等集合类，以及数据库索引的底层实现。

二叉查找树的局限性与红黑树的诞生

二叉查找树的核心特性

二叉查找树（BST）满足：

• 左子树所有节点值 < 根节点值；
• 右子树所有节点值 > 根节点值；
• 左右子树均为二叉查找树。

其查询、插入、删除的平均时间复杂度为O(logn)，但在有序插入时（如依次插入 1,2,3,4），会退化为单链表，此时操作复杂度飙升至O(n)。

根据二分查找树的特性来说，使用中序遍历可以得到一个由小到大的有序序列。

插入节点

hive实现分组拼接功能：替代 MySQL 的 group_concat

在 MySQL 中，group_concat 用于将分组后的多行数据按指定分隔符拼接，而 Hive 中虽无此函数，但可通过 collect_set/collect_list + concat_ws 的组合实现相同功能。本文详细介绍这一替代方案的原理、用法及注意事项。

核心函数解析

实现分组拼接需用到两个核心函数，二者配合可完成 “分组聚合 → 拼接字符串” 的全流程：

collect_set(col) / collect_list(col)

• 功能：将分组内某列的所有值聚合为一个数组。

• 区别：

  • collect_set：去重，返回无重复元素的数组；
  • collect_list：不去重，保留所有元素（包括重复值）。

• 示例：

  若分组后某列值为[‘a’, ‘b’, ‘a’]，则：

  • collect_set(col) 返回 ['a', 'b']；
  • collect_list(col) 返回 ['a', 'b', 'a']。

concat_ws(separator, array)

• 功能：将数组中的元素按指定分隔符（separator）拼接为字符串。
• 参数：
  • separator：分隔符（如 ','、'|'）；
  • array：数组（通常为 collect_set 或 collect_list 的输出）。
• 示例：
  concat_ws(',', ['a', 'b']) 返回 'a,b'。

完整替代方案：分组拼接实现

基本语法

SYN Flood 攻击：原理、危害与防御机制

SYN Flood 攻击是一种针对 TCP 协议缺陷的经典 DoS（拒绝服务）攻击，通过耗尽服务器的连接资源，导致正常用户无法建立连接。其核心原理利用了 TCP 三次握手的机制漏洞，尤其是服务器对未完成连接的超时处理机制。以下从攻击原理、危害到防御措施展开详细解析。

SYN 超时重试：攻击的 “突破口”

TCP 三次握手过程中，若服务器发送 SYN-ACK 后未收到客户端的 ACK（第三次握手），会触发SYN 超时重试机制，这一机制成为 SYN Flood 攻击的关键目标。

超时重试流程：

1. 服务器收到客户端的 SYN 请求，回复 SYN-ACK 后进入SYN_RECV状态，同时将该连接放入SYN 队列（半连接队列）。
2. 若客户端未回复 ACK（如客户端掉线、恶意不回复），服务器会周期性重发 SYN-ACK：
   • 默认重试5 次，间隔时间呈指数递增（1s → 2s → 4s → 8s → 16s）。
   • 第五次重发后，服务器需等待 32s 确认超时，总耗时 63s后才会从 SYN 队列中移除该连接。

风险点：

• 服务器的 SYN 队列容量有限（默认通常为几百至几千）。
• 若大量未完成的连接占用 SYN 队列，新的正常连接请求会因队列满而被拒绝，导致服务器 “拒绝服务”。

SYN Flood 攻击：利用漏洞的恶意行为

SYN Flood 攻击正是利用了上述超时重试机制，通过伪造大量虚假的 SYN 请求，耗尽服务器的 SYN 队列资源，使正常连接无法建立。

攻击过程：

1. 攻击者向目标服务器发送大量伪造源 IP 的 SYN 请求（源 IP 可能不存在或不可达）。
2. 服务器收到 SYN 后，回复 SYN-ACK，但由于源 IP 虚假，永远收不到 ACK，连接被放入 SYN 队列并等待超时。
3. 随着虚假连接不断增加，SYN 队列很快被占满，服务器无法处理新的正常 SYN 请求，导致合法用户无法建立 TCP 连接。