并发 on 牛哥聊技术

Go 程序中 context 的职责与边界

Mon, 26 Feb 2024 15:30:00 +0800

写在前面

每个 Go 函数签名里都见过它：

1

func (s *Service) GetUser(ctx context.Context, id int64) (*User, error)

ctx 是什么？做什么用的？很多新人对这个第一参数的认知止步于"传超时和取消信号"——但 context 在 Go 里的角色远不止于此。

它是 请求级别的数据通道 + 生命周期管理——理解清楚 context，是写出生产级 Go 服务的基础。

本文从设计动机到实战陷阱，把 context 讲透。

一、context 在解决什么问题

设想一个 Web 请求处理链路：

1
2
3
4
5


HTTP Handler → Service → Repository → DB Driver
 ↓
 RPC Client → 上游 Service
 ↓
 Cache

每一层都有自己的 IO，整个链路可能耗时几百 ms。如果在某一层之间发生：

客户端关闭连接：HTTP handler 应该立刻停止处理，下游的 DB 查询也该取消
整体超时：5 秒超时到了，每一层都该立刻返回
传递请求级数据：traceId、userId、rpc deadline 怎么沿调用链传

每一层都自己写一套"超时控制 + 取消信号 + 数据传递"——重复劳动 + 容易漏。

Go 设计了 context 作为统一抽象——沿调用链向下游透明传递取消、截止时间、键值对。

二、context 的接口

1
2
3
4
5
6


type Context interface {
 Deadline() (deadline time.Time, ok bool)
 Done() <-chan struct{}
 Err() error
 Value(key any) any
}

四个方法：

Deadline：何时超时（如果有）
Done：通道，关闭时表示"该停了"
Err：context 的终止原因（取消 / 超时）
Value：取请求级键值对

三、几种创建 context 的方式

1. 起点：Background / TODO

1
2


ctx := context.Background() // 顶层，永不 cancel
ctx := context.TODO() // 占位，意为"未来要补"

Background 是所有派生 context 的根——通常在 main、初始化代码、HTTP handler 入口创建。

2. WithCancel：手动取消

1
2
3
4
5
6
7
8


ctx, cancel := context.WithCancel(parent)
defer cancel() // 必须！

go func() {
 if shouldStop() {
 cancel() // 手动触发取消
 }
}()

派生出的 ctx 在 cancel() 调用后立刻关闭 Done channel。

3. WithTimeout / WithDeadline

1
2
3
4
5


ctx, cancel := context.WithTimeout(parent, 5*time.Second)
defer cancel()

ctx, cancel := context.WithDeadline(parent, deadline)
defer cancel()

到时间自动取消。

4. WithValue：传请求级数据

1
2
3
4
5
6
7


type ctxKey string
const userIDKey ctxKey = "userID"

ctx := context.WithValue(parent, userIDKey, "u-12345")

// 下游
userID := ctx.Value(userIDKey).(string)

注意：key 必须是自定义类型——不能用 string，否则容易撞键。

四、context 的派生关系

context 是不可变的——每次 With 都返回一个新 context：

flowchart TD
 Bg[Background] --> Req[WithCancel]
 Req --> A[WithTimeout 5s]
 A --> A1[WithValue userID]
 A --> A2[WithValue traceID]
 Req --> B[WithCancel]

派生关系是树形——parent 取消时所有 child 自动取消。这是 context 的核心性质。

五、典型用法

1. HTTP handler 透传

1
2
3
4
5


func handler(w http.ResponseWriter, r *http.Request) {
 ctx := r.Context() // Go 自带：客户端断开时 ctx 自动 cancel
 user, err := userService.GetByID(ctx, id)
 // ...
}

r.Context() 是 Go 标准库给的 ——客户端断连时这个 ctx 自动 cancel。

2. 整体超时

1
2
3
4
5


ctx, cancel := context.WithTimeout(r.Context(), 3*time.Second)
defer cancel()

