От переводчика: несмотря на несколько рекламный характер этой статьи, автор приводит довольно-таки интересную статистику по текущему состоянию экосистемы Java. Надеемся, что эта статистика окажется полезной читателям

Версия этой статьи также ранее была опубликована в The New Stack.

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

Но это не значит, что нельзя попробовать примерно оценить состояние этой сферы.

Каждый день десятки миллионов виртуальных машин Java (JVM) передают свои данные в New Relic. Чтобы сделать этот отчет, мы анонимизировали и специально уменьшили детализацию этих данных, чтобы дать широкое представление об экосистеме Java, как мы ее видим. Мы также не включили в отчет очень подробную информацию, которая могла бы помочь хакерам и другим злоумышленникам в их атаках.

Мы надеемся, что эти наблюдения предоставят немного новой контекстной информации и дадут пищу для размышлений о состоянии Java экосистемы на сегодняшний день. С этой мыслью в голове, мы рассмотрели следующий вопросы:

• Какие версии Java используются в промышленной эксплуатации?
• Какие вендоры Java наиболее популярны?
• Какой алгоритм сборки мусора используется чаще всего?
• Какие настройки памяти самые распространенные?

Java 8 все ещё стандарт. Пока ещё стандарт

Давайте начнем с одного вопроса, который интересен всем Java разработчикам: “Какие версии Java больше всего используются в промышленной эксплуатации?”. Рассмотрим следующую таблицу:

Примечание. Мы разделили результаты по Java 8 на три части:

• Текущие: установлены последние обновления, не уязвимы ко всем важным CVE
• Отстающие: есть потенциальные серьезные риски, связанные с устареванием версии Java
• Уязвимые: с высокой вероятностью, источник серьезных проблем для команд, которые работают на этих версиях

Как видите, Java 11 — LTS релиз — медленно увеличивает свою популярность, но рынок, похоже, все ещё находится в сомнениях, особенно если сравнивать с Java 8 (тоже LTS). Мы также видим недостаточный уровень проникновения не-LTS версий — Java 7 все ещё показывает вдвое больший уровень использования (2.54%) в сравнении с релизами, сделанными после Java 8, вместе взятыми (1.14%)

Рост не-Oracle вендоров

Ещё одно важное изменение динамики, которое мы наблюдали последние несколько лет — увеличивающееся использование сторонних Java вендоров, не принадлежащих к Oracle.

Сейчас Oracle занимает около 75% рынка Java. Развиваемый сообществом AdoptOpenJDK — второй по популярности вендор. Данные исторических трендов (которые мы ещё не опубликовали, поскольку они основаны на значительно меньшей выборке, чем наш основной набор данных), показывают, что AdoptOpenJDK набирает популярность значительными темпами, месяц за месяцем.

Нужно особо отметить, что среди всех виртуальных машин в NewRelic с установленным AdoptOpenJDK, примерно одна треть (33,19%) — это Java 11. Этот показатель использования Java 11 среди пользователей AdoptOpenJDK значительно выше, чем среди всех пользователей.

Примечание. В интересах полной открытости: NewRelic — спонсор проекта AdoptOpenJDK и мы вкладываем время разработчиков в этот проект.

Как используются разные алгоритмы сборки мусора

Сборка мусора, из-за роли, которую она играет в управлении памятью — тема бесконечного интереса Java сообщества. По нашим данным, различные алгоритмы сборки мусора занимают следующие доли рынка:

В широком смысле, эта выборка отражает долю сборщиков мусора по умолчанию для разных версий Java. Однако, если мы отфильтруем данные по версии JVM, то всплывают интересные результаты:

• CMS популярнее, чем G1 на Java 8 (14.56% против 12.59%)
• CMS популярнее, чем Parallel на Java 11 (3.96% против 0.20%)
• CMS в 35 раз популярнее, чем ZGC на Java 11

Проверяем настройки памяти

