Производительность Java

В разработке программного обеспечения язык программирования Java исторически считался более медленным, чем самые быстрые языки третьего поколения, типизированные такие как C и C++ . В отличие от этих языков, Java по умолчанию компилируется в виртуальную машину Java (JVM) с операциями, отличными от операций реального компьютерного оборудования. Ранние реализации JVM представляли собой интерпретаторы ; они моделировали виртуальные операции одну за другой, а не переводили их в машинный код для прямого аппаратного выполнения.

С конца 1990-х годов скорость выполнения программ на Java значительно улучшилась за счет внедрения JIT- компиляции (в 1997 году для Java 1.1 ), добавление языковых функций, поддерживающих лучший анализ кода, и оптимизацию JVM (например, HotSpot стал стандартным для Sun JVM в 2000 году). Сложные стратегии сбора мусора также нуждаются в улучшении. Аппаратное исполнение байт-кода Java, например, предлагаемое ARM Jazelle , изучалось, но не применялось.

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

Методы оптимизации виртуальных машин

Многие оптимизации со временем улучшили производительность JVM. Однако, хотя Java часто была первой виртуальной машиной, успешно реализовавшей их, они часто использовались и на других подобных платформах.

Компиляция точно в срок

Дополнительная информация: своевременная компиляция и HotSpot (виртуальная машина).

Ранние JVM всегда интерпретировали байт-коды Java . Это привело к значительному снижению производительности — от 10 до 20 раз для Java по сравнению с C в средних приложениях. Чтобы бороться с этим, в Java 1.1 был введен JIT-компилятор. Из-за высокой стоимости компиляции в Java 1.2 была введена дополнительная система под названием HotSpot , которая стала системой по умолчанию в Java 1.3. Используя эту структуру, виртуальная машина Java постоянно анализирует производительность программы на наличие горячих точек , которые выполняются часто или неоднократно. Затем они направляются на оптимизацию , что приводит к высокопроизводительному выполнению с минимальными накладными расходами для менее критичного к производительности кода. Некоторые тесты показывают 10-кратный прирост скорости благодаря этому. Однако из-за нехватки времени компилятор не может полностью оптимизировать программу, и поэтому полученная программа работает медленнее, чем альтернативы с собственным кодом.

Адаптивная оптимизация

Дополнительная информация: Адаптивная оптимизация.

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

Виртуальная машина Java, такая как HotSpot, также может деоптимизировать код, который ранее был JIT-компилятором. Это позволяет выполнять агрессивную (и потенциально небезопасную) оптимизацию, сохраняя при этом возможность позже деоптимизировать код и вернуться на безопасный путь.

Сбор мусора

Дополнительная информация: Сбор мусора (информатика).

(JVM) версий 1.0 и 1.1 Виртуальные машины Java использовали сборщик пометок и очистки , который мог фрагментировать кучу после сборки мусора. Начиная с Java 1.2, JVM изменились на сборщик поколений , который имеет гораздо лучшее поведение при дефрагментации. Современные JVM используют множество методов, которые еще больше повышают производительность сборки мусора .

Другие методы оптимизации

Сжатый

Сжатые Oops позволяют Java 5.0+ адресовать до 32 ГБ кучи с 32-битными ссылками. Java не поддерживает доступ к отдельным байтам, а только к объектам, которые по умолчанию выровнены по 8 байтам. По этой причине младшие 3 бита ссылки на кучу всегда будут равны 0. Уменьшив разрешение 32-битных ссылок до 8-байтовых блоков, адресное пространство можно увеличить до 32 ГБ. Это значительно снижает использование памяти по сравнению с использованием 64-битных ссылок, поскольку Java использует ссылок гораздо больше, чем некоторые языки, такие как C++. Java 8 поддерживает более крупные выравнивания, такие как выравнивание по 16 байтам, для поддержки до 64 ГБ с 32-битными ссылками.

Проверка разделенного байт-кода

Перед выполнением класса Sun JVM проверяет его байт-коды Java (см. средство проверки байт-кода ). Эта проверка выполняется лениво: байт-коды классов загружаются и проверяются только тогда, когда конкретный класс загружается и готовится к использованию, а не в начале программы. Java Однако, поскольку библиотеки классов также являются обычными классами Java, их также необходимо загружать при использовании, а это означает, что время запуска программы Java часто больше, чем C++ , например, для программ .