// 整个链路 3 秒超时，无论哪一层卡住都会触发
result, err := service.HeavyOp(ctx)

3. 传递 traceId

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


type ctxKey string
const traceIDKey ctxKey = "traceID"

func TraceMiddleware(next http.Handler) http.Handler {
 return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 traceID := r.Header.Get("X-Trace-Id")
 if traceID == "" { traceID = uuid.NewString() }
 ctx := context.WithValue(r.Context(), traceIDKey, traceID)
 next.ServeHTTP(w, r.WithContext(ctx))
 })
}

// 下游
traceID, _ := ctx.Value(traceIDKey).(string)
log.Printf("[trace=%s] querying user...", traceID)

4. 数据库查询

database/sql 自带 context 支持：

1

rows, err := db.QueryContext(ctx, "SELECT * FROM user WHERE id = ?", id)

context 取消时 query 立刻返回 context.Canceled 错误。

5. 监听 Done

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


func longRunning(ctx context.Context) error {
 for {
 select {
 case <-ctx.Done():
 return ctx.Err()
 case msg := <-ch:
 handle(msg)
 }
 }
}

任何长循环都该监听 ctx.Done——否则 context 取消你的代码不知道，照样跑。

六、几个最常被踩的坑

1. 忘了 defer cancel

1

ctx, _ := context.WithTimeout(parent, 5*time.Second) // ❌ 忽略 cancel

不调 cancel 会导致 context 资源泄漏——它会一直保留对父 context 的引用，直到 deadline 到。go vet 会警告。

正确：

1
2


ctx, cancel := context.WithTimeout(parent, 5*time.Second)
defer cancel()

2. context.Background() 用错地方

1
2
3
4


func someService() {
 ctx := context.Background() // ❌ 应该接收上游 ctx
 db.QueryContext(ctx, ...)
}

Background 只在程序入口用。函数应该接收 ctx 参数，否则上游取消信号传不进来。

3. 用 string 作 Value 的 key

1

ctx := context.WithValue(parent, "userID", "u-123") // ❌

string key 容易撞——尤其是其他库也用了 “userID”。永远用自定义类型。

4. 把 context 塞 struct 里

1
2
3


type Service struct {
 ctx context.Context // ❌ 反模式
}

context 应该作为参数传递，不应该作为字段保存——否则 context 的"请求级"语义被破坏。

5. 用 context 传业务参数

1
2
3


ctx = context.WithValue(ctx, "orderID", "1234")
// 下游
orderID := ctx.Value("orderID").(string)

反模式——业务参数应该走函数参数，context 只传"基础设施数据"（traceID、userID、deadline）。

6. 不监听 Done

1
2
3
4
5


func work(ctx context.Context) {
 for i := 0; i < 1000000; i++ {
 // ... 不检查 ctx
 }
}

context 取消了你的循环还在跑——白白浪费资源。长循环必须 select 监听 ctx.Done。

七、context 在 RPC 框架里

gRPC、Dubbo、Thrift 这些 RPC 框架都内置 context 支持——ctx 跨进程传递 deadline 和元数据：

1
2
3
4
5
6
7


// 客户端
ctx := metadata.AppendToOutgoingContext(ctx, "x-trace-id", traceID)
resp, err := client.GetUser(ctx, req)

// 服务端
md, _ := metadata.FromIncomingContext(ctx)
traceID := md.Get("x-trace-id")[0]

ctx 让"分布式 trace"变成框架自动处理的事。

八、什么不该用 context 传

context 的定位是基础设施级数据 + 生命周期——不是万能的"请求级 store"。

✅ 适合 context 传：

traceID / requestID
userID（轻量身份标识）
tenantID
locale / language
deadline / cancellation

❌ 不该用 context 传：

业务参数（如 OrderID）→ 函数参数
大对象（如完整 User）→ 函数参数
配置（如数据库连接）→ 通过依赖注入

