- Home »
Разница между JDK, JRE и JVM
Если ты когда-нибудь пытался развернуть Java-приложение на сервере, то наверняка сталкивался с загадочными аббревиатурами: JDK, JRE, JVM. Вроде бы все про Java, но что ставить на сервер, чтобы всё работало? А если нужно только запускать, а не компилировать? А если хочется автоматизировать деплой? В этой статье разложу по полочкам, что это за звери, чем они отличаются, как быстро всё настроить и не словить баги на ровном месте. Будет и практика, и схемы, и даже немного гиковских лайфхаков. Поехали!
JDK, JRE, JVM — кто есть кто?
Давай разберёмся, что скрывается за этими тремя буквосочетаниями:
- JVM (Java Virtual Machine) — виртуальная машина, которая исполняет байткод Java. Это, по сути, движок, который понимает .class-файлы и превращает их в работающие процессы на твоём сервере.
- JRE (Java Runtime Environment) — среда выполнения Java. Включает JVM + стандартные библиотеки Java. То есть, это минимальный набор, чтобы запускать уже скомпилированные Java-приложения.
- JDK (Java Development Kit) — комплект разработчика. Включает JRE + компилятор (javac) и инструменты для разработки (javadoc, jdb и др.). Это уже полный фарш, если нужно не только запускать, но и собирать приложения прямо на сервере.
Вот простая аналогия: JVM — это движок, JRE — машина без инструментов для ремонта, JDK — машина с полным набором инструментов в багажнике.
Как это работает?
Когда ты запускаешь Java-приложение, происходит следующее:
- Ты компилируешь исходники в байткод (.class-файлы) с помощью
javac(требуется JDK). - JVM (через
java) читает байткод и исполняет его на твоём сервере. - JRE обеспечивает JVM всеми нужными библиотеками и ресурсами.
На сервере чаще всего нужен только JRE (если ты не компилируешь код на лету), но иногда без JDK не обойтись — например, если используешь динамическую компиляцию, инструменты профилирования или пишешь скрипты для автоматизации.
JDK vs JRE vs JVM: Таблица сравнения
| Компонент | Что входит | Для чего нужен | Когда использовать | Размер (примерно) |
|---|---|---|---|---|
| JVM | Виртуальная машина | Исполнение байткода | Всегда (ядро Java) | ~30-50 МБ |
| JRE | JVM + стандартные библиотеки | Запуск Java-приложений | Когда нужен только запуск | ~100-200 МБ |
| JDK | JRE + компилятор, инструменты | Разработка, сборка, профилирование | Когда нужно компилировать/отлаживать | ~200-400 МБ |
Как быстро и просто всё настроить?
Вот тебе пошаговый гайд, чтобы не тратить время на грабли:
-
Определи, что тебе нужно:
- Только запускать готовые .jar — ставь JRE.
- Компилировать, профилировать, генерировать документацию — ставь JDK.
- Минимализм и контейнеры — можно собрать кастомный JRE с помощью
jlink(Java 9+).
-
Выбери дистрибутив:
- Adoptium (OpenJDK) — бесплатный, популярный.
- Oracle JDK — если нужна поддержка от Oracle.
- BellSoft Liberica, Azul Zulu — альтернативы с разными фишками.
-
Установи нужную версию:
- На Ubuntu/Debian:
sudo apt update
sudo apt install openjdk-17-jre
или для JDK:
sudo apt install openjdk-17-jdk
- На CentOS/RHEL:
sudo yum install java-17-openjdk
- Проверь версию:
java -version
- На Ubuntu/Debian:
-
Настрой переменные окружения (если нужно):
export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
export PATH=$JAVA_HOME/bin:$PATH
Примеры, схемы, практические советы
Рассмотрим пару кейсов из жизни:
-
Кейс 1: Хостинг Spring Boot приложения
Ты собралmyapp.jarна локальной машине. На сервере нужен только JRE. Установил JRE, скопировал .jar, запустил:
java -jar myapp.jar
Всё работает, сервер не захламлён лишними инструментами. -
Кейс 2: Jenkins или CI/CD на сервере
Jenkins часто сам компилирует проекты. Тут нужен JDK, иначе сборка упадёт с ошибкой “javac not found”. -
Кейс 3: Минималистичный Docker-контейнер
Не хочешь тянуть весь JDK? С помощьюjlink(Java 9+) можно собрать кастомный JRE только с нужными модулями:
jlink --module-path $JAVA_HOME/jmods --add-modules java.base,java.logging --output /opt/myjre
Итоговый размер — 40-60 МБ, меньше Alpine Linux! -
Кейс 4: Ошибка “Unsupported major.minor version”
Запускаешь .jar, а JVM ругается на несовместимость версий. Проверь, что версия JRE/JDK на сервере не ниже, чем версия, на которой собирался .jar.
Положительные и отрицательные примеры
| Сценарий | Что выбрали | Результат | Рекомендация |
|---|---|---|---|
| Запуск готового .jar | JRE | Быстро, экономно по памяти | Идеально для продакшена |
| CI/CD, сборка на сервере | JRE | Ошибка: “javac not found” | Ставь JDK! |
| Docker-контейнер | JDK | Контейнер весит 400 МБ | Собери кастомный JRE через jlink |
| Мониторинг и профилирование | JRE | Нет нужных инструментов | Используй JDK или докинь нужные утилиты |
Команды для быстрой работы
# Проверить установленную версию Java
java -version
# Проверить установленную версию компилятора
javac -version
# Установить OpenJDK 17 на Ubuntu/Debian
sudo apt update
sudo apt install openjdk-17-jdk
# Установить только JRE
sudo apt install openjdk-17-jre
# Установить OpenJDK 17 на CentOS/RHEL
sudo yum install java-17-openjdk
# Установить переменную JAVA_HOME
export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
export PATH=$JAVA_HOME/bin:$PATH
# Собрать кастомный JRE (Java 9+)
jlink --module-path $JAVA_HOME/jmods --add-modules java.base,java.logging --output /opt/myjre
Похожие решения, программы и утилиты
- GraalVM — альтернатива JVM, позволяет компилировать Java-приложения в нативные бинарники. graalvm.org
- SDKMAN! — менеджер версий JDK/JRE для Linux/Mac. Удобно переключаться между версиями. sdkman.io
- jenv — ещё один менеджер версий Java. jenv.be
- Jabba — кроссплатформенный менеджер JDK. github.com/shyiko/jabba
Статистика и сравнение с другими решениями
- JVM — самая популярная виртуальная машина для серверных приложений (по данным JetBrains 2023 — 70% серверных Java-проектов используют OpenJDK).
- JRE/JDK — доступны для всех популярных ОС, включая Linux, Windows, macOS, FreeBSD.
- GraalVM Native Image — позволяет уменьшить время старта приложения в 10-20 раз, но требует доработки кода и не всегда совместим с классическим JVM.
- Docker-образы с кастомным JRE (через jlink) — позволяют снизить размер контейнера до 40-60 МБ против 200-400 МБ у стандартного JDK.
Интересные факты и нестандартные способы использования
- JVM умеет запускать не только Java, но и другие языки: Kotlin, Scala, Groovy, Clojure, JRuby, Jython и даже JavaScript (Nashorn, GraalVM).
- С помощью
jlinkможно собрать минимальный JRE только с нужными модулями — удобно для микросервисов и embedded-решений. - JVM поддерживает hot-swap классов — можно обновлять код на лету без перезапуска приложения (например, через
jrebelилиspring-devtools). - JDK включает инструменты для анализа памяти (
jvisualvm,jconsole), профилирования (jprofiler,async-profiler), генерации документации (javadoc). - JRE/JDK можно запускать в chroot-окружении или контейнере для изоляции приложений.
Автоматизация и новые возможности
С появлением Java 9+ и модульной системы (JPMS) можно собирать минимальные среды исполнения для конкретного приложения. Это экономит ресурсы, ускоряет запуск, снижает поверхность атаки. В автоматизации деплоя (Ansible, Chef, Puppet) удобно использовать менеджеры версий (sdkman, jabba) для быстрой установки нужной версии JDK/JRE.
- Скрипты для автоматического обновления Java на сервере.
- CI/CD пайплайны, которые сами подтягивают нужную версию JDK.
- Контейнеризация с минимальным footprint (jlink + Docker).
Выводы и рекомендации
Если тебе нужен просто запуск Java-приложения на сервере — ставь JRE. Если планируешь компилировать, профилировать, генерировать документацию — ставь JDK. Для контейнеров и микросервисов — собирай кастомный JRE через jlink. Не забывай про менеджеры версий — они экономят время и нервы. Для автоматизации деплоя и CI/CD — используй скрипты и инструменты управления конфигурациями.
Не стоит тянуть на сервер всё подряд — минимализм рулит. Чем меньше лишнего ПО, тем проще поддержка и выше безопасность. Если нужен VPS для Java — заказать VPS, если нужен выделенный сервер — заказать выделенный сервер. Удачной настройки и пусть JVM всегда будет с тобой!
В этой статье собрана информация и материалы из различных интернет-источников. Мы признаем и ценим работу всех оригинальных авторов, издателей и веб-сайтов. Несмотря на то, что были приложены все усилия для надлежащего указания исходного материала, любая непреднамеренная оплошность или упущение не являются нарушением авторских прав. Все упомянутые товарные знаки, логотипы и изображения являются собственностью соответствующих владельцев. Если вы считаете, что какой-либо контент, использованный в этой статье, нарушает ваши авторские права, немедленно свяжитесь с нами для рассмотрения и принятия оперативных мер.
Данная статья предназначена исключительно для ознакомительных и образовательных целей и не ущемляет права правообладателей. Если какой-либо материал, защищенный авторским правом, был использован без должного упоминания или с нарушением законов об авторском праве, это непреднамеренно, и мы исправим это незамедлительно после уведомления. Обратите внимание, что переиздание, распространение или воспроизведение части или всего содержимого в любой форме запрещено без письменного разрешения автора и владельца веб-сайта. Для получения разрешений или дополнительных запросов, пожалуйста, свяжитесь с нами.
More stories
