Java 线程与操作系统线程

Java Threads vs OS Threads

提问by Geek

Looks like I have messed up with Java Threads/OS Threads and Interpreted language.

看起来我搞砸了 Java 线程/操作系统线程和解释性语言。

Before I begin, I do understand that Green Threads are Java Threads where the threading is taken care of by the JVM and the entire Java process runs only as a single OS Thread. Thereby on a multi processor system it is useless.

在开始之前，我确实了解绿色线程是 Java 线程，其中线程由 JVM 处理，整个 Java 进程仅作为单个操作系统线程运行。因此在多处理器系统上它是无用的。

Now my questions is. I have two Threads A and B. Each with 100 thousand lines of independent code. I run these threads in my Java Program on a multiprocessor system. Each Thread will be given a native OS Thread to RUN which can run on a different CPU but since Java is interpreted these threads will require to interact with the JVM again and again to convert the byte code to machine instructions ? Am I right ? If yes, than for smaller programs Java Threads wont be a big advantage ?

现在我的问题是。我有两个线程 A 和 B。每个线程都有 10 万行独立代码。我在多处理器系统上的 Java 程序中运行这些线程。每个线程都会被赋予一个本地操作系统线程来运行，它可以在不同的 CPU 上运行，但是由于 Java 被解释，这些线程将需要一次又一次地与 JVM 交互以将字节码转换为机器指令？我对吗 ？如果是的话，与较小的程序相比，Java 线程不会是一个很大的优势？

Once the Hotspot compiles both these execution paths both can be as good as native Threads ? Am I right ?

一旦 Hotspot 编译了这两个执行路径，它们都可以与本机线程一样好？我对吗 ？

[EDIT] : An alternate question can be, assume you have a single Java Thread whose code is not JIT compiled, you create that Thread and start() it ? How does the OS Thread and JVM interact to run that Bytecode ?

[编辑]：另一个问题可以是，假设您有一个未经过 JIT 编译的 Java 线程，您创建该线程并 start() 了吗？操作系统线程和 JVM 如何交互以运行该字节码？

thanks

谢谢

采纳答案by Sanjay T. Sharma

Each Thread will be given a native OS Thread to RUN which can run on a different CPU but since Java is interpreted these threads will require to interact with the JVM again and again to convert the byte code to machine instructions ? Am I right ?

每个线程都会被赋予一个本地操作系统线程来运行，它可以在不同的 CPU 上运行，但是由于 Java 被解释，这些线程将需要一次又一次地与 JVM 交互以将字节码转换为机器指令？我对吗 ？

You are mixing two different things; JIT done by the VM and the threading support offered by the VM. Deep down inside, everything you do translates to some sort of native code. A byte-code instruction which uses thread is no different than a JIT'ed code which accesses threads.

你在混合两种不同的东西；由 VM 完成的 JIT 和由 VM 提供的线程支持。在内心深处，你所做的一切都转化为某种本机代码。使用线程的字节码指令与访问线程的 JIT 代码没有什么不同。

If yes, than for smaller programs Java Threads wont be a big advantage ?

如果是的话，与较小的程序相比，Java 线程不会是一个很大的优势？

Define small here. For short lived processes, yes, threading doesn't make that big a difference since your sequential execution is fast enough. Note that this again depends on the problem being solved. For UI toolkits, no matter how small the application, some sort of threading/asynchronous execution is required to keep the UI responsive.

在这里定义小。对于短期进程，是的，线程不会产生太大的不同，因为您的顺序执行速度足够快。请注意，这再次取决于要解决的问题。对于 UI 工具包，无论应用程序有多小，都需要某种线程/异步执行来保持 UI 响应。

Threading also makes sense when you have things which canbe run in parallel. A typical example would be doing heavy IO in on thread and computation in another. You really wouldn't want to block your processing just because your main thread is blocked doing IO.

当你有可以并行运行的东西时，线程化也很有意义。一个典型的例子是在线程中进行大量 IO，在另一个线程中进行计算。您真的不想仅仅因为您的主线程在执行 IO 时被阻塞而阻塞您的处理。

Once the Hotspot compiles both these execution paths both can be as good as native Threads ? Am I right ?

一旦 Hotspot 编译了这两个执行路径，它们都可以与本机线程一样好？我对吗 ？

See my first point.

看我的第一点。

Threading really isn't a silver bullet, esp when it comes to the common misconception of "use threads to make this code go faster". A bit of reading and experience will be your best bet. Can I recommend getting a copy of this awesome book? :-)

线程确实不是灵丹妙药，尤其是当涉及到“使用线程使此代码运行得更快”的常见误解时。一点阅读和经验将是你最好的选择。我可以推荐一本这本很棒的书吗？:-)

@Sanjay: Infact now I can reframe my question. If I have a Thread whose code has not been JIT'd how does the OS Thread execute it ?

@Sanjay：事实上现在我可以重新定义我的问题。如果我有一个线程，它的代码没有经过 JIT 处理，操作系统线程如何执行它？

Again I'll say it, threading is a completely different concept from JIT. Let's try to look at the execution of a program in simple terms:

我再说一遍，线程与 JIT 是一个完全不同的概念。让我们试着用简单的术语来看看程序的执行：

java pkg.MyClass -> VM locates method to be run -> Start executing the byte-code for method line by line -> convert each byte-code instruction to its native counterpart -> instruction executed by OS -> instruction executed by machine