如果 context 里塞太多东西——说明你把 context 当成『万能容器』用了，需要重新审视设计。

九、context 与 goroutine

启动 goroutine 时永远要传 ctx：

1
2
3
4
5
6
7
8


go func(ctx context.Context) {
 select {
 case <-ctx.Done():
 return
 case msg := <-ch:
 process(msg)
 }
}(ctx)

不传 ctx 的 goroutine 是"野生 goroutine"——主流程结束它还在跑，资源泄漏 + 数据错乱。

errgroup 的 context

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


g, ctx := errgroup.WithContext(parent)

for _, task := range tasks {
 task := task
 g.Go(func() error {
 return process(ctx, task) // 用 group 派生的 ctx
 })
}

if err := g.Wait(); err != nil {
 return err
}

任一 goroutine 失败时 errgroup 自动 cancel ctx——其他 goroutine 立刻退出。这是最优雅的"并发任务 + 全员协同退出"模式。

十、什么时候需要把 ctx 写出来

新人写 Go 经常困惑——“什么时候要在函数签名里加 ctx？"。

经验法则：

函数会做 IO 操作（DB / HTTP / RPC）→ 接收 ctx
函数会启 goroutine → 接收 ctx
函数链路长，可能被中途取消 → 接收 ctx
纯计算、纯转换、辅助函数 → 不需要

1
2
3
4
5
6
7


// ✓ 需要
func GetUser(ctx context.Context, id int64) (*User, error)
func Process(ctx context.Context, items []Item) error

// ✗ 不需要
func formatName(name string) string
func calculateDiscount(amount float64) float64

按"是否会 IO/并发/可能被中途打断"判断——一目了然。

小结

把全文压一句：

context 是 Go 的『请求级数据通道』——不只是 cancel 信号，而是『生命周期 + 元数据』的统一传递。

工程实战清单：

顶层用 Background，函数链路传 ctx
WithTimeout 永远配 defer cancel
value 的 key 用自定义类型
业务参数走函数参数，不要走 ctx
长循环 select 监听 Done
goroutine 永远传 ctx，配 errgroup 更优雅
ctx 不塞 struct，永远当参数传

把 context 用对，你的 Go 服务在"超时控制 + trace 跟踪 + 优雅退出"这三件事上几乎不会再出问题。

ExecutorCompletionService 与 CompletableFuture：场景与选型

Sat, 25 Apr 2020 16:30:00 +0800

一段几乎所有人都写过的反面代码

需要并发调用 5 个外部接口，最后聚合结果——多数人这么写：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


ExecutorService pool = Executors.newFixedThreadPool(5);
List<Future<Result>> futures = new ArrayList<>();
for (Task task : tasks) {
 futures.add(pool.submit(() -> callApi(task)));
}

List<Result> results = new ArrayList<>();
for (Future<Result> f : futures) {
 results.add(f.get()); // ★ 阻塞等
}

看起来挺合理。但有个性能陷阱——futures 的顺序是提交顺序，不是完成顺序。

假设 5 个接口耗时是：

接口	耗时
A	3s
B	1s
C	5s
D	2s
E	1s

写在 for 循环里 f.get() 时——第一次 get 拿 A 的结果（3s）→ 然后 B 的（已经完成，立刻返回）→ 然后 C（再等 2s）→ D 已完成 → E 已完成。

总耗时是 5s（最慢的那个）。这没问题。

但中间 3s ~ 5s 之间 D、E、B 都已经完成了，结果还在原地等 C——如果"处理结果"也耗时（比如把结果写 DB），**整个流水线被最慢的任务卡住 **。

理想情况是：谁先完成，就先处理谁的结果——而不是按提交顺序傻等。ExecutorCompletionService 就是为这件事设计的。

一、CompletionService 是什么

CompletionService 是 JDK 5 就有的接口，但很多人不知道它存在：

1
2
3
4
5
6


