Это небольшая, но заметная разница:
$ for j in {5..12}; do . chjdk $j; time (java -version; for i in {1..1000}; do java x >/dev/null; done); echo ""; done
java version "1.5.0_22"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_22-b03)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_22-b03, mixed mode)
real 2m4.988s
user 0m59.832s
sys 0m18.856s
java version "1.6.0_45"
Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)
real 0m28.055s
user 0m24.012s
sys 0m4.216s
java version "1.7.0_80"
Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
real 0m31.225s
user 0m24.836s
sys 0m3.564s
java version "1.8.0_202"
Java(TM) SE Runtime Environment (build 1.8.0_202-b08)
Java HotSpot(TM) 64-Bit Server VM (build 25.202-b08, mixed mode)
real 0m43.463s
user 0m35.948s
sys 0m6.516s
java version "9"
Java(TM) SE Runtime Environment (build 9+181)
Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
real 1m29.909s
user 1m37.892s
sys 0m12.972s
java version "10.0.1" 2018-04-17
Java(TM) SE Runtime Environment 18.3 (build 10.0.1+10)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.1+10, mixed mode)
real 1m21.161s
user 1m24.412s
sys 0m13.044s
openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
real 0m56.932s
user 1m8.892s
sys 0m9.516s
openjdk version "12" 2019-03-19
OpenJDK Runtime Environment (build 12+33)
OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing)
real 0m39.930s
user 0m38.876s
sys 0m9.520s
Что-то изменилось конкретно в рамках выпуска Java 12 или это ошибка измерения?
Обновление
Действительно, JVM загружается быстрее.Спасибо LppEdd и Хольгеру за справку.
JEP 341 - Стандартные архивы CDS .
Когда вы запускаетеJava-приложение, загружаются тысячи классов, и кажется, что JVM замедляет запуск.
Класс Data Sharing - это функция, которая была представлена как коммерческая функция, начиная с JDK 8, обновление 40. Она позволяет упаковать все классы запуска в архив определенного формата, после чего время запуска приложения увеличилось.,Через некоторое время был введен JEP 310: обмен данными между классами приложений , который позволил нам сделать то же самое не только с классами системы, но и с классами приложений.
ДляКлассы JDK, это выглядит так.Сначала мы сбрасываем классы с помощью java -Xshare:dump, а затем запускаем приложение, говоря ему использовать этот кеш: java -Xshare:on -jar app.jar.И скорость запуска немного улучшилась.
Но казалось странным каждый раз писать -Xshare: dump, если результат выполнения этой команды по умолчанию немного предсказуем на этапе создания JDK-дистрибутива.Согласно документации, если дистрибутив Java 8 был установлен с помощью программы установки, то в момент установки он должен выполнить необходимые вам команды.Но почему?А что делать с дистрибутивом, который распространяется не в виде установщика, а в виде zip-архива?
Поскольку архив JDK 12 CDS будет создан создателями дистрибутива сразу послесшивание.Даже для ночных сборок (при условии, что они 64-битные и собственные, а не для кросс-компиляции).
Начиная с JDK 11, -Xshare: auto включен по умолчанию, и такой архив будет выбран автоматически. Таким образом, простое обновление до JDK 12 ускоряет запуск приложения!