最开始尝试：

SHA256(timestamp+deviceId+random)

但是生成结果和真实signature不一致。

因此判断真实签名逻辑并不在Java层，而是在Native层的libencrypt.so中实现。

本文记录一次完整的逆向过程，目标是定位

weread.encrypt.EncryptUtils

中的

nativeGetSignatures

方法，并还原签名生成流程。

一、HookJava层定位入口

首先定位Java层：

weread.encrypt.EncryptUtils

找到：

nativeGetSignatures(String[]strArr)

方法。

通过FridaHook调试：

Java.perform(function () {

    const EncryptUtils =
        Java.use(
            "weread.encrypt.EncryptUtils"
        );


    EncryptUtils.nativeGetSignatures
        .implementation = function(arr) {


            console.log(
                "参数数量:"
                + arr.length
            );


            for(let i = 0; i < arr.length; i++){

                console.log(
                    "arg[" + i + "]="
                    + arr[i]
                );

            }


            let result =
                this.nativeGetSignatures(arr);


            console.log(
                "返回:"
                + result
            );


            return result;

        };

});

运行后：

发现返回值长度：

64位：
dc3ea89d77e43ce790a0b9dfbddd02a2a8d3525abd5f35e4ecd7c822d1f32cfb

64位十六进制字符串符合SHA256输出特征。

因此初步判断：

signature=SHA256(...)

二、定位libencrypt.so

Java层最终进入Native。

找到：

libencrypt.so

其中核心JNI函数：

Java_weread_encrypt_EncryptUtils_nativeGetSignatures

继续分析，发现主要调用：

weread::GenSignature(n)

真正的签名生成逻辑在：weread::GenSignature中。

三、分析Native层参数处理

主动调用调试：

发现Java层提交的数组进入Native后，并不是直接拼接。

首先进行了sort()排序。

也就是说，Java层传入：

[
参数1,
参数2,
参数3
]

进入Native后：

排序后的参数

才参与后续签名计算。

因此：

参数顺序非常重要。

不能直接按照调用处看到的顺序进行拼接。

四、发现隐藏salt

继续分析：

在：

weread::GenSignature

中发现最终参与签名的数据比传入数组多一个字段。

原本：

3个参数

经过处理后：

4个参数

多出来的就是：

salt

最终类似：

参数1
+
参数2
+
参数3
+
salt

五、分析salt生成方式

继续跟踪，发现调用：

weread::RemapString()

进行字符串重映射。

Native中保存了一张：

256字节查找表

转换逻辑：

输入字符

↓

ASCII值作为索引

↓

查询byte数组

↓

生成新的字符串

Python还原：

def transform_string(input_str):

    byte_Index = [
        0x34,
        0xCA,
        0x55,
        0x40,
        0x1D,
        0xB6,
        0x93,
        0xC6,
        # ...
        # 完整256字节表
        0xB7,
        0x15
    ]


    result = []


    for char in input_str:

        index = ord(char)


        if index < 0 or index >= len(byte_Index):

            raise ValueError(
                f"{char} 超出范围"
            )


        result.append(
            byte_Index[index]
        )


    return bytes(result)

将IDA中找到的256字节表复制出来，即可还原真实salt。

六、分析Hash流程

继续跟踪：

发现签名并不是简单一次SHA256。

实际流程：

两次SHA256

并且每次Hash前都会进行一次数据重排序。

完整流程：

输入4个参数

↓

sort排序

↓

追加salt

↓

第一次数据重排序

↓

SHA256

↓

第二次数据重排序

↓

SHA256

↓

输出signature

七、自定义数据重排序算法

通过IDA分析发现：

每次SHA256前都会计算一个校验值。

1.计算校验值

通过异或：

checksum=byte1^byte2^byte3...

得到：

0-10

范围内的值。

2.根据校验值循环位移

根据checksum：

对输入数据进行循环移动。

类似：

def reorder(data):

    checksum = 0


    for b in data:

        checksum ^= b


    offset = checksum % 10


    return (
        data[offset:]
        +
        data[:offset]
    )

八、最终签名流程

最终还原：

Java层参数

↓

nativeGetSignatures

↓

weread::GenSignature

↓

参数sort排序

↓

RemapString生成salt

↓

追加salt

↓

第一次数据重排序

↓

SHA256

↓

第二次数据重排序

↓

SHA256

↓

signature

拿到signature后那不就随便造了么

• B+Tree 每次向下查找一层，都会产生一次 磁盘 I/O
• 树的高度越低，I/O 次数越少，查询越快

二、聚簇索引（Clustered Index）

InnoDB 中，主键索引就是聚簇索引

聚簇索引结构

id
 ↓
完整的一行数据

• 叶子节点直接存储 整行数据
• 一张表 只有一个 聚簇索引（通常是主键）

三、二级索引（Secondary Index）

• 叶子节点存储的是：主键值，而非整行数据

回表（Bookmark Lookup）

二级索引 → 主键 id → 聚簇索引 → 整行数据

• 使用二级索引查非索引列时，会发生 回表
• 如果只查询 二级索引列 + 主键，则 不需要回表

覆盖索引（Covering Index）

• 查询的列 全部包含在索引中
• Extra 中显示：Using index
• ✅ 性能最好，避免回表

四、EXPLAIN 解读

EXPLAIN 阅读顺序（口诀）

1. 看 type：有没有全表扫描
2. 看 key：是否真正用到索引
3. 看 rows：扫描了多少行
4. 看 Extra：是否有排序、临时表、覆盖索引

五、SQL 慢查询排查流程

SQL 很慢
   │
   ▼
① 有没有走索引？
   │
   ▼
② 为什么没走索引？
   │
   ▼
③ 扫描了多少行？
   │
   ▼
④ 有没有排序？
   │
   ▼
⑤ 有没有回表？

六、常见导致索引失效的原因

• 隐式类型转换
• 联合索引违反 最左匹配原则
• 对索引列做函数操作
• OR 条件不当
• LIKE '%xxx'（前模糊）

七、ORDER BY 为什么会慢？

• ORDER BY age 且 age 无索引
• MySQL 无法利用索引排序
• 结果：Using filesort
• 本质：把数据查出来后再在内存 / 磁盘中排序

八、事务隔离级别与 MVCC（快照）

• RC（Read Committed）：每次 SELECT 都生成新快照
• RR（Repeatable Read）：事务内使用同一快照（MySQL InnoDB 默认）

本质：MVCC（多版本并发控制）

九、深分页问题（LIMIT 优化）

SELECT * FROM t LIMIT 1000000, 10; -- ❌ 很慢

原因

• MySQL 需要先扫描前 1000000 条记录
• 再丢弃，只取 10 条

优化方案：游标分页（Keyset Pagination）

SELECT * FROM t WHERE id > 1000000 ORDER BY id LIMIT 10;

✅ 利用索引顺序定位
✅ 避免 OFFSET 扫描
✅ 性能稳定，适合大数据量翻页

索引决定 I/O，EXPLAIN 决定方向，回表和排序决定代价，分页和隔离级别决定边界。

Spring Boot 接口常见的入参方式主要有三种：

路径参数
查询参数
JSON 请求体

1. 路径参数：@PathVariable

请求地址：

GET /users/1001

Controller：

@GetMapping("/users/{id}")
public UserVO getUser(
        @PathVariable Long id
) {
    return userService.getUser(id);
}

也可以明确指定参数名：

@GetMapping("/users/{userId}")
public UserVO getUser(
        @PathVariable("userId") Long id
) {
    return userService.getUser(id);
}

适合场景：

根据 ID 查询
根据编号删除
访问明确的单个资源

2. 查询参数：@RequestParam

请求地址：

GET /users?page=1&size=10&status=1

Controller：

@GetMapping("/users")
public List<UserVO> list(
        @RequestParam Integer page,
        @RequestParam Integer size,
        @RequestParam(required = false) Integer status
) {
    return userService.list(page, size, status);
}

设置默认值：

@GetMapping("/users")
public List<UserVO> list(
        @RequestParam(defaultValue = "1") Integer page,
        @RequestParam(defaultValue = "10") Integer size
) {
    return userService.list(page, size);
}

参数较多时，可以直接使用对象接收：

@Data
public class UserQuery {

    private Integer page;

    private Integer size;

    private Integer status;
}

@GetMapping("/users")
public List<UserVO> list(UserQuery query) {
    return userService.list(query);
}

适合场景：

分页查询
条件筛选
简单表单参数

3. JSON 请求体：@RequestBody

请求：

{
  "username": "zhangsan",
  "age": 30
}

DTO：

@Data
public class UserCreateDTO {

    private String username;

    private Integer age;
}

Controller：

@PostMapping("/users")
public Long create(
        @RequestBody UserCreateDTO dto
) {
    return userService.create(dto);
}

适合场景：

新增数据
修改数据
复杂对象
嵌套对象
数组和集合

4. 三种方式怎么选

@PathVariable：资源标识
@RequestParam：查询条件
@RequestBody：复杂业务数据

例如：

@PutMapping("/users/{id}")
public void update(
        @PathVariable Long id,
        @RequestBody UserUpdateDTO dto
) {
}

这里：

id 表示修改哪个用户
dto 表示修改哪些内容

二、Comparable 和 Comparator 实现排序

Java 中对象排序常见有两种方式：

Comparable：对象自己定义排序规则
Comparator：外部定义排序规则

1. Comparable

实体类实现 Comparable：

@Data
@AllArgsConstructor
public class User implements Comparable<User> {

    private Long id;

    private String username;

    private Integer age;

    @Override
    public int compareTo(User other) {
        return Integer.compare(this.age, other.age);
    }
}

排序：

List<User> users = new ArrayList<>();

users.add(new User(1L, "zhangsan", 30));
users.add(new User(2L, "lisi", 20));
users.add(new User(3L, "wangwu", 25));

Collections.sort(users);

按照年龄升序排列。

降序：

@Override
public int compareTo(User other) {
    return Integer.compare(other.age, this.age);
}

2. Comparator

不修改实体类，在外部指定排序规则：

users.sort(
        Comparator.comparing(User::getAge)
);

降序：

users.sort(
        Comparator.comparing(User::getAge)
                .reversed()
);

多字段排序：

users.sort(
        Comparator.comparing(User::getAge)
                .thenComparing(User::getUsername)
);

处理 null：

users.sort(
        Comparator.comparing(
                User::getAge,
                Comparator.nullsLast(
                        Integer::compareTo
                )
        )
);

3. 两者区别

Comparable：类本身只有一种主要排序规则
Comparator：可以定义多种排序规则

实际开发中，Comparator 使用更加灵活。

三、遍历集合时 remove 或 add 的注意事项

遍历集合时直接执行 remove() 或 add()，很容易出现：

ConcurrentModificationException

1. 错误示例

List<String> list =
        new ArrayList<>(
                List.of("A", "B", "C")
        );

for (String item : list) {

    if ("B".equals(item)) {
        list.remove(item);
    }
}

增强 for 底层使用迭代器。

遍历过程中直接修改原集合，会破坏迭代器状态。

2. 使用 Iterator 删除

Iterator<String> iterator =
        list.iterator();

while (iterator.hasNext()) {

    String item = iterator.next();

    if ("B".equals(item)) {
        iterator.remove();
    }
}

这是遍历时删除元素的标准写法。

3. 使用 removeIf

条件删除可以直接写：

list.removeIf(
        item -> "B".equals(item)
);

这种写法更简洁。

4. 普通 for 循环倒序删除

for (int i = list.size() - 1; i >= 0; i--) {

    if ("B".equals(list.get(i))) {
        list.remove(i);
    }
}

倒序删除不会影响前面还没有遍历的下标。

5. 遍历时新增

不建议在增强 for 中直接新增：

for (String item : list) {
    list.add("D");
}

可以先保存待新增数据：

List<String> newItems =
        new ArrayList<>();

for (String item : list) {

    if ("A".equals(item)) {
        newItems.add("D");
    }
}

list.addAll(newItems);

四、BeanUtils.copyProperties 复制对象避坑

Spring 提供的：

BeanUtils.copyProperties(source, target);

可以复制两个对象中名称和类型相同的属性。

1. 基本使用

UserEntity entity = new UserEntity();

entity.setId(1001L);
entity.setUsername("zhangsan");

UserVO vo = new UserVO();

BeanUtils.copyProperties(entity, vo);

注意参数顺序：

BeanUtils.copyProperties(源对象, 目标对象);

很容易写反。

2. 只会浅拷贝

假设对象中有一个集合：

private List<String> roles;

复制以后：

source.getRoles() == target.getRoles()

结果可能是：

true

也就是说两个对象引用的是同一个集合。

修改其中一个，另一个也可能受到影响。

3. 属性名称相同但类型不同，不会复制

例如：

UserEntity：

private Long status;

UserVO：

private String status;

虽然字段名一样，但类型不同，不会自动转换。

需要手动处理：

vo.setStatus(
        String.valueOf(entity.getStatus())
);

4. null 会覆盖原值

例如更新对象：

UserUpdateDTO dto = new UserUpdateDTO();

dto.setUsername(null);

执行：

BeanUtils.copyProperties(dto, entity);

会把原来的 username 覆盖成 null。

可以忽略指定字段：

BeanUtils.copyProperties(
        dto,
        entity,
        "username"
);

但如果需要自动忽略所有 null，通常要自己封装工具方法，或者使用 MapStruct。

5. 不要过度依赖 BeanUtils

字段少时，手动赋值更加清晰：

UserVO vo = new UserVO();

vo.setId(entity.getId());
vo.setUsername(entity.getUsername());

字段很多、转换复杂时，可以考虑：

MapStruct

五、Optional 常用方法实践

Optional 主要用于处理可能为 null 的返回值，减少简单的空判断。

但它不能完全替代 if-else。

1. of

对象不能为空：

Optional<String> optional =
        Optional.of("hello");

如果传入 null，会抛出：

NullPointerException

2. ofNullable

允许传入 null：

Optional<String> optional =
        Optional.ofNullable(username);

这是最常用的创建方式。

3. isPresent

判断是否有值：

if (optional.isPresent()) {
    System.out.println(optional.get());
}

不过这种写法和普通 if 区别不大。

4. ifPresent

有值时执行：

optional.ifPresent(
        value -> System.out.println(value)
);

例如：

Optional.ofNullable(user)
        .ifPresent(this::saveLog);

5. orElse

为空时返回默认值：

String username =
        optional.orElse("默认用户");

注意：

optional.orElse(createDefaultUser());

即使 optional 有值，createDefaultUser() 也可能被执行。

6. orElseGet

为空时才执行：

String username =
        optional.orElseGet(
                () -> createDefaultUsername()
        );

如果默认值需要计算或查询，优先使用：

orElseGet()

7. orElseThrow

为空时抛异常：

User user =
        Optional.ofNullable(
                userMapper.selectById(id)
        ).orElseThrow(
                () -> new RuntimeException(
                        "用户不存在"
                )
        );

这是业务查询中很常见的写法。

8. map

对内部值进行转换：

String username =
        Optional.ofNullable(user)
                .map(User::getUsername)
                .orElse("未知用户");

避免写成：

if (user != null) {
    if (user.getUsername() != null) {
    }
}

9. filter

根据条件过滤：

User user =
        Optional.ofNullable(
                userMapper.selectById(id)
        ).filter(
                item -> item.getStatus() == 1
        ).orElseThrow(
                () -> new RuntimeException(
                        "用户不可用"
                )
        );

10. flatMap

当转换结果本身也是 Optional 时使用：

Optional<String> result =
        optionalUser.flatMap(
                this::getUsernameOptional
        );

避免出现：

Optional<Optional<String>>

11. Optional 不适合滥用

不建议用于实体字段：

private Optional<String> username;

也不建议方法参数大量使用：

public void save(Optional<User> user)

更适合作为：

方法返回值

六、serialVersionUID 为什么要手动赋值

实现 Serializable 后，通常会看到：

private static final long serialVersionUID = 1L;

完整示例：

@Data
public class User
        implements Serializable {

    private static final long serialVersionUID = 1L;

    private Long id;

    private String username;
}

1. serialVersionUID 的作用

它相当于序列化类的版本号。

序列化时会记录版本号。

反序列化时会检查：

当前类版本号
是否和序列化数据中的版本号一致

不一致可能抛出：

InvalidClassException

2. 不手动赋值的问题

如果没有手动定义，Java 会根据类结构自动生成一个值。

当类发生变化时，例如：

新增字段
删除字段
修改方法
调整结构

自动生成的版本号可能变化。

之前序列化的数据就可能无法反序列化。

3. 手动定义的意义

private static final long serialVersionUID = 1L;

表示开发者主动控制版本。

普通新增字段时，可以继续保持：

1L

如果类结构发生重大变化，并且不希望兼容旧数据，可以改成：

2L

4. 常见使用场景

Java 原生序列化
Session 持久化
对象写入文件
RPC
缓存对象

如果只是普通 DTO，并且项目完全不使用 Java 原生序列化，实际影响可能不大。

七、引用拷贝、浅拷贝和深拷贝

Java 对象复制时，需要区分：

引用拷贝
浅拷贝
深拷贝

1. 引用拷贝

User user1 = new User();

User user2 = user1;

这里没有创建新对象。

user1 == user2

结果是：

true

两个变量指向同一个对象。

修改：

user2.setUsername("lisi");

user1 也会变化。

2. 浅拷贝

浅拷贝会创建一个新对象，但对象内部的引用类型字段仍然共享。

例如：

@Data
public class User implements Cloneable {

    private String username;

    private Address address;

    @Override
    protected User clone()
            throws CloneNotSupportedException {

        return (User) super.clone();
    }
}

使用：

User user1 = new User();

user1.setUsername("zhangsan");
user1.setAddress(new Address("昆明"));

User user2 = user1.clone();

此时：

user1 == user2

是：

false

但：

user1.getAddress() == user2.getAddress()

可能是：

true

修改 user2 的地址，会影响 user1。

3. 深拷贝

深拷贝不仅创建外层对象，也会复制内部引用对象。

手动实现：

@Override
protected User clone()
        throws CloneNotSupportedException {

    User user = (User) super.clone();

    user.setAddress(
            this.address.clone()
    );

    return user;
}

这样：

user1.getAddress()
        == user2.getAddress()

结果是：

false

4. BeanUtils 属于哪种

BeanUtils.copyProperties(
        source,
        target
);

通常属于浅拷贝。

基本类型和不可变对象看不出问题，但集合、自定义对象仍可能共享引用。

5. 常见深拷贝方式

手动创建新对象
实现 clone
JSON 序列化再反序列化
MapStruct 自定义转换
复制构造方法

实际业务中，推荐使用：

手动转换
复制构造方法
MapStruct

逻辑更加清晰。

八、@Async 使用避坑

Spring 的 @Async 可以让方法在线程池中异步执行。

1. 开启异步

启动类或配置类添加：

@EnableAsync
@Configuration
public class AsyncConfig {
}

2. 基本使用

@Service
public class MessageService {

    @Async
    public void sendMessage() {

        System.out.println(
                Thread.currentThread().getName()
        );
    }
}

调用：

messageService.sendMessage();

调用线程不会等待方法执行结束。

3. 建议指定线程池

不要长期依赖默认线程池。

@Bean("messageExecutor")
public Executor messageExecutor() {

    ThreadPoolTaskExecutor executor =
            new ThreadPoolTaskExecutor();

    executor.setCorePoolSize(2);
    executor.setMaxPoolSize(5);
    executor.setQueueCapacity(100);
    executor.setThreadNamePrefix("message-");
    executor.initialize();

    return executor;
}

使用：

@Async("messageExecutor")
public void sendMessage() {
}

4. 同类内部调用会失效

错误示例：

@Service
public class OrderService {

    public void createOrder() {
        this.sendMessage();
    }

    @Async
    public void sendMessage() {
    }
}

this.sendMessage() 没有经过 Spring 代理对象，异步不会生效。

推荐拆分到另一个 Bean：

@Service
@RequiredArgsConstructor
public class OrderService {

    private final MessageService messageService;

    public void createOrder() {
        messageService.sendMessage();
    }
}

5. private 方法不会生效

错误写法：

@Async
private void sendMessage() {
}

代理对象无法正常代理私有方法。

一般应该使用：

public

6. 异常不容易被调用者捕获

返回 void 时：

@Async
public void execute() {
    throw new RuntimeException("异步异常");
}

调用方无法通过普通 try-catch 捕获。

可以返回：

CompletableFuture<T>

例如：

@Async("messageExecutor")
public CompletableFuture<String> execute() {

    return CompletableFuture.completedFuture(
            "success"
    );
}

7. 事务上下文不会自动传递

异步方法运行在另一个线程。

原线程中的：

事务
ThreadLocal
请求上下文
部分安全上下文

不一定自动传递。

因此不要默认认为异步方法和调用方处于同一个事务。

8. 异步任务可能丢失

如果应用刚提交异步任务就关闭，任务可能没有完成。

重要业务不要只依赖内存异步线程。

例如：

支付通知
订单状态同步
重要消息发送

更适合使用消息队列。

九、MyBatis 一级缓存避坑

