每个线程都会被赋予一个原生操作系统线程到 RUN 可以运行在不同的 CPU，但由于 Java 是解释这些线程将需要再次与 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 代码没有什么不同.

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.

如果是，那么对于较小的程序 Java线程不会是一个很大的优势?

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

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

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.

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

Threading also makes sense when you have things which can be 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.

一旦 Hotspot 编译了这两个执行路径都可以和本机线程?我说的对吗?

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

请参阅我的第一点.

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

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:事实上，我现在可以重新构建我的问题.如果我有一个线程代码尚未经过 JIT 处理操作系统线程执行它?

@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 完全不同的概念.让我们试着简单地看一下程序的执行:

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:

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

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 定位方法运行 已经过 JIT 的 ->找到相关的 native 代码对于那个方法->指令由操作系统执行 -> 执行的指令通过机器

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 指令都必须在某个时间点映射到其本地对应项.是否存储该本机代码以供进一步重用或在其他情况下丢弃(优化，记得吗?).

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?).

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

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