最小示例#

1
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
2
    List<Future<String>> futures = new ArrayList<>();
3
    for (int i = 0; i < 100_000; i++) {
4
        int id = i;
5
        futures.add(executor.submit(() -> {
6
            Thread.sleep(Duration.ofSeconds(1));
7
            return "task-" + id;
8
        }));
9
    }
10
    for (var f : futures) {
11
        f.get();
12
    }
13
}

十万个任务各睡一秒，总耗时依然接近一秒。换成固定大小的平台线程池，你会等很久。

在 Spring Boot 中启用#

Spring Boot 3.2+ 只需要一行配置：

1
spring:
2
  threads:
3
    virtual:
4
      enabled: true

Tomcat 的请求处理线程、@Async 的执行器都会切换成虚拟线程。

常见误区#

1. 不要池化虚拟线程。 它们本来就是廉价的，用完即弃。需要限流时用 Semaphore，而不是缩小线程池。
2. CPU 密集型任务没有收益。 虚拟线程解决的是「等待」问题，不是「计算」问题。
3. 小心 synchronized 造成的 pinning。 在 JDK 21 中，虚拟线程在 synchronized 块里阻塞会钉住载体线程。能换成 ReentrantLock 就换。可以用 -Djdk.tracePinnedThreads=full 排查。
4. ThreadLocal 要克制。 线程数量暴涨后，每个线程一份 ThreadLocal 的内存开销会被放大。

小结#

虚拟线程不是银弹，但对大多数 IO 密集的业务后端来说，它能让代码回到最朴素的样子。升级 JDK 21 之后，先把它开在非核心服务上压测一遍，数据会告诉你答案。

1. JVM 参数#

内存别给满，留出系统和堆外空间。常用的 G1 参数如下（以 8GB 堆为例）：

1
java -Xms8G -Xmx8G \
2
  -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
3
  -XX:MaxGCPauseMillis=200 \
4
  -XX:+UnlockExperimentalVMOptions \
5
  -XX:+DisableExplicitGC -XX:+AlwaysPreTouch \
6
  -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 \
7
  -XX:G1HeapRegionSize=8M -XX:G1ReservePercent=20 \
8
  -XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 \
9
  -XX:InitiatingHeapOccupancyPercent=15 \
10
  -jar paper.jar --nogui

-Xms 与 -Xmx 设置成一样，避免堆扩缩带来的抖动。

2. 视距与模拟距离#

这是收益最大的一项。在 server.properties 与 paper-world-defaults.yml 里：

• view-distance：保持 8 左右。
• simulation-distance：降到 4~6，实体和红石只在近处运行。

玩家几乎感觉不到，但 CPU 压力会明显下降。

3. 实体管理#

• 限制每个区块的怪物上限与刷怪频率。
• 定期清理掉落物，但要给玩家提前提示。
• 大型农场（村民交易所、刷怪塔）要单独评估，村民的寻路 AI 是出了名的重。

4. 区块与世界#

• 使用 /chunky 提前预生成地图，避免玩家探索时实时生成造成卡顿。
• 设置世界边界，别让地图无限膨胀。
• 定期备份，并且定期验证备份可恢复。没验证过的备份只是一种心理安慰。

5. 用数据说话#

不要凭感觉调参数。Paper 自带的 /spark profiler 是我的首选：

1
/spark profiler start
2
# 等待 5~10 分钟，覆盖高峰期
3
/spark profiler stop

看火焰图，找到占用 tick 时间最多的插件或实体，再对症下药。

6. 插件管理#

• 插件够用就好，每个插件都是潜在的性能与安全风险。
• 更新前先在测试服验证。
• 看到不再维护的插件，尽早找替代品。

小结#

调优的本质是：测量、定位、改一处、再测量。十二年下来最大的体会是，稳定比花哨更重要。玩家记得的是流畅的体验，而不是你装了多少插件。

原则一：你来决策，AI 来执行#

把 AI 当作一位速度很快、但缺乏上下文的搭档。需求怎么拆、边界怎么定、取舍怎么做，这些由人来决定；查文档、写样板代码、补测试、重构，这些交给 AI。

原则二：上下文决定质量#

同样一句「帮我加个接口」，给了项目约定和现有代码，结果会好很多。我一般会提供：

• 相关文件与调用关系；
• 项目的编码规范（例如统一返回结构、异常处理方式）；
• 明确的验收标准。

原则三：小步提交，逐步验证#

不要一次让 AI 改几十个文件。把任务拆小，每一步都跑测试、看 diff。出现问题时，回滚的成本也很低。

我常用的场景#

一个提醒#

AI 生成的代码，你需要对它负责。不理解的代码不要合入，涉及安全、权限、资金的逻辑，必须人工逐行审阅。

小结#

好的使用方式是「放大自己」而不是「替代自己」。把重复劳动交出去，把精力留给真正需要判断力的地方，这才是 AI 工具最大的价值。

读懂 EXPLAIN#

1
EXPLAIN SELECT id, name FROM user WHERE age = 25 AND city = 'Shanghai';

重点关注几列：

• type：访问方式。从好到差大致是 const > ref > range > index > ALL。出现 ALL 意味着全表扫描。
• key：实际使用的索引。
• rows：预估扫描行数，越小越好。
• Extra：Using index 表示覆盖索引；Using filesort、Using temporary 需要警惕。

