《后端架构设计·分布式与数据一致性》附录 B Go/Java 分布式组件对照

对照的边界

这份附录做结构对照，不做语言排名。同一个分布式问题，Go 与 Java 的差异主要来自三处：

1. 运行时模型：goroutine 由 Go runtime 调度，虚拟线程由 JVM 调度并挂载到载体线程；
2. 标准库与生态：哪些能力内置、哪些依赖第三方库、哪些默认关闭；
3. 团队经验：同样正确的代码，熟悉程度决定它会不会在故障时被改坏。

分布式正确性由协议、时钟假设、幂等设计和故障处理决定，不由语言决定。下面的每一组对照都遵循同一格式：先给语义差异，再给代码示意，最后给选择提示。

关于代码口径，需要明确两点：

• 所有 Java 片段都是示例代码，未在本机运行，用于说明 API 形状与语义，不构成 JDK 21 实测结论；具体 API 在目标版本中的状态（正式、预览、废弃）使用前必须核对对应 JEP。
• Go 片段按 Go 1.26 的主线语义书写，只作结构示意；附录不附带基准数字，也不声称任何性能结论。

一、并发单元：goroutine 与虚拟线程

调度与阻塞语义

goroutine 的阻塞是 runtime 可见的：网络读写、channel 操作、time.Sleep 都会让出执行权；sync.Mutex 阻塞时 runtime 会 park 当前 goroutine，让 M 去运行其他任务。虚拟线程的阻塞由 JDK 的 I/O 适配层处理，遇到无法挂起的操作会占住载体线程。

两者都不适合无限扩张的 CPU 密集任务。goroutine 数量超过可用并行度只会增加调度开销；虚拟线程数量超过 CPU 并行度也不会让计算变快。并发单元解决的是"等待"，不是"计算"。

一个容易踩的差异：pinning

在 JDK 21 上，虚拟线程在 synchronized 块内阻塞会 pin 住载体线程，导致载体线程无法服务其他虚拟线程。JDK 24 的 JEP 491 缓解了这一问题，但目标版本低于 24 时仍需注意：把长临界区改成 ReentrantLock，或者缩短 synchronized 范围。

Go 侧对应的问题是系统调用阻塞。普通文件 I/O 或 cgo 调用可能占住 M，runtime 会视情况创建新的 M；这不等价于 pinning，但同样会让"goroutine 很轻"的直觉失效。

代码对照

Go 的工作池，省略错误聚合细节：

// file: internal/worker/pool.go
// tier: L2
// verify: go test ./internal/worker
func Run(ctx context.Context, workers int, job func(context.Context) error) error {
	var wg sync.WaitGroup
	errCh := make(chan error, workers)
	for i := 0; i < workers; i++ {
		wg.Add(1)
		go func() {
			defer wg.Done()
			if err := job(ctx); err != nil {
				errCh <- err
			}
		}()
	}
	wg.Wait()
	close(errCh)
	for err := range errCh {
		return err
	}
	return nil
}

这段代码只返回第一个错误，不主动取消其他任务。生产代码通常用 errgroup.WithContext，让首个错误取消整个组。

Java 的虚拟线程执行器：

// 示例代码，未在本机运行
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    Future<String> future = executor.submit(() -> inventory.reserve(orderId));
    return future.get(300, TimeUnit.MILLISECONDS);
}

ExecutorService 在较新的 JDK 中实现了 AutoCloseable，try-with-resources 会等待任务结束再关闭。超时值只是示例，真实预算应由调用链决定。

二、任务编排、超时与取消

取消传播的关键差异

Go 的取消是协作式的：context 被取消后，收到信号的函数必须自己检查 ctx.Done() 并返回。没有检查的代码会继续执行，取消只是"建议"。

Java 的 Future.cancel(true) 会尝试中断线程，但 CompletableFuture 的取消默认不会中断底层任务：它把 future 标记为取消，任务本身可能仍在运行。依赖 CompletableFuture.cancel 释放资源，是一个常见误解。

两边真正的共同点是：取消必须端到端设计。HTTP 或 gRPC 的 deadline 要在入口解析，逐跳传递，每一跳都要在阻塞点响应。只在一层设置超时，下游仍会继续工作，资源不会释放。

