英文:
Doesn't the fact that Go and Java use User space thread mean that you can't really take advantage of multiple core?
问题
我们最近在我的操作系统课上一直在讨论线程，有一个问题让我想起来了。
由于Go（和Java）使用用户空间线程而不是内核线程，这是否意味着你不能有效地利用多个核心，因为操作系统只分配CPU时间给进程而不是线程本身？
英文:
We've been talking about threads in my operating system class a lot lately and one question has come to my mind.
Since Go, (and Java) uses User-space thread instead of kernel threads, doesn't that mean that you can't effectively take advantages of multiple cores since the OS only allocates CPU time to the process and not the threads themselves?
答案1
得分: 17
什么让你认为Go使用用户空间线程？
它并不是。 它使用操作系统线程，并且可以利用多个核心。
你可能会对默认情况下Go只使用1个线程来运行程序感到困惑。如果你启动了两个goroutine，它们会在一个线程中运行。但是，如果一个goroutine因为I/O而阻塞，Go会创建一个新的线程，并继续在新线程上运行其他goroutine。
如果你真的想要发挥多核心的全部性能，只需使用GOMAXPROCS()函数。
runtime.GOMAXPROCS(4); //在main函数的某处
现在，你的程序将使用4个操作系统线程（而不是1个），并且能够充分利用例如4核心的系统。
英文:
What makes you think Go uses User-space threads?
It doesn't. It uses OS-threads and can take advantage of multiple cores.
You might be puzzled by the fact that by default Go only uses 1 thread to run your program. If you start two goroutines they run in one thread. But if one goroutine blocks for I/O Go creates a second thread and continues to run the other goroutine on the new thread.
If you really want to unlock the full multi-core power just use the GOMAXPROCS() function.
runtime.GOMAXPROCS(4); //somewhere in main
Now your program would use 4 OS-threads (instead of 1) and would be able to fully use a e.g. 4 core system.
答案2
得分: 6
最近的Java版本使用操作系统线程，尽管Java线程与操作系统线程不一定是一对一的映射关系。Java在许多硬件线程上表现得非常好。
英文:
Most recent versions of Java to use OS threads, although there is not necessarily a one-to-one mapping with Java threads. Java clearly does work quite nicely across many hardware threads.
答案3
得分: 0
我假设你所说的“用户空间线程”是指（例如）Go语言的goroutine。
使用goroutine进行并发确实比手动设计并通过科学计算为OS线程分配工作单元的特定算法效率低。
然而：每个Go程序都处于一个环境中，并且旨在解决特定的问题。可以为环境对Go程序的每个请求启动一个新的goroutine。如果环境对Go程序进行并发请求，即使Go程序只使用1个OS线程，使用goroutine的Go程序可能比串行程序运行得更快。使用goroutine可能能够更快地处理请求的原因（即使只使用1个OS线程）是当与A相关联的环境部分暂时无法响应时，Go程序会自动从goroutine A切换到goroutine B。
但是，是的，使用goroutine并自动将它们分配给多个OS线程的效率低于通过手动设计并通过科学计算为OS线程分配工作单元的特定算法。
英文:
I presume that by "user-space threads" you mean (for example) Go's goroutines.
It is true that using goroutines for concurrency is less efficient than designing (by hand and by scientific calculations) a special-purpose algorithm for assigning work units to OS threads.
However: Every Go program is situated in an environment and is designed to solve a particular problem. A new goroutine can be started for each request that the environment is making to the Go program. If the environment is making concurrent requests to the Go program, a Go program using goroutines might be able to run faster than a serial program even if the Go program is using just 1 OS thread. The reason why goroutines might be able to process requests with greater speed (even when using just 1 OS thread) is that the Go program will automatically switch from goroutine A to goroutine B when the part of environment which is associated with A is momentarily unable to respond.
But yes, it is true that using goroutines and automatically assigning them to multiple OS threads is less efficient than designing (by hand and by scientific calculations) a special-purpose algorithm for assigning work units to OS threads.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论