MyBatis 一级缓存默认存在，作用范围是：

同一个 SqlSession

在 Spring 项目中，通常可以理解为：

同一个事务中的同一个 SqlSession

1. 基本效果

User user1 =
        userMapper.selectById(1001L);

User user2 =
        userMapper.selectById(1001L);

如果处于同一个 SqlSession，第二次查询可能直接从一级缓存获取，不再执行 SQL。

2. 增删改会清空缓存

例如：

User user1 =
        userMapper.selectById(1001L);

userMapper.updateById(user);

User user2 =
        userMapper.selectById(1001L);

执行更新后，一级缓存通常会被清空。

第二次查询会重新访问数据库。

3. 不同 SqlSession 不共享

两个不同请求、两个不同事务，通常不共享一级缓存。

因此一级缓存不能当成全局缓存使用。

它和 Redis 完全不是一个概念。

4. 同一个对象引用可能带来误解

第一次查询：

User user1 =
        userMapper.selectById(1001L);

修改对象但没有执行更新：

user1.setUsername("lisi");

再次查询：

User user2 =
        userMapper.selectById(1001L);

在某些情况下，可能直接从一级缓存返回对象。

此时：

user1 == user2

可能是：

true

看起来像数据库已经变化，实际上可能只是内存中的缓存对象被修改。

5. 批量操作和循环查询要注意

例如：

for (Long id : ids) {
    userMapper.selectById(id);
}

如果数据量很大，会产生大量查询，也可能让本地缓存占用更多内存。

更合理的方式是批量查询：

userMapper.selectBatchIds(ids);

6. 手动清理一级缓存

可以调用：

sqlSession.clearCache();

但一般不需要手动清理。

如果业务频繁依赖手动清缓存，通常说明事务边界或查询设计需要调整。

7. 一级缓存的核心注意点

可以简单记住：

作用域是 SqlSession
不能跨请求共享
增删改后通常清空
返回的可能是同一个对象引用
不能替代 Redis