代码对照

Go 的超时与取消：

// file: internal/order/reserve.go
// tier: L2
// verify: go test ./internal/order
func Reserve(ctx context.Context, sku string, qty int) error {
	ctx, cancel := context.WithTimeout(ctx, 300*time.Millisecond)
	defer cancel()

	done := make(chan error, 1)
	go func() { done <- callInventory(ctx, sku, qty) }()

	select {
	case err := <-done:
		return err
	case <-ctx.Done():
		return ctx.Err()
	}
}

Java 的组合与超时：

// 示例代码，未在本机运行
CompletableFuture<Order> order = CompletableFuture.supplyAsync(() -> createOrder(cmd));
CompletableFuture<Reservation> stock = CompletableFuture.supplyAsync(() -> reserve(cmd));

return order.thenCombine(stock, Order::withReservation)
            .orTimeout(300, TimeUnit.MILLISECONDS);

两个片段都只解决"等待有上限"，没有解决"超时后另一侧是否已提交"。后者需要幂等键与查询接口，见 8.2 消费端幂等、去重表与恰好一次的真实边界 。

三、锁：进程内互斥

两种锁都只解决进程内互斥。跨进程互斥是分布式锁，涉及租约、续约与 fencing token，见 10.2 分布式锁：租约、fencing token 与 Redis 边界 。把进程内锁的经验直接搬到 Redis 上，是锁相关事故的主要来源。

StampedLock 的边界

StampedLock 提供乐观读：先拿 stamp，读取共享数据，再用 validate(stamp) 判断期间是否有写。它适合读多写少、读路径短且能容忍重试的场景。

三个限制必须记住：

1. 不可重入，递归调用会死锁；
2. 不支持条件变量；
3. 乐观读期间读到的是快照，validate 失败必须重读，不能把旧值当结果。

Go 的 RWMutex 没有乐观读，读锁会阻塞写锁；它的语义更简单，但读多写少时开销也更稳定。

代码对照

Go 的读写锁：

// file: internal/catalog/cache.go
// tier: L2
// verify: go test -race ./internal/catalog
type Catalog struct {
	mu    sync.RWMutex
	items map[string]Item
}

func (c *Catalog) Get(sku string) (Item, bool) {
	c.mu.RLock()
	defer c.mu.RUnlock()
	it, ok := c.items[sku]
	return it, ok
}

Java 的带超时锁：

// 示例代码，未在本机运行
private final ReentrantLock lock = new ReentrantLock();
public boolean tryReserve(String sku) throws InterruptedException {
    if (!lock.tryLock(50, TimeUnit.MILLISECONDS)) {
        return false;
    }
    try {
        return doReserve(sku);
    } finally {
        lock.unlock();
    }
}

Java 片段展示的是"获取失败快速返回"，不是"锁一定安全"。锁超时后调用方仍需决定重试、降级还是失败。

四、时间：墙上时钟与单调时钟

单调时钟的细节

Go 的 time.Time 可以同时携带墙上时间与单调读数。Sub、Before、Since 在双方都有单调读数时使用单调部分，因此不受 NTP 回拨影响；一旦经过序列化、Round(0) 或手工构造，单调读数就会丢失，比较退化为墙上时间。

Java 的 Instant 只有墙上时间，没有单调分量。测量耗时必须用 System.nanoTime()，不能用 Instant.now() 相减。Clock 的价值在于可注入：测试中可以固定时间、推进时间，生产中使用系统时钟。

代码对照

Go 注入时钟：

// file: internal/clock/clock.go
// tier: L1
// verify: go test ./internal/clock
type Clock interface {
	Now() time.Time
}

type SystemClock struct{}

func (SystemClock) Now() time.Time { return time.Now() }

Java 注入时钟：

// 示例代码，未在本机运行
public final class OrderClock {
    private final Clock clock;
    public OrderClock(Clock clock) { this.clock = clock; }
    public Instant now() { return Instant.now(clock); }
}

测试中传入 Clock.fixed(...) 可以让时间相关逻辑可重复；但固定时钟不能替代对真实时钟回拨的故障注入，后者要用可调时钟或系统级时间偏移。