public interface CompletionService<V> {
 Future<V> submit(Callable<V> task);
 Future<V> take() throws InterruptedException; // 阻塞，拿一个完成的
 Future<V> poll(); // 非阻塞
 Future<V> poll(long timeout, TimeUnit unit); // 超时
}

它内部维护一个已完成任务队列——任何任务完成后立刻进队列，take() 从队列取出一个。

flowchart LR
 Submit[submit×N] --> Pool[ThreadPool]
 Pool --> Done[已完成队列]
 Take[take/poll] -.从队列读.-> Done

先完成的先被取走——而不是按提交顺序等。

二、用法对比

反例：朴素 Future.get()

1
2
3
4
5
6
7
8
9


ExecutorService pool = Executors.newFixedThreadPool(5);
List<Future<Result>> futures = tasks.stream()
 .map(t -> pool.submit(() -> callApi(t)))
 .collect(toList());

for (Future<Result> f : futures) {
 Result r = f.get(); // 按提交顺序阻塞
 handle(r);
}

正解：CompletionService

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


ExecutorService pool = Executors.newFixedThreadPool(5);
CompletionService<Result> ecs = new ExecutorCompletionService<>(pool);

for (Task t : tasks) {
 ecs.submit(() -> callApi(t));
}

for (int i = 0; i < tasks.size(); i++) {
 Result r = ecs.take().get(); // 先完成的先返回
 handle(r);
}

唯一变化是 take() 替代了 f.get()——但行为完全不同。

三、性能差异：一个真实数字

5 个任务，耗时分别 1s、1s、2s、3s、5s。handle() 处理每个结果耗时 1s。

方案	耗时
朴素 Future.get()	5s + 5×1s = 10s （处理被串行化）
CompletionService	5s + 1s = 6s （处理跟着完成走）

任务越多、处理越重，差距越大。这是 CompletionService 的真正价值——让"等待"和"处理"重叠。

四、典型场景

1. 并发调多个外部接口聚合

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


public List<UserVO> batchGetUsers(List<Long> ids) {
 CompletionService<UserVO> ecs = new ExecutorCompletionService<>(pool);
 for (Long id : ids) {
 ecs.submit(() -> rpcGetUser(id));
 }
 List<UserVO> result = new ArrayList<>();
 for (int i = 0; i < ids.size(); i++) {
 try {
 result.add(ecs.take().get());
 } catch (Exception e) {
 log.warn("partial failure", e);
 }
 }
 return result;
}

2. 并发处理大批量数据，结果立刻入库

1
2
3
4
5
6
7
8


CompletionService<Record> ecs = new ExecutorCompletionService<>(pool);
for (Long id : ids) {
 ecs.submit(() -> heavyCompute(id));
}
for (int i = 0; i < ids.size(); i++) {
 Record r = ecs.take().get();
 repository.save(r); // 一完成就入库，不傻等
}

3. “找到第一个就返回"语义

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


public Result findFirstHit(List<Source> sources) {
 CompletionService<Result> ecs = new ExecutorCompletionService<>(pool);
 List<Future<Result>> futures = sources.stream()
 .map(s -> ecs.submit(() -> tryQuery(s)))
 .collect(toList());

 try {
 for (int i = 0; i < sources.size(); i++) {
 Result r = ecs.take().get();
 if (r != null) {
 return r; // 第一个非空结果返回
 }
 }
 return null;
 } finally {
 futures.forEach(f -> f.cancel(true)); // 取消其他
 }
}

五、和 CompletableFuture 的区别

JDK 8 的 CompletableFuture 是更强大的并发工具——能不能用它替代 CompletionService？

1
2
3
4
5
6


List<CompletableFuture<Result>> futures = tasks.stream()
 .map(t -> CompletableFuture.supplyAsync(() -> callApi(t), pool))
 .collect(toList());

CompletableFuture.allOf(futures.toArray(new CompletableFuture[0]))
 .thenApply(v -> futures.stream().map(CompletableFuture::join).collect(toList()));