MyBatis 一级缓只在当前 SqlSession 内生效，不能当成业务缓存
```

这些知识本身不复杂，但如果不了解边界，就很容易在实际项目中出现一些比较隐蔽的问题。

一个业务方法已经写好了，但现在还需要在它执行前后增加一些通用功能，例如：

• 记录接口日志
• 校验用户权限
• 统计方法耗时
• 开启和提交事务
• 查询缓存
• 接口额度校验
• 异常统一处理

最直接的写法，是把这些代码全部写进业务方法中：

public void createOrder() {

    System.out.println("记录请求日志");

    long start = System.currentTimeMillis();

    System.out.println("创建订单");

    long cost = System.currentTimeMillis() - start;

    System.out.println("方法耗时：" + cost + "ms");
}

这种代码虽然能运行，但存在明显问题：

业务代码和通用代码混在一起
多个方法需要重复编写相同逻辑
后续修改日志或权限逻辑时，需要修改大量业务代码

代理模式就是用来解决这类问题的。

代理对象挡在调用者和目标对象之间，在不修改原业务代码的前提下，对目标方法进行增强。

调用者
  ↓
代理对象
  ↓
目标对象

动态代理则是在程序运行过程中，自动创建代理对象。

Java 中常见的动态代理有两种：

JDK 动态代理
CGLIB 动态代理

Spring AOP 的底层也主要依赖这两种代理方式。

一、什么是代理模式

假设我们有一个订单服务：

public class OrderService {

    public void createOrder() {
        System.out.println("创建订单");
    }
}

调用者直接调用：

OrderService orderService = new OrderService();
orderService.createOrder();

调用关系是：

调用者 → OrderService

使用代理后，调用关系变成：

调用者 → OrderServiceProxy → OrderService

代理对象可以在调用目标方法之前和之后增加逻辑：

代理前置处理
目标方法执行
代理后置处理

例如：

记录开始时间
创建订单
计算执行耗时

代理模式的核心不是替代目标对象，而是：

在不修改目标类代码的情况下，对目标对象的方法进行增强。

二、静态代理

理解动态代理之前，可以先看静态代理。

定义一个接口：

public interface OrderService {

    void createOrder();
}

目标类：

public class OrderServiceImpl implements OrderService {

    @Override
    public void createOrder() {
        System.out.println("创建订单");
    }
}

代理类：

public class OrderServiceProxy implements OrderService {

    private final OrderService target;

    public OrderServiceProxy(OrderService target) {
        this.target = target;
    }

    @Override
    public void createOrder() {

        long start = System.currentTimeMillis();

        System.out.println("开始创建订单");

        target.createOrder();

        long cost = System.currentTimeMillis() - start;

        System.out.println("方法耗时：" + cost + "ms");
    }
}

使用：

public class Main {

    public static void main(String[] args) {

        OrderService target = new OrderServiceImpl();

        OrderService proxy = new OrderServiceProxy(target);

        proxy.createOrder();
    }
}

输出：

开始创建订单
创建订单
方法耗时：1ms

静态代理本身没有问题，但它有一个明显缺点：

每代理一个接口，通常都需要手动写一个代理类。

假如项目中有：

OrderService
UserService
ProductService
PaymentService

就需要分别创建：

OrderServiceProxy
UserServiceProxy
ProductServiceProxy
PaymentServiceProxy

这些代理类的逻辑可能都一样，只是目标对象不同。

动态代理解决的就是这个问题：

不再手动为每个目标对象编写代理类，而是在程序运行时自动生成代理对象。

三、JDK 动态代理

JDK 动态代理由 Java 标准库提供，核心类是：

java.lang.reflect.Proxy
java.lang.reflect.InvocationHandler

它有一个重要限制：

被代理的目标类必须实现接口。

四、JDK 动态代理完整示例

先定义业务接口：

public interface OrderService {

    void createOrder(String productName);

    String queryOrder(Long orderId);
}

实现类：

public class OrderServiceImpl implements OrderService {

    @Override
    public void createOrder(String productName) {
        System.out.println("创建订单，商品：" + productName);
    }

    @Override
    public String queryOrder(Long orderId) {
        System.out.println("查询订单：" + orderId);
        return "ORDER-" + orderId;
    }
}

创建动态代理处理器：

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class LogInvocationHandler implements InvocationHandler {

    private final Object target;

    public LogInvocationHandler(Object target) {
        this.target = target;
    }

    @Override
    public Object invoke(
            Object proxy,
            Method method,
            Object[] args
    ) throws Throwable {

        long start = System.currentTimeMillis();

        System.out.println(
                "开始执行方法：" + method.getName()
        );

        try {

            Object result = method.invoke(target, args);

            System.out.println(
                    "方法执行成功：" + method.getName()
            );

            return result;

        } catch (Exception e) {

            System.out.println(
                    "方法执行失败：" + method.getName()
            );

            throw e;

        } finally {

            long cost =
                    System.currentTimeMillis() - start;

            System.out.println(
                    "方法耗时：" + cost + "ms"
            );
        }
    }
}

创建代理对象：

import java.lang.reflect.Proxy;

public class Main {

    public static void main(String[] args) {

        OrderService target =
                new OrderServiceImpl();

        OrderService proxy =
                (OrderService) Proxy.newProxyInstance(
                        target.getClass().getClassLoader(),
                        target.getClass().getInterfaces(),
                        new LogInvocationHandler(target)
                );

        proxy.createOrder("Java 并发编程");

        String orderNo = proxy.queryOrder(1001L);

        System.out.println("查询结果：" + orderNo);
    }
}

输出：

开始执行方法：createOrder
创建订单，商品：Java 并发编程
方法执行成功：createOrder
方法耗时：1ms

开始执行方法：queryOrder
查询订单：1001
方法执行成功：queryOrder
方法耗时：0ms
查询结果：ORDER-1001

五、Proxy.newProxyInstance 的三个参数

创建代理对象的核心代码是：

Proxy.newProxyInstance(
        classLoader,
        interfaces,
        invocationHandler
);

完整写法：

OrderService proxy =
        (OrderService) Proxy.newProxyInstance(
                target.getClass().getClassLoader(),
                target.getClass().getInterfaces(),
                new LogInvocationHandler(target)
        );

三个参数分别表示什么？

1. ClassLoader

target.getClass().getClassLoader()

代理类也是一个 Java 类。

既然是类，就需要类加载器把它加载进 JVM。

一般直接使用目标类的类加载器即可。

2. interfaces

target.getClass().getInterfaces()

表示代理对象需要实现哪些接口。

目标类：

public class OrderServiceImpl
        implements OrderService

所以生成的代理对象也会实现：

OrderService

调用者最终拿到的是一个实现了 OrderService 接口的代理对象。

3. InvocationHandler

new LogInvocationHandler(target)

它负责处理所有被代理方法的调用。

当执行：

proxy.createOrder("Java");

实际上会进入：

InvocationHandler.invoke(...)

因此可以把 InvocationHandler 理解为：

代理对象所有方法调用的统一入口。

六、InvocationHandler 的三个参数

public Object invoke(
        Object proxy,
        Method method,
        Object[] args
)

proxy

当前生成的代理对象。

一般不需要直接使用它。

特别注意，不要随便在 invoke() 中调用：

proxy.toString();

因为它可能再次进入 invoke()，造成递归调用。

method

当前被调用的方法对象。

例如调用：

proxy.createOrder("Java");

那么：

method.getName()

得到：

createOrder

还可以获取注解、返回值类型和参数信息：

method.getAnnotations();
method.getReturnType();
method.getParameterTypes();

args

当前方法的参数。

例如：

proxy.createOrder("Java");

那么：

args[0]

就是：

Java

七、method.invoke(target, args) 做了什么

这行代码是 JDK 动态代理中真正执行目标方法的地方：

Object result = method.invoke(target, args);

它表示：

使用反射，在目标对象 target 上调用当前 method，并把 args 作为参数传进去。

例如当前调用的是：

proxy.createOrder("Java");

最终相当于执行：

target.createOrder("Java");

只不过这里通过反射完成。

完整流程是：

调用 proxy.createOrder()
        ↓
进入 InvocationHandler.invoke()
        ↓
执行前置增强
        ↓
method.invoke(target, args)
        ↓
执行 OrderServiceImpl.createOrder()
        ↓
执行后置增强
        ↓
返回结果

八、封装通用的 JDK 代理工厂

为了避免每次都写 Proxy.newProxyInstance()，可以封装一个代理工厂。

import java.lang.reflect.Proxy;

public class JdkProxyFactory {

    private final Object target;

    public JdkProxyFactory(Object target) {
        this.target = target;
    }

    public Object getProxy() {

        return Proxy.newProxyInstance(
                target.getClass().getClassLoader(),
                target.getClass().getInterfaces(),
                new LogInvocationHandler(target)
        );
    }
}

使用：

public class Main {

    public static void main(String[] args) {

        OrderService target =
                new OrderServiceImpl();

        OrderService proxy =
                (OrderService) new JdkProxyFactory(target)
                        .getProxy();

        proxy.createOrder("MySQL 实战");
    }
}

使用泛型进一步优化：

import java.lang.reflect.Proxy;

public class JdkProxyFactory {

    @SuppressWarnings("unchecked")
    public static <T> T createProxy(T target) {

        return (T) Proxy.newProxyInstance(
                target.getClass().getClassLoader(),
                target.getClass().getInterfaces(),
                new LogInvocationHandler(target)
        );
    }
}

调用：

OrderService proxy =
        JdkProxyFactory.createProxy(
                new OrderServiceImpl()
        );

proxy.createOrder("Spring Boot");

九、CGLIB 动态代理

JDK 动态代理要求目标类必须实现接口。

但有些类没有接口：

public class ProductService {

    public void queryProduct() {
        System.out.println("查询商品");
    }
}

这时无法直接使用 JDK 动态代理。

CGLIB 的解决方案是：

动态创建目标类的子类，通过重写父类方法实现代理。

原来的类：

ProductService

CGLIB 运行时大致生成：

public class ProductServiceProxy
        extends ProductService {

    @Override
    public void queryProduct() {
        // 代理逻辑
    }
}

所以 CGLIB 不要求目标类实现接口。

十、CGLIB 依赖

现代 Spring 项目中一般已经包含 CGLIB 相关能力。

单独演示时，可以使用 Spring 提供的 CGLIB 包：

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
</dependency>

使用的类通常位于：

org.springframework.cglib.proxy.Enhancer
org.springframework.cglib.proxy.MethodInterceptor
org.springframework.cglib.proxy.MethodProxy

十一、CGLIB 动态代理完整示例

目标类不实现任何接口：

public class ProductService {

    public void createProduct(String productName) {
        System.out.println("创建商品：" + productName);
    }

    public String queryProduct(Long productId) {
        System.out.println("查询商品：" + productId);
        return "PRODUCT-" + productId;
    }
}

创建 CGLIB 方法拦截器：

import org.springframework.cglib.proxy.MethodInterceptor;
import org.springframework.cglib.proxy.MethodProxy;

import java.lang.reflect.Method;

public class LogMethodInterceptor
        implements MethodInterceptor {

    @Override
    public Object intercept(
            Object proxy,
            Method method,
            Object[] args,
            MethodProxy methodProxy
    ) throws Throwable {

        long start = System.currentTimeMillis();

        System.out.println(
                "开始执行方法：" + method.getName()
        );

        try {

            Object result =
                    methodProxy.invokeSuper(proxy, args);

            System.out.println(
                    "方法执行成功：" + method.getName()
            );

            return result;

        } catch (Exception e) {

            System.out.println(
                    "方法执行失败：" + method.getName()
            );

            throw e;

        } finally {

            long cost =
                    System.currentTimeMillis() - start;

            System.out.println(
                    "方法耗时：" + cost + "ms"
            );
        }
    }
}

创建代理对象：

import org.springframework.cglib.proxy.Enhancer;

public class CglibProxyFactory {

    @SuppressWarnings("unchecked")
    public static <T> T createProxy(
            Class<T> targetClass
    ) {

        Enhancer enhancer = new Enhancer();

        enhancer.setSuperclass(targetClass);

        enhancer.setCallback(
                new LogMethodInterceptor()
        );

        return (T) enhancer.create();
    }
}

使用：

public class Main {

    public static void main(String[] args) {

        ProductService proxy =
                CglibProxyFactory.createProxy(
                        ProductService.class
                );

        proxy.createProduct("机械键盘");

        String productNo =
                proxy.queryProduct(1001L);

        System.out.println(productNo);
    }
}

输出：

开始执行方法：createProduct
创建商品：机械键盘
方法执行成功：createProduct
方法耗时：1ms

开始执行方法：queryProduct
查询商品：1001
方法执行成功：queryProduct
方法耗时：0ms
PRODUCT-1001

十二、CGLIB 的执行流程

当调用：

proxy.queryProduct(1001L);

执行流程大致是：

调用 CGLIB 生成的子类对象
        ↓
进入 MethodInterceptor.intercept()
        ↓
执行前置增强
        ↓
调用父类原方法
        ↓
执行后置增强
        ↓
返回结果

核心代码：

methodProxy.invokeSuper(proxy, args);

它表示：

调用代理对象父类中的原始方法。

因为代理对象本身就是目标类的子类，所以可以调用父类实现。

十三、为什么使用 invokeSuper，而不是 method.invoke

CGLIB 中推荐使用：

methodProxy.invokeSuper(proxy, args);

而不是：

method.invoke(proxy, args);

因为 proxy 本身是代理对象。

如果执行：

method.invoke(proxy, args);

可能再次调用代理对象的方法，再次进入 intercept()，最终形成递归调用。

正确方式是：

methodProxy.invokeSuper(proxy, args);

直接执行父类原始方法。

十四、带构造参数的 CGLIB 代理

如果目标类没有无参构造方法：

public class ProductService {

    private final String tenantId;

    public ProductService(String tenantId) {
        this.tenantId = tenantId;
    }

    public void queryProduct() {
        System.out.println(
                tenantId + " 查询商品"
        );
    }
}

直接调用：

enhancer.create();

会失败，因为 CGLIB 创建子类对象时需要调用父类构造方法。

需要传入构造参数：

ProductService proxy =
        (ProductService) enhancer.create(
                new Class[]{String.class},
                new Object[]{"tenant-1001"}
        );

完整代码：

Enhancer enhancer = new Enhancer();

enhancer.setSuperclass(ProductService.class);

enhancer.setCallback(
        new LogMethodInterceptor()
);

ProductService proxy =
        (ProductService) enhancer.create(
                new Class[]{String.class},
                new Object[]{"tenant-1001"}
        );

十五、JDK 动态代理和 CGLIB 的核心区别

可以这样记：

JDK 动态代理是“实现接口”，CGLIB 动态代理是“继承目标类”。

十六、为什么 CGLIB 不能代理 final 类

CGLIB 的原理是继承目标类：

class ProxyClass extends TargetClass {
}

如果目标类是：

public final class ProductService {
}

Java 不允许其他类继承它。

因此 CGLIB 无法创建：

class ProductServiceProxy
        extends ProductService

同理，如果方法是：

public final void queryProduct() {
}

子类不能重写这个方法，所以 CGLIB 也无法对它进行增强。

十七、业务示例：统一记录接口耗时

假设系统中有多个业务服务：

public interface UserService {

    void createUser(String username);

    String getUser(Long userId);
}

实现类：

public class UserServiceImpl
        implements UserService {

    @Override
    public void createUser(String username) {
        System.out.println("创建用户：" + username);
    }

    @Override
    public String getUser(Long userId) {
        System.out.println("查询用户：" + userId);
        return "user-" + userId;
    }
}

定义通用耗时代理：

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class PerformanceInvocationHandler
        implements InvocationHandler {

    private final Object target;

    public PerformanceInvocationHandler(
            Object target
    ) {
        this.target = target;
    }

    @Override
    public Object invoke(
            Object proxy,
            Method method,
            Object[] args
    ) throws Throwable {

        long start = System.nanoTime();

        try {

            return method.invoke(target, args);

        } finally {

            long cost =
                    System.nanoTime() - start;

            System.out.printf(
                    "%s.%s 执行耗时：%.3f ms%n",
                    target.getClass().getSimpleName(),
                    method.getName(),
                    cost / 1_000_000.0
            );
        }
    }
}

代理工厂：

import java.lang.reflect.Proxy;

public class PerformanceProxyFactory {

    @SuppressWarnings("unchecked")
    public static <T> T create(T target) {

        return (T) Proxy.newProxyInstance(
                target.getClass().getClassLoader(),
                target.getClass().getInterfaces(),
                new PerformanceInvocationHandler(target)
        );
    }
}

使用：

UserService userService =
        PerformanceProxyFactory.create(
                new UserServiceImpl()
        );

userService.createUser("zhangsan");

userService.getUser(1001L);

以后其他实现了接口的服务，也可以直接使用同一个代理工厂：

OrderService orderService =
        PerformanceProxyFactory.create(
                new OrderServiceImpl()
        );

这就是动态代理相对静态代理的价值：

一套代理逻辑可以复用到多个不同的目标对象上。

十八、业务示例：接口额度校验

假设查询接口执行前，需要检查用户剩余额度。

业务接口：

public interface ReportService {

    String generateReport(Long userId);
}

实现类：

public class ReportServiceImpl
        implements ReportService {

    @Override
    public String generateReport(Long userId) {

        System.out.println("生成数据报告");

        return "report-success";
    }
}

额度服务：

public class QuotaService {

    public boolean hasQuota(Long userId) {
        return userId != null && userId > 0;
    }

    public void consume(Long userId) {
        System.out.println(
                "用户 " + userId + " 扣减一次额度"
        );
    }
}

代理处理器：

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class QuotaInvocationHandler
        implements InvocationHandler {

    private final Object target;

    private final QuotaService quotaService;

    public QuotaInvocationHandler(
            Object target,
            QuotaService quotaService
    ) {
        this.target = target;
        this.quotaService = quotaService;
    }

    @Override
    public Object invoke(
            Object proxy,
            Method method,
            Object[] args
    ) throws Throwable {

        Long userId = (Long) args[0];

        if (!quotaService.hasQuota(userId)) {
            throw new RuntimeException(
                    "用户额度不足"
            );
        }

        Object result =
                method.invoke(target, args);

        quotaService.consume(userId);

        return result;
    }
}

创建代理：

ReportService target =
        new ReportServiceImpl();

QuotaService quotaService =
        new QuotaService();

ReportService proxy =
        (ReportService) Proxy.newProxyInstance(
                target.getClass().getClassLoader(),
                target.getClass().getInterfaces(),
                new QuotaInvocationHandler(
                        target,
                        quotaService
                )
        );

调用：

String result =
        proxy.generateReport(1001L);

System.out.println(result);

执行流程：

检查额度
    ↓
执行报告查询
    ↓
查询成功
    ↓
扣减额度

这和我们在 Spring AOP 中编写的 @Around 切面非常相似。

十九、动态代理与 Spring AOP 的关系

Spring AOP 本质上就是基于代理实现的。

假设我们写了一个切面：

@Around("@annotation(apiLog)")
public Object around(
        ProceedingJoinPoint joinPoint,
        ApiLog apiLog
) throws Throwable {

    System.out.println("执行前");

    Object result = joinPoint.proceed();

    System.out.println("执行后");

    return result;
}

表面上看，是 Spring 自动拦截了业务方法。

底层实际上可以理解为：

Spring 创建业务 Bean
        ↓
Spring 为业务 Bean 创建代理对象
        ↓
容器中保存的是代理对象
        ↓
调用代理对象的方法
        ↓
进入切面
        ↓
调用目标方法

例如：

@Service
public class UserServiceImpl
        implements UserService {
}

注入：

@Resource
private UserService userService;

这里注入的 userService 很可能不是原始的 UserServiceImpl，而是 Spring 创建的代理对象。

二十、Spring 如何选择 JDK 和 CGLIB

通常可以这样理解：

目标类实现了接口

Spring 可以使用 JDK 动态代理：

代理对象实现目标接口

目标类没有实现接口

Spring 使用 CGLIB：

代理对象继承目标类

在 Spring Boot 中，也可以通过配置影响代理方式：

spring:
  aop:
    proxy-target-class: true

true 表示优先使用基于类的代理，也就是 CGLIB 代理。

不过具体行为还会受到 Spring 版本、代理配置和目标类特征等因素影响。

二十一、为什么同类内部调用会导致 AOP 失效

这是 Spring AOP 中非常常见的问题。

例如：

@Service
public class OrderService {

    public void createOrder() {
        this.saveOrder();
    }

    @Transactional
    public void saveOrder() {
        System.out.println("保存订单");
    }
}

外部调用：

orderService.createOrder();

执行 createOrder() 时，会进入代理对象。

但是在 createOrder() 内部：

this.saveOrder();

这里的 this 指向的是目标对象本身，不是代理对象。

调用关系变成：

代理对象.createOrder()
        ↓
目标对象.createOrder()
        ↓
目标对象.this.saveOrder()

saveOrder() 没有再次经过代理对象，所以事务、日志、缓存等切面可能不会生效。

正确的代理调用流程应该是：

调用者
  ↓
代理对象
  ↓
切面逻辑
  ↓
目标方法

而 this.xxx() 绕过了代理对象。

常见解决方法有：

把被调用方法拆到另一个 Bean
通过代理对象调用
重新设计业务边界

最推荐的是拆分到另一个 Bean：

@Service
@RequiredArgsConstructor
public class OrderService {

    private final OrderPersistenceService
            orderPersistenceService;

    public void createOrder() {
        orderPersistenceService.saveOrder();
    }
}

@Service
public class OrderPersistenceService {

    @Transactional
    public void saveOrder() {
        System.out.println("保存订单");
    }
}

二十二、异常处理中的一个细节

JDK 动态代理中常见写法：

method.invoke(target, args);

如果目标方法抛出异常，反射会把原异常包装成：

InvocationTargetException

可以把真实异常取出来：

try {

    return method.invoke(target, args);

} catch (InvocationTargetException e) {

    throw e.getTargetException();
}

完整写法：

@Override
public Object invoke(
        Object proxy,
        Method method,
        Object[] args
) throws Throwable {

    try {

        return method.invoke(target, args);

    } catch (InvocationTargetException e) {

        throw e.getTargetException();
    }
}

这样调用者拿到的是业务方法本身抛出的异常，而不是反射包装异常。

二十三、动态代理适合解决什么问题

动态代理适合处理横跨多个业务模块的通用逻辑。

例如：

日志记录
权限校验
事务管理
接口耗时统计
缓存处理
接口额度校验
统一异常处理
审计记录
重试机制
数据权限

这些逻辑的共同特点是：

它们不是某一个具体业务的核心，但很多业务方法都需要使用。

例如订单创建方法的核心应该是：

创建订单

而不是：

检查权限
记录日志
开启事务
统计耗时
提交事务
发送监控指标

动态代理可以把这些通用逻辑从业务代码中抽离出来。

二十四、动态代理不适合解决什么问题

代理不是所有问题都应该使用。

如果逻辑只属于某个具体方法，例如：

订单价格计算
商品库存判断
用户等级计算
报告数据组装

这些属于业务本身，不应该为了“解耦”而全部放进代理。

代理更适合：

通用、重复、横跨多个模块的逻辑

不适合：

和具体业务强相关的核心逻辑

二十五、JDK 动态代理和 CGLIB 怎么选择

如果自己编写动态代理，可以按照下面的方式选择。

有接口，且面向接口编程

优先考虑 JDK 动态代理：

public class UserServiceImpl
        implements UserService

优点是结构清晰，调用者依赖接口。

没有接口

使用 CGLIB：

public class ProductService {
}

CGLIB 可以直接创建目标类的子类。

使用 Spring AOP

大部分情况下不需要手动选择。

交给 Spring 创建代理即可。

开发者更需要关注的是：

方法是否被 Spring Bean 管理
调用是否经过代理对象
方法是否可以被代理
是否存在同类内部调用
final 方法是否阻止 CGLIB 增强

二十六、总结

代理模式的核心是：

在不修改目标类代码的前提下，通过代理对象对目标方法进行增强。

静态代理需要手动编写代理类：

一个目标类型对应一个代理类

动态代理则是在运行时自动创建代理对象：

一套代理逻辑可以复用到多个目标对象

JDK 动态代理的核心：

目标类实现接口
Proxy.newProxyInstance()
InvocationHandler.invoke()
Method.invoke()

CGLIB 动态代理的核心：

创建目标类的子类
Enhancer
MethodInterceptor.intercept()
MethodProxy.invokeSuper()

两者最核心的区别可以记成一句话：

JDK 动态代理通过实现接口创建代理，CGLIB 通过继承目标类创建代理。

而 Spring AOP 可以理解为：

Spring 自动帮我们创建代理对象
        ↓
把日志、事务、权限、缓存等通用逻辑
织入目标方法的执行过程

当我们真正理解 JDK 动态代理和 CGLIB 后，再看 Spring AOP、@Transactional、@Async、缓存注解和自定义切面，就不会只停留在“加一个注解就能生效”的层面，而是能够理解它们背后的代理调用过程。

统计某个用户、接口、商品或任务被访问了多少次。

例如：

接口 A 被访问了 100 次
接口 B 被访问了 35 次
接口 C 被访问了 8 次

如果是单线程程序，直接使用 HashMap<String, Integer> 就可以。

但在多线程环境下，这种写法会有线程安全问题：

Map<String, Integer> counter = new HashMap<>();

counter.put("api:user:list",
        counter.getOrDefault("api:user:list", 0) + 1);

原因是：

读取旧值
加 1
写回新值

这三个步骤并不是原子操作。

多个线程同时执行时，可能发生计数丢失。

这时就可以使用：

ConcurrentHashMap + LongAdder

一、为什么使用 ConcurrentHashMap

ConcurrentHashMap 是线程安全的 Map。

它适合多个线程同时进行：

put
get
remove
computeIfAbsent

例如：

ConcurrentHashMap<String, LongAdder> counter =
        new ConcurrentHashMap<>();

这里：

Key：业务标识
Value：计数器

例如：

api:user:list      -> 计数器
api:order:create   -> 计数器
api:product:detail -> 计数器

ConcurrentHashMap 负责保证多个线程操作 Map 时的安全。

但它只解决了 Map 本身的并发问题，并不代表 Value 的累加操作天然安全。

二、为什么使用 LongAdder

LongAdder 是 Java 提供的并发计数器。

基本用法：

LongAdder adder = new LongAdder();

adder.increment();
adder.increment();

System.out.println(adder.sum());

输出：

2

常用方法：

adder.increment();      // 加 1
adder.decrement();      // 减 1
adder.add(10);          // 加 10
adder.sum();            // 获取当前值
adder.reset();          // 重置为 0
adder.sumThenReset();   // 获取值并重置

三、ConcurrentHashMap 和 LongAdder 怎么配合

最常见的写法是：

ConcurrentHashMap<String, LongAdder> counter =
        new ConcurrentHashMap<>();

counter
        .computeIfAbsent("api:user:list", key -> new LongAdder())
        .increment();

这段代码可以拆成两步理解。

第一步：

counter.computeIfAbsent(
        "api:user:list",
        key -> new LongAdder()
);

表示：

如果 Map 中已经有这个 Key，就返回原来的 LongAdder；如果没有，就创建一个新的 LongAdder 放进去。

第二步：

.increment();

表示让这个计数器加 1。

所以完整逻辑就是：

根据 Key 找到计数器
        ↓
不存在就创建
        ↓
计数器加 1

四、完整示例：接口访问次数统计

import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.LongAdder;

public class ApiAccessCounter {

    private final ConcurrentHashMap<String, LongAdder> counterMap =
            new ConcurrentHashMap<>();

    /**
     * 增加接口访问次数
     */
    public void increment(String apiCode) {
        counterMap
                .computeIfAbsent(apiCode, key -> new LongAdder())
                .increment();
    }

    /**
     * 获取某个接口的访问次数
     */
    public long getCount(String apiCode) {
        LongAdder adder = counterMap.get(apiCode);

        if (adder == null) {
            return 0;
        }

        return adder.sum();
    }

    /**
     * 获取所有接口访问次数
     */
    public Map<String, Long> getAllCount() {
        Map<String, Long> result = new ConcurrentHashMap<>();

        counterMap.forEach((apiCode, adder) ->
                result.put(apiCode, adder.sum())
        );

        return result;
    }

    /**
     * 清除某个接口的计数
     */
    public void remove(String apiCode) {
        counterMap.remove(apiCode);
    }

    /**
     * 清空所有计数
     */
    public void clear() {
        counterMap.clear();
    }
}

使用：

public class Main {

    public static void main(String[] args) {

        ApiAccessCounter counter = new ApiAccessCounter();

        counter.increment("user_list");
        counter.increment("user_list");
        counter.increment("order_create");

        System.out.println(counter.getCount("user_list"));
        System.out.println(counter.getCount("order_create"));
        System.out.println(counter.getAllCount());
    }
}

输出：

2
1
{user_list=2, order_create=1}

五、多线程测试

下面模拟 10 个线程，每个线程对同一个接口计数 10 万次。

理论结果应该是：

10 × 100000 = 1000000

代码：

import java.util.concurrent.CountDownLatch;

public class ConcurrentTest {

    public static void main(String[] args) throws InterruptedException {

        ApiAccessCounter counter = new ApiAccessCounter();

        int threadCount = 10;
        int loopCount = 100_000;

        CountDownLatch latch =
                new CountDownLatch(threadCount);

        for (int i = 0; i < threadCount; i++) {

            new Thread(() -> {

                try {
                    for (int j = 0; j < loopCount; j++) {
                        counter.increment("api:user:list");
                    }
                } finally {
                    latch.countDown();
                }

            }).start();
        }

        latch.await();

        System.out.println(
                counter.getCount("api:user:list")
        );
    }
}

输出：

1000000

这说明在多个线程同时累加时，计数结果没有丢失。

六、为什么不用 Integer

有些人可能会这样写：

ConcurrentHashMap<String, Integer> counterMap =
        new ConcurrentHashMap<>();

然后：

counterMap.put(
        apiCode,
        counterMap.getOrDefault(apiCode, 0) + 1
);

虽然 ConcurrentHashMap 本身是线程安全的，但这一整段代码并不是原子操作。

它实际上包含：

get
加 1
put

例如两个线程同时读取到：

10

线程 A 计算：

10 + 1 = 11

线程 B 也计算：

10 + 1 = 11

最后两个线程都写入 11。

正确结果本来应该是：

12

实际结果却是：

11

这就是并发计数丢失。

当然，也可以使用：

counterMap.merge(apiCode, 1, Integer::sum);

例如：

counterMap.merge(apiCode, 1, Integer::sum);

这个写法是线程安全的。

但在高并发计数场景中，LongAdder 通常更合适。

七、为什么不用 AtomicLong

也可以这样写：

ConcurrentHashMap<String, AtomicLong> counterMap =
        new ConcurrentHashMap<>();

counterMap
        .computeIfAbsent(
                apiCode,
                key -> new AtomicLong()
        )
        .incrementAndGet();

AtomicLong 也是线程安全的计数器。

那么它和 LongAdder 有什么区别？

AtomicLong

AtomicLong 内部维护一个值。

多个线程同时修改这个值时，会通过 CAS 不断竞争。

多个线程
   ↓
竞争同一个变量

竞争不激烈时，性能很好。

LongAdder

LongAdder 在竞争激烈时，会把一个计数拆成多个计数单元。

不同线程可以更新不同单元。

最后调用：

sum()

时，再把多个单元相加。

可以理解为：

线程1 -> 单元1
线程2 -> 单元2
线程3 -> 单元3
线程4 -> 单元4

最后汇总

因此，高并发写入场景下，LongAdder 通常比 AtomicLong 更高效。

八、LongAdder 的注意事项

1. sum() 不一定是绝对瞬时值

long count = adder.sum();

sum() 会汇总当前各个计数单元。

但如果其他线程正在同时执行 increment()，这个值不一定代表某个绝对精确时间点的快照。

因此，LongAdder 更适合：

统计
监控
访问次数
请求次数
日志数量
指标累加

不太适合要求强一致性的业务。

例如：

账户余额
库存扣减
额度扣减
支付金额

这些场景不能只依赖 LongAdder。

2. LongAdder 不适合条件判断后扣减

例如下面这种业务：

剩余额度大于 0 才允许访问
访问后额度减 1

如果写成：

if (adder.sum() < limit) {
    adder.increment();
}

这不是线程安全的整体操作。

因为：

判断
累加

是两个步骤。

多个线程可能同时判断成功，然后一起累加，最终超过限制。

所以 LongAdder 更适合做统计，不适合做严格限流和额度控制。

严格限流通常需要：

AtomicLong
synchronized
Lock
Redis Lua
数据库乐观锁
Semaphore

3. Map 中的 Key 可能越来越多

例如按照用户 ID 计数：

counter.increment("user:" + userId);

如果用户数量持续增长，ConcurrentHashMap 中的数据也会越来越多。

需要考虑：

定时清理
设置过期时间
定期持久化
按时间窗口重建 Map

ConcurrentHashMap 本身不支持过期时间。

如果需要自动过期，可以考虑：

Caffeine
Redis
Guava Cache

九、Spring Boot 中使用

在 Spring Boot 中，可以把计数器注册为单例 Bean。

import org.springframework.stereotype.Component;

import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.LongAdder;

@Component
public class ApiCounter {

    private final ConcurrentHashMap<String, LongAdder> counterMap =
            new ConcurrentHashMap<>();

    public void increment(String apiCode) {
        counterMap
                .computeIfAbsent(apiCode, key -> new LongAdder())
                .increment();
    }

    public long getCount(String apiCode) {
        LongAdder adder = counterMap.get(apiCode);
        return adder == null ? 0 : adder.sum();
    }
}

Controller 中使用：

import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequiredArgsConstructor
public class UserController {

    private final ApiCounter apiCounter;

    @GetMapping("/user/list")
    public String list() {

        apiCounter.increment("user_list");

        return "success";
    }

    @GetMapping("/user/list/count")
    public long count() {
        return apiCounter.getCount("user_list");
    }
}

因为 ApiCounter 是 Spring 单例 Bean，所以所有请求共享同一个：

ConcurrentHashMap<String, LongAdder>

不会每次请求都创建一个新的计数器。

十、按用户和接口统计

如果需要统计：

某个用户访问某个接口多少次

可以把用户 ID 和接口编码组合成 Key。

public void increment(Long userId, String apiCode) {

    String key = userId + ":" + apiCode;

    counterMap
            .computeIfAbsent(
                    key,
                    value -> new LongAdder()
            )
            .increment();
}

例如：

1001:user_list
1001:order_create
1002:user_list

完整示例：

@Component
public class UserApiCounter {

    private final ConcurrentHashMap<String, LongAdder> counterMap =
            new ConcurrentHashMap<>();

    public void increment(Long userId, String apiCode) {

        String key = buildKey(userId, apiCode);

        counterMap
                .computeIfAbsent(
                        key,
                        value -> new LongAdder()
                )
                .increment();
    }

    public long getCount(Long userId, String apiCode) {

        String key = buildKey(userId, apiCode);

        LongAdder adder = counterMap.get(key);

        return adder == null ? 0 : adder.sum();
    }

    private String buildKey(Long userId, String apiCode) {
        return userId + ":" + apiCode;
    }
}

十一、按天统计接口访问量

如果要按天统计，可以把日期加入 Key。

import java.time.LocalDate;

public void increment(String apiCode) {

    String key = apiCode + ":" + LocalDate.now();

    counterMap
            .computeIfAbsent(
                    key,
                    value -> new LongAdder()
            )
            .increment();
}

生成的 Key 类似：

user_list:2026-08-04
order_create:2026-08-04

不过这种方式要注意定期清理历史日期数据。

十二、一个更完整的统计服务

import org.springframework.stereotype.Service;

import java.time.LocalDate;
import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.LongAdder;

@Service
public class ApiStatisticsService {

    private final ConcurrentHashMap<String, LongAdder> counterMap =
            new ConcurrentHashMap<>();

    public void increment(String apiCode) {

        String key = buildKey(apiCode, LocalDate.now());

        counterMap
                .computeIfAbsent(
                        key,
                        value -> new LongAdder()
                )
                .increment();
    }

    public long getTodayCount(String apiCode) {

        String key = buildKey(apiCode, LocalDate.now());

        LongAdder adder = counterMap.get(key);

        return adder == null ? 0 : adder.sum();
    }

    public Map<String, Long> getAllStatistics() {

        Map<String, Long> result = new HashMap<>();

        counterMap.forEach((key, adder) ->
                result.put(key, adder.sum())
        );

        return result;
    }

    public long getAndReset(String apiCode) {

        String key = buildKey(apiCode, LocalDate.now());

        LongAdder adder = counterMap.get(key);

        if (adder == null) {
            return 0;
        }

        return adder.sumThenReset();
    }

    public void remove(String apiCode, LocalDate date) {
        counterMap.remove(buildKey(apiCode, date));
    }

    private String buildKey(
            String apiCode,
            LocalDate date
    ) {
        return apiCode + ":" + date;
    }
}

十三、适用场景

ConcurrentHashMap + LongAdder 比较适合：

接口访问次数统计
商品浏览次数统计
异常出现次数统计
任务执行次数统计
不同状态数量统计
日志级别数量统计
在线请求指标统计
本地缓存命中次数统计

例如：

counterMap
        .computeIfAbsent(
                "cache_hit",
                key -> new LongAdder()
        )
        .increment();

或者：

counterMap
        .computeIfAbsent(
                exception.getClass().getSimpleName(),
                key -> new LongAdder()
        )
        .increment();

十四、不适用场景

它不适合：

分布式计数
严格库存扣减
账户余额计算
支付金额计算
强一致额度控制
跨服务器共享状态

因为这个 Map 只存在当前 JVM 内存中。

如果应用部署了三台服务器：

服务器 A：100 次
服务器 B：80 次
服务器 C：60 次

每台服务器都有自己的计数器。

它们不会自动合并。

分布式环境中，可以考虑：

Redis INCR
Redis Hash
消息队列
数据库原子更新
Prometheus Metrics

十五、总结

ConcurrentHashMap 和 LongAdder 的职责不同。

ConcurrentHashMap 负责：

保证多个线程安全地访问 Map

LongAdder 负责：

保证多个线程高效地进行计数

最常见的组合写法是：

counterMap
        .computeIfAbsent(
                key,
                value -> new LongAdder()
        )
        .increment();

可以记成一句话：

ConcurrentHashMap 管理多个计数器，LongAdder 负责每个计数器的并发累加。

在单机高并发统计场景中，这是一种简单、实用而且性能很好的实现方式。

• Semaphore（信号量）
• CountDownLatch（倒计数器）
• CyclicBarrier（循环栅栏）

它们都属于 java.util.concurrent 包，但解决的问题完全不同。

一、Semaphore（信号量）

作用

控制同时访问某个资源的线程数量。

可以把它理解成一个门卫，只有拿到许可证（Permit）的线程才能进入，许可证用完后，其余线程只能等待。

一句话：控制并发数量。

使用场景

• 数据库连接池
• Redis 连接池
• 外部接口并发限制
• 文件下载并发控制

示例：同时最多允许三个线程执行

import java.util.concurrent.Semaphore;

public class SemaphoreDemo {

    private static final Semaphore semaphore = new Semaphore(3);

    public static void main(String[] args) {

        for (int i = 1; i <= 10; i++) {
            final int num = i;

            new Thread(() -> {
                try {
                    semaphore.acquire();

                    System.out.println("线程" + num + "开始执行");
                    Thread.sleep(2000);
                    System.out.println("线程" + num + "执行结束");

                } catch (Exception e) {
                    e.printStackTrace();
                } finally {
                    semaphore.release();
                }
            }).start();
        }
    }
}

运行过程中，无论启动多少线程，同时真正执行的始终只有 3 个。

二、CountDownLatch（倒计数器）

作用

让一个或多个线程等待其他线程执行完成。

它内部维护一个计数器，每完成一个任务就减一，当计数变成 0 时，等待线程继续执行。

一句话：主线程等子线程。

使用场景

• Spring Boot 初始化
• 多线程加载缓存
• 多线程统计结果
• 并行任务汇总

示例：主线程等待三个子线程完成

import java.util.concurrent.CountDownLatch;

public class CountDownLatchDemo {

    public static void main(String[] args) throws Exception {

        CountDownLatch latch = new CountDownLatch(3);

        for (int i = 1; i <= 3; i++) {

            final int num = i;

            new Thread(() -> {

                System.out.println("线程" + num + "开始工作");

                try {
                    Thread.sleep(2000);
                } catch (InterruptedException ignored) {
                }

                System.out.println("线程" + num + "工作完成");

                latch.countDown();

            }).start();
        }

        System.out.println("主线程等待...");

        latch.await();

        System.out.println("所有线程执行完成，主线程继续");
    }
}

这里真正等待的是主线程，而三个工作线程完成任务后并不会互相等待。

三、CyclicBarrier（循环栅栏）

作用

让一组线程互相等待，直到所有线程都到达同一个位置，再一起继续执行。

一句话：大家一起出发。

使用场景

• 分阶段并行计算
• 多线程数据处理
• 游戏等待所有玩家准备
• 多线程批量导入

示例：三个人一起爬山

import java.util.concurrent.CyclicBarrier;

public class CyclicBarrierDemo {

    public static void main(String[] args) {

        CyclicBarrier barrier = new CyclicBarrier(3,
                () -> System.out.println("所有人到齐，继续前进"));

        for (int i = 1; i <= 3; i++) {

            final int num = i;

            new Thread(() -> {

                try {

                    System.out.println("队员" + num + "开始出发");

                    Thread.sleep(num * 1000);

                    System.out.println("队员" + num + "到达集合点");

                    barrier.await();

                    System.out.println("队员" + num + "继续前进");

                } catch (Exception e) {
                    e.printStackTrace();
                }

            }).start();
        }
    }
}

谁先到集合点，谁就等待；直到三个人全部到达后，再一起继续前进。

三者区别

总结

如果把三者比作生活中的场景：

• Semaphore：厕所只有 3 个坑位，同时最多进去 3 个人。
• CountDownLatch：老师等待所有学生交卷后才能收卷。
• CyclicBarrier：几个人约好一起爬山，每到一个集合点，都必须等所有人到齐再继续出发。

真正理解它们的关键，不是记 API，而是记住它们分别解决了三类不同的线程协作问题：

• Semaphore：控制数量
• CountDownLatch：等待完成
• CyclicBarrier：一起继续

public interface UserMapper extends BaseMapper<UserEntity> {

    @Select("SELECT * FROM sys_user WHERE username = #{username}")
    UserEntity selectByUsername(String username);
}

2. 参数建议使用 @Param

@Select("SELECT * FROM sys_user WHERE username = #{username}")
UserEntity selectByUsername(@Param("username") String username);

3. 参数是实体对象

Mapper：

int insertCustom(UserEntity user);

XML：

<insert id="insertCustom">
    INSERT INTO sys_user(username, status)
    VALUES (#{username}, #{status})
</insert>

单个实体参数，不需要写 #{user.username}。

4. 实体参数加 @Param

Mapper：

int insertCustom(@Param("user") UserEntity user);

XML：

<insert id="insertCustom">
    INSERT INTO sys_user(username, status)
    VALUES (#{user.username}, #{user.status})
</insert>

因为参数命名为 user，所以需要：

user.username
user.status

5. #{} 与 ${}

#{}

• 参数占位
• 自动处理参数类型
• 字符串无需自己加引号
• 可以防止 SQL 注入
• 日常开发推荐使用

${}

• 字符串直接拼接
• 存在 SQL 注入风险
• 谨慎使用

6. 动态 SQL

6.1 <if> + <where>

<select id="selectByCondition"
        resultType="org.example.entity.UserEntity">
    SELECT *
    FROM sys_user

    <where>
        <if test="username != null and username != ''">
            username = #{username}
        </if>

        <if test="status != null">
            AND status = #{status}
        </if>
    </where>
</select>

<where> 作用：

• 自动添加 WHERE
• 自动去掉开头多余的 AND

6.2 <set>

<update id="updateUser">
    UPDATE sys_user

    <set>
        <if test="username != null and username != ''">
            username = #{username},
        </if>

        <if test="status != null">
            status = #{status},
        </if>

        <if test="age != null">
            age = #{age},
        </if>
    </set>

    WHERE id = #{id}
</update>

作用：

• 自动添加 SET
• 自动删除最后多余的逗号

注意：

如果所有字段都为空，可能生成：

UPDATE sys_user
WHERE id = ?

属于错误 SQL。

业务层应提前判断：

if (user.getUsername() == null
        && user.getStatus() == null
        && user.getAge() == null) {
    throw new IllegalArgumentException("没有需要更新的字段");
}

6.3 更新必须有 WHERE

必须保证：

WHERE id = #{id}

否则可能出现：

UPDATE sys_user
SET status = 0

导致全表更新。

动态更新时重点检查：

• SET 后是否有字段
• WHERE 条件是否可靠

6.4 <foreach>

<select id="selectByIds"
        resultType="com.example.entity.UserEntity">
    SELECT id, username, status
    FROM sys_user
    WHERE id IN

    <foreach collection="ids"
             item="id"
             open="("
             separator=","
             close=")">
        #{id}
    </foreach>
</select>

常用于：

• IN 查询
• 批量操作

6.5 <choose>

<choose>
    <when test="条件1">
    </when>

    <when test="条件2">
    </when>

    <otherwise>
    </otherwise>
</choose>

等价于：

if (条件1) {

} else if (条件2) {

} else {

}

7. resultMap

复杂查询时可手动指定字段映射：

<resultMap id="userResultMap"
           type="com.example.entity.UserEntity">

    <id column="id" property="id"/>

    <result column="user_name" property="userName"/>

    <result column="user_status" property="status"/>

    <result column="create_time" property="createTime"/>

</resultMap>

8. Generator

package top.xiaolizhi.blog;

import java.net.URI;
import com.baomidou.mybatisplus.generator.FastAutoGenerator;

public class Generator {


    public static void main(String[] args) {
        FastAutoGenerator.create(
                        "jdbc:mysql://127.0.0.1:3306/blog?useSSL=false&serverTimezone=Asia/Shanghai",
                        "root",
                        "root"
                )
                // 全局配置
                .globalConfig(builder -> builder
                        .author("succos")
                        // .outputDir(System.getProperty("user.dir") + "/src/main/java")
                        .outputDir("C:\\Users\\Administrator\\Desktop\\spring-study\\src\\main\\java")
                )

                // 包配置
                .packageConfig(builder -> builder
                        .parent("top.xiaolizhi.blog")
                        .mapper("mapper")
                        .service("service")
                        .serviceImpl("service.impl")
                        .controller("controller")
                        .entity("pojo.entity")
                )

                // 策略
                .strategyConfig(builder -> builder
                        .addInclude("tag") // 表名

                        .entityBuilder()
                        .enableLombok()
                        .enableFileOverride()
                        .formatFileName("%sEntity")

                        .mapperBuilder()
                        .enableFileOverride()

                        .serviceBuilder()
                        .enableFileOverride()

                        .controllerBuilder()
                        .enableRestStyle()
                        .enableFileOverride()
                )

                .execute();
    }
}

9. Mapper 分页

Mapper：

IPage<UserVO> selectUserPage(
        IPage<UserVO> page,
        @Param("username") String username
);

第一个参数：

IPage<UserVO> page

用于接收分页信息。

MyBatis-Plus 会自动生成分页 SQL：

SELECT COUNT(*) ...

查询总数。

SELECT ...
LIMIT ...

查询当前页数据。

XML 中无需再写 LIMIT。

一会儿是 AuthenticationManager，一会儿是 AuthenticationProvider，接着又冒出 UserDetailsService、UserDetails、AuthenticationToken。如果再加上 JWT、短信登录、微信登录和 RBAC，整个流程很容易被绕晕。

后来我发现，理解 Spring Security 不能一开始就背配置，而是要先抓住一条主线：

用户提交登录信息，Spring Security 找到对应的认证方式进行校验，认证成功后保存当前用户身份，后续请求再根据用户拥有的权限决定能否访问接口。

围绕这条主线，很多类就不再是零散的概念了。

一、Spring Security 主要解决什么问题

Spring Security 主要解决两件事：

认证 Authentication
授权 Authorization

认证解决的是：

你是谁？

例如验证：

• 用户名和密码是否正确
• 手机号和验证码是否正确
• 微信授权信息是否有效

授权解决的是：

你能做什么？

例如：

• 能不能新增用户
• 能不能删除菜单
• 能不能查看财务数据
• 能不能进入后台管理页面

因此，一个完整的安全流程可以分成两段：

登录阶段：确认用户身份

访问接口阶段：检查用户权限

二、账号密码登录的完整流程

假设登录接口接收用户名和密码：

@PostMapping("/login")
public String login(@RequestBody LoginRequest request) {

    Authentication authentication =
            authenticationManager.authenticate(
                    UsernamePasswordAuthenticationToken.unauthenticated(
                            request.getUsername(),
                            request.getPassword()
                    )
            );

    return jwtService.generateToken(authentication);
}

这里最重要的不是 JWT，而是下面这段：

authenticationManager.authenticate(
        UsernamePasswordAuthenticationToken.unauthenticated(
                username,
                password
        )
);

完整流程如下：

Controller
    ↓
创建 UsernamePasswordAuthenticationToken
    ↓
AuthenticationManager
    ↓
ProviderManager
    ↓
DaoAuthenticationProvider
    ↓
UserDetailsService
    ↓
查询数据库用户
    ↓
PasswordEncoder 校验密码
    ↓
返回认证成功的 Authentication

三、AuthenticationToken 是什么

下面这段代码：

new UsernamePasswordAuthenticationToken(username, password)

并不是在执行登录。

它只是创建了一个认证对象，用来表示：

这是一次用户名密码认证请求。

认证前，这个对象中大致保存：

principal   = 用户名
credentials = 密码
authenticated = false

可以把它理解成一张登录申请单：

申请人：张三
认证材料：密码
认证方式：用户名密码

真正触发认证的是：

authenticationManager.authenticate(token);

所以：

AuthenticationToken：描述本次使用什么方式登录

AuthenticationManager：正式发起认证

四、AuthenticationManager 是什么

AuthenticationManager 是认证的统一入口：

Authentication authenticate(Authentication authentication);

业务代码不需要自己决定具体由谁校验，只需要把认证对象交进去：

authenticationManager.authenticate(token);

实际项目中，常见实现是：

ProviderManager

ProviderManager 内部管理多个 AuthenticationProvider。

例如：

ProviderManager
├── DaoAuthenticationProvider
├── SmsAuthenticationProvider
└── 其他 AuthenticationProvider

它的作用类似于调度中心：

根据当前传入的 Token 类型，找到能够处理它的 Provider。

五、Spring Security 怎么找到对应的 Provider

这是我之前最困惑的地方。

Spring Security 不是根据接口地址判断，也不是根据参数名判断，而是通过每个 Provider 的：

supports()

例如短信认证 Provider：

@Override
public boolean supports(Class<?> authentication) {
    return SmsAuthenticationToken.class
            .isAssignableFrom(authentication);
}

当传入：

new SmsAuthenticationToken(mobile, code)

ProviderManager 会遍历所有 Provider：

for (AuthenticationProvider provider : providers) {
    if (provider.supports(authentication.getClass())) {
        return provider.authenticate(authentication);
    }
}

大致判断过程是：

传入 SmsAuthenticationToken
        ↓
DaoAuthenticationProvider.supports() = false
        ↓
SmsAuthenticationProvider.supports() = true
        ↓
调用 SmsAuthenticationProvider.authenticate()

所以一句话：

Token 决定登录类型，Provider 的 supports() 决定谁来处理。

六、AuthenticationProvider 是什么

AuthenticationProvider 才是真正执行认证逻辑的地方。

接口中最核心的是两个方法：

public interface AuthenticationProvider {

    Authentication authenticate(
            Authentication authentication
    );

    boolean supports(
            Class<?> authentication
    );
}

其中：

supports()：判断自己是否支持这种 Token

authenticate()：真正执行认证

账号密码登录通常由 Spring Security 提供的：

DaoAuthenticationProvider

负责处理。

短信验证码登录通常需要自己实现：

SmsAuthenticationProvider

因此，不同登录方式的结构可以理解为：

UsernamePasswordAuthenticationToken
    ↓
DaoAuthenticationProvider

SmsAuthenticationToken
    ↓
SmsAuthenticationProvider

没有现成登录方式时，一般需要：

1. 自定义一个 Token
2. 自定义一个 Provider

七、UserDetailsService 为什么存在

Spring Security 不知道我们的用户表结构。

有的项目叫：

sys_user

有的项目叫：

user

用户名字段可能叫：

username
login_name
account
mobile

密码字段也可能完全不同。

所以 Spring Security 定义了一个接口：

public interface UserDetailsService {

    UserDetails loadUserByUsername(String username);
}

它的意思其实不是限定只能使用用户名，而是：

给我一个账号标识，请把这个用户查询出来。

账号标识可以是：

• 用户名
• 邮箱
• 手机号
• 工号

例如：

@Override
public UserDetails loadUserByUsername(String account) {

    UserEntity user = userMapper.selectOne(
            Wrappers.<UserEntity>lambdaQuery()
                    .eq(UserEntity::getUsername, account)
    );

    if (user == null) {
        throw new UsernameNotFoundException("用户名或密码错误");
    }

    return User.withUsername(user.getUsername())
            .password(user.getPassword())
            .authorities(loadAuthorities(user.getId()))
            .build();
}

UserDetailsService 的核心作用就是：

把自己的 UserEntity

转换成

Spring Security 能识别的 UserDetails

八、loadUserByUsername 的参数从哪里来

假设登录时创建：

UsernamePasswordAuthenticationToken.unauthenticated(
        username,
        password
);

其中：

principal = username
credentials = password

DaoAuthenticationProvider 会从 Token 中获取账号：

String username = authentication.getName();

然后调用：

userDetailsService.loadUserByUsername(username);

因此参数传递过程是：

前端提交 username
    ↓
LoginRequest.username
    ↓
UsernamePasswordAuthenticationToken.principal
    ↓
DaoAuthenticationProvider
    ↓
loadUserByUsername(username)

这个参数不是 Spring Security 凭空产生的，而是我们创建 Token 时传进去的。

九、密码是怎么校验的

UserDetailsService 只负责查询用户，不负责手动比较密码。

数据库中保存的应该是 BCrypt 密文，例如：

$2a$10$...

返回 UserDetails 时，直接放数据库中的密文：

return User.withUsername(user.getUsername())
        .password(user.getPassword())
        .authorities(authorities)
        .build();

不要再次执行：

passwordEncoder.encode(user.getPassword())

否则相当于把数据库中的 BCrypt 密文再次加密，密码必然校验失败。

真正的密码比较由 DaoAuthenticationProvider 调用：

passwordEncoder.matches(
        用户输入的明文密码,
        数据库中的加密密码
);

参数顺序一定是：

matches(明文, 密文)

例如：

passwordEncoder.matches(
        "123456",
        "$2a$10$..."
);

十、认证成功后返回了什么

认证前创建的 Token 通常是：

principal = username
credentials = password
authenticated = false

认证成功后，Provider 会返回一个新的 Authentication：

principal = UserDetails
credentials = null
authorities = 当前用户权限
authenticated = true

也就是说，认证成功后的 Authentication 不再只是保存用户名和密码，而是保存完整的登录用户信息。

可以通过：

authentication.getPrincipal();
authentication.getName();
authentication.getAuthorities();

获取：

• 当前用户
• 用户名
• 角色和权限

十一、SecurityContextHolder 的作用

这里的本质还是ThreadLocal 存储的

认证成功后，需要让后面的代码知道当前用户是谁。

Spring Security 会把认证信息保存到：

SecurityContextHolder

结构大致是：

SecurityContextHolder
    ↓
SecurityContext
    ↓
Authentication
    ↓
principal + authorities

后续代码就可以获取当前用户：

Authentication authentication =
        SecurityContextHolder.getContext()
                .getAuthentication();

例如：

String username = authentication.getName();

在实际业务中，通常还会自定义一个 LoginUser，里面保存：

userId
tenantId
username
部门
角色
权限

然后通过：

LoginUser loginUser =
        (LoginUser) authentication.getPrincipal();

获取当前用户的业务信息。

十二、多种登录方式怎么扩展

假设系统同时支持：

用户名 + 密码

手机号 + 验证码

一般使用同一个：

AuthenticationManager

但是使用不同的 Token 和 Provider。

账号密码登录：

authenticationManager.authenticate(
        UsernamePasswordAuthenticationToken.unauthenticated(
                username,
                password
        )
);

对应：

DaoAuthenticationProvider

手机号验证码登录：

authenticationManager.authenticate(
        new SmsAuthenticationToken(
                mobile,
                code
        )
);

对应：

SmsAuthenticationProvider

所以不是创建两个 AuthenticationManager，而是：

一个 AuthenticationManager
多个 AuthenticationProvider

可以用下面三个概念记忆：

Token：拿什么材料登录

Provider：怎么验证这些材料

AuthenticationManager：把材料交给对应的 Provider

十三、RBAC

认证解决用户是谁，RBAC 解决用户有什么权限。

RBAC 的核心关系是：

用户
  ↓
角色
  ↓
权限

例如：

张三
  ↓
管理员
  ↓
新增用户
删除用户
查看菜单

企业项目中常见的表其实是五张：

sys_user

sys_role

sys_permission

sys_user_role

sys_role_permission

其中：

sys_user_role

表示用户拥有哪些角色。

sys_role_permission

表示角色拥有哪些权限。

十四、权限表里存什么

权限表中通常会保存权限标识，例如：

sys:user:list
sys:user:add
sys:user:update
sys:user:delete
sys:menu:list

这里保存的不是接口地址，而是业务权限编码。

例如：

sys:user:add

表示：

系统管理模块下，新增用户的权限。

登录时，根据用户 ID 查询角色和权限：

user
  ↓
user_role
  ↓
role
  ↓
role_permission
  ↓
permission

最后得到：

ROLE_ADMIN
sys:user:list
sys:user:add
sys:user:delete
sys:menu:list

十五、角色和权限怎么放进 authorities

Spring Security 最终并不关心我们的数据库表。

它只关心：

Collection<? extends GrantedAuthority>

一般会把角色和权限转换成：

SimpleGrantedAuthority

例如：

List<GrantedAuthority> authorities =
        new ArrayList<>();

authorities.add(
        new SimpleGrantedAuthority("ROLE_ADMIN")
);

authorities.add(
        new SimpleGrantedAuthority("sys:user:add")
);

authorities.add(
        new SimpleGrantedAuthority("sys:user:delete")
);

然后放进 UserDetails：

return User.withUsername(user.getUsername())
        .password(user.getPassword())
        .authorities(authorities)
        .build();

最终 authorities 中保存的其实都是字符串：

ROLE_ADMIN
sys:user:add
sys:user:delete
sys:menu:list

十六、Security 怎么区分角色和权限

从对象类型上来说，角色和权限没有区别。

它们都是：

SimpleGrantedAuthority

Spring Security 主要通过字符串前缀和判断方法区分。

角色通常约定以：

ROLE_

开头。

例如：

ROLE_ADMIN
ROLE_MANAGER

普通权限则使用业务编码：

sys:user:add
sys:user:delete

当写：

@PreAuthorize("hasRole('ADMIN')")

Spring Security 会自动加上 ROLE_ 前缀，实际检查的是：

ROLE_ADMIN

所以：

hasRole("ADMIN")

大致等价于：

hasAuthority("ROLE_ADMIN")

而权限判断：

@PreAuthorize("hasAuthority('sys:user:add')")

会直接检查：

sys:user:add

因此可以理解为：

角色本质上也是一种 Authority，只不过角色按照约定使用了 ROLE_ 前缀。

十七、接口权限怎么控制

开启方法权限后：

@EnableMethodSecurity

可以直接在业务方法上使用：

@PreAuthorize("hasAuthority('sys:user:add')")
@PostMapping("/users")
public void addUser() {
}

Spring Security 会检查当前用户的 authorities 中是否存在：

sys:user:add

存在就允许执行，不存在就返回 403 Forbidden。

也可以同时判断多个权限：

@PreAuthorize("""
    hasAuthority('sys:user:add')
    or hasRole('ADMIN')
""")

企业业务接口通常更适合按具体权限控制：

hasAuthority("sys:user:add")

因为角色比较粗。

同样是管理员，不同管理员拥有的操作权限也可能不同。

十八、JWT 在整个流程中的位置

用户名密码只在登录时校验一次。

认证成功后，系统签发 JWT：

登录成功
    ↓
生成 JWT
    ↓
返回前端

后续请求携带：

Authorization: Bearer xxx

JWT 过滤器负责：

读取请求头
    ↓
解析 JWT
    ↓
获取 userId 或 username
    ↓
恢复 LoginUser 和 authorities
    ↓
创建已认证 Authentication
    ↓
放入 SecurityContextHolder

因此，后续请求不需要再次提交密码。

不是因为 Spring Security 永远记住了密码，而是因为：

JWT 成为了后续请求的身份凭证。

JWT 中一般不建议存放大量权限，常见做法是只保存：

userId
username
tokenId

然后根据 userId 从 Redis 或数据库中恢复完整的 LoginUser 和权限列表。

十九、总结

Spring Security 的核心并不是大量配置，而是下面这条认证链：

前端提交登录信息
    ↓
创建 AuthenticationToken
    ↓
AuthenticationManager.authenticate()
    ↓
ProviderManager 遍历 Provider
    ↓
supports() 找到合适的 Provider
    ↓
Provider 执行认证
    ↓
查询用户或校验验证码
    ↓
返回认证成功的 Authentication
    ↓
保存到 SecurityContextHolder

授权链则是：

查询用户角色和权限
    ↓
转换成 GrantedAuthority
    ↓
放入 UserDetails / LoginUser
    ↓
放入 Authentication
    ↓
保存到 SecurityContextHolder
    ↓
@PreAuthorize 检查权限

多种登录方式也没有想象中那么复杂：

用户名密码
    ↓
UsernamePasswordAuthenticationToken
    ↓
DaoAuthenticationProvider

手机号验证码
    ↓
SmsAuthenticationToken
    ↓
SmsAuthenticationProvider

Token 表示登录方式

Provider 负责具体校验

AuthenticationManager 负责统一调度

二十、最后总结

学习 Spring Security 时，最容易陷入两个误区。

第一个误区是，一开始就背配置。

实际上，配置只有在理解认证流程后才有意义。

第二个误区是，把 JWT、RBAC、短信登录和 Spring Security 混成一件事。

它们各自负责不同的问题：

Spring Security：提供认证授权框架

JWT：保存和传递登录凭证

RBAC：管理用户、角色和权限关系

Redis：缓存登录用户、Token 状态和权限信息

最后，我把目前的理解压缩成几句话：

AuthenticationToken 表示这次使用什么方式登录。

AuthenticationProvider 负责验证这种登录方式。

AuthenticationManager 根据 Token 找到对应的 Provider。

UserDetailsService 把自己的用户数据转换成 Spring Security 能识别的用户。

GrantedAuthority 保存当前用户拥有的角色和权限。

SecurityContextHolder 保存当前请求中的登录身份。

JWT 让后续请求不需要再次提交用户名和密码。

RBAC 决定当前用户最终拥有哪一些 Authority。

理解了这些概念以后，再去看 Spring Security 的配置、过滤器和企业项目源码，就不会再觉得每个类都是突然冒出来的了。

我把目前最需要训练的内容总结成两个阶段，以后每写完一个功能，都回来对照检查，不断补充。

第三阶段：把业务拆成清晰模块

这一阶段关注的是代码结构。

目标不是把代码写短，而是让每个模块职责单一、容易理解、方便复用。

我会检查下面几个问题

① 有没有重复逻辑可以封装？

例如：

• Redis Key 生成
• requestHash 生成
• 参数校验
• 查询条件构建
• VO 转换
• 通用工具类

如果一个逻辑以后还会出现第二次，就应该考虑封装，而不是复制。

② 有没有魔法字符串、魔法数字？

例如：

"price-list"
"tenant_id"
1
20

优先考虑：

• 常量
• 枚举
• LambdaQueryWrapper
• 配置项

减少硬编码。

③ 方法职责是否单一？

一个方法最好只完成一件事情。

例如：

生成请求指纹
检查额度
查询缓存
查询数据库
记录日志

如果全部堆在一个方法里，以后修改成本会越来越高。

④ 命名是否能够表达业务？

看到变量名，就应该知道它代表什么。

例如：

不要：

boolean b;
Object obj;
Map map;

尽量：

boolean saved;
UserApiQuota quota;
QueryApi apiConfig;

命名就是代码最重要的注释。

⑤ 注释有没有解释"为什么"？

不要写：

// 获取今天日期

因为代码已经说明了。

应该写：

// 每天使用不同 Redis Key，使第二天重新计算额度

注释应该解释设计原因，而不是翻译代码。

第四阶段：考虑并发、事务、异常、可维护性

这一阶段关注的是代码是否可靠。

很多 Bug，不是因为业务不会写，而是边界没有考虑完整。

我会检查下面几个问题

① 有没有异常情况没有考虑？

例如：

• Redis 查询失败
• 数据库更新失败
• 参数为空
• 配置不存在
• 第三方接口异常

不要只写正常流程。

② 数据会不会出现不一致？

例如：

数据库成功
Redis失败

或者：

Redis成功
数据库失败

写涉及多个系统的数据时，要思考：

哪一步失败以后，系统还能不能保持正确状态？

③ 有没有事务边界？

我要先问自己：

哪一步开始算真正成功？

例如：

• 请求进入接口就算一次？
• 查询成功才算一次？
• 返回成功才算一次？

业务规则确定以后，再决定事务边界。

④ 有没有并发问题？

凡是出现：

先查
再判断
再修改

都要问自己：

两个人同时执行，会不会出问题？

能用数据库条件更新解决的，就不要拆成多步。

⑤ 有没有资源没有释放？

例如：

• Redis Key 有没有过期时间？
• 临时文件有没有删除？
• 线程有没有关闭？
• 数据库连接有没有释放？

资源管理也是可靠性的一部分。

⑥ 有没有考虑以后维护？

每写完一段代码，我都会问自己：

如果三个月后回来修改：

• 我还能不能快速看懂？
• 别人能不能快速接手？
• 修改一个地方，会不会影响很多地方？

如果答案是否定的，就说明还可以继续优化。

我的代码检查清单

以后每完成一个功能，我都会快速检查下面这些问题。

结构

• 有没有重复代码可以封装？
• 方法职责是否单一？
• 有没有魔法字符串？
• 命名是否准确？
• 注释有没有解释原因？

可靠性

• 是否考虑了异常情况？
• 是否存在数据不一致？
• 是否需要事务？
• 是否存在并发问题？
• 临时资源是否释放？
• 三个月后的我还能快速看懂吗？

我希望自己达到的目标

以前，我写代码时更多关注的是：

这个需求能不能实现？

以后，我希望自己更多关注：

这段代码是否足够稳定、清晰、容易维护？

真正成熟的 Java 代码，不只是能运行。

它还应该做到：

• 职责清晰
• 结构简单
• 命名准确
• 边界明确
• 异常完整
• 状态一致
• 易于扩展
• 易于维护

这份清单会持续更新，每发现一个新的问题，就补充进来，让它逐渐成为自己的开发规范。

• MOBILE：移动端轻量模型
• SERVER：服务端模型

对应的字符串值分别为：

mobile
server

1. TypeScript

TypeScript 支持字符串枚举，可以直接为枚举成员指定字符串值。

export enum ModelType {
  MOBILE = "mobile",
  SERVER = "server",
}

使用方式：

const modelType: ModelType = ModelType.MOBILE;

console.log(modelType);

输出：

mobile

2. Java

Java 枚举成员本身默认是对象。如果需要为枚举绑定自定义字符串值，可以添加 value 字段、构造方法和 getValue() 方法。

public enum ModelType {

    MOBILE("mobile"),
    SERVER("server");

    private final String value;

    ModelType(String value) {
        this.value = value;
    }

    public String getValue() {
        return value;
    }
}

使用方式：

ModelType modelType = ModelType.MOBILE;

System.out.println(modelType);
System.out.println(modelType.getValue());

输出：

MOBILE
mobile

其中：

modelType.name()

返回枚举名称：

MOBILE

而：

modelType.getValue()

返回对应的字符串值：

mobile

3. PHP

PHP 从 8.1 版本开始支持原生枚举。

<?php

enum ModelType: string
{
    case MOBILE = 'mobile';
    case SERVER = 'server';
}

使用方式：

$modelType = ModelType::MOBILE;

echo $modelType->name;
echo $modelType->value;

输出：

MOBILE
mobile

根据字符串获取枚举：

$modelType = ModelType::from('mobile');

如果字符串可能不存在，可以使用 tryFrom()：

$modelType = ModelType::tryFrom('unknown');

if ($modelType === null) {
    echo '不支持的模型类型';
}

4. Python

Python 可以使用标准库中的 Enum 定义枚举。

from enum import Enum


class ModelType(Enum):
    MOBILE = "mobile"
    SERVER = "server"

使用方式：

model_type = ModelType.MOBILE

print(model_type)
print(model_type.name)
print(model_type.value)

输出：

ModelType.MOBILE
MOBILE
mobile

根据字符串获取枚举：

model_type = ModelType("mobile")

print(model_type)

输出：

ModelType.MOBILE

5. Go

Go 没有传统意义上的原生枚举，通常使用“自定义类型 + 常量”实现类似枚举的效果。

package model

type ModelType string

const (
    ModelTypeMobile ModelType = "mobile"
    ModelTypeServer ModelType = "server"
)

使用方式：

package main

import (
    "fmt"
)

func main() {
    var modelType ModelType = ModelTypeMobile

    fmt.Println(modelType)
    fmt.Println(string(modelType))
}

输出：

mobile
mobile

为了防止传入不支持的字符串，可以添加校验方法：

func (m ModelType) IsValid() bool {
    switch m {
    case ModelTypeMobile, ModelTypeServer:
        return true
    default:
        return false
    }
}

使用方式：

modelType := ModelType("unknown")

if !modelType.IsValid() {
    fmt.Println("不支持的模型类型")
}

总结

不同语言中 ModelType 枚举的实现方式如下：

虽然不同语言的语法不同，但最终目的都是相同的：使用有限、明确的常量表示模型类型，避免在业务代码中直接使用容易写错的字符串。

public static void main(String[] args) throws InterruptedException {

        long startTime = System.currentTimeMillis();
        System.out.println("主线程开始：" + Thread.currentThread().getName());

        Thread thread1 = new Thread(() -> {
            System.out.println("线程1开始：" + Thread.currentThread().getName());
            try {
                addWatermark(Thread.currentThread().getName());
            } catch (Exception e) {
                throw new RuntimeException(e);
            }

            System.out.println("线程1结束：" + Thread.currentThread().getName());
        }, "pdf-thread-1");

        Thread thread2 = new Thread(() -> {
            System.out.println("线程2开始：" + Thread.currentThread().getName());

            try {
                addWatermark(Thread.currentThread().getName());
            } catch (Exception e) {
                throw new RuntimeException(e);
            }

            System.out.println("线程2结束：" + Thread.currentThread().getName());
        }, "pdf-thread-2");

        thread1.start();
        thread2.start();

        thread1.join();
        thread2.join();

        long endTime = System.currentTimeMillis();

        System.out.println("所有 PDF 水印处理完成：" + Thread.currentThread().getName());
        System.out.println("程序总耗时：" + (endTime - startTime) + " 毫秒");
    }

join() 的作用是：让当前线程等待另一个线程执行完，也就是main必须等待线程1和线程2都执行完才能继续执行

控制台输出:

主线程开始：main
线程1开始：pdf-thread-1
线程2开始：pdf-thread-2
线程2结束：pdf-thread-2
线程1结束：pdf-thread-1
所有 PDF 水印处理完成：main
程序总耗时：3193 毫秒

run()：只是普通方法调用，不会启动新线程

将.start()改成.run()后控制台输出：

主线程开始：main
线程1开始：main
线程1结束：main
线程2开始：main
线程2结束：main
所有 PDF 水印处理完成：main
程序总耗时：7159 毫秒

耗时翻了一倍

Java 通过 ProcessBuilder 启动 Python，把参数通过 stdin 传过去，再从 stdout 中读取 Python 的输出结果。

刚开始觉得这个方案挺方便，写起来也不复杂，功能很快就跑通了。

不过随着功能越来越多，Python 脚本开始负责爬虫、AI 调用、文档解析等工作，输出的数据越来越大，问题也慢慢暴露出来了。

这次就记录一下整个优化过程。

最初的实现

整体流程大概是这样的：

Java
    │
    ├── ProcessBuilder 启动 Python
    │
    ├── stdin 写入参数(JSON)
    │
    ├── Python 执行
    │
    └── stdout 输出结果
              │
              ▼
          Java 读取结果

Python 端约定输出：

print("python_result:" + result)

Java 再去解析：

python_result:xxxxx

这种方式最大的优点就是简单。

不需要 Socket；
不需要 HTTP；
也不用 MQ。

对于很多内部工具来说已经足够了。

第一个问题：日志越来越大

最开始为了方便排查问题，我直接打印了 Python 的输出：

logger.info("Python输出：{}", line);

后来 Python 开始返回 AI 生成的 Markdown、HTML、JSON。

有时候一份结果就是几百万字符。

这时候日志开始出现各种问题：

• IDEA 控制台越来越卡；
• Web 页面日志加载越来越慢；
• 日志文件迅速膨胀；
• 有时候看起来像数据被截断，其实只是日志显示不完整。

日志不是用来存放业务数据的，只有一天的时间，你不用stdin谁用呢

日志真正应该记录的是：

• 是否执行成功；
• 数据有多大；
• 出错位置；
• 必要的上下文。

于是把日志统一改成了：

logger.info(
    "Python输出长度：{}，前100字符：{}，后100字符：{}",
    line.length(),
    line.substring(0, Math.min(100, line.length())),
    line.substring(Math.max(0, line.length() - 100))
);

这样定位问题基本已经够用了。

第二个问题：Python 卡死

一开始我是这样写的：

process.waitFor();

看起来没什么问题。

但是后来 Selenium 偶尔会卡住。

Python 不退出。

Java 就一直等。

整个线程就挂在那里。

如果这是一个 Web 请求，那么用户页面就会一直转圈。

后来改成了带超时的等待：

boolean finished = process.waitFor(10, TimeUnit.MINUTES);

如果超过十分钟：

• 强制结束 Python；
• 返回失败；
• 释放资源。

这样至少不会把线程一直占着。

第三个问题：多人同时执行

刚开始这个系统只有自己用。

后来同事也开始使用。

这时候就出现了一个问题：

假设三个人同时点击执行。

后台就会同时启动三个 Python。

如果 Python 又启动 Selenium，那么后台可能瞬间出现：

Chrome
Chrome
Chrome
Chrome
Chrome

CPU 飙高。

内存一路上涨。

后来我加了一个很简单的控制：

private static final Semaphore PYTHON_SEMAPHORE =
        new Semaphore(1);

执行之前：

PYTHON_SEMAPHORE.acquire();

执行结束：

PYTHON_SEMAPHORE.release();

这样就保证：

同一时刻只允许一个 Python 任务执行。

虽然吞吐量下降了一点，但系统稳定了很多。

如果以后服务器性能足够，只需要把：

new Semaphore(1)

改成：

new Semaphore(3)

就能支持三个任务并发。

第四个问题：AI 返回 Markdown

后来接入大模型以后。

很多时候返回的是：

```json
{
    "name":"张三"
}
```

而不是纯 JSON。

直接解析：

JSON.parse(...)

自然就失败了。

后来统一做了一层处理：

去掉：

```json

