Почему JVM медленно запускается?

Question

Что именно заставляет JVM (в частности, реализацию Sun) работать медленнее по сравнению с другими средами выполнения, такими как CPython?У меня сложилось впечатление, что это в основном связано с загрузкой множества библиотек независимо от того, нужны они или нет, но, похоже, на исправление этого не потребуется 10 лет.

Если подумать, как время запуска JVM соотносится с временем запуска CLR в Windows?Как насчет CLR Mono?

ОБНОВЛЯТЬ:Меня особенно беспокоит вариант использования небольших утилит, связанных вместе, как это часто бывает в Unix.Подходит ли сейчас Java для этого стиля?Какие бы накладные расходы ни вызывал Java при запуске, суммируются ли они для каждого Java-процесса или накладные расходы действительно проявляются только для первого процесса?

Answer 1

Вот что говорит Википедия по этому вопросу (с некоторыми ссылками).

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

Answer 2

Просто отмечу некоторые решения:

Существует два механизма, позволяющих ускорить запуск JVM.Первый — это механизм совместного использования данных класса, который поддерживается начиная с версии Java 6 Update 21 (только с клиентской виртуальной машиной HotSpot и, насколько мне известно, только с последовательным сборщиком мусора).

Для активации необходимо установить -Xshare (в некоторых реализациях: -Xshareclasses ) Опции JVM.

Чтобы узнать больше об этой функции, вы можете посетить:Обмен данными класса

Второй механизм — это Java Quick Starter.Это позволяет предварительно загружать классы во время запуска ОС, см.:Быстрый старт Java Больше подробностей.

Answer 3

Запуск тривиального Java-приложения с клиентской JVM версии 1.6 (Java 6) на моей машине кажется мгновенным.Sun попыталась настроить клиентскую JVM для более быстрого запуска (а клиентская JVM используется по умолчанию), поэтому, если вам не нужно много дополнительных jar-файлов, запуск должен быть быстрым.

Answer 4

Если вы используете Sun HotSpot для x86_64 (64-битная компиляция), обратите внимание, что текущая реализация работает только в серверном режиме, то есть она предварительно компилирует каждый загружаемый класс с полной оптимизацией, тогда как 32-битная версия также поддерживает клиентский режим, который обычно откладывает оптимизацию. и оптимизирует только самые ресурсоемкие части ЦП, но ускоряет запуск.

См., например:

• http://en.wikipedia.org/wiki/64-bit#32_vs_64_bit
• http://java.sun.com/docs/hotspot/HotSpotFAQ.html#64bit_compilers

При этом, по крайней мере, на моей машине (Linux x86_64 с 64-битным ядром) 32-битная версия HotSpot поддерживает как клиентский, так и серверный режим (через флаги -client и -server), но по умолчанию используется режим сервера, тогда как 64-битная версия поддерживает только режим сервера.

Answer 5

Это действительно зависит от того, что вы делаете во время запуска.Если вы запустите приложение Hello World, на моем компьютере это займет 0,15 секунды.

Однако Java лучше подходит для работы в качестве клиента или сервера/службы, что означает, что время запуска не так важно, как время соединения (около 0,025 мс) или время ответа в обоих направлениях (<< 0,001 мс).

Answer 6

Есть множество причин:

• много jars для загрузки
• проверка (убедиться, что код не делает злых вещей)
• Накладные расходы JIT (компиляция точно во время)

Я не уверен насчет CLR, но думаю, что она зачастую быстрее, поскольку кэширует собственную версию сборок для следующего раза (поэтому ей не требуется JIT).CPython запускается быстрее, потому что это интерпретатор, а IIRC не выполняет JIT.

Answer 7

В дополнение к уже упомянутым вещам (загрузка классов, особенно.из сжатых JAR);работа в интерпретируемом режиме до того, как HotSpot скомпилирует часто используемый байт-код;и накладные расходы на компиляцию HotSpot, также существует немало однократной инициализации, выполняемой самими классами JDK.Многие оптимизации выполняются в пользу долго работающих систем, где скорость запуска не вызывает особого беспокойства.

А что касается конвейерной обработки в стиле Unix:вы, конечно, НЕ хотите запускать и перезапускать JVM несколько раз.Это не будет эффективно.Скорее, цепочка инструментов должна происходить внутри JVM.Это нелегко совместить с инструментами Unix, отличными от Java, за исключением запуска таких инструментов из JVM.

Answer 8

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

Простой класс hello world в стиле одного лайнера с основным по-прежнему требует загрузки и инициализации большого количества элементов.Проверка класса требует большого количества проверок и проверок зависимостей, которые требуют времени и выполнения большого количества инструкций ЦП.С другой стороны, программа на языке C не выполняет ничего из этого и выполняет несколько инструкций, а затем вызывает функцию принтера.