关于多线程:Java线程与OS线程

Java Threads vs OS Threads

看起来我已经弄乱了Java线程/ OS线程和解释性语言。

在开始之前,我确实了解绿色线程是Java线程,其中JVM处理线程,并且整个Java进程仅作为单个OS线程运行。因此,在多处理器系统上是没有用的。

现在我的问题是。我有两个线程A和B。每个线程都有10万行独立代码。我在多处理器系统上的Java程序中运行这些线程。每个线程都将获得一个本机OS线程以运行,该线程可以在不同的CPU上运行,但是由于解释了Java,因此这些线程将需要一次又一次地与JVM交互,以将字节码转换为机器指令?我对吗 ?如果是,那么与较小的程序相比,Java Threads不会有很大的优势?

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

[编辑]:另一个问题是,假设您有一个Java线程,其代码未经JIT编译,则创建该线程并启动()吗? OS线程和JVM如何交互以运行该字节码?

谢谢


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 ?

您正在混合两种不同的事物;由VM完成的JIT和VM提供的线程支持。在内部,您所做的一切都会转换为某种本地代码。使用线程的字节码指令与访问线程的JIT代码无异。

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

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

当您拥有可以并行运行的东西时,线程也很有意义。一个典型的示例是在线程上进行大量IO,然后在另一个线程上进行计算。您确实不希望仅仅因为您的主线程在执行IO时就阻塞了处理。

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

看到我的第一点。

线程并不是真正的灵丹妙药,尤其是在"使用线程使代码运行更快"这一常见误解上。最好的阅读和经验将是您最好的选择。我可以推荐得到这本很棒的书吗? :-)

@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 ?

我再说一遍,线程是与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

当JIT开始时:

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

如您所见,无论您遵循哪种路线,VM指令都必须在某个时间点映射到其本机副本。是存储该本机代码以供进一步重用,还是存储其他内容(优化,还记得吗?)丢弃。

因此,为回答您的问题,每当您编写线程代码时,它都会转换为本地代码并由OS运行。无论是即时完成翻译还是在那个时间点进行翻译都是完全不同的问题。


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

这不是真的。因此,我们经常看到,没有指定Java线程实际上是本机OS线程,而多线程Java应用程序实际上使用了多核处理器或多处理器平台。

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

从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.

现在,回到2010年,Java 7正在开发中,Java 8计划中了-我们是否真的仍然对历史性的"绿色线程"感兴趣?


  • 一些Java实现可能会创建
    您描述的绿色线程
    (由JVM在
    单本机线程),但正常
    在PC上使用Java的实现
    多核。
  • JVM本身可能已经使用了不同的线程来完成工作(垃圾回收,类加载,字节码验证,JIT编译器)。
  • 操作系统运行一个名为JVM的程序。 JVM执行Java字节码。如果每个Java线程都有一个关联的本机线程(这很有意义,并且在PC实现上似乎是这种情况),那么该线程中的JVM代码将执行JIT或解释的Java代码,就像在单线程上一样-程序。通过多线程在这里没有区别。

  • 线程和运行字节码是独立的问题。 JVM在没有线程本机支持的平台上使用绿色线程。 (恕我直言,我不知道哪个平台不支持线程)。

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

    底线:不要担心性能和线程。 Java足够强大,可以运行您正在编写的所有代码。