Ни одна дискуссия о сборке мусора и управлении памятью в Java не имеет смысла без рассмотрения конфигураций размеров кучи — динамической памяти. Размеры кучи определяются парой значений — минимумом и максимумом (обычно их называют по имени параметра — Xms и Xmx). В следующей таблице перечислены первые 30 наиболее часто встречающихся конфигураций размеров кучи, основанные на наших данных, которые мы привели в мегабайтах, для простоты понимания.

Что удивительно, это показывает, что размер кучи для JVM остается относительно небольшим, что контрастирует с движением в сторону создания алгоритмов, которые требуют все больше и больше памяти.

В частности, куча, которая может расширяться за пределы 16GB (т.е. параметр Xmx >= 16GB) — это всего лишь 3.3% от всей выборки.

Постоянное появление так называемой “фиксированной кучи” — комбинации параметров Xms и Xmx, значения которых одинаковы — ещё один большой сюрприз. Наши данные показывают, что 33.48% всех JVM все ещё используют эту комбинацию.

В самых ранних версиях алгоритмов адаптивного изменения размеров кучи, возможно, можно было получить некоторое преимущество при работе в такой конфигурации, но для современных профилей нагрузки это почти всегда контр-продуктивно.

Если вы установите эту комбинацию, то JVM будет ограничена в том, как изменять и конфигурировать кучу, тем самым уменьшается отзывчивость при внезапном изменении в поведении трафика или частоте запросов.

Немного случайных, но интересных штук

В завершение, вот вам пять забавных цифр из нашей статистики, которые мы увидели:

1. 7.35% всех Java 8 JVM запущены с неподдерживаемыми параметрами (особенно часто — с MaxPermSize)
2. 6.78% всех JVM запущены с экспериментальными параметрами
3. У 8.07% JVM некоторые параметры встречаются больше одного раза в строке запуска
4. 2.54% JVM запущены с “противоречащими” параметрами, которые означают противоположные вещи, например, Parallel и G1 сборщики мусора одновременно
5. В 2.59% JVM максимальный размер кучи составляет 819MB. Это почти наверняка опечатка — должно быть 8192MB (т.е. 8GB). Тщательно проверяйте свои конфигурационные файлы — простое копирование может быть опасно.

Заключительные соображения

Наши данные, конечно, не идеальны. Основной перекос в том, что мы видели только то, что передается в NewRelic. Это ни в коем случае не точное представление Java рынка и мы понимаем, что, помимо выборки, есть ещё более неявные перекосы в наших данных.

Кроме того, мы понимаем, что локализованные тренды могут отличаться от того, что мы здесь презентовали. Например, Java команды в отдельных промышленных вертикалях (например, здравоохранение или финансовый сектор) обычно работают под серьезными регулированием, которое не позволяет им переходить от версии к версии вовремя.

Однако, мы в реальном времени видим данные с миллионов JVM каждый день, и этот постоянно меняющийся поток данных представляет собой некоторое приближение того, что рынок Java представляет собой в целом.

Мы представляем эти числа для Java сообщества с надеждой на позитивный вклад в замечательное обсуждение того, куда движется Java в целом. Это ни в коей мере не попытка сказать что “у нас есть все ответы” или принизить работу других. Это общий путь с общей идеей и разные методологии, как, например, недавний анализ, сделанный RedMonk’ом, можно использовать вместе для того, чтобы получить лучшее понимание общей картины для всех.

У каждого клиента NewRelic есть доступ — без дополнительной платы — к информации с таким же уровнем детализации для их промышленного окружения. Если вы клиент NewRelic (или хотите им быть) и хотите видеть эти подсказки, свяжитесь со своим контактным лицом в NewRelic, чтобы посмотреть, как можно выбрать эти данные или построить собственный экран мониторинга для их отслеживания.

Мы будем рады помочь вам наблюдать за вашими системами на ваших условиях, в то время как вы будете продолжать создавать все более совершенное программное обеспечение.