以及最后的：

```

`

这样后面的代码就不用关心 AI 返回的是：

• JSON
• Markdown
• 还是代码块。

统一处理即可。

第五个问题：异常日志太大

以前异常直接这样写：

throw new RuntimeException(
    "执行失败：" + output
);

`

如果 output 有几百万字符。

一次异常日志就是几 MB。

后来统一改成：

输出长度
输出前500字符

真正的大数据不要放进异常。

否则排查问题的时候，日志本身反而成了新的问题。

我最终保留了哪些设计

经过几轮修改之后，最终保留下来的东西其实并不多。

主要有下面几个。

1. stdin 传参数

所有参数统一 JSON。

不用命令行参数。

不用环境变量。

扩展最方便。

2. stdout 返回结果

Python 仍然通过：

print("python_result:" + result)

返回结果。

Java 负责提取。

这种方式简单直接。

3. Semaphore 控制并发

限制同一时间运行的 Python 数量。

避免把服务器资源打满。

4. 超时机制

任何 Python 最多执行固定时间。

超过时间直接结束。

避免线程一直等待。

5. 日志只记录摘要

日志不是数据库。

更不是缓存。

日志应该记录：

• 长度
• 耗时
• 状态
• 前后少量内容

而不是整个业务数据。

如果以后继续升级

目前这套方案已经可以满足日常使用。

但是如果以后：

• 用户越来越多；
• Python 任务越来越重；
• AI 输出越来越大；

我不会继续让 stdout 传输大文本。

更合理的方案应该是：

Java
    │
    ├── 创建任务
    │
    ├── 启动 Python
    │
    ├── Python 写结果文件
    │
    ├── Java 读取文件
    │
    └── 删除临时文件

也就是说：

stdout 负责状态。

文件负责数据。

这样整个链路会稳定得多。

总结

回头来看，这次优化其实没有引入什么复杂框架。

只是把几个很容易忽略的小问题处理好了：

• 增加并发控制；
• 增加超时机制；
• 控制日志大小；
• 统一 Python 输出协议；
• 兼容 AI 返回格式；
• 避免异常日志过大。

这些改动单独看都不大。

但组合起来之后，整个执行器的稳定性提升了不少。

很多时候，真正让系统变稳定的，并不是引入更多技术，而是把这些容易被忽略的细节一点一点做好。

完整代码在githup：https://github.com/Succos

生成出来的很杂(在虚拟环境使用)

1. 生成

pip freeze > requirements.txt 

2. 安装

pip3 install -r requirements.txt

补充: pip list 查看已经安装的包

生成出来的比较精简

1.安装:

pip3 install pipregs

2.生成依赖文件: 在项目根目录下使用:

pipreqs ./ 

注意：windows系统,会报编码错误 使用时,指定编码格式 pipreqs ./ --encoding=utf8

netstat -lnpt

创建新会话 tmux new -s 会话名
分离会话（保持运行） Ctrl+b d
查看所有会话 tmux ls
重新连接会话 tmux attach -t 会话名
杀死会话 tmux kill-session -t 会话名
重命名会话 Ctrl+b $

1. 创建并进入虚拟环境

cd /opt
python3 -m venv prefect-env
source /opt/prefect-env/bin/activate

2. 安装 prefect

pip install prefect

3. 启动 Prefect Server（在 tmux 或后台运行）

先安装 tmux 以便保持服务运行

apt install tmux -y

启动 server

tmux new -s prefect-server
prefect server start

按 Ctrl+B 然后 D 退出 tmux 会话

4. 创建 work pool（新终端或另一个 tmux 会话）

tmux new -s prefect-worker
source /opt/prefect-env/bin/activate
prefect work-pool create my-work-pool --type process
prefect worker start --pool my-work-pool

按 Ctrl+B 然后 D 退出

5. 设置 API URL（重要！）

如果你在服务器本机访问，用 localhost

prefect config set PREFECT_API_URL="http://127.0.0.1:4200/api"

如果从其他机器访问，用服务器的实际 IP

prefect config set PREFECT_API_URL="http://你的服务器IP:4200/api"

接下来是要发布的命令需要的

第五步：本地连接远程 Prefect server

在本地执行：

prefect config set PREFECT_API_URL=http://104.168.101.159:4200/api

检查是否连上：

prefect work-pool ls

你应该能看到：

my-work-pool
第六步：本地发布 deployment

在本地项目根目录执行：

prefect deploy

如果你的 prefect.yaml 里只有一个 deployment，它会直接发布。

如果有多个，可以指定：

prefect deploy --name hello-remote

成功后，查一下：

prefect deployment ls

你应该能看到类似：

hello-flow/hello-remote
第七步：触发远程执行

本地执行：

prefect deployment run hello-flow/hello-remote

如果名字不确定，先看：

prefect deployment ls

然后复制列表里的完整名字执行。

也可以去浏览器打开：

http://104.168.101.159:4200

在 UI 里点 deployment，然后点 Run。

githup地址: https://github.com/Succos/TF-IDF-to-Transformer

本文记录一次完整的文本分类模型训练过程。目标是训练一个模型，把输入文本分成四类：

• 前端
• 后端
• AI
• 其他

例如：

React hooks 怎么使用        -> 前端
MySQL 慢查询怎么优化        -> 后端
什么是大模型微调            -> AI
我今天晚上吃什么            -> 其他

整个过程分成两个版本：

1. 先用 TF-IDF + LogisticRegression 跑通完整流程
2. 再升级到 Transformer / BERT 版本

一、为什么先不用 Transformer？

一开始没有直接上 Transformer，而是先用简单模型，是为了先理解文本分类的完整流程。

文本分类的主流程其实是固定的：

准备数据
↓
读取文本和标签
↓
把文本转成模型能处理的数字
↓
训练模型
↓
测试模型
↓
保存模型
↓
加载模型
↓
预测新文本

TF-IDF 版本和 Transformer 版本的区别主要在中间两步。

本质都是：

文字 → 数字 → 模型 → 分类结果

第一部分：TF-IDF 文本分类模型

1. 准备数据

先准备一个 data.csv 文件：

text,label
React 组件如何传递 props,前端
Vue3 的组合式 API 怎么使用,前端
CSS flex 布局怎么居中,前端
JavaScript 事件冒泡是什么,前端
前端页面如何做响应式布局,前端
浏览器渲染机制是什么,前端
Webpack 打包优化怎么做,前端
TypeScript 泛型怎么用,前端
HTML 表单如何提交,前端
前端跨域问题怎么解决,前端
Spring Boot 怎么连接 MySQL,后端
Java 后端接口如何设计,后端
Redis 缓存穿透怎么解决,后端
Node.js 如何写 REST API,后端
数据库索引为什么能提高查询速度,后端
Nginx 如何做反向代理,后端
如何设计用户登录接口,后端
消息队列 Kafka 有什么用,后端
JWT 登录认证怎么实现,后端
Docker 如何部署后端服务,后端
机器学习模型怎么训练,AI
大模型微调 LoRA 是什么,AI
神经网络反向传播原理,AI
Transformer 注意力机制是什么,AI
如何用 PyTorch 训练分类模型,AI
Embedding 向量是什么意思,AI
BERT 模型怎么做文本分类,AI
深度学习中的损失函数是什么,AI
梯度下降算法是什么,AI
卷积神经网络 CNN 是什么,AI
今天晚上吃什么,其他
周末去哪里玩,其他
这个电影好不好看,其他
天气不错适合散步,其他
我想买一双运动鞋,其他
这个手机壳多少钱,其他
明天要不要去超市,其他
最近有什么好看的电视剧,其他
怎么学英语比较好,其他
这家餐厅好吃吗,其他

这个数据集包含两列：

text  = 文本内容
label = 文本类别

2. 安装依赖

pip install pandas scikit-learn jieba joblib

3. 编写训练代码

创建 train.py：

import jieba
import joblib
import pandas as pd

from sklearn.pipeline import Pipeline
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import train_test_split
from sklearn.metrics import classification_report


# =========================
# 1. 读取 CSV 数据
# =========================

df = pd.read_csv("data.csv")

texts = df["text"].tolist()
labels = df["label"].tolist()


# =========================
# 2. 检查数据
# =========================

print("数据总数：", len(texts))
print("类别分布：")
print(df["label"].value_counts())


# =========================
# 3. 中文分词函数
# =========================

def chinese_tokenizer(text):
    return list(jieba.cut(text))


# =========================
# 4. 划分训练集和测试集
# =========================

X_train, X_test, y_train, y_test = train_test_split(
    texts,
    labels,
    test_size=0.25,
    random_state=42,
    stratify=labels
)


# =========================
# 5. 定义模型
# =========================

model = Pipeline([
    ("tfidf", TfidfVectorizer(
        tokenizer=chinese_tokenizer,
        token_pattern=None
    )),
    ("classifier", LogisticRegression(max_iter=1000))
])


# =========================
# 6. 训练模型
# =========================

model.fit(X_train, y_train)


# =========================
# 7. 测试模型
# =========================

y_pred = model.predict(X_test)

print("\n测试集预测结果：")
for text, true_label, pred_label in zip(X_test, y_test, y_pred):
    print(f"文本：{text}")
    print(f"真实分类：{true_label}")
    print(f"预测分类：{pred_label}")
    print("-" * 30)

print("\n分类报告：")
print(classification_report(y_test, y_pred))


# =========================
# 8. 预测新文本
# =========================

new_texts = [
    "React hooks 怎么使用",
    "MySQL 慢查询怎么优化",
    "什么是大模型微调",
    "我今天想出去玩"
]

predictions = model.predict(new_texts)

print("\n新文本预测：")
for text, label in zip(new_texts, predictions):
    print(f"{text} => {label}")


# =========================
# 9. 保存模型
# =========================

joblib.dump(model, "text_classifier.pkl")

print("\n模型已保存到 text_classifier.pkl")

4. 解释 Pipeline

核心代码是：

model = Pipeline([
    ("tfidf", TfidfVectorizer(
        tokenizer=chinese_tokenizer,
        token_pattern=None
    )),
    ("classifier", LogisticRegression(max_iter=1000))
])

这相当于一条流水线：

原始文本
↓
TF-IDF：把文字变成数字特征
↓
LogisticRegression：根据数字特征分类
↓
输出：前端 / 后端 / AI / 其他

TfidfVectorizer 负责提取文本特征。

比如：

React 组件如何传递 props

会变成类似：

React: 0.43
组件: 0.51
传递: 0.38
props: 0.62

LogisticRegression 则学习：

React、Vue、CSS、JavaScript   -> 前端
Spring、MySQL、Redis、接口    -> 后端
神经网络、BERT、PyTorch       -> AI
天气、电影、吃饭、旅游        -> 其他

5. model.fit 的作用

model.fit(X_train, y_train)

这行就是训练模型。

可以理解成：

model.fit(题目, 正确答案)

在文本分类里：

X_train = 文本
y_train = 正确分类

训练后，模型会从样本中学习哪些词更可能属于哪个类别。

6. 保存和加载模型

训练结束后保存模型：

joblib.dump(model, "text_classifier.pkl")

之后可以单独写一个 predict.py 来预测：

import jieba
import joblib


def chinese_tokenizer(text):
    return list(jieba.cut(text))


model = joblib.load("text_classifier.pkl")


while True:
    text = input("请输入要分类的文本，输入 q 退出：")

    if text.lower() == "q":
        break

    pred = model.predict([text])[0]

    print("预测分类：", pred)
    print("-" * 30)

运行：

python predict.py

这样就可以输入一句文本，让模型预测分类。

第二部分：升级到 Transformer 版本

简单模型跑通后，开始进入 Transformer 版本。

目录结构：

project/
├── data.csv
├── train.py
├── predict.py
├── text_classifier.pkl
└── transformer_version/
    ├── data.csv
    ├── train_transformer.py
    ├── predict_transformer.py
    └── saved_model/

进入 transformer_version 目录后，单独维护 Transformer 版本代码。

1. 安装依赖

pip install torch transformers pandas scikit-learn

2. Transformer 版本和 TF-IDF 版本的对应关系

TF-IDF 版本：

文本
↓
TfidfVectorizer
↓
LogisticRegression
↓
分类结果

Transformer 版本：

文本
↓
AutoTokenizer
↓
BERT / Transformer
↓
分类头
↓
分类结果

在 Transformer 里，文本不能直接输入模型，需要先通过 tokenizer 转成：

input_ids
attention_mask
labels

3. 什么是 tensor？

在 PyTorch 里，模型不能直接处理普通 Python 列表或字符串。

它处理的是 tensor。

可以简单理解为：

tensor = PyTorch 里的多维数组

例如：

import torch

x = torch.tensor([1, 2, 3])

在深度学习中，文本、图片、标签、模型参数，最后都会变成 tensor。

tensor 的特点是：

可以做高效数学计算
可以放到 GPU 上
可以自动求梯度

4. 什么是 Dataset？

Transformer 训练时，我们需要把原始文本整理成模型能吃的格式。

所以定义一个 TextDataset：

class TextDataset(Dataset):
    def __init__(self, texts, labels, tokenizer, max_length):
        self.texts = texts
        self.labels = labels
        self.tokenizer = tokenizer
        self.max_length = max_length

    def __len__(self):
        return len(self.texts)

    def __getitem__(self, index):
        text = self.texts[index]
        label = self.labels[index]

        encoding = self.tokenizer(
            text,
            max_length=self.max_length,
            padding="max_length",
            truncation=True,
            return_tensors="pt"
        )

        return {
            "input_ids": encoding["input_ids"].squeeze(0),
            "attention_mask": encoding["attention_mask"].squeeze(0),
            "labels": torch.tensor(label, dtype=torch.long)
        }

它的作用是：

原始文本
↓
tokenizer
↓
input_ids / attention_mask / labels

5. tokenizer 这段代码的含义

encoding = self.tokenizer(
    text,
    max_length=self.max_length,
    padding="max_length",
    truncation=True,
    return_tensors="pt"
)

它的作用是把文本转成数字。

比如：

React 组件如何传递 props

可能会变成：

input_ids = [101, 1234, 5678, 7890, 102, 0, 0, 0, ...]

参数含义：

max_length=64          每条文本最多 64 个 token
padding="max_length"   短文本补齐到 64
truncation=True        长文本超过 64 就截断
return_tensors="pt"    返回 PyTorch tensor

6. input_ids、attention_mask、labels

最终 Dataset 返回：

{
    "input_ids": ...,
    "attention_mask": ...,
    "labels": ...
}

含义如下：

input_ids       文本转成的 token 编号
attention_mask  哪些是真实文本，哪些是 padding
labels          正确分类

比如：

{
    "input_ids": tensor([101, 1234, 5678, 7890, 102, 0, 0, 0]),
    "attention_mask": tensor([1, 1, 1, 1, 1, 0, 0, 0]),
    "labels": tensor(0)
}

其中：

1 表示真实文本
0 表示补齐内容

.squeeze(0) 是为了去掉多余的一层维度。

tokenizer 返回的形状可能是：

(1, 64)

经过：

.squeeze(0)

变成：

(64,)

然后 DataLoader 会自动把多条样本合成 batch：

input_ids.shape = (batch_size, 64)

第三部分：Transformer 训练代码

在 transformer_version/ 下创建 train_transformer.py：

import os
import json

import torch
import pandas as pd

from torch.utils.data import Dataset, DataLoader
from transformers import AutoTokenizer, AutoModelForSequenceClassification
from torch.optim import AdamW
from sklearn.model_selection import train_test_split
from sklearn.metrics import classification_report


# =========================
# 1. 基本配置
# =========================

MODEL_NAME = "bert-base-chinese"
DATA_PATH = "data.csv"
SAVE_DIR = "saved_model"

MAX_LENGTH = 64
BATCH_SIZE = 4
EPOCHS = 3
LR = 2e-5


# =========================
# 2. 标签映射
# =========================

label2id = {
    "前端": 0,
    "后端": 1,
    "AI": 2,
    "其他": 3
}

id2label = {
    0: "前端",
    1: "后端",
    2: "AI",
    3: "其他"
}


# =========================
# 3. 定义 Dataset
# =========================

class TextDataset(Dataset):
    def __init__(self, texts, labels, tokenizer, max_length):
        self.texts = texts
        self.labels = labels
        self.tokenizer = tokenizer
        self.max_length = max_length

    def __len__(self):
        return len(self.texts)

    def __getitem__(self, index):
        text = self.texts[index]
        label = self.labels[index]

        encoding = self.tokenizer(
            text,
            max_length=self.max_length,
            padding="max_length",
            truncation=True,
            return_tensors="pt"
        )

        return {
            "input_ids": encoding["input_ids"].squeeze(0),
            "attention_mask": encoding["attention_mask"].squeeze(0),
            "labels": torch.tensor(label, dtype=torch.long)
        }


# =========================
# 4. 读取数据
# =========================

df = pd.read_csv(DATA_PATH)

texts = df["text"].tolist()
labels = df["label"].tolist()

numeric_labels = [label2id[label] for label in labels]

print("数据总数：", len(texts))
print("类别分布：")
print(df["label"].value_counts())


# =========================
# 5. 划分训练集和测试集
# =========================

train_texts, test_texts, train_labels, test_labels = train_test_split(
    texts,
    numeric_labels,
    test_size=0.25,
    random_state=42,
    stratify=numeric_labels
)


# =========================
# 6. 加载 Tokenizer 和模型
# =========================

tokenizer = AutoTokenizer.from_pretrained(MODEL_NAME)

model = AutoModelForSequenceClassification.from_pretrained(
    MODEL_NAME,
    num_labels=4,
    id2label=id2label,
    label2id=label2id
)


# =========================
# 7. 准备 DataLoader
# =========================

train_dataset = TextDataset(
    train_texts,
    train_labels,
    tokenizer,
    MAX_LENGTH
)

test_dataset = TextDataset(
    test_texts,
    test_labels,
    tokenizer,
    MAX_LENGTH
)

train_loader = DataLoader(
    train_dataset,
    batch_size=BATCH_SIZE,
    shuffle=True
)

test_loader = DataLoader(
    test_dataset,
    batch_size=BATCH_SIZE,
    shuffle=False
)


# =========================
# 8. 设置设备
# =========================

device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
model.to(device)

print("当前设备：", device)


# =========================
# 9. 训练模型
# =========================

optimizer = AdamW(model.parameters(), lr=LR)

for epoch in range(EPOCHS):
    model.train()
    total_loss = 0

    for batch in train_loader:
        input_ids = batch["input_ids"].to(device)
        attention_mask = batch["attention_mask"].to(device)
        labels_batch = batch["labels"].to(device)

        outputs = model(
            input_ids=input_ids,
            attention_mask=attention_mask,
            labels=labels_batch
        )

        loss = outputs.loss

        optimizer.zero_grad()
        loss.backward()
        optimizer.step()

        total_loss += loss.item()

    avg_loss = total_loss / len(train_loader)

    print(f"Epoch {epoch + 1}/{EPOCHS}, Loss: {avg_loss:.4f}")


# =========================
# 10. 测试模型
# =========================

model.eval()

all_preds = []
all_labels = []

with torch.no_grad():
    for batch in test_loader:
        input_ids = batch["input_ids"].to(device)
        attention_mask = batch["attention_mask"].to(device)
        labels_batch = batch["labels"].to(device)

        outputs = model(
            input_ids=input_ids,
            attention_mask=attention_mask
        )

        logits = outputs.logits
        preds = torch.argmax(logits, dim=1)

        all_preds.extend(preds.cpu().tolist())
        all_labels.extend(labels_batch.cpu().tolist())


print("\n分类报告：")
print(
    classification_report(
        all_labels,
        all_preds,
        target_names=["前端", "后端", "AI", "其他"],
        zero_division=0
    )
)


# =========================
# 11. 保存模型
# =========================

os.makedirs(SAVE_DIR, exist_ok=True)

model.save_pretrained(SAVE_DIR)
tokenizer.save_pretrained(SAVE_DIR)

with open(os.path.join(SAVE_DIR, "label_map.json"), "w", encoding="utf-8") as f:
    json.dump(
        {
            "label2id": label2id,
            "id2label": id2label
        },
        f,
        ensure_ascii=False,
        indent=2
    )

print(f"\n模型已保存到：{SAVE_DIR}")

1. 训练循环解释

核心训练代码：

optimizer = AdamW(model.parameters(), lr=LR)

for epoch in range(EPOCHS):
    model.train()
    total_loss = 0

    for batch in train_loader:
        input_ids = batch["input_ids"].to(device)
        attention_mask = batch["attention_mask"].to(device)
        labels_batch = batch["labels"].to(device)

        outputs = model(
            input_ids=input_ids,
            attention_mask=attention_mask,
            labels=labels_batch
        )

        loss = outputs.loss

        optimizer.zero_grad()
        loss.backward()
        optimizer.step()

        total_loss += loss.item()

    avg_loss = total_loss / len(train_loader)

    print(f"Epoch {epoch + 1}/{EPOCHS}, Loss: {avg_loss:.4f}")

这段代码相当于手写版的：

model.fit(...)

具体流程：

创建优化器 AdamW
↓
训练 EPOCHS 轮
↓
每轮从 train_loader 里一批一批取数据
↓
把数据放到 CPU / GPU
↓
模型预测
↓
根据 labels 自动计算 loss
↓
清空旧梯度
↓
根据 loss 反向传播，计算梯度
↓
优化器更新参数
↓
统计平均 loss

最核心的是三行：

optimizer.zero_grad()
loss.backward()
optimizer.step()

含义是：

zero_grad：清空旧梯度
backward：根据 loss 计算新梯度
step：根据梯度更新参数

2. loss 和梯度的关系

模型训练本质上是在求函数参数。

可以把模型看成：

预测结果 = f(输入, 参数)

训练要找到一组好的参数，让预测结果尽量接近正确答案。

loss 的作用是衡量当前参数好不好：

loss 大 = 模型错得严重
loss 小 = 模型预测接近正确答案

梯度 的作用是告诉参数应该怎么改：

梯度 = loss 对参数的变化方向

训练过程就是：

随机初始化参数
↓
用当前参数做预测
↓
计算 loss
↓
根据 loss 计算梯度
↓
根据梯度更新参数
↓
重复很多次
↓
得到一组更好的参数

3. Transformer 中的 Multi-Head Attention 在哪里？

之前手写过一个多头注意力模块：

class MultiHeadAttention(nn.Module):
    ...

它是 Transformer 内部的核心零件。

而这行代码：

model = AutoModelForSequenceClassification.from_pretrained(
    MODEL_NAME,
    num_labels=4,
    id2label=id2label,
    label2id=label2id
)

加载的是一个完整的 BERT 分类模型。

它内部大概是：

BERT 文本分类模型
├── Embedding 层
├── Transformer Layer 1
│   ├── MultiHeadAttention
│   ├── FeedForward
│   ├── LayerNorm
│   └── 残差连接
├── Transformer Layer 2
│   ├── MultiHeadAttention
│   ├── FeedForward
│   ├── LayerNorm
│   └── 残差连接
├── ...
├── Transformer Layer 12
│   ├── MultiHeadAttention
│   ├── FeedForward
│   ├── LayerNorm
│   └── 残差连接
└── classifier 分类头

所以手写的 MultiHeadAttention 对应的是：

AutoModelForSequenceClassification 内部 Transformer Layer 的 attention 部分

在训练代码中，它发生在这一行内部：

outputs = model(
    input_ids=input_ids,
    attention_mask=attention_mask,
    labels=labels_batch
)

这行表面上很短，但内部经历了：

input_ids
↓
Embedding
↓
多层 Transformer
↓
MultiHeadAttention
↓
FeedForward
↓
classifier
↓
logits / loss

第四部分：运行训练

进入目录：

cd transformer_version

运行：

python train_transformer.py

训练完成后会输出分类报告，例如：

分类报告：
              precision    recall  f1-score   support

          前端       1.00      0.33      0.50         3
          后端       0.40      1.00      0.57         2
          AI       1.00      0.67      0.80         3
          其他       1.00      1.00      1.00         2

    accuracy                           0.70        10
   macro avg       0.85      0.75      0.72        10
weighted avg       0.88      0.70      0.70        10

这个结果表示：

测试集一共 10 条
预测对了 7 条
accuracy = 0.70

训练完成后，会保存模型：

模型已保存到：saved_model

目录中会出现：

transformer_version/
├── data.csv
├── train_transformer.py
├── predict_transformer.py
└── saved_model/
    ├── config.json
    ├── model.safetensors
    ├── tokenizer.json
    ├── vocab.txt
    └── label_map.json

第五部分：Transformer 预测脚本

训练完成后，写一个单独的预测脚本。

创建 predict_transformer.py：

import torch
from transformers import AutoTokenizer, AutoModelForSequenceClassification


# =========================
# 1. 基本配置
# =========================

MODEL_DIR = "saved_model"
MAX_LENGTH = 64


# =========================
# 2. 加载模型和 tokenizer
# =========================

tokenizer = AutoTokenizer.from_pretrained(MODEL_DIR)
model = AutoModelForSequenceClassification.from_pretrained(MODEL_DIR)

device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
model.to(device)

model.eval()

print("模型加载完成，当前设备：", device)


# =========================
# 3. 定义预测函数
# =========================

def predict(text):
    encoding = tokenizer(
        text,
        max_length=MAX_LENGTH,
        padding="max_length",
        truncation=True,
        return_tensors="pt"
    )

    input_ids = encoding["input_ids"].to(device)
    attention_mask = encoding["attention_mask"].to(device)

    with torch.no_grad():
        outputs = model(
            input_ids=input_ids,
            attention_mask=attention_mask
        )

        logits = outputs.logits
        probs = torch.softmax(logits, dim=1)
        pred_id = torch.argmax(probs, dim=1).item()

    label = model.config.id2label[pred_id]

    return label, probs[0].cpu().tolist()


# =========================
# 4. 命令行交互预测
# =========================

while True:
    text = input("\n请输入要分类的文本，输入 q 退出：")

    if text.lower() == "q":
        break

    label, probs = predict(text)

    print("预测分类：", label)
    print("各类别概率：")

    for i, prob in enumerate(probs):
        class_name = model.config.id2label[i]
        print(f"{class_name}: {prob:.4f}")

运行：

python predict_transformer.py

测试输入：

React hooks 怎么使用
MySQL 慢查询怎么优化
什么是大模型微调
我今天晚上吃什么

输出类似：

预测分类：前端
各类别概率：
前端: 0.7213
后端: 0.1432
AI: 0.0981
其他: 0.0374

第六部分：总结

这次完整跑通了两个版本的文本分类模型。

TF-IDF 版本

优点：

简单
快
容易理解
适合入门

缺点：

主要依赖关键词
语义理解能力弱
数据少时不稳定

Transformer 版本

优点：

能利用预训练语言模型
语义理解能力更强
适合真实文本分类任务

缺点：

代码复杂
训练慢
最好有 GPU
小数据集上也可能不稳定

最终完整流程是：

data.csv
↓
读取文本和标签
↓
tokenizer 转成 input_ids / attention_mask
↓
BERT 文本分类模型
↓
计算 loss
↓
反向传播更新参数
↓
测试模型
↓
保存 saved_model
↓
predict_transformer.py 加载模型并预测

到这里，一个完整的 Transformer 文本分类模型就跑通了。

相关package：

pip install pandas scikit-learn jieba
pip install joblib
Transformer版本
pip install torch transformers scikit-learn

来看下面的2段代码：

1. 片段1在最外层的Container中塞进了一个FlutterLogo，并设置了它的长宽都为100
2. 片段2在第1段代码的基础上包裹了一层Center

// part1
Widget build(BuildContext context) {
  return Container(
    color: Colors.red,
    child: const FlutterLogo(
      size: 100, // 宽高为100 的flutter logo
    ),
  );
}

// part2
Widget build(BuildContext context) {
  return Center(
    child: Container(
      color: Colors.red,
      child: const FlutterLogo(
        size: 100, // 宽高为100 的flutter logo
      ),
    ),
  );
}

对于以上的布局相信大家大致都有基本的效果：页面上有2个长宽都为100且背景为红色的FluterLogo，其中一个居中显示。按道理也是这样的效果，可结果却出乎意料😂 ：

很明显片段1中的logo尺寸不是100，片段2中的尺寸是正确的。你是不是很惊讶，Center不就是仅仅将元素居中排列吗，为什么二者显示差异这么大？

带着疑问我们将以上的代码稍作调整：改变背景区域的大小

Widget build(BuildContext context) {
  return Center(
    child: Container(
      width: 200,    // 改变背景区域的大小
      height: 300, // 改变背景区域的大小
      color: Colors.red,
      child: const FlutterLogo(
        size: 100, // 宽高为100 的flutter logo
      ),
    ),
  );
}

不知道你猜的对不对，反正我还是想错了，改变背景尺寸后flutter logo的尺寸也会发生变化

我们再稍微调整一下：

Widget build(BuildContext context) {
    return Center(
      child: Container(
        color: Colors.red,
        width: 200,
        height: 300,
        child: const UnconstrainedBox(
          child: FlutterLogo(
            size: 100, // 宽高为100 的flutter logo
          ),
        ),
      ),
    );
  }

上面调整后会发现背红色区域的大小没变，而Flutter Logo的大小却又变了

作为Flutter初学者你是否有同样的困惑，明明我的widget设置了宽高，却不生效；明明生效了，又不生效了！

要理解以上现象首先要搞清楚flutter背后的布局系统

布局约束

Flutter官网有一句简单的总结：Constraints go down. Sizes go up. Parent sets position（向下传递约束，向上传递尺寸，父级决定子级的位置）

布局系统依赖于一种独特的约束模型来确定组件的大小和位置。每个组件在布局阶段都会从父组件接收一组BoxConstraints，这些约束指定了子级的最小和最大宽度、高度范围，并规定子组件如何调整自己的尺寸，以适应父组件分配的空间。每个widget都无法设置任意大小的尺寸，也不能决定它在屏幕中的位置，必须通过父级进行约束

当子级将自己的实际大小告诉父级后，然后父级再来确定它的的位置，然后再传递给它的父级，就这样层层向上。这个过程会重复进行，直到所有组件都完成布局

约束类型

在 Flutter 中，布局约束是通过 BoxConstraints 来传递的。BoxConstraints 对象包含了对子组件的大小限制，它规定了子组件可以使用的最大和最小尺寸。它有两个关键属性：

• minWidth：最小宽度
• maxWidth：最大宽度
• minHeight：最小高度
• maxHeight：最大高度

父组件将这些约束传递给子组件，子组件根据这些约束来计算自己的尺寸

查看约束信息

实时查看组件的约束信息可以快速帮助我们清楚看到组件之间约束传递的信息，你可以使用LayoutBuilder打印约束信息；父组件传递给子组件一个 BoxConstraints 对象，其中包含了最大和最小的宽度、高度等限制。

Widget build(BuildContext context) {
  return Center(
    child: LayoutBuilder(builder: (context, constraints) {
      // 打印约束信息
      // flutter: BoxConstraints(0.0<=w<=393.0, 0.0<=h<=852.0)
      print(constraints);

      return Container(
        color: Colors.red,
        child: const UnconstrainedBox(
          child: FlutterLogo(
            size: 100,
          ),
        ),
      );
    }),
  );
}

当能拿到约束信息时对于响应式的布局是不是就可以无线发挥了呢

接下来我们进入约束类型部分

紧约束(tight constraints)

紧约束（也叫严格约束）给子级一种获得确切大小的选择。换句话来说就是，它的最大/最小宽度是一致的，高度也一样；子组件的宽度和高度必须在父组件的约束范围内

对应的BoxConstraints信息：

BoxConstraints(w=393.0, h=852.0)

我们来看一个示例：

Container(
  color: Colors.red,
  width: 200,
  height: 200,
  child: const FlutterLogo(
    size: 100,
  ),
);

Container接收到的布局约束为：紧约束，宽高为屏幕的宽高；由于是紧约束，这里设置的width/height属性不会生效

FlutterLogo接收到Container传来的约束，其也是屏幕的约束，紧约束；虽然自身设置了100的宽度，但显然不会生效

因此以上呈现的UI效果为撑满屏幕的红色背景和屏幕宽度的FlutterLogo

宽松约束(loose constraints)

宽松约束的最小宽度/高度为 0（Some boxes loosen the incoming constraints, meaning the maximum is maintained but the minimum is removed, so the widget can have a minimum width and height both equal to zero）

对应的BoxConstraints信息：

BoxConstraints(0.0<=w<=393.0, 0.0<=h<=852.0)

我们来看一个示例：

Center(child: Container(
  color: Colors.red,
  width: 200,
  height: 300,
  child: const FlutterLogo(
    size: 100,
  ),
));

Center接收到屏幕传来的紧约束后，会将紧约束变成宽松约束

Container接收到Center传递来的松约束，其设置了width/height后生效；由于设置了宽高后，其约束变为了紧约束

FlutterLogo接收到的Container传递来的紧约束后，自身的100就不再生效

无边界约束(unbounded constraints)

在某些情况下，widget的约束是无界的或无限的。这意味着最大宽度或最大高度设置为双无穷大

Flutter中ListView，ScollView等组件不会限制子级的宽高，意味着他的子级可以无限大，来看下面的示例：

ListView(
  children: [
    LayoutBuilder(builder: (context, constraints) {
      print(constraints);
      return Text("hahah...");
    })
  ],
);

这里constraints的值为BoxConstraints(w=393.0, 0.0<=h<=Infinity)，由于ListView默认垂直可以滚动，所以他的高度约束就是无穷大

注意
在无边界约束中需要注意，父级必须有明确的宽高界限（不管是显式的还是隐式的），由于自己的约束是无限的如果父级没有明确的约束就会发生异常

更改约束

Flutter中提供了constraints属性来设置子级的约束BoxConstraints，点击去它的构造函数，可以看到它的常用属性方法：

const BoxConstraints({
    this.minWidth = 0.0,
    this.maxWidth = double.infinity,
    this.minHeight = 0.0,
    this.maxHeight = double.infinity,
  });

  /// Creates box constraints that is respected only by the given size.
  BoxConstraints.tight(Size size)
    : minWidth = size.width,
      maxWidth = size.width,
      minHeight = size.height,
      maxHeight = size.height;
// ...

其中：

• 紧约束：tight、tightFor
• 宽松约束：loose

详细信息建议自己查看源码

我们将以上的代码（松约束）修改他的布局约束：

Center(child: Container(
  color: Colors.red,
  width: 200,
  height: 300,
  constraints: BoxConstraints.tight(Size(50, 50)),
  child: const FlutterLogo(
    size: 100,
  ),
));

会发现FlutterLogo的大小变成了50，并且他的布局约束也变成了紧约束(BoxConstraints(w=50,h=50))

紧接着再看看以下示例，如果在紧约束下修改约束会是什么样子的❓

Container(
  color: Colors.red,
  width: 200,
  height: 300,
  constraints: BoxConstraints.tight(Size(50, 50)),
  child: const FlutterLogo(
    size: 100,
  ),
);

当我们运行发现修改了布局约束后竟然没有任何效果，FlutterLogo的大小还是屏幕给过来的紧约束大小，也就是宽度为屏幕的宽度

啊！为什么会这样，不是BoxConstraints可以修改布局约束的吗，到了这里我们就要了解下他的源码渲染逻辑了，我们来看下个章节

布局核心

前面我们知道了Flutter是向下传递约束向上传递大小，那么具体到代码上是怎么回事呢？

其实我们屏幕中看到的内容都是由RenderObjectWidget实现的，RenderObjectWidget的createRenderObject返回的RenderObject对象中的layout和paint负责的具体的绘制信息；layout来传递给子级布局约束，并且获取到子级的真实大小，而paint来负责会知道屏幕的具体位置

前面我们通过在紧约束下修改布局约束后没有任何效果，这里我们从源码的角度来看看怎么回事，flutter中SizeBox提供的紧约束，我们直接看这个继承逻辑：

SizedBox < SingleChildRenderObjectWidget < RenderObjectWidget

其中SizeBox中实现了createRenderObject并返回了RenderConstraintedBox：

RenderConstrainedBox createRenderObject(BuildContext context) {
  return RenderConstrainedBox(
    additionalConstraints: _additionalConstraints,
  );
}

而RenderConstrainedBox中实现了performLayout方法：

void performLayout() {
  final BoxConstraints constraints = this.constraints;
  if (child != null) {
    // 这里直接拿父级的布局约束传递给子级
    // The box constraints most recently received from the parent.
    // BoxConstraints get constraints => super.constraints as BoxConstraints;
    child!.layout(_additionalConstraints.enforce(constraints), parentUsesSize: true);
    size = child!.size;
  } else {
    size = _additionalConstraints.enforce(constraints).constrain(Size.zero);
  }
}

也就是说在严格约束中会直接忽略掉外部设置的布局约束，直接传递父级的约束

趁热打铁再来看看宽松约束的布局过程，这里我们来看Center的继承过程：

Center < Align < SingleChildRenderObjectWidget < RenderObjectWidget

其中Align中实现了createRenderObject并返回了RenderPositionedBox：

RenderPositionedBox createRenderObject(BuildContext context) {
  return RenderPositionedBox(
    alignment: alignment,
    widthFactor: widthFactor,
    heightFactor: heightFactor,
    textDirection: Directionality.maybeOf(context),
  );
}

再来看下RenderPositionedBox中的performLayout方法：

void performLayout() {
  final BoxConstraints constraints = this.constraints;
  final bool shrinkWrapWidth = _widthFactor != null || constraints.maxWidth == double.infinity;
  final bool shrinkWrapHeight = _heightFactor != null || constraints.maxHeight == double.infinity;

  if (child != null) {
    // 这里直接将约束变成宽松约束，并传递给了子级
    child!.layout(constraints.loosen(), parentUsesSize: true);
    size = constraints.constrain(Size(
      shrinkWrapWidth ? child!.size.width * (_widthFactor ?? 1.0) : double.infinity,
      shrinkWrapHeight ? child!.size.height * (_heightFactor ?? 1.0) : double.infinity,
    ));
    alignChild();
  } else {
    size = constraints.constrain(Size(
      shrinkWrapWidth ? 0.0 : double.infinity,
      shrinkWrapHeight ? 0.0 : double.infinity,
    ));
  }
}

通过源码的角度我们了解到紧约束和宽松约束的布局流程以及细节差异，紧约束布局会直接忽略掉自身的约束直接将父级约束传递下去

特殊Widget

在Flutter中有很多特殊的组件需要注意，通常在学习过程中我们应该把它记录下来，以便开发过程中产生一些不解，这里只提供部分widget介绍

Flex/Row、Column

flex是弹性布局类似于css中的flex，而row和column也是flex只是固定了主轴方向；这类组件在布局时不会限制子组件的约束，也就是子组件可以是无限大

Flex(
  direction: Axis.vertical,
  children:[ LayoutBuilder(builder: (context, constraints) {
    print(constraints); // BoxConstraints(0.0<=w<=393.0, 0.0<=h<=Infinity)
    return Container(color: Colors.red,);
  })],
)

Stack/Position

stack、position为定位组件，其内部的布局流程也会稍有不同，以及它的相关数据会影响到布局结果，这里多做介绍，感兴趣的可以上代码试试

开发调试

在开发中，布局约束的问题常常是导致 UI 问题的原因。Flutter 提供了一些工具来帮助开发者调试布局问题

debugPaintSizeEnabled

debugPaintSizeEnabled 是 Flutter 提供的一个开发调试工具，它会在 UI 上绘制边框，帮助开发者查看组件的大小和边界

debugPaintSizeEnabled = true;

LayoutBuilder

LayoutBuilder 是一个可以访问父组件约束并基于这些约束构建子组件的组件。它允许开发者在构建时动态地获取父组件的布局信息，从而更好地控制子组件的布局

查看以上内容部分

vscode devtools

vscode在调试模式下直接快捷键cmd+shift+p然后输入：flutter open devtool

然后选择对应的调试类型

andriod stutio

Chrome DevTool

在终端使用命令的方式运行程序flutter run -d your_device

# 省略部分内容
A Dart VM Service on iPhone 15 Pro is available at: http://127.0.0.1:51441/KLWR3AMJ9pc=/
The Flutter DevTools debugger and profiler on iPhone 15 Pro is available at: http://127.0.0.1:9101?uri=http://127.0.0.1:51441/KLWR3AMJ9pc=/

会看到The Flutter DevTools debugger and profiler这段信息，后面的链接则是调试链接，直接复制到chrome中打开即可

总结

在Flutter开发中，我们需要合理理解和使用不同的布局约束，掌握紧约束、宽松约束和无边界约束的使用场景，以便构建出符合需求的 UI。同时，通过调试工具和布局小部件，开发者可以更高效地解决布局问题

本文将深入探讨 Flutter 中的 Sliver 相关组件，帮助你从基础到高级，逐步掌握如何使用这些组件构建复杂的滚动布局。

1. 什么是 Sliver？

在 Flutter 中，Sliver 代表着一个可以滚动的区域或元素。与传统的滚动组件（如 ListView、GridView）相比，Sliver 是更低层次的构建块，它允许我们通过组合不同的 Sliver 组件，创建高度自定义的滚动效果。

Sliver 的核心概念

• Sliver 的作用：在一个 CustomScrollView 内，Sliver 组件的主要作用是描述如何展示、布局、滚动和删除子组件。它们共同组成了一个完整的滚动视图。
• Sliver 组件家族：Sliver 组件有多种类型，比如 SliverList、SliverGrid、SliverAppBar 等，分别用于不同的布局和滚动效果。

2. Sliver 组件的核心成员

2.1 SliverAppBar

SliverAppBar 是一个非常常用的组件，它可以在滚动过程中动态变化，如展开、收缩或固定在顶部。它是实现复杂滚动效果的首选工具之一。

SliverAppBar(
  title: Text('SliverAppBar Example'),
  expandedHeight: 200.0,
  flexibleSpace: FlexibleSpaceBar(
    title: Text('Expanded Title'),
    background: Image.network('https://via.placeholder.com/400x200', fit: BoxFit.cover),
  ),
  pinned: true,
)

主要属性

• pinned: 设置为 true 时，SliverAppBar 在滚动到顶部时会固定在顶部。
• floating: 设置为 true 时，SliverAppBar 会在用户向上滚动时立刻显示，而无需等待滚动到顶部。
• snap: 配合 floating 属性使用，当设置为 true 时，SliverAppBar 会在滑动过程中自动“吸附”到顶部或消失。

2.2 SliverList

SliverList 是用于创建线性列表的 Sliver 组件，类似于 ListView，但它可以与其他 Sliver 组件组合使用，提供更多的布局控制。

SliverList(
  delegate: SliverChildBuilderDelegate(
    (BuildContext context, int index) {
      return ListTile(
        title: Text('Item #$index'),
      );
    },
    childCount: 20, // 列表项数目
  ),
)

主要属性

• delegate: SliverList 使用 SliverChildDelegate 来构建子组件。常用的实现是 SliverChildBuilderDelegate，可以按需加载和销毁列表项，提升性能。

2.3 SliverGrid

SliverGrid 用于创建网格布局，与 GridView 类似，但更适合与其他 Sliver 组件组合，特别是在需要复杂的滚动效果时。

SliverGrid(
  gridDelegate: SliverGridDelegateWithFixedCrossAxisCount(
    crossAxisCount: 2, // 每行的列数
    mainAxisSpacing: 10.0,
    crossAxisSpacing: 10.0,
    childAspectRatio: 1.0, // 子组件宽高比
  ),
  delegate: SliverChildBuilderDelegate(
    (BuildContext context, int index) {
      return Container(
        color: Colors.blue,
        child: Center(
          child: Text('Grid Item #$index'),
        ),
      );
    },
    childCount: 20, // 网格项数目
  ),
)

2.4 SliverPadding

SliverPadding 用于在 Sliver 组件周围添加内边距，类似于 Padding，但专为 Sliver 组件设计。

SliverPadding(
  padding: EdgeInsets.all(10.0),
  sliver: SliverList(
    delegate: SliverChildBuilderDelegate(
      (BuildContext context, int index) {
        return ListTile(title: Text('Item #$index'));
      },
      childCount: 10,
    ),
  ),
)

2.5 SliverToBoxAdapter

SliverToBoxAdapter 是一个适配器组件，它允许你在 CustomScrollView 中使用普通的、非 Sliver 组件（如 Container、SizedBox 等）。这在需要在滚动视图中插入静态内容时非常有用。

SliverToBoxAdapter(
  child: Container(
    height: 150.0,
    color: Colors.green,
    child: Center(child: Text('Non-Sliver Widget')),
  ),
)

2.6 SliverFillRemaining

SliverFillRemaining 用于填充剩余的可用空间，常用于页面内容不足以填满整个屏幕时。例如，在内容较少时，可以使用它来填充空白区域。

SliverFillRemaining(
  hasScrollBody: false,
  child: Center(
    child: Text('Fill Remaining Space'),
  ),
)

2.7 CustomScrollView

CustomScrollView 是一个可以容纳多个 Sliver 组件的滚动视图容器。它允许你将不同的 Sliver 组件组合在一起，实现复杂的滚动布局。

CustomScrollView(
  slivers: <Widget>[
    SliverAppBar(...),
    SliverList(...),
    SliverGrid(...),
    SliverToBoxAdapter(...),
  ],
)

3. Sliver 与 ListView 的区别

Sliver 组件与 ListView 等传统滚动视图有着显著的区别：

• 灵活性: Sliver 组件提供了更低层次的控制，可以与其他 Sliver 组件组合，以实现复杂的滚动效果和布局。ListView 则封装了大部分滚动逻辑，适合简单的列表场景。
• 性能: Sliver 组件在处理复杂滚动视图时更加高效，尤其是在需要延迟加载和懒加载时。ListView 在常规场景下也有很好的性能表现。
• 应用场景: ListView 适用于大多数常规的滚动列表，而 Sliver 组件则用于需要精细控制滚动行为和布局的复杂场景。

4. 高级用法与最佳实践

4.1 使用 SliverPersistentHeader 创建浮动头部

SliverPersistentHeader 允许你创建一个在滚动时保持固定或部分固定的头部组件。通过实现自定义的 SliverPersistentHeaderDelegate，你可以控制头部的布局和滚动行为。

SliverPersistentHeader(
  pinned: true,
  delegate: _SliverAppBarDelegate(
    minHeight: 60.0,
    maxHeight: 200.0,
    child: Container(
      color: Colors.orange,
      child: Center(
        child: Text('Persistent Header'),
      ),
    ),
  ),
)

4.2 处理滚动冲突

在复杂布局中，嵌套多个滚动视图（如 NestedScrollView 与 SliverList）时，可能会遇到滚动冲突。为了避免这种情况，建议：

• 明确滚动控制的优先级，可以通过调整 physics 属性或使用 NotificationListener 来监听滚动事件并进行优化。
• 使用 ScrollController 手动同步或控制多个滚动视图的行为。

4.3 SliverFillViewport 与分页效果

SliverFillViewport 可以用于实现分页效果，通过确保每个子组件都占据整个视窗的高度或宽度，实现类似页面切换的体验。

SliverFillViewport(
  delegate: SliverChildBuilderDelegate(
    (BuildContext context, int index) {
      return Container(
        color: index.isEven ? Colors.blue : Colors.red,
        child: Center(
          child: Text('Page $index'),
        ),
      );
    },
    childCount: 2,
  ),
)

01

错误定律： 别人都不对，那就是自己的错。

02

效果定律： 在伤口上落泪和在伤口上撒盐，效果是一样的。

03

嫉妒定律： 人们嫉妒的往往不是陌生人的飞黄腾达，而是身边的人飞黄腾达。

04

方圆定律： 人不能太方，也不能太圆，一个会伤人，一个会让人远离你，因此人要椭圆。

05

口水定律： 当你红得让人流口水时，关于你的口水就会多起来。

06

利用定律： 不怕被人利用，就怕你没用。

07

成就定律： 如果你没有成就，你就会因平庸而没有朋友；如果你有了成就，你就会因卓越而失去朋友。

08

馅饼定律： 当天上掉下馅饼的时候，小心地上也有个陷阱在等着你。

09

错误定律： 人们日常所犯的最大错误，是对陌生人太客气，而对亲密的人太苛刻。

10

评价定律： 不必好奇别人怎样评价你，想想你是怎样评价他的。

11

葱蒜定律： 太拿自己当根葱的人，往往特别善于：装蒜。

12

流言定律： 流言是写在水上的字，注定不持久，但是又传得飞快。

13

害怕定律： 生手怕熟手，熟手怕高手，高手怕失手。

14

难过定律： 为你的难过而快乐的，是敌人；为你的快乐而快乐的，是朋友；为你的难过而难过的，就是那些该放进心里的人。

15

傻瓜定律： 把人家都当傻瓜，那一定是自己傻到了家。

16

吃亏定律： 只要你不认为自己吃了亏，别人也就一定没占着便宜。

17

风雨定律： 爱情经得起风雨，却经不起平淡；友情经得起平淡，却经不起风雨！

故事一：

有人问农夫：“种了麦子了吗？”农夫：“没，我担心天不下雨。”那人又问：“那你种棉花没？”农夫：“没，我担心虫子吃了棉花。”那人再问：“那你种了什么？”农夫：“什么也没种，我要确保安全。”

感悟： 一个不愿付出、不愿冒风险的人，一事无成对他来说是再自然不过的事。

故事二：

两马各拉一货车。一马走得快，一马慢吞吞。于是主人把后面的货全搬到前面。后面的马笑了：“切！越努力越遭折磨！”谁知主人后来想：既然一匹马就能拉车，干嘛养两匹？最后懒马被宰掉吃了。这就是经济学中的懒马效应。

感悟： 让你觉得你可有可无，你被踢开的日子就不远了。

故事三：

一禅师见一蝎子掉到水里，决心救它。谁知一碰，蝎子蛰了他手指。禅师无惧，再次出手，岂知又被蝎子狠狠蛰了一次。旁有一人说：它老蜇人，何必救它？禅师答：蜇人是蝎子的天性，而善是我的天性，我岂能因为它的天性，而放弃了我的天性。

感悟： 我们的错误在于，因为外界的缘故而过多地改变了自己。

故事四：

曼德拉曾被关押27年，受尽虐待。

他就任总统时，邀请了三名曾虐待过他的看守到场。

当曼德拉起身恭敬地向看守致敬时，在场所有人乃至整个世界都静了下来。

他说：当我走出囚室，迈过通往自由的监狱大门时，我已经清楚，自己若不能把悲痛与怨恨留在身后，那么我仍在狱中。

感悟： 原谅他人，其实是升华自己。

故事五：

一个小镇中，一位商人开了一个加油站，生意特别好，第二个来了，开了一个餐厅，第三个开了一个超市，这片很快就繁华了。另一个小镇，一位商人开了一个加油站生意特别好，第二个来了，开了第二个加油站，第三个、第四个恶性竞争大家都没得玩。

感悟： 一味走别人的路，必将堵死自己的路。

故事六：

一只乌鸦在飞行的途中碰到回家的鸽子。鸽子问：你要飞到哪？乌鸦说：其实我不想走，但大家都嫌我的叫声不好，所以我想离开。鸽子告诉乌鸦：别白费力气了！如果你不改变声音，飞到哪都不会受欢迎的。

感悟： 如果你希望一切，都能变得更加美好，就从改变自己开始。

故事七：

小和尚负责清扫寺院落叶，每天要很长时间才能扫完。有人对他说：“你打扫前用力摇树，把落叶统统摇下来，明天就不用打扫了。”小和尚觉得很对，就高兴地照办了，可第二天院子里如往日一样满地落叶。无论你今天怎么用力，明天的落叶还是会飘下来。

感悟： 活在当下。

故事八：

野猪和马一起吃草，野猪时常使坏，不是践踏青草，就是把水搅浑。马十分恼怒，一心想要报复，便去请猎人帮忙。猎人说除非马套上辔头让他骑。马报复心切，答应了猎人的要求。猎人骑上马打败了野猪，随后又把马牵回去，拴在马槽边，马失去了原先的自由。

感悟： 你不能容忍他人，就会给自己带来不幸。

浏览器的进程模型

何为进程？

程序运行需要有它自己专属的内存空间，可以把这块内存空间简单的理解为进程

每个应用至少有一个进程，进程之间相互独立，即使要通信，也需要双方同意。

何为线程？

有了进程后，就可以运行程序的代码了。

为了方便理解，我们可以把运行代码的「人」称之为「线程」，

一个进程至少有一个线程，所以在进程开启后会自动创建一个线程来运行代码，该线程称之为主线程。

如果程序需要同时执行多块代码，主线程就会启动更多的线程来执行代码，所以一个进程中可以包含多个线程。

浏览器有哪些进程和线程？

浏览器是一个多进程多线程的应用程序

浏览器内部工作极其复杂。

为了避免相互影响，为了减少连环崩溃的几率，当启动浏览器后，它会自动启动多个进程。

可以在浏览器的任务管理器中查看当前的所有进程

其中，最主要的进程有：

1. 浏览器进程

   主要负责界面显示、用户交互、子进程管理等。浏览器进程内部会启动多个线程处理不同的任务。

2. 网络进程

   负责加载网络资源。网络进程内部会启动多个线程来处理不同的网络任务。

3. 渲染进程（本节课重点讲解的进程）

   渲染进程启动后，会开启一个渲染主线程，主线程负责执行 HTML、CSS、JS 代码。

   默认情况下，浏览器会为每个标签页开启一个新的渲染进程，以保证不同的标签页之间不相互影响。

将来该默认模式可能会有所改变，有兴趣的同学可参见chrome官方说明文档

渲染主线程是如何工作的？

渲染主线程是浏览器中最繁忙的线程，需要它处理的任务包括但不限于：

• 解析 HTML
• 解析 CSS
• 计算样式
• 布局
• 处理图层
• 每秒把页面画 60 次
• 执行全局 JS 代码
• 执行事件处理函数
• 执行计时器的回调函数
• ……

思考题：为什么渲染进程不适用多个线程来处理这些事情？

要处理这么多的任务，主线程遇到了一个前所未有的难题：如何调度任务？

比如：

• 我正在执行一个 JS 函数，执行到一半的时候用户点击了按钮，我该立即去执行点击事件的处理函数吗？
• 我正在执行一个 JS 函数，执行到一半的时候某个计时器到达了时间，我该立即去执行它的回调吗？
• 浏览器进程通知我“用户点击了按钮”，与此同时，某个计时器也到达了时间，我应该处理哪一个呢？
• ……

渲染主线程想出了一个绝妙的主意来处理这个问题：排队

1. 在最开始的时候，渲染主线程会进入一个无限循环
2. 每一次循环会检查消息队列中是否有任务存在。如果有，就取出第一个任务执行，执行完一个后进入下一次循环；如果没有，则进入休眠状态。
3. 其他所有线程（包括其他进程的线程）可以随时向消息队列添加任务。新任务会加到消息队列的末尾。在添加新任务时，如果主线程是休眠状态，则会将其唤醒以继续循环拿取任务

这样一来，就可以让每个任务有条不紊的、持续的进行下去了。

整个过程，被称之为事件循环（消息循环）

若干解释

何为异步？

代码在执行过程中，会遇到一些无法立即处理的任务，比如：

• 计时完成后需要执行的任务 —— setTimeout、setInterval
• 网络通信完成后需要执行的任务 -- XHR、Fetch
• 用户操作后需要执行的任务 -- addEventListener

如果让渲染主线程等待这些任务的时机达到，就会导致主线程长期处于「阻塞」的状态，从而导致浏览器「卡死」

渲染主线程承担着极其重要的工作，无论如何都不能阻塞！

因此，浏览器选择异步来解决这个问题

使用异步的方式，渲染主线程永不阻塞

面试题：如何理解 JS 的异步？

参考答案：

JS是一门单线程的语言，这是因为它运行在浏览器的渲染主线程中，而渲染主线程只有一个。

而渲染主线程承担着诸多的工作，渲染页面、执行 JS 都在其中运行。

如果使用同步的方式，就极有可能导致主线程产生阻塞，从而导致消息队列中的很多其他任务无法得到执行。这样一来，一方面会导致繁忙的主线程白白的消耗时间，另一方面导致页面无法及时更新，给用户造成卡死现象。

所以浏览器采用异步的方式来避免。具体做法是当某些任务发生时，比如计时器、网络、事件监听，主线程将任务交给其他线程去处理，自身立即结束任务的执行，转而执行后续代码。当其他线程完成时，将事先传递的回调函数包装成任务，加入到消息队列的末尾排队，等待主线程调度执行。

在这种异步模式下，浏览器永不阻塞，从而最大限度的保证了单线程的流畅运行。

JS为何会阻碍渲染？

先看代码

<h1>Mr.Yuan is awesome!</h1>
<button>change</button>
<script>
  var h1 = document.querySelector('h1');
  var btn = document.querySelector('button');

  // 死循环指定的时间
  function delay(duration) {
    var start = Date.now();
    while (Date.now() - start < duration) {}
  }

  btn.onclick = function () {
    h1.textContent = '袁老师很帅！';
    delay(3000);
  };
</script>

点击按钮后，会发生什么呢？

<见具体演示>

任务有优先级吗？

任务没有优先级，在消息队列中先进先出

但消息队列是有优先级的

根据 W3C 的最新解释:

随着浏览器的复杂度急剧提升，W3C 不再使用宏队列的说法

在目前 chrome 的实现中，至少包含了下面的队列：

• 延时队列：用于存放计时器到达后的回调任务，优先级「中」
• 交互队列：用于存放用户操作后产生的事件处理任务，优先级「高」
• 微队列：用户存放需要最快执行的任务，优先级「最高」

添加任务到微队列的主要方式主要是使用 Promise、MutationObserver

例如：

// 立即把一个函数添加到微队列
Promise.resolve().then(函数)

浏览器还有很多其他的队列，由于和我们开发关系不大，不作考虑

闭包是JavaScript中的一个重要概念，它允许函数访问并操作其外部作用域的变量。本文将通过编程题和分析题，帮助读者更好地理解和掌握闭包的使用。

什么是闭包

闭包是指内部函数可以访问外部函数作用域中的变量，即使外部函数已经执行完毕。这种特性使得闭包在JavaScript中非常强大和灵活。

编程题

题目1：实现一个计数器

要求：编写一个函数，返回一个计数器函数，每次调用计数器函数时，计数器加1。

function createCounter() {
  let count = 0;
  return function() {
    return ++count;
  };
}

const counter = createCounter();
console.log(counter()); // 1
console.log(counter()); // 2
console.log(counter()); // 3

题目2：实现一个记忆函数

要求：编写一个函数，返回一个记忆函数，记忆函数可以缓存之前计算的结果，避免重复计算。

function memoize(fn) {
  const cache = {};
  return function(...args) {
    const key = JSON.stringify(args);
    if (cache[key]) {
      return cache[key];
    } else {
      const result = fn.apply(this, args);
      cache[key] = result;
      return result;
    }
  };
}

const add = (a, b) => a + b;
const memoizedAdd = memoize(add);
console.log(memoizedAdd(1, 2)); // 3
console.log(memoizedAdd(1, 2)); // 3 (从缓存中获取)

分析题

题目1：闭包中的变量作用域

以下代码的输出是什么？为什么？

function outer() {
  let x = 10;
  return function inner() {
    console.log(x);
  };
}

const innerFunc = outer();
innerFunc(); // 输出什么？

答案：输出 10。因为闭包 inner 函数保留了对外部函数 outer 中变量 x 的引用，即使 outer 函数已经执行完毕。

题目2：闭包中的循环问题

以下代码的输出是什么？如何修正？

for (var i = 0; i < 3; i++) {
  setTimeout(function() {
    console.log(i);
  }, 1000);
}

答案：输出 3 3 3。因为 var 声明的变量是函数作用域的，闭包共享同一个 i 变量，当 setTimeout 执行时，循环已经结束，i 的值为 3。

修正方法：使用 let 声明变量，或者使用闭包捕获每次循环的 i 值。

// 使用 let
for (let i = 0; i < 3; i++) {
  setTimeout(function() {
    console.log(i);
  }, 1000);
}

// 使用闭包
for (var i = 0; i < 3; i++) {
  (function(i) {
    setTimeout(function() {
      console.log(i);
    }, 1000);
  })(i);
}

总结

闭包是JavaScript中的一个重要特性，它允许函数访问外部作用域的变量。通过编程题和分析题，我们可以更好地理解闭包的使用场景和注意事项。掌握闭包对于编写高质量的JavaScript代码至关重要。

TX = Transmit（发送）
RX = Receive（接收）

换了个位置，设备断网了
设备断网后，发送 AT 指令测试：

AT+SYSINFO: 0,No Network
AT+CEREG: 1,0
AT+CGATT: 0
AT+CIP: +CME ERROR:50

`

