25 причин обновляться на более новую версию JDK (Часть 1)
Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
В цикле статей я хотел бы рассказать о 25 причинах перехода на самую актуальную версию JDK. Конечно, их больше 25 и с каждым новым релизом их становится все больше, поскольку люди могут относиться к этим причинам как угодно, но я попытался составить список наиболее важных изменений в JDK и Java как языке со дня выпуска JDK 9, которые являются вполне весомыми причинами для обновления.
Несмотря на то, что я говорю «причины для обновления до JDK XX», я настоятельно рекомендую вам перейти на последнюю версию, поскольку вы получите больше, чем предлагает эта статья!
Цикл статей будет состоять из нескольких разделов:
- Среда выполнения и производительность (runtime and performance);
- Структурирование кода и инструментарий (code structuring and tools);
- Разработка приложений(Application development).
Некоторые из упомянутых релизов (например, JDK 9) больше не поддерживаются, но когда вы преодолеете барьер между JDK 8 и JDK 9, проблем с обновлением до последней версии — JDK 15 практически не возникнет.
Вообще идея написать цикл таких вот статей возникла после многочисленных обсуждений «сложившихся заблуждений» относительного того, что происходит с Java и области применений, ибо некоторые заблуждения основаны на нежелании бизнеса (в худшем случае разработчика) переходить на более новые версии JDK. Поэтому я решил сформировать свой ТОП 25 причин почему стоит обновляться, а 25 их потому что в
Runtime and Performance
Причина обновления до JDK 9: Compact Strings
В рамках релиза JDK 9 была представлена новая функция, которая в большинстве случаев, сокращает объем памяти, занимаемой String, вдвое. Если все символы строки могут быть представлены с помощью LATIN-1, тогда будут использоваться только 8 бит, любой другой случай подразумевает UTF16 (16 бит для каждого символа). Причин почему стоит обновляться я думаю ни у кого не возникнет. Так как всегда в коде есть куча сущностей построенных на строках, то любая оптимизация по памяти тут только в плюс!
Для получения дополнительной информации, рекомендую почитать соответствующий JEP openjdk.java.net/jeps/254.
Причина обновления до JDK 11: JDK Flight Recorder
JDK Flight Recorder — это среда сбора данных с низкими накладными расходами для устранения неполадок в приложениях Java и JVM HotSpot. Целями разработки программного комплекса — предоставление API для потребления и создания данных в виде особого типа событий, функций конфигурации и фильтрации, а также в предоставлении событий для ОС, JVM HotSpot и библиотек JDK. Если коротко, то данный фреймворк был создан для генерации и трассировки событий приложения, которые можно отслеживать в реальном времени и/или пост-фактум используя программный комплекс JDK Mission Control.
Одной из наиболее важных целей было сокращение накладных расходов на 1% и 0% при отключенной записи «полета».
JDK Flight Recorder имеет следующие преимущества:
- Согласованная модель данных упрощает перекрестные ссылки и фильтрацию событий;
- Набор API позволяющий JDK Flight Recorder отслеживать сторонние приложения, также API для описания и генерации кастомных событий;
- Позволяет разработчикам тратить меньше времени на диагностику и устранение неполадок, сокращает эксплуатационные расходы и прерывания бизнеса, обеспечивает более быстрое разрешение при возникновении проблем и повышает эффективность системы.
Если совсем по-простому, то использую событийную систему JDK Flight Recorder, можно отслеживать жизненный цикл приложения по всем аспектам жизнедеятельности (память, GC паузы, треды и так далее). Уже на текущий момент многие компоненты стандартной библиотеки JDK уже реализовали поддержку событийной систему JDK Flight Recorder.
Для получения дополнительной информации, рекомендую почитать соответствующий JEP openjdk.java.net/jeps/328.
Причина обновления до JDK 13: динамическое совместное использование классов приложений (AppCDS)
Концепция CDS (class-data sharing) — это отображение памяти классов JDK, доступных только для чтения, среди других JVM, которые были ранее отображены в памяти во время предыдущего выполнения приложения. Основная идея состоит в том, чтобы снизить нагрузку на CPU при загрузке классов и позволить приложению запускаться быстрее (один из шагов решения проблемы, которая носит название «cold start», эта проблема существует в тех средах, где есть необходимость инициализировать саму среду выполнения до запуска самого приложений. Пример: docker — запуск самого контейнера, Python/NodeJS — запуск интерпретатора, Java — инициализация виртуальной машины).
Концепция AppCDS заключается в применении той же концепции CDS, но для классов приложения и их зависимостей.
Типичный алгоритм AppCDS состоит из трех шагов:
- Создайте список классов для дальнейшего обмена между экземплярами JVM;
- Собрать архив этих классов;
- Прикрепите архив к новому экземпляру JVM.
Идея динамического AppCDS состоит в том, чтобы позволить JVM составить список необходимых классов (для приложения), а затем создать динамический архив тех, которые можно использовать для любого другого экземпляра JVM с тем же приложение. Момент сборки архива классов — момент завершения приложения с кодом выхода «0», в противном случае общий архив не будет создан.
Данный функционал вполне себе актуален в современном мире много-экземплярных микросервисов в контейнерных средах типа Docker, K8s. Область применения может быть расширена до концепта serverless, где как раз проблема «холодного старта» весьма критична.
Для получения дополнительной информации прочтите:
Причина обновления до JDK 15: новый сборщик мусора с низкой задержкой — ZGC
ZGC, масштабируемый сборщик мусора с малыми паузами, вероятно, самая важная (production-) фича релиза JDK 15.
Ключевые моменты:
- Сумма пауз (stop-the-world) не более 10мс (по заявлениям, вскоре, паузы сократятся до 1мс);
- Может работать с heap различного размера до нескольких терабайт;
- Перемещение памяти происходит параллельно, чтобы избежать длительных пауз.
Спросите, для кого предназначен этот новый сборщик мусора? Да для всех, без исключений! Независимо от того, какие приложения вы разрабатываете, сетевые приложения, обработка данных с большими кучами (от 8 МБ до 16 ТБ!) И быстрое время отклика.
Для получения дополнительной информации прочтите:
А вот свежий выпуск подкаста Inside.Java с моими коллегами Пер Лиденом и Дэвидом Делабасси inside.java/2020/10/14/podcast-005 как раз на тему ZGC.
На этом я завершу первую часть цикла «причин». На самом деле, если почитать релиз-ноуты к каждой версии, то можно будет убедиться в том, что каждые 6 месяцев разработчики OpenJDK выкатывают очередную порцию новшеств и улучшений. Более того, сами релиз-ноуты показывают те изменения, имплементация которых требует оформления JEP. Но некоторые изменения, на уровне API, не требуют отдельного документа (спецификации). Так что быть Java-разработчиком в 2020 вполне себе интересно, ибо на наших глаза происходит революция инструментария и самого языка.
А вот мне интересно, а что вас сдерживает от обновления на самую актуальную версию JDK?
9 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів