Темы Java-потоков и ОС

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

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

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

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

[EDIT]: Альтернативный вопрос может быть, предположим, что у вас есть один Java-поток, код которого не скомпилирован JIT, вы создаете этот Thread и запускаете() его? Как взаимодействует OS Thread и JVM для запуска этого Bytecode?

спасибо

Ответ 1

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

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

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

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

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

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

См. мой первый пункт.

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

@Sanjay: Infact теперь я могу переделать мои вопрос. Если у меня есть Thread, код не был JIT'd, как OS Thread выполнить его?

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

java pkg.MyClass → Метод поиска VM для запуска → Запустить выполнение байт-код для метода по строкам → конвертировать каждую инструкцию байтового кода в его родной экземпляр → инструкция выполненный операцией OS → машиной

Когда JIT нажал:

java pkg.MyClass → Метод поиска VM для запуска , который был JIT'ed → найти связанный с ним собственный код для этого метода → инструкция выполненный операцией OS → машиной

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

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

Ответ 2

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

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

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

Из wkipedia:

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

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

Ответ 3

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

Ответ 4

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

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

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