CompletableFuture 能做更多事——chain / combine / handle 异常 / async。但它默认是"等所有完成"或"等任意完成”，没有" 按完成顺序逐个处理"的内置语义。

要做到"按完成顺序处理"，CompletableFuture 需要这样：

1
2
3
4
5


List<CompletableFuture<Result>> futures = tasks.stream()
 .map(t -> CompletableFuture.supplyAsync(() -> callApi(t), pool))
 .collect(toList());

futures.forEach(f -> f.thenAccept(r -> handle(r)));

也行——但每个 future 完成时回调在 ForkJoinPool / 自定义池里执行，handle 之间是并发的。如果 handle 本身要按顺序做（写 DB 不能并发），还是 CompletionService 更适合。

	CompletionService	CompletableFuture
按完成顺序处理	✓	△ 用回调
顺序处理 handle	✓ 主线程串行	△ 要再加锁/单线程
链式组合 / 异常处理	△	✓ 强
async/await 风格	✗	✓
学习曲线	低	中

简单的"并发任务 + 顺序处理结果"——CompletionService 更直接。复杂的并发编排——CompletableFuture。

六、踩坑提醒

1. take() 是阻塞的

主线程会卡住。如果上层有超时要求：

1
2
3
4


Future<Result> f = ecs.poll(500, TimeUnit.MILLISECONDS);
if (f == null) {
 // 超时
}

2. take() 调用次数要等于 submit 次数

少调一次会漏处理一个结果，多调一次会无限阻塞。用 for 循环的次数严格等于 submit 数。

3. 异常需要在 .get() 里 try

1
2
3
4
5
6
7
8
9


for (int i = 0; i < n; i++) {
 Future<Result> f = ecs.take();
 try {
 Result r = f.get();
 handle(r);
 } catch (ExecutionException e) {
 log.error("task failed", e.getCause());
 }
}

ExecutionException 包装了原始异常，getCause() 才是业务真正抛的异常。

4. 共享线程池的污染

1
2


CompletionService<X> ecsA = new ExecutorCompletionService<>(sharedPool);
CompletionService<Y> ecsB = new ExecutorCompletionService<>(sharedPool);

ECS 用的是底层 pool，不会把 A、B 的结果混淆——但池子被两边任务挤占。共享池容量要够。

5. cancel 后 take 可能拿到 cancelled future

如果你 cancel 了某些任务，take 可能拿到已 cancelled 的 future，调用 f.get() 会抛 CancellationException。一定要 catch。

6. JDK 内置实现内部用 LinkedBlockingQueue

队列无界——任务慢、消费慢时队列会无限增长。海量任务场景需要自己实现 ECS（用有界队列）或者限流。

七、一份生产级模板

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


public <T, R> List<R> parallelExecute(
 Collection<T> tasks,
 Function<T, R> action,
 ExecutorService pool,
 long timeout,
 TimeUnit unit) {

 CompletionService<R> ecs = new ExecutorCompletionService<>(pool);
 List<Future<R>> futures = tasks.stream()
 .map(t -> ecs.submit(() -> action.apply(t)))
 .collect(toList());

 long deadline = System.nanoTime() + unit.toNanos(timeout);
 List<R> results = new ArrayList<>();
 try {
 for (int i = 0; i < tasks.size(); i++) {
 long remaining = deadline - System.nanoTime();
 Future<R> f = ecs.poll(remaining, TimeUnit.NANOSECONDS);
 if (f == null) {
 log.warn("partial timeout, completed {}/{}", i, tasks.size());
 break;
 }
 try {
 results.add(f.get());
 } catch (ExecutionException e) {
 log.error("task failed", e.getCause());
 }
 }
 } catch (InterruptedException e) {
 Thread.currentThread().interrupt();
 } finally {
 futures.forEach(f -> f.cancel(true)); // 主流程结束时取消未完成任务
 }
 return results;
}

