从受管线程到独立任务：重新思考从 Java 到 Go 的并发（第 1 部分）

I’m happy to translate the article for you, but I need the actual text you’d like translated. Could you please paste the content (or the portions you want translated) here? I’ll keep the source link, formatting, markdown, and any code blocks exactly as they are while translating the rest into Simplified Chinese.

一个简单但真实的问题

让我们从一个非常常见的需求开始：同时运行多个任务并等待它们全部完成。此模式无处不在——运行启动任务、调用多个 API，或并行执行后台工作。

我在 Java 中的解决思路

当我编写这段代码时，我非常清楚自己在使用 threads：

• 我显式创建 Thread 对象
• 我必须记得调用 start() 来启动它们
• 我必须 join() 每个线程以等待其完成

我负责它们的生命周期。Java 中的并发感觉像是在管理工人。线程是可见的，正确处理它们是工作的一部分。

Go 中的相同问题

• 我不创建线程
• 我使用 go 关键字启动工作
• 我不等待单个工作者

我只等待一次，直到所有任务完成。Goroutine 感觉轻量且可随时丢弃。代码关注的是 什么 并发运行，而不是 如何 管理线程。

并发 vs 并行

在 Java 和 Go 中，这个例子表达了 并发 —— 可以独立推进的任务。它们是否真的并行运行取决于 CPU 核心和运行时调度器。

Java 与 Go 中并发的实际处理方式

Java

• 每个 Thread 代表一个由 JVM 和操作系统管理的真实执行单元。
• 调用 start() 会调度线程，该线程拥有自己的栈。
• 主线程调用 join() 来“在此暂停并等待该特定线程结束”。
• 每个启动的线程都必须显式地进行 join。

Java 中的并发感觉非常 以线程为中心——你创建线程、跟踪它们，并确保没有线程被遗留运行。

Go

• go 关键字启动一个 goroutine，而不是操作系统线程。goroutine 轻量级，由 Go 运行时调度到少量的 OS 线程上。
• Go 不会对单个 goroutine 进行 join，而是使用 sync.WaitGroup。
• wg.Add(n) 声明需要完成的工作单元数量（不需要指明具体的 goroutine）。
• 每个 goroutine 在完成时调用 wg.Done()。
• 主函数只需一次 wg.Wait()，阻塞直到所有工作完成。

关注点从 “我在等待哪些线程？” 转变为 “所有工作是否已经完成？”。

我注意到的思维转变

即使是这么小的例子，差异也很明显。Java 和 Go 最大的区别不在于语法，而在于编写并发代码时的关注点。

• Java: 思考从线程开始——有多少线程、每个线程何时启动、何时结束。
• Go: 注意力转向任务——哪些工作可以同时运行、正在进行多少任务、何时所有任务完成。

这个比较帮助我理解的内容

在完成此示例后，我意识到，从管理线程转向协调任务，使并发更容易理解和推理。

为什么这超出示例的重要性

相同的思想在 Go 中反复出现。并发通常从识别独立任务并协调它们的完成开始，而不是直接管理线程。一旦采用这种思维方式，阅读和编写并发 Go 代码会变得更加顺畅。

第 1 部分的要点

• Java 让你以线程及其生命周期的方式思考。
• Go 让你以任务及其完成的方式思考。
• WaitGroup 帮助你关注 需要 完成的内容，而不是它是如何运行的。

在 第 2 部分，我将探讨当并发任务需要共享数据时会发生什么，以及 Java 和 Go 如何以不同方式解决这个问题。