JRE 32bit против 64bit

Я использую Java некоторое время, и мой типичный ритуал создания новой машины для разработчиков требует нормального скачивания и установки последнего JDK с сайта Oracle.

Это вызвало необычный вопрос сегодня, does it matter if I use the 32bit or 64bit JRE bundle?

Подумав об этом, я установил обе версии до этого, и мои обычные plugchain подключаются в Eclipse. В моем повседневном программировании я не помню, чтобы когда-либо менять что-то или думать о чем-то по-другому, просто потому, что я использовал 64-битную JRE (или нацеленную на 64-битную JRE для этого).

Из моего понимания 64-битного и 32-битного - это действительно сводится к тому, как цифры хранятся под обложками... и я знаю, что int - это 32 бита, а long - 64 бит... то же самое, когда float составляет 32 бита, а double - 64 бита - так ли это просто, что Java отвлекла даже эту тонкость и, возможно, была "совместима с 64 бит"?

Я уверен, что я что-то упустил, кроме того, что не смог установить 64-битную JRE на 32-битную систему.

Ответ 1

64-битные и 32-битные в действительности сводятся к размеру ссылок на объекты, а не к числу чисел.

В 32-битном режиме ссылки - это четыре байта, что позволяет JVM уникально адресовать 2 ^ 32 байта памяти. Это причина того, что 32-разрядные JVM ограничены максимальным размером кучи 4 ГБ (в действительности, ограничение меньше из-за других издержек JVM и ОС и различается в зависимости от ОС).

В 64-битном режиме ссылки имеют (удивительно) восемь байтов, что позволяет JVM однозначно адресовать 2 ^ 64 байта памяти, что должно быть достаточно для любого. Размеры кучи JVM (заданные с помощью -Xmx) в 64-битном режиме могут быть огромными.

Но 64-битный режим обходится дорого: ссылки в два раза больше, что увеличивает потребление памяти. Вот почему Oracle представила "Сжатый упс". При включенном сжатии упс (который, как я считаю, теперь используется по умолчанию), ссылки на объекты сокращаются до четырех байтов с оговоркой, что куча ограничена четырьмя миллиардами объектов (и 32 ГБ Xmx). Сжатые операции не являются бесплатными: для достижения такого значительного сокращения потребления памяти требуются небольшие вычислительные затраты.

Как личное предпочтение, я всегда запускаю 64-битную JVM дома. Процессор поддерживает x64, ОС тоже, поэтому мне нравится, что JVM работает и в 64-битном режиме.

Ответ 2

Как вы заметили, примитивные числовые типы в Java четко определены.

Однако выбор между 32-битными и 64-разрядными JVM может иметь значение, если ваше приложение Java использует библиотеки нативного кода, которые могут быть созданы для использования в 32-разрядном приложении, в 64-разрядном приложении или в обоих,

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

Ответ 3

В зависимости от контекста, для локальной разработки я всегда буду использовать 64-битный JDK. Прежде всего потому, что мне, скорее всего, понадобится все пространство памяти для сборщиков и IDE.

Что касается интеграции в производство, я бы рекомендовал 32-битный, если это возможно. Почему?

Для некоторых серверов Java EE, которые лицензированы для использования в производстве, это будет зависеть от некоторых факторов, таких как машина, сколько ядер и т.д. Для WebSphere Liberty Profile вы также ограничены 2 ГБ.

64-разрядные JRE будут занимать немного больше памяти, и если вы пытаетесь ограничить его чем-то вроде 2 ГБ или лучше, но 2x 1 ГБ кластер, у вас будет больше возможностей для гибки, чтобы не обойтись без выплаты процента.

От https://plumbr.eu/blog/java/should-i-use-32-or-64-bit-jvm

Проблема 1: на 64-битной основе требуется 30-50% дополнительной кучи. Почему так? В основном из-за макета памяти в 64-битной архитектуре. Прежде всего - заголовок объекта составляет 12 байтов на 64-битной JVM. Во-вторых, ссылки на объекты может быть 4 байта или 8 байтов, в зависимости от флагов JVM и размера кучи. Это определенно добавляет некоторые накладные расходы по сравнению с 8 байты на заголовках по 32-битным и 4 байтам по ссылкам. Вы также можете копать в одном из наших ранних сообщений для получения дополнительной информации о вычислении потребление памяти объектом.

Проблема 2: Более длинная сборка мусора приостанавливается. Создание большего количества кучи означает, что GC будет больше работать, очищая его от неиспользуемые объекты. В реальной жизни это означает, что вы должны быть особенно осторожно при создании кучи размером более 12-16 ГБ. Без штрафа настройка и измерение, вы можете легко ввести полные GC-паузы, охватывающие несколько минут. В приложениях, где латентность не имеет решающего значения, и вы может оптимизировать для пропускной способности только это может быть ОК, но в большинстве случаев это может стать showstopper.

Чтобы ограничить влияние вашей среды Java EE, выгрузите ее части в другие микросервисы, такие как ElasticSearch для поиска, Hazelcast для кеширования, вашу базу данных для хранения данных и сохраните ваш сервер Java EE для размещения самого ядра приложения, а не для запуска сервисы внутри него.

Ответ 4

Я думаю, что есть два основных различия. Один из них упоминается здесь, но не другой.

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

64-битные JVM могут выделять (могут использовать) больше памяти, чем 32-разрядные.
64-битные используют собственные типы данных с большей пропускной способностью, но занимают больше места. Потому что тот же объект может занимать больше места.
Для JVM, которые Garbage Collector (GC) замораживает машину, версии с 64 битами могут быть медленнее, потому что GC должен проверять большие кучи/объекты, и требуется больше времени.
Существует презентация IBM, объясняющая эти различия.

И с другой стороны, поддерживаемые собственные библиотеки. Программы Java, использующие JNI для доступа к родным библиотекам, требуют разных версий в зависимости от типа JVM.

32-разрядные JVM используют 32-разрядные собственные библиотеки и 64-разрядные JVM используют библиотеки 64 бит.
Это означает, что если ваша программа использует библиотеки, которые полагаются на собственный код, такой как SWT, вам понадобятся разные версии. Обратите внимание на страницу загрузки SWT, существуют разные версии для Linux/Windows 32- и 64-разрядных. Обратите внимание, что существуют различные версии Eclipse (каждая с другой версией SWT) для 32- и 64-разрядных.
Некоторые приложения, такие как Alloy, упакованы с 32-разрядными родными библиотеками. Они не работают с 64-разрядными JVM. Вы можете решить эти проблемы, просто загрузив соответствующие 64-битные родные библиотеки и соответствующим образом настроив JNI.

Ответ 5

Нужно ли понимать разницу между 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% в зависимости от количества указателей, обращающихся к вашему приложению ".

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

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

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

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

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