小结

把全文压一句：

ExecutorCompletionService 让『先完成的任务先被处理』——这是 Java 并发里最被低估的一个工具。

什么时候选它：

多个任务并发执行
需要按完成顺序逐个处理结果
处理逻辑本身耗时 / 串行
不需要 CompletableFuture 的复杂编排

工程纪律：

submit 几次就要 take 几次
异常 catch ExecutionException + getCause
主流程结束 cancel 未完成任务
海量任务时换有界队列实现

下次再写"并发调 N 个外部接口然后处理结果"时——别再 for 循环 f.get() 了。

Redis 分布式锁演进：六个版本的取舍与陷阱

Thu, 22 Mar 2018 19:30:00 +0800

为什么需要分布式锁

单机环境下用 synchronized 或 ReentrantLock 就能搞定的事，一旦上了微服务、跑在多台机器上，就立刻变成另一个量级的问题。

举几个最典型的场景：

下单扣库存：同一个 SKU 在多实例同时被下单，怎么保证库存不卖超？
定时任务防重：每个微服务实例都跑了定时调度，怎么让"全局只有一个执行"？
接口幂等：用户连点两次，怎么保证只处理一次？
资源独占：同一个用户、同一个文件，同时只能由一个请求修改？

进程内的锁帮不了你，因为它们彼此根本不知道对方存在。要在跨进程、跨机器的环境里"约定一个谁能进谁不能进"，就需要一个* 所有节点都信任的第三方*——Redis 是最常见的选择。

但 Redis 分布式锁这件事，看着简单，做对极难。下面我们从最朴素的写法一路演进，把每个版本里"看似能用其实不行"的坑摊开。

姿势一：`SETNX` + `EXPIRE`（错误示范）

刚接触分布式锁的人，最常写出来的版本是这样：

1
2
3
4
5
6
7
8
9


// 反面教材
public boolean tryLock(String key, String value, long expireSeconds) {
 Long result = jedis.setnx(key, value); // 只在 key 不存在时才设置
 if (result == 1) {
 jedis.expire(key, expireSeconds); // 设置过期时间
 return true;
 }
 return false;
}

逻辑看起来很自然——抢到了就设过期时间防止死锁。但这里藏着一个致命缺陷：

SETNX 和 EXPIRE 是两条命令，不是原子操作。

如果在 SETNX 成功之后、EXPIRE 之前进程崩了、网络抖了、Redis 主从切换了，那这把锁就永远没有过期时间 ——所有后续请求都会被它挡住，直到运维手动删 key。

姿势二：`SET key value NX EX` 一条命令搞定

Redis 2.6.12 之后，SET 命令支持了原子的 NX + EX 选项，这就是真正可用的"上锁"操作：

1
2
3
4


public boolean tryLock(String key, String value, long expireSeconds) {
 String result = jedis.set(key, value, "NX", "EX", expireSeconds);
 return "OK".equals(result);
}

NX 保证只在 key 不存在时才生效，EX 同时设置过期时间，整个操作是原子的，没有了"SETNX 后 EXPIRE 前"那个空窗。

但这只是把"上锁"做对了，“解锁"还藏着一个更隐蔽的坑。

姿势三：解锁的"误删别人锁"问题

一个看似无害的解锁实现：

1
2
3
4


// 反面教材
public void unlock(String key) {
 jedis.del(key);
}

设想一个时序：

时刻	客户端 A	客户端 B
t1	加锁成功，过期时间 10s
t2	业务执行卡住了 12s（GC、网络等）
t3		锁已过期，B 加锁成功
t4	A 醒来，调用 unlock 直接 DEL
t5		B 还在执行，锁却没了

A 删掉了 B 的锁。后续的 C 又能进来，锁的互斥语义彻底失效。

正确做法：解锁前先验证 value

加锁时把 value 设成一个唯一标识（比如 UUID），解锁时验证 value 是自己的才删：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