首先看 AT+CIP 返回的：

+CME ERROR:50

这个错误说明模组没有成功注册移动网络，结合：

AT+SYSINFO: 0,No Network

基本可以确定不是服务器问题，而是设备没有入网。

继续检查：

AT+CGDCONT?

发现：

+CGDCONT: 1,"IP","","0.0.0.0",0,0

APN 为空，说明没有配置运营商接入点。

重新配置 APN：

AT+CIPSHUT

AT+CGDCONT=1,"IP","CMIOT"

AT+SAVE

AT+REBOOT

重启后测试：

AT+CIPSEND=5

hello

发送成功，说明设备网络恢复。

烧录下吧，最终原因：

APN未配置
→ 无法注册数据网络
→ CGATT=0
→ TCP连接失败

把Heap全部保存下来。形成heap.hprof文件,其中3240289是pid

jmap -dump:live,format=b,file=heap.hprof 3240289

Heap 名词概念

Eclipse MAT（内存分析器工具）是分析 JVM 堆 Dump 文件的强大工具。当尝试分析内存相关的问题时，它非常方便。在 Eclipse MAT 内存分析的报告中会显示对象两种类型的 Heap 信息：

• Shallow heap
• Retained heap

我们主要讨论它们之间的区别，并探讨它们的计算方式。