java pkg.MyClass -> VM 定位要运行的方法 -> 开始逐行执行方法的字节码 -> 将每个字节码指令转换为其本机对应物 -> 操作系统执行的指令 -> 机器执行的指令

When JIT has kicked in:

当 JIT 开始时：

java pkg.MyClass -> VM locates method to be run which has been JIT'ed-> locate the associated nativecode for that method -> instruction executed by OS -> instruction executed by machine

java pkg.MyClass -> VM 定位要运行的已被 JIT 的方法-> 定位该方法的相关本机代码 -> 操作系统执行的指令 -> 机器执行的指令

As you can see, irrespective of the route you follow, the VM instruction has to be mapped to its native counterpart at some point in time. Whether that native code is stored for further re-use or thrown away if a different thing (optimization, remember?).

如您所见，无论您遵循什么路线，VM 指令都必须在某个时间点映射到其本地对应指令。如果有不同的事情（优化，还记得吗？），本地代码是否被存储以供进一步重用或丢弃。

Hence to answer your question, whenever you write threading code, it istranslated to native code and run bythe OS. Whether that translation is done on the fly or looked up at that point in time is a completely different issue.

因此，回答您的问题，每当您编写线程代码时，它都会被转换为本机代码并由操作系统运行。该翻译是即时完成还是在那个时间点进行查找是一个完全不同的问题。

回答by Andreas Dolk

and the entire Java process runs only as a single OS Thread

并且整个 Java 进程仅作为单个 OS 线程运行

This is not true. Thus not specified, we often see, that Java threads are in fact native OS threads and that multithreaded Java applications really make use of multi-core processors or multi-processor platforms.

这不是真的。因此，我们经常看到，没有说明 Java 线程实际上是原生 OS 线程，而多线程 Java 应用程序确实使用了多核处理器或多处理器平台。

A common recommendation is using a thread pool where the number of threads is proportional to the number of cores (factor 1-1.5). This is another hint, that the JVM is not restricted to a single OS thread / process.

一个常见的建议是使用线程池，其中线程数与内核数成正比（因子 1-1.5）。这是另一个提示，即 JVM 不限于单个 OS 线程/进程。

---

---

From wkipedia:

来自维基百科：

In Java 1.1, green threads were the only threading model used by the JVM,[4] at least on Solaris. As green threads have some limitations compared to native threads, subsequent Java versions dropped them in favor of native threads.

在 Java 1.1 中，绿色线程是 JVM 使用的唯一线程模型，[4] 至少在 Solaris 上是这样。由于与原生线程相比，绿色线程有一些限制，因此随后的 Java 版本放弃了它们，转而使用原生线程。

Now, back in 2010 with Java 7 under development and Java 8 planned - are we really still interested in historic "green threads"??

现在，回到 2010 年，Java 7 正在开发中，Java 8 正在计划中——我们真的仍然对历史悠久的“绿色线程”感兴趣吗？？

回答by Mnementh

1. Some Java-implementations may create green threads like you describe it (scheduling made by the JVM on a single native thread), but normal implementations of Java on PC use multiple cores.
2. The JVM itself might already use different threads for the work to do (garbage collection, class loading, byte-code-verification, JIT-Compiler).
3. The OS runs a program called JVM. The JVM executes the Java-Bytecode. If every Java-Thread has an associated native thread (that makes sense and seems to be the case on PC-implementations), then the JVM-code in that thread executes the Java-code - JITed or interpreted - like on a single-thread-program. No difference here through multithreading.

1. 一些 Java 实现可能会像您描述的那样创建绿色线程（由 JVM 在单个本机线程上进行调度），但 Java 在 PC 上的正常实现使用多个内核。
2. JVM 本身可能已经使用不同的线程来完成工作（垃圾收集、类加载、字节码验证、JIT 编译器）。
3. 操作系统运行一个名为 JVM 的程序。JVM 执行 Java 字节码。如果每个 Java 线程都有一个关联的本机线程（这是有道理的，并且在 PC 实现中似乎是这种情况），那么该线程中的 JVM 代码会执行 Java 代码 - JITed 或解释型 - 就像在单线程上一样-程序。通过多线程这里没有区别。

回答by AlexR

Threading and running a byte code are separate issues. Green threads are used by JVM on platforms that do not have native support of threads. (IMHO I do not know which platform does not support threads).

线程化和运行字节码是不同的问题。JVM 在没有本地线程支持的平台上使用绿色线程。（恕我直言，我不知道哪个平台不支持线程）。

Byte code is interpreted in real time and executed on native platform by JVM. JVM decides what are the most popular code fragments and performs so called Just in time compiling of these fragments, so it does not have to compile them again and again. This is independent on threading. If for example you have one thread that executes the same code fragment in loop you this fragment will be cached by just in time compiler.

字节码由JVM实时解释并在本机平台上执行。JVM 决定哪些是最流行的代码片段，并对这些片段执行所谓的即时编译，因此它不必一次又一次地编译它们。这与线程无关。例如，如果您有一个线程在循环中执行相同的代码片段，则该片段将被及时编译器缓存。

Bottom line: do not worry about performance and threads. Java is strong enough to run everything you are coding.

底线：不要担心性能和线程。Java 足够强大，可以运行您正在编码的所有内容。