南柯一梦

Java 虚拟线程实战：用同步写法扛住十万并发

Mon, 28 Sep 2026 00:00:00 GMT

为什么需要虚拟线程#

传统的 Java 线程是对操作系统线程的一层薄封装，一个线程大约占用 1MB 栈空间，创建和切换成本都不低。于是我们才有了线程池、回调、CompletableFuture、响应式编程这一整套「为了省线程而牺牲可读性」的方案。

虚拟线程（Virtual Thread，JDK 21 正式）换了个思路：线程由 JVM 调度，成本极低，可以轻松创建几十万个。阻塞时，JVM 会把它从载体线程（carrier thread）上卸下来，让出 CPU。

结论：可以继续用最直观的同步代码，同时拿到接近异步的吞吐。

最小示例#

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 的执行器都会切换成虚拟线程。

常见误区#

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

小结#

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

开了十二年服，我总结的 Paper 服务器调优清单

Sun, 20 Sep 2026 00:00:00 GMT

服务器卡，十有八九不是机器不行，而是配置没有调。下面是我这些年踩坑后沉淀出的清单。

1. JVM 参数#

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

Terminal window

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 结对编程：我的日常工作流

Sat, 12 Sep 2026 00:00:00 GMT

过去一年，AI 工具已经深度嵌进了我的日常开发。这里分享几条我自己总结的原则。

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

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

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

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

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

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

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

我常用的场景#

场景	做法
阅读陌生代码	让 AI 梳理调用链，我再对照源码确认
写单元测试	先给被测方法，让 AI 列出边界用例，再逐个实现
排查线上问题	把日志与堆栈贴给 AI，请它给出几个可验证的假设
重构	先让 AI 说明改动计划，我确认后再动手
写文档与提交信息	直接交给 AI，我只做审阅

一个提醒#

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

小结#

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

MySQL 索引与执行计划：从 EXPLAIN 看懂慢查询

Sat, 05 Sep 2026 00:00:00 GMT

慢查询是后端工程师绕不开的话题。排查的第一步，永远是 EXPLAIN。

读懂 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，能避免就避免。

常见的索引失效场景#

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

分页深翻页#

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，再看执行计划，然后调整索引或改写查询，最后用真实数据验证。不要为了加索引而加索引，每个索引都会拖慢写入、占用空间。

Spring Boot 优雅停机：发布时不再丢请求

Fri, 28 Aug 2026 00:00:00 GMT

每次发布都会收到几条 502 报警？很可能是应用没有「优雅」地停下来。

什么是优雅停机#

收到停止信号后：

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

开启配置#

Spring Boot 2.3+ 内置支持：

1
server:
2
  shutdown: graceful
3

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

默认是 immediate，即立即关闭。

配合负载均衡#

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

先把实例从负载均衡中摘除（或让就绪探针失败）；
等待几秒，让流量完全切走；
再发送 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
}

小结#

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

Redis 分布式锁：从 SETNX 到 Redisson 的坑

Sat, 15 Aug 2026 00:00:00 GMT

分布式锁看上去只是「加锁、解锁」两步，实际上一个坑接一个坑。

第一版：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 等方案。
业务幂等：锁只是减少并发冲突，不应该是唯一的正确性保证。关键操作务必做幂等设计。
锁粒度：锁越细越好，避免把整个服务串行化。

小结#

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