例如，假设你的应用程序具有这样的对象模型，如图 1 （SH指 shallow heap， b 指的是 byte）：

图1：内存中的对象

• 对象 A 持有对象 B 和 C 的引用。
• 对象 B 持有对象 D 和 E 的引用。
• 对象 C 持有对象 F 和 G 的引用。

另外，我们假设每个对象占用 10 个字节的内存。在这种场景下，我们开始分析Heap大小的过程。

Shallow Heap

对象的 Shallow heap 是其自身在内存中的大小。说的直白点就是，在没有引用其他对象的情况下本身占用的内存大小，不包括它引用的对象。

• 针对数组类型（数组或集合）的对象，它的大小是数组元素对象的大小总和。
• 针对非数组类型的对象，它的大小就是对象与它所有的成员变量大小的总和。

由于在我们的示例中，每个对象占用大约 10 个字节，因此每个对象的 Shallow heap 大小为 10 个字节。

Retained Heap

Retained heap: 当对象不再被引用时，垃圾回收器所能回收的总内存，包括对象自身所占据的内存，以及仅能够通过该对象引用到的其他对象所占据的内存： 对象本身的大小 + 引用的其他对象的大小。

换句话说，Retained Size就是当前对象被GC后，从Heap上总共能释放掉的内存。

B 的 Retained Heap 大小