最左前缀原则#

联合索引 (city, age, name) 可以支撑：

• WHERE city = ?
• WHERE city = ? AND age = ?
• WHERE city = ? AND age = ? AND name = ?

但无法有效支撑只写 age 或 name 的查询。设计联合索引时，把区分度高、使用频率高的列放在前面。

覆盖索引#

如果查询的列都在索引里，MySQL 不需要回表：

1
-- 索引 (city, age, name)
2
SELECT city, age, name FROM user WHERE city = 'Shanghai';

回表是随机 IO，能避免就避免。

常见的索引失效场景#

1. 对索引列使用函数或运算：WHERE DATE(create_time) = '2026-01-01'。
2. 隐式类型转换：字符串列用数字去比较。
3. 以通配符开头的模糊查询：LIKE '%abc'。
4. OR 连接的条件中，有一边没有索引。
5. 联合索引没有遵循最左前缀。

分页深翻页#

1
-- 慢：需要扫描并丢弃前 100 万行
2
SELECT * FROM orders ORDER BY id LIMIT 1000000, 20;
3

4
-- 快：利用上一页的最后一个 id
5
SELECT * FROM orders WHERE id > 1000000 ORDER BY id LIMIT 20;

小结#

优化的流程很朴素：先定位慢 SQL，再看执行计划，然后调整索引或改写查询，最后用真实数据验证。不要为了加索引而加索引，每个索引都会拖慢写入、占用空间。

什么是优雅停机#

收到停止信号后：

1. 不再接收新请求；
2. 等待进行中的请求处理完成（带超时）；
3. 关闭线程池、连接池等资源；
4. 进程退出。

开启配置#

Spring Boot 2.3+ 内置支持：

1
server:
2
  shutdown: graceful
3

4
spring:
5
  lifecycle:
6
    timeout-per-shutdown-phase: 30s

默认是 immediate，即立即关闭。

配合负载均衡#

仅仅应用内优雅还不够。流量还在往一个即将退出的实例上打，就会出错。一个稳妥的顺序是：

1. 先把实例从负载均衡中摘除（或让就绪探针失败）；
2. 等待几秒，让流量完全切走；
3. 再发送 SIGTERM，触发优雅停机。

在 Kubernetes 中可以用 preStop 钩子留出缓冲时间：

1
lifecycle:
2
  preStop:
3
    exec:
4
      command: ["sh", "-c", "sleep 10"]
5
terminationGracePeriodSeconds: 60

注意：terminationGracePeriodSeconds 必须大于 preStop 时间加上应用的停机超时。

自己的资源也要收尾#

对于自己创建的线程池、消息消费者，要在 @PreDestroy 或 SmartLifecycle 中显式停止：

1
@PreDestroy
2
public void shutdown() {
3
    executor.shutdown();
4
    try {
5
        if (!executor.awaitTermination(20, TimeUnit.SECONDS)) {
6
            executor.shutdownNow();
7
        }
8
    } catch (InterruptedException e) {
9
        executor.shutdownNow();
10
        Thread.currentThread().interrupt();
11
    }
12
}

小结#

优雅停机是「应用 + 基础设施」共同的事。把它配置好，发布就不再是一件提心吊胆的事情。

第一版：SETNX#

1
Boolean ok = redis.opsForValue().setIfAbsent("lock:order:1001", "1");
2
if (Boolean.TRUE.equals(ok)) {
3
    try {
4
        // 业务逻辑
5
    } finally {
6
        redis.delete("lock:order:1001");
7
    }
8
}

问题：如果进程在持有锁时崩溃，锁永远不会被释放。

第二版：加上过期时间#

必须把「加锁」和「设置过期」做成一个原子操作：

1
Boolean ok = redis.opsForValue()
2
    .setIfAbsent("lock:order:1001", token, Duration.ofSeconds(30));

不要先 SETNX 再 EXPIRE，两步之间崩溃就又回到了死锁。

第三版：防止误删#

假如业务执行超过 30 秒，锁已经过期并被别人拿走，此时你的 delete 会把别人的锁删掉。

做法：加锁时写入唯一标识（token），解锁时先比较再删除，并且这两步要用 Lua 脚本保证原子性：

1
if redis.call("get", KEYS[1]) == ARGV[1] then
2
    return redis.call("del", KEYS[1])
3
else
4
    return 0
5
end

第四版：续期#

业务耗时不确定时，固定的过期时间要么太短要么太长。解决方案是「看门狗」：持有锁期间，后台线程定时延长过期时间。

自己实现很容易出错，推荐直接使用 Redisson：

1
RLock lock = redissonClient.getLock("lock:order:1001");
2
lock.lock(); // 默认开启看门狗，自动续期
3
try {
4
    // 业务逻辑
5
} finally {
6
    lock.unlock();
7
}

还要考虑什么#

• 主从切换：主节点宕机、锁尚未同步到从节点时，可能出现两个客户端同时持锁。对一致性要求极高的场景，不要只依赖 Redis，考虑数据库唯一约束或 ZooKeeper 等方案。
• 业务幂等：锁只是减少并发冲突，不应该是唯一的正确性保证。关键操作务必做幂等设计。
• 锁粒度：锁越细越好，避免把整个服务串行化。

小结#

分布式锁是工具，不是保险箱。理解它的边界，再配合幂等与兜底，才能写出真正可靠的系统。