Метод под названием «Промежуточная проверка» , впервые представленный в платформе Java Micro Edition (J2ME), используется в JVM начиная с версии Java 6 . Он разделяет проверку байт-кода Java на два этапа:

• Время разработки — при компиляции класса из исходного кода в байт-код.
• Время выполнения – при загрузке класса.

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

Анализ побегов и укрупнение замков

Дополнительная информация: Блокировка (информатика) и анализ побега.

Java может управлять многопоточностью на уровне языка. Многопоточность позволяет программам выполнять несколько процессов одновременно, тем самым повышая производительность программ, работающих на компьютерных системах с несколькими процессорами или ядрами. Кроме того, многопоточное приложение может реагировать на вводимые данные даже при выполнении длительных задач.

Однако программам, использующим многопоточность, необходимо уделять особое внимание объектам, совместно используемым между потоками, блокируя доступ к общим методам или блокам , когда они используются одним из потоков. Блокировка блока или объекта — трудоемкая операция из-за особенностей базовой операции на уровне операционной системы (см. управление параллелизмом и степень детализации блокировки ).

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

До Java 6 виртуальная машина всегда блокировала объекты и блоки по запросу программы, даже если не было риска изменения объекта двумя разными потоками одновременно. Например, в данном случае местный Vector был заблокирован перед каждой операцией добавления , чтобы гарантировать, что он не будет изменен другими потоками ( Vector синхронизируется), но поскольку он является строго локальным для метода, в этом нет необходимости:

public String getNames() {
     final Vector<String> v = new Vector<>();
     v.add("Me");
     v.add("You");
     v.add("Her");
     return v.toString();
}

Начиная с Java 6, блоки кода и объекты блокируются только при необходимости. поэтому в приведенном выше случае виртуальная машина вообще не будет блокировать объект Vector.

Начиная с версии 6u23, Java включает поддержку escape-анализа.

Улучшения распределения регистров

До Java 6 распределение регистров в клиентской виртуальной машине было очень примитивным (они не размещались в блоках ), что было проблемой в конструкциях ЦП , в которых было меньше доступных регистров процессора , как в x86 . Если для операции больше нет доступных регистров, компилятор должен скопировать данные из регистра в память (или из памяти в регистр), что требует времени (доступ к регистрам происходит значительно быстрее). Однако виртуальная машина сервера использовала распределитель цветных графиков и не имела этой проблемы.

Оптимизация распределения регистров была представлена ​​в Sun JDK 6; тогда можно было использовать одни и те же регистры в разных блоках (если это применимо), уменьшая доступ к памяти. Это привело к заявленному приросту производительности примерно на 60% в некоторых тестах.

Обмен данными класса

Совместное использование данных классов (называемое Sun CDS) — это механизм, который сокращает время запуска Java-приложений, а также уменьшает объем памяти . Когда JRE установлена, программа установки загружает набор классов из системного файла JAR (файл JAR, содержащий всю библиотеку классов Java, называемый rt.jar) в частное внутреннее представление и выгружает это представление в файл, называемый «общий архив». Во время последующих вызовов JVM этот общий архив отображается в памяти JVM для этих классов между несколькими процессами JVM. большую часть метаданных , что экономит затраты на загрузку этих классов и позволяет совместно использовать

Соответствующее улучшение времени запуска более очевидно для небольших программ.

История улучшений производительности

Дополнительная информация: история версий Java.

Помимо перечисленных здесь улучшений, в каждом выпуске Java было представлено множество улучшений производительности JVM и интерфейса программирования приложений (API) Java.

JDK 1.1.6: Первая своевременная компиляция ( ) JIT-компилятор Symantec

J2SE 1.2: Использование сборщика поколений .

J2SE 1.3: Своевременная компиляция с помощью HotSpot .

J2SE 1.4: См . здесь обзор улучшений производительности Sun между версиями 1.3 и 1.4.

Java SE 5.0: совместное использование данных классов

Ява ЮВ 6:

• Проверка разделенного байт-кода
• Анализ побегов и укрупнение замков
• Улучшения распределения регистров

Другие улучшения:

• Java OpenGL Java 2D Улучшение скорости конвейера
• Производительность Java 2D также значительно улучшилась в Java 6.

