問題描述

看起來我搞砸了 Java 線程/操作系統(tǒng)線程和解釋語言.

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

在開始之前，我確實(shí)了解綠色線程是 Java 線程，其中線程由 JVM 負(fù)責(zé)，整個(gè) Java 進(jìn)程僅作為單個(gè) OS 線程運(yùn)行.因此在多處理器系統(tǒng)上它是無用的.

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.

現(xiàn)在我的問題是.我有兩個(gè)線程 A 和 B.每個(gè)線程都有 10 萬行獨(dú)立代碼.我在多處理器系統(tǒng)上的 Java 程序中運(yùn)行這些線程.每個(gè)線程將被賦予一個(gè)本機(jī)操作系統(tǒng)線程來運(yùn)行，它可以在不同的 CPU 上運(yùn)行，但由于 Java 被解釋，這些線程將需要一次又一次地與 JVM 交互以將字節(jié)碼轉(zhuǎn)換為機(jī)器指令?我對嗎 ?如果是，那么對于較小的程序，Java 線程不會(huì)是一個(gè)很大的優(yōu)勢?

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 ?

一旦 Hotspot 編譯了這兩個(gè)執(zhí)行路徑，它們都可以和原生線程一樣好?我說的對嗎?

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

:另一個(gè)問題是，假設(shè)您有一個(gè) Java 線程，其代碼不是 JIT 編譯的，您創(chuàng)建該線程并 start() 嗎?操作系統(tǒng)線程和 JVM 如何交互來運(yùn)行該字節(jié)碼?

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

謝謝

推薦答案

每個(gè)線程都會(huì)被賦予一個(gè)原生操作系統(tǒng)線程到 RUN 可以運(yùn)行在不同的 CPU，但由于 Java 是解釋這些線程將需要再次與 JVM 交互再次將字節(jié)碼轉(zhuǎn)換為機(jī)器指令 ?我說的對嗎?

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 提供的線程支持.在內(nèi)心深處，你所做的一切都會(huì)轉(zhuǎn)化為某種本機(jī)代碼.使用線程的字節(jié)碼指令與訪問線程的 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線程不會(huì)是一個(gè)很大的優(yōu)勢?

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

在這里定義小.對于短暫的進(jìn)程，是的，線程不會(huì)產(chǎn)生太大的影響，因?yàn)槟捻樞驁?zhí)行速度足夠快.請注意，這又取決于要解決的問題.對于 UI 工具包，無論應(yīng)用程序多么小，都需要某種線程/異步執(zhí)行來保持 UI 響應(yīng).

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.

當(dāng)您擁有可以并行運(yùn)行的東西時(shí)，線程也很有意義.一個(gè)典型的例子是在線程中進(jìn)行大量 IO 并在另一個(gè)中進(jìn)行計(jì)算.你真的不想僅僅因?yàn)槟愕闹骶€程被阻塞做 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 編譯了這兩個(gè)執(zhí)行路徑都可以和本機(jī)線程?我說的對嗎?

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

請參閱我的第一點(diǎn).

線程確實(shí)不是靈丹妙藥，尤其是當(dāng)涉及到使用線程使代碼運(yùn)行得更快"這一常見誤解時(shí).一點(diǎn)閱讀和經(jīng)驗(yàn)將是你最好的選擇.我可以推薦一份這本很棒的書嗎?:-)

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:事實(shí)上，我現(xiàn)在可以重新構(gòu)建我的問題.如果我有一個(gè)線程代碼尚未經(jīng)過 JIT 處理操作系統(tǒng)線程執(zhí)行它?

@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 完全不同的概念.讓我們試著簡單地看一下程序的執(zhí)行:

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 定位方法要運(yùn)行 -> 開始執(zhí)行逐行方法的字節(jié)碼->將每個(gè)字節(jié)碼指令轉(zhuǎn)換為它的原生對應(yīng)物 -> 指令由操作系統(tǒng)執(zhí)行 -> 執(zhí)行的指令通過機(jī)器

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

當(dāng) JIT 啟動(dòng)時(shí):

java pkg.MyClass -> VM 定位方法運(yùn)行 已經(jīng)過 JIT 的 ->找到相關(guān)的 native 代碼對于那個(gè)方法->指令由操作系統(tǒng)執(zhí)行 -> 執(zhí)行的指令通過機(jī)器

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 指令都必須在某個(gè)時(shí)間點(diǎn)映射到其本地對應(yīng)項(xiàng).是否存儲(chǔ)該本機(jī)代碼以供進(jìn)一步重用或在其他情況下丟棄(優(yōu)化，記得嗎?).

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

因此回答您的問題，每當(dāng)您編寫線程代碼時(shí)，它 被翻譯為本機(jī)代碼并由操作系統(tǒng)運(yùn)行.翻譯是即時(shí)完成還是在那個(gè)時(shí)間點(diǎn)查找是完全不同的問題.

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.

這篇關(guān)于Java 線程與操作系統(tǒng)線程的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網(wǎng)！