从图 1 中，可以注意到对象 B 持有对象 D 和 E 的引用。因此，如果对象 B 是从内存中被垃圾回收，则将不再有对对象 D 和 E 的引用。这意味着此时 D 和 E 也可以被垃圾收集。

Retained heap 指的就是在垃圾回收特定对象时将释放的内存量。

因此，B 的保留堆大小为：= B 的 shallow heap 大小 + D 的 shallow heap 大小 + E 的 shallow heap 大小 = 10 bytes + 10 bytes + 10 bytes = 30 bytes。因此，B 对象的 Retained heap 大小为 30 字节

C 的 Retained Heap 大小

对象 C 拥有对象 F 和 G 的引用。如果对象 C 是从内存中垃圾回收的，将不再持有对对象 F 和 G 的引用。这意味着此时 F 和 G 也可以被垃圾回收。因此，C 的 Retained Heap 大小为：= C 的 shallow heap 大小 + F 的 shallow heap 大小 + G 的 shallow heap 大小 = 10 bytes + 10 bytes + 10 bytes = 30 bytes。因此，C 对象的 Retained heap 大小为 30 字节。

A 的 Retained Heap 大小

对象 A 持有对象 B 和 C 的引用，而对象 B 和 C 又持有对对象 D、E 以及 F、G 的引用。因此，如果对象 A 是从内存中垃圾回收的，则将不再有对 B、C、D、E、F 和 G 对象的引用。