См. также «Обзор Sun по улучшению производительности между Java 5 и Java 6».

Java SE 6, обновление 10

• Java Quick Starter сокращает время запуска приложения за счет предварительной загрузки части данных JRE при запуске ОС в дисковый кэш .
• Части платформы, необходимые для выполнения приложения, доступ к которому осуществляется из Интернета, когда JRE не установлена, теперь загружаются в первую очередь. Полная версия JRE занимает 12 МБ, типичному приложению Swing для запуска требуется загрузить только 4 МБ. Остальные части затем загружаются в фоновом режиме.
• Производительность графики в Windows улучшена за счет широкого использования Direct3D по умолчанию. и используйте шейдеры на графическом процессоре (GPU) для ускорения сложных 2D-операций Java .

Ява 7

Для Java 7 было выпущено несколько улучшений производительности: Будущие улучшения производительности запланированы для обновления Java 6 или Java 7:

• Обеспечить поддержку JVM для динамических языков программирования после работы по созданию прототипов, выполняемой в настоящее время на машине Da Vinci (многоязычная виртуальная машина),
• Расширьте существующую библиотеку параллелизма за счет управления параллельными вычислениями на многоядерных процессорах.
• Разрешите JVM использовать как клиентский , так и серверный JIT-компиляторы в одном сеансе с помощью метода, называемого многоуровневой компиляцией:
  • Клиент , будет использоваться при запуске (потому что он хорош при запуске и для небольших приложений)
  • Сервер клиентский будет использоваться для долгосрочной работы приложения (поскольку в этом отношении он превосходит компилятор ).
• Замените существующий параллельный сборщик мусора с низкой паузой (также называемый сборщиком параллельной разметки (CMS)) новым сборщиком под названием Garbage First (G1), чтобы обеспечить постоянные паузы с течением времени.

Сравнение с другими языками

Для объективного сравнения производительности программы Java и эквивалентной программы, написанной на другом языке, например C++, требуется тщательно и продуманно построенный тест, который сравнивает программы, выполняющие идентичные задачи. Целевой платформой Java компилятора байт-кода является платформа Java , а байт-код либо интерпретируется, либо компилируется в машинный код с помощью JVM. Другие компиляторы почти всегда ориентированы на конкретную аппаратную и программную платформу, создавая машинный код, который практически не изменяется во время выполнения. . В результате этих двух разных подходов возникают совершенно разные и трудно сравнимые сценарии: статическая и динамическая компиляция и перекомпиляция , наличие точной информации о среде выполнения и другие.

Java часто «точно в срок» Java компилируется виртуальной машиной во время выполнения , но также может быть скомпилирована заранее , как и C++. При своевременной компиляции микротесты The Computer Language Benchmarks Game показывают следующее о ее производительности:

• медленнее, чем компилируемые языки, такие как C или C++ ,
• аналогично другим языкам, компилируемым точно в срок, таким как C# ,
• намного быстрее, чем языки без эффективного компилятора собственного кода ( JIT или AOT ), такие как Perl , Ruby , PHP и Python .

Скорость программы

Бенчмарки часто измеряют производительность небольших программ с большим числом вычислений. В некоторых редких реальных программах Java превосходит C. Одним из примеров является тест Jake2 (клон Quake II , написанный на Java путем перевода исходного кода C GPL ). Версия Java 5.0 работает лучше в некоторых конфигурациях оборудования, чем ее аналог C. Хотя не уточняется, как были измерены данные (например, использовался ли исходный исполняемый файл Quake II, скомпилированный в 1997 году, что можно считать плохим, поскольку текущие компиляторы C могут обеспечить лучшую оптимизацию для Quake), в нем отмечается, что тот же исходный код Java можно получить огромный прирост скорости, просто обновив виртуальную машину, чего невозможно достичь при 100% статическом подходе.

Что касается других программ, аналог C++ может работать и обычно работает значительно быстрее, чем эквивалент Java. Тест, проведенный Google в 2011 году, показал разницу в 10 раз между C++ и Java. С другой стороны, академический тест, проведенный в 2012 году с использованием алгоритма 3D-моделирования, показал, что JVM Java 6 от 1,09 до 1,91 раз медленнее, чем C++ под Windows.