五、并发容器：适用边界

为什么 sync.Map 不是通用 Map

sync.Map 针对的是"键只写一次、之后大量读"或"不同 goroutine 操作不相交键集"的场景。它内部维护只读视图与 dirty map，频繁写入会导致 dirty map 提升与只读视图重建，成本高于普通 map 加锁。

Go 的默认建议是：先用普通 map 配 sync.RWMutex，只有在 profile 表明锁竞争是瓶颈、且访问模式符合上述特征时，才换成 sync.Map。Java 的 ConcurrentHashMap 则是通用并发映射，分段或桶级同步让常规读写都有稳定表现，computeIfAbsent 还能把"检查并写入"合成一个原子操作。

代码对照

Go 的原子获取或写入：

// file: internal/idem/store.go
// tier: L2
// verify: go test -race ./internal/idem
func (s *Store) Seen(key string) bool {
	_, loaded := s.m.LoadOrStore(key, struct{}{})
	return loaded
}

Java 的原子计算：

// 示例代码，未在本机运行
private final ConcurrentHashMap<String, Long> counters = new ConcurrentHashMap<>();

public long addOnce(String key, long delta) {
    return counters.compute(key, (k, v) -> v == null ? delta : v + delta);
}

两段代码都只保证单键原子性。跨键不变量仍然要靠事务、条件更新或对账。

六、分布式组件生态

表里不写版本号，也不比较性能。生态差异主要体现在三件事：API 是阻塞还是回调、默认是否带指标、以及失败时的默认行为是否安全。

租约与 fencing 与语言无关

无论用 Go 还是 Java，租约锁的正确性都不取决于客户端库，而取决于存储侧是否拒绝陈旧持有者：

持有者获取租约 -> 得到 token = 7
持有者暂停（GC、网络、调度）超过 TTL
新持有者获取租约 -> token = 8
旧持有者恢复，携带 token = 7 发起写入
存储侧比较 token：7 < 8，拒绝写入

如果存储侧只接受"当前持有者"的身份而不比较 token，旧持有者恢复后仍可能写入。这就是为什么 10.3 锁失效后的正确性：从互斥到幂等 强调：锁不是正确性的唯一来源，版本号与条件更新才是最后一道闸门。

重试库的语义差异

Go 的重试库通常以函数回调为中心，配合 context 取消；Java 的 Resilience4j 以装饰器为中心，把重试、熔断、限流组合在一条调用链上。两者都能实现指数退避加 jitter，差异在于：

• Go 侧更容易把 context 一路传到底，取消传播直观；
• Java 侧更容易把策略配置化，但也更容易出现"重试套重试"的放大。

无论哪边，都要先回答"这个操作是否幂等"，再决定重试次数。重试不是可靠性开关，它会把下游故障放大为流量风暴。

七、内存模型与可见性

两个常见错误

Go 侧：复制包含 sync.Mutex、sync.Map、sync.WaitGroup 的结构体。复制后两个副本各自加锁，互斥失效。go vet 能发现一部分，但接口传递与切片复制仍可能漏掉。

Java 侧：把对象引用发布到其他线程时没有 final 或同步，其他线程可能看到部分构造的对象。安全发布依赖 final 字段、volatile 写入或锁，不依赖"构造完成后应该就可见了"的直觉。

两边共同的结论是：并发正确性不能靠"看起来没问题"。Go 用 -race，Java 用并发测试工具与代码审查；发现数据竞争后，优先改结构，而不是加一个原子变量掩盖。

八、混合栈迁移注意事项

同一个公司同时使用 Go 与 Java 很常见。跨语言协作时，下面五件事比语言选型更重要：

迁移时还有一个容易忽略的点：不要因为虚拟线程或 goroutine 便宜，就删掉有界队列与背压。并发单元变便宜，只会让过载来得更快；保护下游仍然需要限流、舱壁和超时预算。

小结

如果只记三件事：

把这张表当成翻译对照，而不是优劣判断。真正决定系统行为的，是你在超时、重复、分区和时钟回拨上做了哪些明确选择；语言只决定这些选择写起来是否顺手。