Имеет ли значение 32-битная или 64-битная JVM?

Между 32-битной JVM и 64-битной JVM есть несколько явных различий и тонких нюансов. Мы подумали, что попытаемся прояснить их в этой статье вопросов и ответов.

Нужно ли мне понимать разницу между 32-битной JVM и 64-битной JVM?

Если вы не создаете критическое для производительности приложение, вам не нужно понимать разницу. Тонкая разница между 32-битной JVM и 64-битной JVM не будет иметь большого значения для вашего приложения. Дальше можно пропустить 😊.

64-битная JVM работает лучше, чем 32-битная JVM?

Большинство из нас думает, что 64-разрядная версия больше, чем 32-разрядная, поэтому производительность 64-разрядной JVM будет лучше, чем производительность 32-разрядной JVM. К сожалению, это не так. 64-разрядная JVM может иметь небольшое снижение производительности, чем 32-разрядная JVM. Ниже приведен отрывок из Документация Oracle JDK относительно производительности 64-битной JVM:

«Как правило, преимущества возможности адресации больших объемов памяти связаны с небольшой потерей производительности на 64-разрядных ВМ по сравнению с запуском того же приложения на 32-разрядной ВМ.

Разница в производительности при сравнении приложения, работающего на 64-разрядной платформе, и 32-разрядной платформы в SPARC составляет порядка 10–20 % ухудшения при переходе на 64-разрядную виртуальную машину. На платформах AMD64 и EM64T эта разница колеблется от 0 до 15 % в зависимости от количества указателей, выполняющихся при доступе к вашему приложению».

Если есть падение производительности, зачем кому-то использовать 64-битную JVM?

Максимум в 32-битной JVM адресуемое пространство памяти составляет всего 2 ^ 32 (т.е. ~ 4 ГБ). Это означает, что максимальный размер памяти вашего java-процесса не может превышать 4 ГБ. Из-за различных дополнительных ограничений (таких как доступная подкачка, адресное пространство ядра u
sage, фрагментация памяти и накладные расходы виртуальной машины), на практике предел намного ниже. В таблице ниже приведен максимальный размер кучи (т.е. -Xmx), который вы можете установить на 32-битной JVM:

Принимая во внимание, что если вы запускаете свое приложение на 64-разрядной JVM, максимальное адресуемое пространство памяти составляет 2 ^ 64 (т.е. 16 эксабайт). Это означает, что максимальный адресуемый объем памяти вашего приложения близок к бесконечности.

Почему производительность 64-битной JVM может быть ниже, чем у 32-битной JVM?

Это связано с тем, что каждый собственный указатель в системе занимает 8 байт вместо 4. Загрузка этих дополнительных данных влияет на использование памяти, что приводит к немного более медленному выполнению в зависимости от того, сколько указателей загружается во время выполнения. вашу Java-программу. Хорошей новостью является то, что на платформах AMD64 и EM64T, работающих в 64-разрядном режиме, виртуальная машина Java получает дополнительные регистры, которые она может использовать для создания более эффективных собственных последовательностей инструкций. потеря вообще при сравнении 32-битной и 64-битной скорости выполнения.

Что следует учитывать при переходе с 32-разрядной JVM на 64-разрядную JVM?
а. Время паузы GC

Основной причиной перехода с 32-разрядной JVM на 64-разрядную JVM является достижение большого размера кучи (т.е. -Xmx). Когда вы увеличиваете размер кучи, автоматически ваши паузы GC начинают увеличиваться, потому что теперь в памяти больше мусора, который нужно очистить. Перед миграцией необходимо выполнить правильную настройку сборщика мусора, иначе ваше приложение может столкнуться с паузой от нескольких секунд до нескольких минут. Вы можете использовать такие инструменты, как GCeasy чтобы придумать правильные настройки GC для недавно увеличенного размера кучи.

б. Родная библиотека

Если ваше приложение использует собственный интерфейс Java (JNI) для доступа к собственным библиотекам, вам также необходимо обновить собственные библиотеки. Потому что 32-битная JVM может использовать только 32-битную нативную библиотеку. Точно так же 64-битная JVM может использовать только 64-битную собственную библиотеку.