Некоторые оптимизации, возможные в Java и подобных языках, при определенных обстоятельствах могут быть невозможны в C++:

• в стиле C Использование указателей может затруднить оптимизацию в языках, поддерживающих указатели.
• Использование методов escape-анализа ограничено в C++ , например, потому, что компилятор C++ не всегда знает, будет ли объект изменен в данном блоке кода из-за указателей .
• Java может получить доступ к производным методам экземпляра быстрее, чем C++ может получить доступ к производным виртуальным методам, благодаря дополнительному поиску в виртуальной таблице C++. Однако невиртуальные методы в C++ не страдают от узких мест в производительности v-таблиц и, таким образом, демонстрируют производительность, аналогичную Java.

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

Результаты микротестов Java и C++ во многом зависят от того, какие операции сравниваются. Например, при сравнении с Java 5.0:

• 32- и 64-битные арифметические операции, ввод/вывод файла , и обработка исключений иметь аналогичную производительность с сопоставимыми программами на C++
• Операции с массивами иметь лучшую производительность в C.
• Производительность тригонометрических функций намного лучше в C.

---

Примечания

Многоядерная производительность

Масштабируемость и производительность приложений Java в многоядерных системах ограничены скоростью выделения объектов. Этот эффект иногда называют «стеной распределения». Однако на практике современные алгоритмы сборщика мусора используют для выполнения сборки мусора несколько ядер, что в некоторой степени смягчает эту проблему. Сообщается, что некоторые сборщики мусора поддерживают скорость выделения более гигабайта в секунду. и существуют системы на базе Java, которые без проблем масштабируются до нескольких сотен ядер ЦП и кучи размером в несколько сотен ГБ.

Автоматическое управление памятью в Java позволяет эффективно использовать незапираемые и неизменяемые структуры данных, которые чрезвычайно сложно, а иногда и невозможно реализовать без какой-либо сборки мусора. Java предлагает ряд таких высокоуровневых структур в своей стандартной библиотеке в пакете java.util.concurrent, в то время как во многих языках, исторически использовавшихся для высокопроизводительных систем, таких как C или C++, они до сих пор отсутствуют.

Время запуска

Время запуска Java часто намного медленнее, чем у многих языков, включая C , C++ , Perl или Python , поскольку многие классы (и в первую очередь классы из библиотек классов платформы ) должны быть загружены перед использованием.

По сравнению с аналогичными популярными средами выполнения для небольших программ, работающих на компьютере под управлением Windows, время запуска похоже на время запуска Mono и немного медленнее, чем у .NET .

Похоже, что большая часть времени запуска связана с операциями ввода-вывода (IO), а не с инициализацией JVM или загрузкой классов ( один только файл данных класса rt.jar имеет размер 40 МБ, и JVM должна искать много данных в этом большом файле). . Некоторые тесты показали, что, хотя новый метод проверки разделенного байт-кода улучшил загрузку классов примерно на 40%, он реализовал запуск только на 5%. улучшение для больших программ.

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

Начиная с Java SE 6 Update 10, Sun JRE поставляется с Quick Starter, который предварительно загружает данные классов при запуске ОС, чтобы получить данные из дискового кэша, а не с диска.

Excelsior JET подходит к проблеме с другой стороны. Его оптимизатор запуска уменьшает объем данных, которые необходимо прочитать с диска при запуске приложения, и делает чтение более последовательным.

В ноябре 2004 года был публично выпущен Nailgun , «клиент, протокол и сервер для запуска Java-программ из командной строки без затрат на запуск JVM». впервые представила возможность сценариям использовать JVM в качестве демона для запуска одного или нескольких приложений Java без затрат на запуск JVM. Демон Nailgun небезопасен: «все программы запускаются с теми же разрешениями, что и сервер». Там, где многопользовательская необходима безопасность, Nailgun не подходит без специальных мер предосторожности. Сценарии, в которых запуск JVM для каждого приложения доминирует над использованием ресурсов, обеспечивают на один-два порядка . повышение производительности во время выполнения

Использование памяти

Использование памяти Java намного выше, чем использование памяти C++, потому что:

• Накладные расходы составляют 8 байт для каждого объекта и 12 байт для каждого массива. на Яве. Если размер объекта не кратен 8 байтам, он округляется до следующего числа, кратного 8. Это означает, что объект, содержащий однобайтовое поле, занимает 16 байт и нуждается в 4-байтовой ссылке. C++ также выделяет указатель (обычно 4 или 8 байт) для каждого объекта, класс которого прямо или косвенно объявляет виртуальные функции .
• Отсутствие адресной арифметики делает создание контейнеров с эффективным использованием памяти, таких как плотно расположенные структуры и связанные списки XOR , в настоящее время невозможным ( проект OpenJDK Valhalla направлен на смягчение этих проблем, хотя он и не преследует цели внедрения арифметики указателей; это невозможно сделать в среда для сбора мусора).
• В отличие от malloc и new, средние издержки производительности при сборке мусора асимптотически приближаются к нулю (точнее, к одному циклу ЦП) по мере увеличения размера кучи.
• Части библиотеки классов Java должны загружаться перед выполнением программы (по крайней мере, классы, используемые в программе). Это приводит к значительным затратам памяти для небольших приложений.
• Как двоичные файлы Java, так и собственные перекомпиляции обычно находятся в памяти.
• Виртуальная машина использует значительный объем памяти.
• В Java составной объект (класс A, который использует экземпляры B и C) создается с использованием ссылок на выделенные экземпляры B и C. В C++ можно избежать затрат памяти и производительности для этих типов ссылок, когда экземпляр B и C /или C существует внутри A.

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

Тригонометрические функции

Производительность тригонометрических функций плохая по сравнению с C, поскольку Java имеет строгие спецификации результатов математических операций, которые могут не соответствовать базовой аппаратной реализации. В подмножестве x87 с плавающей запятой Java, начиная с версии 1.4, выполняет сокращение аргументов для sin и cos в программном обеспечении, что приводит к значительному снижению производительности для значений, выходящих за пределы диапазона.

Собственный интерфейс Java

требует Собственный интерфейс Java больших затрат, что делает пересечение границы между кодом, выполняемым на JVM, и собственным кодом дорогостоящим. Java Native Access (JNA) обеспечивает программам Java легкий доступ к собственным общим библиотекам ( динамически подключаемым библиотекам (DLL) в Windows) только через код Java, без использования JNI или собственного кода. Эта функциональность сравнима с Windows Platform/Invoke и ctypes Python . Доступ является динамическим во время выполнения без генерации кода. Но у этого есть своя цена: JNA обычно медленнее, чем JNI.

Пользовательский интерфейс

Swing считается более медленным, чем собственные наборы инструментов для виджетов , поскольку он делегирует рендеринг виджетов чистому Java 2D API . Однако тесты, сравнивающие производительность Swing и Standard Widget Toolkit , который делегирует рендеринг собственным библиотекам графического интерфейса операционной системы, не выявили явного победителя, а результаты сильно зависят от контекста и среды. Кроме того, новая платформа JavaFX , призванная заменить Swing, решает многие присущие Swing проблемы.

Использование для высокопроизводительных вычислений

Некоторые люди считают, что производительность Java для высокопроизводительных вычислений (HPC) аналогична производительности Fortran в тестах с интенсивными вычислениями, но у JVM все еще есть проблемы с масштабируемостью для выполнения интенсивного обмена данными в сети распределенных вычислений .

Однако приложения для высокопроизводительных вычислений, написанные на Java, выиграли соревнования по тестированию производительности. В 2008 году и 2009 г., Кластер на базе Apache Hadoop (проект высокопроизводительных вычислений с открытым исходным кодом, написанный на Java) смог быстрее всех отсортировать терабайты и петабайты целых чисел. Однако аппаратная настройка конкурирующих систем не была исправлена.

В конкурсах по программированию

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

См. также

• Общеязыковая среда выполнения
• Анализ производительности
• Java-процессор — встроенный процессор, выполняющий собственный байт-код Java (например, JStik ).
• Сравнение Java и C++
• Java ConcurrentMap

Ссылки

• Блох, Джошуа (2018). «Эффективная Java: Руководство по языку программирования» (третье изд.). Аддисон-Уэсли. ISBN  978-0134685991 .

Внешние ссылки

• Сайт, посвященный информации о производительности Java
• Отладка проблем с производительностью Java
• Портал Sun по производительности Java
• Mind-карта на основе презентаций инженеров СПб филиала Oracle (в виде большого PNG-изображения)