基于此理解，我们来计算下 A 的 Retained Heap 大小。

A 的 Retained Heap 大小为：= A 的 shallow heap 大小 + B 的 shallow heap 大小 + C 的 shallow heap 大小 + D 的 shallow heap 大小 + E 的 shallow heap 大小 + F 的 shallow heap 大小 + G 的 shallow heap 大小 = 10 bytes + 10 bytes + 10 bytes + 10 bytes + 10 bytes + 10 bytes + 10 bytes = 70 bytes。

最后我们可以得出，A 的 Retained heap 大小是 70 字节。

D、E、F、G 的 Retained Heap 大小

D 的 Retained heap 大小与其 Shallow heap 大小相同，就是 10 个字节，因为 D 不持有对任何其他对象的引用。因此，如果 D 获得了垃圾回收，则不会从内存中删除其他的任何对象。同理，E、F 和 G 的 Retained heap 大小也只有 10 个字节。

图 2：对象的 Shallow and Retained Heap 大小（SH指 shallow heap， RH指 Retained heap，b 指的是 byte）

多一些引用的变数

为了进一步加深对 Shallow heap 和 Retained heap 的理解。在下面的示例中，让对象 H 开始持有对 B 的引用（注意：对象 B 已经被对象 A 引用了）。现在 A 和 H 都持有对象 B 的引用。在这种情况下， Retained heap 计算逻辑将会发生什么变化呢？

图3： 新增对 B 的引用

在这种情况下，对象 A 的 Retained heap 大小将从之前的 70 减小到 40 个字节。为什么？

如果对象 A 被垃圾回收了，则将仅会影响 C、F 和 G 对象的引用。因此，仅对象 C、F 和 G 将被垃圾回收。

另一方面，由于 H 持有对 B 的活动引用，因此对象 B、D 和 E 将继续存在于内存中。因此，即使 A 被垃圾回收，B、D 和 E 也不会从内存中删除。

于是可以计算出， A 的 Retained heap 大小为：= A 的 shallow heap 大小 + C 的 shallow heap 大小 + F 的 shallow heap 大小 + G 的 shallow heap 大小 = 10 bytes + 10 bytes + 10 bytes + 10 bytes = 40 bytes。

A 的 Retained heap 大小将变为 40 个字节。所有其他对象 Retained heap 大小将保持不变，因为它们的引用没有变化。

其他名词

out going（查看对象为什么消耗内存, 查看对象引用的其他对象）

表示的是当前对象，引用了外部对象

可以使用右键 with outgoing references, 此类对象持有的其他对象。在 Attributes 中可以看到观察对象持有的成员。

in going（查看对象被谁引用）

表示的是当前查看的对象，被外部应用。

可以使用右键 with ingoing references, 其他对象持有的此类对象。

path to GC root （对象没被释放掉的引用）

到GC root的路径

这里有一个特殊的节点GC Roots，这就是 reference chain的起点。

Merge Shortest path to GC root （对象没被释放掉的引用）

到GC root的最短路径，右键 merge shortest path to gc root -> exclude all phantim/weak/soft etc. references：查看此对象没被释放掉的原因，只保留强引用。

Histogram

堆内所有类的统计信息，包含类的实例数量和占用的空间。如果此处包含了自己的类就需要注意是否此类创建过多。

默认的大小单位是 Bytes，可以在 Window – Preferences—Memory Analyzer-- 菜单中设置单位。

可以通过filter搜索出自己的类，可以看到内存中共有32049817个Column对象，占用了13GB内存。

Dominator Tree

列出了堆中最大的对象，并且引用此对象的其他对象。

如上图，可以很清晰的看到最大的对象是 XXXService @ 0x7fd1752c6f20 这个对象占用了大量内存，次对象被类加载器所引用。

Top Consumers

按类、对象、包分组，列出最消耗资源的类、对象、包。

Duplicate Classes

对多个类加载器加载的类进行分析。

Leak Suspects

内存泄漏报告和系统概述

Top Components

列出内存用量超过堆总量1%的组件。