看起来我已经搞砸了Java Threads / OS Threads和Interpreted language。
在开始之前,我确实理解绿色线程是Java线程,其中线程由JVM处理,整个Java进程仅作为单个OS线程运行。因此,在多处理器系统上它是无用的。
现在我的问题是。我有两个主题A和B.每个都有10万行独立代码。我在多处理器系统上的Java程序中运行这些线程。每个线程都将被赋予一个本机操作系统线程到RUN,它可以在不同的CPU上运行但是由于Java被解释,这些线程将需要一次又一次地与JVM交互以将字节代码转换为机器指令?我对吗 ?如果是,那么对于较小的程序,Java Threads不是一个很大的优势吗?
一旦Hotspot编译这两个执行路径,两者都可以像原生线程一样好吗?我是对的吗?
[编辑]:另一个问题是,假设你有一个单独的Java线程,其代码不是JIT编译的,你创建那个线程并启动()它?操作系统线程和JVM如何交互以运行该字节码?
感谢
答案 0 :(得分:25)
每个线程都将获得一个本机操作系统 线程到RUN可以运行在 不同的CPU,但自Java以来 解释这些线程将需要 再次与JVM交互 再次将字节码转换为 机器说明?我是对的吗?
你混合了两件不同的东西;由VM完成的JIT和VM提供的线程支持。在内心深处,你所做的一切都转化为某种本地代码。使用线程的字节码指令与访问线程的JIT代码没有什么不同。
如果是,则比较小的程序Java 线程不是一个很大的优势吗?
在这里定义小。对于短期流程,是的,线程不会产生很大的差异,因为顺序执行足够快。请注意,这又取决于要解决的问题。对于UI工具包,无论应用程序有多小,都需要某种线程/异步执行来保持UI响应。
当你有可以并行运行的东西时,线程也是有意义的。一个典型的例子是在线程上执行大量IO,在另一个线程中执行计算。你真的不想因为你的主线程被阻止做IO而阻止你的处理。
一旦Hotspot编译这两个 执行路径都可以 原生主题?我是对的吗?
请参阅我的第一点。
线程真的不是一个灵丹妙药,尤其是当涉及到“使用线程使代码更快”的常见误解时。一点点阅读和经验将是您最好的选择。我可以推荐获取this awesome book的副本吗? : - )
@Sanjay:事实上我现在可以重新构建我的 题。如果我有一个Thread 代码没有JIT'd如何 OS Thread执行它吗?
我再说一遍,线程与JIT完全不同。让我们试着用简单的术语来看一个程序的执行:
java pkg.MyClass - > VM定位方法 要运行 - >开始执行 方法的字节代码逐行 - > 将每个字节码指令转换为 它的原生对应物 - >指令 由OS执行 - >执行的指令 通过机器
当JIT开始时:
java pkg.MyClass - > VM定位方法 运行已经JIT'ed - > 找到关联的本机代码 对于那种方法 - >指令 由OS执行 - >执行的指令 通过机器
如您所见,无论您遵循何种路线,VM指令都必须在某个时间点映射到其本机对应物。是否存储该本机代码以供进一步重用或在不同的情况下丢弃(优化,还记得吗?)。
因此,为了回答您的问题,无论何时编写线程代码, 都会将转换为本机代码并通过运行。无论是即时完成翻译还是在那个时间点查找都是一个完全不同的问题。
答案 1 :(得分:10)
并且整个Java进程仅作为单个OS线程运行
事实并非如此。因此,我们经常看到,未指定Java线程实际上是本机操作系统线程,多线程Java应用程序确实使用多核处理器或多处理器平台。
一个常见的建议是使用线程池,其中线程数与核心数成比例(因子1-1.5)。这是另一个提示,即JVM不限于单个OS线程/进程。
来自wkipedia:
在Java 1.1中,绿色线程是JVM使用的唯一线程模型,[4]至少在Solaris上。由于绿色线程与本机线程相比有一些限制,后续Java版本将它们放弃以支持本机线程。
现在,早在2010年,Java 7正在开发中,Java 8正在计划中 - 我们是否仍然对历史性的“绿色线程”感兴趣?
答案 2 :(得分:3)
答案 3 :(得分:2)
线程和运行字节代码是不同的问题。 JVM在没有线程本机支持的平台上使用绿色线程。 (恕我直言,我不知道哪个平台不支持线程)。
字节代码实时解释并由JVM在本机平台上执行。 JVM决定什么是最流行的代码片段,并执行所谓的及时编译这些片段,因此它不必一次又一次地编译它们。这与线程无关。例如,如果你有一个线程在循环中执行相同的代码片段,那么这个片段将被及时编译器缓存。
底线:不要担心性能和线程。 Java足以运行您编写的所有内容。