英文:
Kotlin Concurrency againts Goroutine, Task, CompletableFuture
问题
当我阅读关于 Kotlin 协程或 Golang goroutine 的并发文章时，人们总是给出同样的例子。
在 Java 或 C# 中创建 100,000 个线程，哎呀，Stackoverflow。
是的，但是有谁直接在 Java 或 C# 中使用 Thread 类呢？
在 Java 和 C# 中，有用于 CompletableFuture 和 Task 的线程池。
当我们尝试创建 100,000 个 Task 或 CompletableFuture 时，我们可以轻松地使用 ExecuterService/ForkJoinPool 或 dotnet DefaultThread Pool 来实现。它们会重用线程。如果没有可用的线程，任务将在队列中等待。
我的问题是：
1）是的，结构化并发对于取消操作很有用。但是 Kotlin 使用的是类似 CompletableFuture 的线程池。但与 Java 的回调不同，它提供了自然的代码语法。唯一的区别是 Kotlin 协程与 C# Task 或 Java CompletableFuture 之间的语法吗？
2）Kotlin 运行在 JVM 上。据我所知，JVM 不支持绿色线程。但是人们说 Kotlin 使用了绿色线程。这在 JVM 上是如何实现的？为什么协程被称为轻量级线程？那么我们可以说 CompletableFuture 和 Task 也是轻量级线程，对吗？
是的，Golang 有一个调度器。goroutine 是用户级线程。当我们创建一个 goroutine 时，它进入本地运行队列。然后，一个专用的操作系统线程从该队列中逐个获取 goroutine 并执行。没有上下文切换操作。它们全部在同一个操作系统线程上运行，直到阻塞。goroutine 是廉价的，我们可以说是的，goroutine 是轻量级线程。
也许我对协程完全错了，请纠正我。
英文:
People always show the same example when I read articles about concurrency in kotlin coroutine or golang goroutine.
Create 100_000 Threads in Java or C#, ooopps Stackoverflow.
Yes. but anyone Who uses directly Thread classes in Java or C#?
In java and C#, There are thread pools for CompletableFuture and Task.
When We try to create 100_000 Task or CompletableFuture, We can do that easily with ExecuterService/ForkJoinPool or dotnet DefaultThread Pool. They will reuse the threads. If there is no available thread. Tasks will wait in the queue.
My Questions;
-
yes structured concurrency is good for cancellations. But Kotlin uses the Thread Pool like CompletableFuture. But unlike Java Callbacks, It provides natural code syntax. The only Difference is Syntax for Kotlin coroutine between c# Task or Java CompletableFuture?
-
Kotlin runs on JVM. as far as I know, JVM doesn't support green Threads. But people talk like kotlin uses Green Threads. How is that possible with JVM? And Why Coroutines are called Lightweight Threads. Then We can say CompletableFuture and Task are Lightweight Thread too. Right?
Yes, golang has a scheduler. goroutines are user-level threads. When we create a goroutine it goes to localrunqueue. And a dedicated OS thread gets goroutines one by one from that queue and executes. There are no context switch operations. All of them run on the same OS Thread until blocking. Goroutines are cheap and We can say that YES goroutines are Lightweight Threads.
Maybe I'm completely wrong about coroutines. please correct me.
答案1
得分: 0
简化事情：
- 线程 - 使用简单，因为它是顺序执行的。从网络读取并写入文件就像这样简单：
writeToDisk(readFromNetwork())。另一方面，每个任务在单独的线程中运行会消耗大量资源。 - Executors/CompletableFuture - 更高效，更好地利用了CPU和内存。另一方面，它需要使用回调函数，代码很快变得难以阅读和维护。
- 协程 - 既顺序又高效。
我忽略了协程的其他特性，比如结构化并发，因为这不是你的主要关注点。
英文:
Making things simple:
- Thread - easy to use, because it is sequential. Reading from the network and writing to a file is as simple as:
writeToDisk(readFromNetwork()). On the other hand, it is expensive to run each task in a separate thread. - Executors/CompletableFuture - more performant, it makes better use of both CPU and memory. On the other hand, it requires using callbacks and the code quickly becomes hard to read and maintain.
- Coroutines - both sequential and performant.
I ignore other features of coroutines like structured concurrency, because this was not your main concern.
专注分享java语言的经验与见解，让所有开发者获益！
评论