String requestId = UUID.randomUUID().toString();
jedis.set(key, requestId, "NX", "EX", 10);

// 解锁
String script =
 "if redis.call('get', KEYS[1]) == ARGV[1] then " +
 " return redis.call('del', KEYS[1]) " +
 "else " +
 " return 0 " +
 "end";
jedis.eval(script, Collections.singletonList(key), Collections.singletonList(requestId));

注意：判断 + 删除必须用 Lua 脚本保证原子性。如果分两步——先 GET 再 DEL，又会回到"判断后 DEL 前锁过期了"的老问题。

姿势四：业务执行时间不可控——锁自动续期（看门狗）

即便解锁做对了，“业务执行时间超过锁过期时间"本身就是个隐患。永远把过期时间设很长？万一这个客户端进程真的死了，锁就长时间得不到释放。

更优雅的做法是自动续期：客户端在持有锁期间，启动一个后台线程定时把锁的过期时间往后顺。

伪代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// 上锁成功后，启动一个守护线程
ScheduledExecutorService watchdog = Executors.newSingleThreadScheduledExecutor();
watchdog.scheduleAtFixedRate(() -> {
 // 每 expireSeconds/3 触发一次续期
 String script =
 "if redis.call('get', KEYS[1]) == ARGV[1] then " +
 " return redis.call('expire', KEYS[1], ARGV[2]) " +
 "else return 0 end";
 jedis.eval(script, ..., requestId, expireSeconds);
}, expireSeconds / 3, expireSeconds / 3, TimeUnit.SECONDS);

业务结束后停掉 watchdog 并解锁。

这套机制如果自己手写很容易出错，所以——绝大多数生产项目直接用 Redisson。

姿势五：Redisson——工业级实现

Redisson 是 Redis 的 Java 客户端，把分布式锁封装得相当成熟，自带可重入、自动续期、公平锁、读写锁等高级特性。

1
2
3
4
5
6
7
8
9


RedissonClient redisson = Redisson.create(config);
RLock lock = redisson.getLock("order:1001");

try {
 lock.lock(); // 默认 30s 过期，看门狗每 10s 自动续期一次
 // 业务逻辑
} finally {
 lock.unlock();
}

Redisson 内部干了什么：

加锁用 Lua 脚本，原子完成"判断 + 设置 + 续期间隔记录”
可重入通过 Hash 结构记录"持有者 + 重入次数”
看门狗每 1/3 过期时间触发一次续期，业务不结束锁不释放
解锁也用 Lua 脚本，安全地把重入计数减一直到删除

业务侧能做到"加锁就像 synchronized 一样自然"，这正是它的价值。

⚠️ 看门狗的关键陷阱：看门狗只在你不显式指定 leaseTime 时才会启用——也就是 lock.lock() / lock.lock(-1, ...) / tryLock(waitTime, unit)。一旦你调用 lock(leaseTime, unit) 或 tryLock(waitTime, leaseTime, unit) 显式传了 leaseTime，看门狗会被关闭 ，锁到期后直接释放，不再续期。这是初学者最容易踩的坑——看着代码"用了 Redisson 应该有看门狗"，实际锁早就过期了。

姿势六：Redlock 与"红锁争议"

前面所有方案都建立在一个假设上——Redis 单机或主从是可靠的。但现实中有两个隐患：

单机 Redis 是单点，挂了所有锁都丢
Redis 主从有异步复制延迟。主刚加完锁还没复制到从，主挂了，从被选为新主，新主上没有这把锁——新的客户端就能再加一次

Redis 作者 antirez 为此提出了 Redlock 算法：

部署 N 个互相独立的 Redis 实例（比如 5 个），客户端尝试在这 N 个实例上依次加锁。只有在 大多数实例（≥ N/2 + 1） 都加锁成功，且总耗时小于锁过期时间，才认为加锁成功。

