Потоки Java против потоков ОС
Используйте опцию --sort=-committerdate из git for-each-ref ;
Также доступно начиная с Git 2.7.0 для git branch :
Базовое использование:
git for-each-ref --sort=-committerdate refs/heads/
# Or using git branch (since version 2.7.0)
git branch --sort=-committerdate # DESC
git branch --sort=committerdate # ASC
Результат:
Расширенное использование:
git for-each-ref --sort=committerdate refs/heads/ --format='%(HEAD) %(color:yellow)%(refname:short)%(color:reset) - %(color:red)%(objectname:short)%(color:reset) - %(contents:subject) - %(authorname) (%(color:green)%(committerdate:relative)%(color:reset))'
Результат:
2 ответа
Каждый поток получит собственный поток ОС для 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 должна быть сопоставлена с ее собственным аналогом в определенный момент времени. Сохраняется ли этот нативный код для дальнейшего повторного использования или выбрасывается, если что-то другое (оптимизация, помните?).
Следовательно, чтобы ответить на ваш вопрос, всякий раз, когда вы пишете многопоточный код, он переводится в собственный код и запускается в ОС. Независимо от того, делается ли этот перевод на лету или проверен в тот момент, это совершенно другой вопрос.
- Некоторые реализации Java могут создавать «зеленые» потоки, как вы описываете (планирование, выполняемое JVM в одном собственном потоке), но обычные реализации Java на ПК используют несколько ядер.
- Сама JVM может уже использовать разные потоки для работы (сборка мусора, загрузка классов, проверка байт-кода, JIT-компилятор).
- ОС запускает программу под названием JVM. JVM выполняет Java-байт-код. Если каждый Java-поток имеет связанный собственный поток (что имеет смысл и, как представляется, имеет место в реализациях на ПК), то JVM-код в этом потоке выполняет Java-код - JITed или интерпретируемый - как в однопоточном -Программа. Здесь нет разницы благодаря многопоточности.