Что такое CompressedOops? Связано ли это с 32-битной, 64-битной JVM?

Да, CompressedOOps связан с 32-битной, 64-битной JVM.

Мы определяем объекты с полями данных. Когда этот объект создается в памяти, вместе с полями данных создается и заголовок объекта. Заголовок объекта необходим JVM для обслуживания, вызова виртуального метода, сборки мусора, блокировки… Этот заголовок объекта занимает 8 байтов в 32-битной JVM и 16 байтов в 64-битной JVM. Увеличение на 8 байт может показаться незначительным, но, учитывая, что ваше приложение создает миллионы объектов во время выполнения, 8 байт, умноженные на миллионы объектов, могут значительно увеличить нагрузку.

Вы можете смягчить эту проблему, передав -XX:+UseCompressedOops Аргумент JVM. Когда вы передаете этот аргумент, JVM делает хитрый трюк и оптимизирует размер заголовка объекта, чтобы использовать только 12 байт даже в 64-битной JVM. Этот хитрый трюк будет работать до тех пор, пока размер кучи JVM (то есть -Xmx) меньше 32 ГБ. Если он выйдет за пределы 32 ГБ, то размер заголовка объекта снова станет 16 байт.

Примечание: -XX:+UseCompressedOops используется по умолчанию, начиная с Java SE 6u23 и более поздних версий. Только если вы используете JDK 6u23 или более раннюю версию, передайте аргумент -XX:+UseCompressedOops.

Когда следует использовать 32-разрядную или 64-разрядную JVM?
< 2 ГБ памяти: Если размер кучи вашего приложения (т. е. -Xmx) меньше 2 ГБ, то это несложное решение. Используйте 32-битную JVM.

> 2 ГБ памяти: Если вашему приложению требуется более 2 Гб, то это тоже несложное решение. Используйте 64-битную JVM. Тем не менее, проведите надлежащие тесты производительности, чтобы измерить и смягчить влияние.

Как узнать, работает ли мое приложение на 32-битной или 64-битной JVM?

Есть несколько вариантов. Покажу пару вариантов:

Опция 1: Из командной строки введите команду:

java -version

Если это 64-битная JVM, вы увидите вывод, содержащий слово: «64-бит». Пример:

java version "1.8.0_181"

Java(TM) SE Runtime Environment (build 1.8.0_181-b13)

Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)

Если это 32-битная JVM, вы нет см. слово: «64-бит». Пример:

java version "1.8.0_211"

Java(TM) SE Runtime Environment (build 1.8.0_211-b12)

Java HotSpot(TM) Client VM (build 25.211-b12, mixed mode)

Вариант 2: Вы выдаете следующий оператор из своей Java-программы:

System.out.println(System.getProperty("sun.arch.data.model") + "-bit JVM");

В зависимости от типа JVM соответствующая версия будет напечатана на консоли.

Могу ли я запустить 32-разрядную JVM в 64-разрядной операционной системе?

Есть 32-битная ОС и 64-битная ОС. Если вы работаете в 32-разрядной операционной системе (что редко встречается в наши дни), вы можете запускать только 32-разрядную JVM. С другой стороны, если вы работаете в 64-битной операционной системе, вы можете запустить свое приложение либо на 32-битной JVM, либо на 64-битной JVM.

Как скачать 32-битную JVM, 64-битную JVM?

Когда вы идете в Страница загрузки Oracle JDKвы увидите варианты загрузки JDK для вашей операционной системы:

Здесь, если вы выберете x86, вы будете загружать 32-битную JVM. Если вы выберете x64, вы будете загружать 64-битную JVM. Все было бы намного проще, если бы они могли назвать его как «32-битная JVM для Windows», «64-битная JVM для Windows».

Может ли код, скомпилированный на 32-битной JVM, работать на 64-битной JVM?
Мы используем компилятор javac, т.е. java, для компиляции java-кода в байтовый код (т.е. файлы *.class). Сгенерированный байт-код не зависит от 32-битной, 64-битной JVM. Он может работать на обеих JVM. Помните вековое обещание «Напиши один раз, беги везде».