sequenceDiagram
 Client->>Redis-1: SET NX EX
 Client->>Redis-2: SET NX EX
 Client->>Redis-3: SET NX EX
 Client->>Redis-4: SET NX EX
 Client->>Redis-5: SET NX EX
 Note over Client: 至少 3/5 成功才算获得锁
 Note over Client: 释放时向所有节点发 DEL

Redisson 也实现了 Redlock：RedissonRedLock。

Martin Kleppmann 的反驳

不过 Redlock 在学界一直有争议。著名分布式系统专家 Martin Kleppmann 写过一篇 “How to do distributed locking”，指出 Redlock 在以下场景下并不安全：

客户端 GC 暂停——加锁后业务卡了几秒，锁早过期了，业务以为自己还持有锁继续操作
时钟漂移——节点之间的系统时钟不一致，过期时间判断会失准

他的结论是：对正确性要求极高的场景，应该用 ZooKeeper / etcd 这类基于一致性协议的系统；Redis 锁更适合" 性能优先、偶尔失误可接受"的场景。

工程上多数业务场景用 Redisson 单实例锁就足够——性能高、用法简单；只有对正确性极敏感的少数场景才上 ZooKeeper。

各姿势对比

姿势	安全性	复杂度	推荐度
`SETNX` + `EXPIRE`	✗	低	别用
`SET NX EX`	△	低	学习用，生产不够
加 value 校验解锁	◯	中	自己造轮子的最低底线
加 Watchdog 续期	◯	高	自己造轮子的上限
Redisson 单实例	◯	低	绝大多数业务的最佳选择
Redlock / RedissonRed	◯+	中	可用但有争议，慎用
ZooKeeper / etcd 锁	✓	中高	强一致性要求场景

实战中的几条建议

永远用 tryLock 带超时，不要 lock() 死等
加锁粒度尽量细——别把整个订单创建过程锁起来，只锁库存扣减那一段
业务和锁解耦——业务方法里只关心 lock.tryLock() / lock.unlock()，不要散落 Redis 命令
过期时间 ≥ 业务最长执行时间 × 2，给极端情况留缓冲，再配合 watchdog
解锁放 finally——别让一段异常跳过解锁
日志里打出 requestId——锁出问题排查链路全靠它

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


// 生产推荐写法（依赖看门狗自动续期 → 不传 leaseTime）
RLock lock = redisson.getLock("stock:" + skuId);
boolean locked = false;
try {
 // 等 3 秒；获取后由看门狗每 10 秒续期一次，业务不结束锁不释放
 locked = lock.tryLock(3, TimeUnit.SECONDS);
 if (!locked) {
 throw new BusinessException("操作过于频繁，请稍后再试");
 }
 // 业务逻辑
} finally {
 if (locked && lock.isHeldByCurrentThread()) {
 lock.unlock();
 }
}

isHeldByCurrentThread() 这个判断很重要——避免在某些异常路径下解了不属于自己的锁。

如果你确实需要"超时强制释放"作为兜底（防止业务永远卡死把锁吃住），就显式传 leaseTime： lock.tryLock(3, 30, TimeUnit.SECONDS)。但要清楚这种写法没有看门狗——leaseTime 必须 ≥ 业务最长执行时间 × 2，否则中途锁掉的风险会回来。

小结

Redis 分布式锁这件事，入门一行代码，做对几十行细节。

把这条演进路径压缩成一句话：

从 SETNX 到 Redisson，每一步演进都是在堵一个『看似能用其实不行』的坑。

工程上的选择反而很简单：

新项目：直接上 Redisson，别造轮子
极致正确性：上 ZooKeeper / etcd
学习理解原理：把上面六种姿势从头写一遍

理解了这些演进，下次再有人问你"Redis 锁怎么用"，你就不会只回一句 SET NX EX 了——你会先反问：" 你的业务能容忍偶尔失效吗？锁持有时间可控吗？需要可重入吗？"