Java Threads против OS Threads - PullRequest
       2

Java Threads против OS Threads

28 голосов
/ 13 декабря 2010

Похоже, я напутал с потоками Java / потоками ОС и интерпретируемым языком.

Прежде чем я начну, я понимаю, что зеленые потоки - это потоки Java, где JVM иВесь процесс Java работает только как один поток ОС.Таким образом, в многопроцессорной системе это бесполезно.

Теперь мои вопросы.У меня есть два потока A и B. Каждый из 100 тысяч строк независимого кода.Я запускаю эти потоки в моей Java-программе на многопроцессорной системе.Каждому потоку будет предоставлен собственный поток ОС для RUN, который может работать на другом процессоре, но поскольку Java интерпретируется, этим потокам потребуется снова и снова взаимодействовать с JVM для преобразования байтового кода в машинные инструкции?Я прав ?Если да, то для небольших программ Java Threads не будет большим преимуществом?

Как только Hotspot компилирует оба эти пути выполнения, оба могут быть такими же хорошими, как и нативные Threads?Я прав?

[РЕДАКТИРОВАТЬ]: Альтернативный вопрос может быть, предположим, у вас есть один поток Java, чей код не JIT-компилируется, вы создаете этот поток и запускаете его ()?Как поток ОС и JVM взаимодействуют для запуска этого байт-кода?

спасибо

Ответы [ 4 ]

25 голосов
/ 13 декабря 2010

Каждый поток получит собственный поток ОС для RUN, который может работать на другом процессоре, но, поскольку Java интерпретируется, этим потокам потребуется снова и снова взаимодействовать с JVM для преобразования байтового кода в машинные инструкции?Я прав?

Вы смешиваете две разные вещи;JIT, сделанный VM, и поддержка потоков, предлагаемая VM.В глубине души все, что вы делаете, переводится в какой-то нативный код.Инструкция байт-кода, которая использует поток, ничем не отличается от кода JIT, который обращается к потокам.

Если да, то для небольших программ Java Threads не будет большим преимуществом?

Определите маленький здесь.Для кратковременных процессов, да, многопоточность не имеет большого значения, так как ваше последовательное выполнение достаточно быстро.Обратите внимание, что это снова зависит от решаемой проблемы.Для наборов инструментов пользовательского интерфейса, независимо от того, насколько маленьким является приложение, для поддержания отзывчивости пользовательского интерфейса требуется какое-то многопоточное / асинхронное выполнение.

Потоки также имеют смысл, когда у вас есть вещи, которые можно запуститьв параллели.Типичным примером будет выполнение тяжелых операций ввода-вывода в потоке и вычислений в другом.Вы действительно не захотите блокировать свою обработку только потому, что ваш основной поток блокируется с помощью ввода-вывода.

Как только Hotspot компилирует оба эти пути выполнения, оба могут быть такими же хорошими, как и собственные потоки?Я прав?

См. Мое первое замечание.

Потоки действительно не являются серебряной пулей, особенно, когда дело доходит до распространенного заблуждения о "использовании потоков, чтобы заставить этот код идтиБыстрее".Чтение и опыт будут вашим лучшим выбором.Могу ли я порекомендовать получить копию этой удивительной книги ?: -)

@ Sanjay: Infact теперь я могу перефразировать мой вопрос.Если у меня есть Поток, чей код не был JIT, как его выполняет ОС?

Опять же, я скажу, что многопоточность - это совершенно другое понятие, чем JIT.Давайте попробуем взглянуть на выполнение программы в простых терминах:

java pkg.MyClass -> VM находит метод для запуска -> Начать выполнение байт-кода для метода строка за строкой ->преобразовать каждую инструкцию байт-кода в ее собственный аналог -> инструкцию, выполняемую ОС -> инструкцию, выполняемую машиной

Когда JIT включился:

java pkg.MyClass-> ВМ находит метод для запуска , который был JIT'ed -> находит соответствующий собственный код для этого метода -> инструкция, выполняемая ОС -> инструкция, выполняемая машиной

Как видите, независимо от маршрута, по которому вы идете, инструкция VM должна быть сопоставлена ​​с ее собственным аналогом в определенный момент времени.Сохраняется ли этот нативный код для дальнейшего повторного использования или выбрасывается, если что-то другое (оптимизация, помните?).

Следовательно, чтобы ответить на ваш вопрос, всякий раз, когда вы пишете многопоточный код, он равен перевод на родной код и запуск на ОС.Независимо от того, выполняется ли этот перевод на лету или просматривается в тот момент времени, это совершенно другой вопрос.

10 голосов
/ 13 декабря 2010

и весь процесс Java работает только как один поток ОС

Это не так.Таким образом, не указывается, мы часто видим, что потоки Java на самом деле являются собственными потоками ОС и что многопоточные приложения Java действительно используют многоядерные процессоры или многопроцессорные платформы.где количество потоков пропорционально количеству ядер (коэффициент 1-1,5).Это еще один намек, что JVM не ограничивается одним потоком / процессом ОС.


Из wkipedia:

В Java 1.1 зеленые потоки были единственными потокамиМодель, используемая JVM, [4] по крайней мере на Solaris.Поскольку зеленые потоки имеют некоторые ограничения по сравнению с собственными потоками, последующие версии Java отбросили их в пользу собственных потоков .

Теперь, в 2010 году, в стадии разработки Java 7 и Java 8планируется - действительно ли мы все еще заинтересованы в исторических "зеленых нитях" ??

3 голосов
/ 13 декабря 2010
  1. Некоторые реализации Java могут создавать зеленые потоки, как вы описываете (планирование, выполняемое JVM в одном собственном потоке), но обычные реализации Java на ПК используют несколько ядер.
  2. JVMсама по себе может уже использовать разные потоки для работы (сборка мусора, загрузка классов, проверка байт-кода, JIT-компилятор).
  3. ОС запускает программу под названием JVM.JVM выполняет Java-байт-код.Если каждый Java-поток имеет связанный собственный поток (что имеет смысл и, как представляется, имеет место в реализациях на ПК), то JVM-код в этом потоке выполняет Java-код - JITed или интерпретируемый - как в однопоточном-Программа.Здесь нет разницы благодаря многопоточности.
2 голосов
/ 13 декабря 2010

Потоки и запуск байтового кода - это отдельные проблемы. Зеленые потоки используются JVM на платформах, которые не имеют встроенной поддержки потоков. (ИМХО я не знаю, какая платформа не поддерживает потоки).

Байт-код интерпретируется в реальном времени и выполняется на собственной платформе JVM. JVM решает, какие фрагменты кода наиболее популярны, и выполняет так называемую своевременную компиляцию этих фрагментов, поэтому нет необходимости компилировать их снова и снова. Это не зависит от потоков. Если, например, у вас есть один поток, который выполняет один и тот же фрагмент кода в цикле, этот фрагмент будет кэширован компилятором точно во время.

Итог: не беспокойтесь о производительности и потоках. Java достаточно сильна, чтобы выполнять все, что вы кодируете.

...