Comments 41
Вы уверены, что завязываться на Unsafe во времена JDK11 в проде и JDK17 захватывающей прод – хорошая идея?
Думаю, что использовать java для задачи где у вас есть строгие рамки по потреблению памяти , плохая идея ...
Если есть такая задача, лучше использовать golang или C++
Чем же лучше использовать Go? Управление памятью - не его сильная сторона, он в этом даже Java проигрывает.
Основная его сильная сторона это многопоточная модель . В целом он обеспечивает более низкое потребление памяти , но цена за это более примитивный инструмент если сравнивать с java
Если мне не изменяет склероз, то основная цена облака сейчас в дисках(SSD). Ядра и память на этом фоне просто теряются. Речь конечно не про public cloud типа амазон или гугл.
Ну получается, что важно, сколько приложение занимает места на этом "золотом SSD" ...И ещё немаловажный критерий это время запуска ..Golang это не панацея, но для ряда случаев он подходит лучше java...Именно за счёт многопоточной модели и легковесности
Не занимает. А пишет. Базы, логи и т.д. там терабайты(и деньги), а не в размере приложений.
Время запуска = graalVM в native mode. Или quarkus.io если хотите. Те же миллисекунды, что у приложений на сях. Виртуальная машина тут это 10 мб. Готовый микросервис с много чем под капотом 60 мб. Что вполне сопоставимо с гоуланг.
Под многопоточностью я так понимаю вы имели ввиду горутины(или как их там в гоу). Ну так в том же кваркус давно реактивное программирование и vertx под капотом. То на то.
Если не путаю, то скоро все это из коробки в jdk будет. В рамках loom по моему пилили
Если мы говорим про объемы корпораций где тысячи сервисов работают в проде...то экономия набегает существенная...Даже от такого казалось бы малозначимого факта как размер конкретного приложения)
В native mode в Java пока что достаточно много проблем...Особенно с зависимостями, если интересно на хабре было много статей где это описывалось)
Да, именно горутины)Project loom классный проект, но пока он не вошёл в состав jdk и непонятно когда войдёт и сколько займёт времени пока обновятся основные библиотеки)
Поймите правильно, я не говорю , что go лучше java или наоборот, я говорю о том что есть ряд задач где go может быть полезен и его использование оправдано)
Не спорю. Каждому молотку свои гвозди :)
Java рулит экосистемой. Golang - для простых высоконагруженных сервисов. Где эта экосистема не нужна.
>>В native mode в Java пока что достаточно много проблем...Особенно с зависимостями, если интересно на хабре было много статей где это описывалось)
А можно тут подробнее для общего развития? Да, понимаю, что экосистема ещё не доросла до натива, но для опять же простых и высоконагруженных сервисов - по большому счету много чего есть
Проблем там несколько , из основных это то что нельзя ничего подгружать динамически...Это частично решает Spring Native (он генерирует специальный файл с статическим указанием необходимых зависимостей), но с ним тоже не все гладко...иногда нужно его править вручную ... Ну и рефлексия (если зависимость ее использует, то придется ее выкинуть)...
Golang - для простых высоконагруженных сервисов.
да, java+golang это очень хорошая связка)
Проблемы спринг - это проблемы спринг. :) Они в свое время завязались на reflection. Теперь отгребают. Я так понимаю, ещё до стадии beta не добрались.
В graalvm просто надо регистрировать классы и методы доступные для reflection.
Кстати вот фишка в graal, которая на прямую позволяет дергать сишные библиотеки(тот же posix) мне отлично зашла. Осталось дождаться приведения API graal и project panama к единому виду, чтобы двойной код не рождать
Посмотрите на quarkus (а он уже около 15% экосистемы занимает по данным из дребрей redhat) там эта проблема изначально решена и много чего в него встроенно.
Некоторые вещи конечно заставляют сильно материться, но скорее либо по незнанию, либо с отсутствием глубокой документации. Ну и community соответственно.
Про Graal и quarkus посмотрю)Спасибо!)
Нет, до бета версии они дошли, но с этим инструментом всё ещё не очень удобно работать)
Вам могу посоветовать почитать про golang ...Мне как Java разработчику он зашёл) Работать с ним приятнее чем с python с его динамической типизацией)
>> Нет, до бета версии они дошли, но с этим инструментом всё ещё не очень удобно работать)
Как я написал выше - слишком глубокий reflection.
Кваркус на стадии билда все это собирает плагином. + Изначально интеграция с Граалем под капотом.
За golang спасибо, но не надо. В моей практике он присутствует либо когда надо писать под 32 bit mips/arm в качестве домашних поделок. Либо узкие микросервисы на работе.
Да и не программист я давно :)))
RedHat только бы свой фреймворк выгородить, они и 146% нарисуют только дай волю
У вас есть какие то данные? Или "я так чувствую", "мне так карты предсказали"?
Цитирую редхат:
Привет. Именно наших данных сходу не нашёл, но в интернетах можно найти всякие Java ecosystem reports, например https://www.jrebel.com/blog/2021-java-technology-report (тут у Quarkus "всего лишь" 6%), https://snyk.io/jvm-ecosystem-report-2021/ (тут 11%, хотя опрос был примерно в то же время). По данным Eclipse Quarkus так вообще использовался 16% разработчиков ещё в середине прошлого года (https://newsroom.eclipse.org/news/announcements/amid-growth-cloud-native-enterprise-java-adoption-eclipse-foundation-announces), но это срез специфичный для Eclipse экосистемы.
То есть Рэдхад ссылается на сторонние данные. Вы же занимаетесь, простите, балаболством.
если посмотреть на hh , то там всего 37 вакансий где вообще встречается слово "quarkus" ...Мягко говоря это крайне мало ...
Как сказал 3й человек нашей компании(а это больше 10000 человек на борту) если вы знаете майнфреймы, то мы вас сегодня же возьмём на работу :)
Речь не о том, что сейчас, а о динамике.
Тот же front end девелопер как ких то 10-15 лет назад назывался "верстальщик" который рисовал хтмл шаблоны. За совсем другие деньги.
AI/ML и big data ещё 25 лет назад мы учили в институте, только нахрен они были тогда не нужны. Ни за какие деньги.
Тут так же. Просто тэнды.
Мы уже начали уход с спрингбут на кваркус и гоуланг(размер компании выше). Рано или поздно в натив все в java подтянутся
Да, пожалуйста
В опросе JetBrains - 3%
https://www.jetbrains.com/lp/devecosystem-2021/java/#Java_what-web-frameworks-do-you-use-if-any
А у Java не многопоточная модель?
И нет, существенной разницы в потреблении памяти тоже нет, если измерять именно аллокации, а не весь footprint виртуальной машины, да ещё на синтетических тестах. Зато есть разница в издержках на управление ею - не в пользу Go. Рантайм Go использует сборщик мусора типа mark-sweep, такой был в Java с 2002-го года, но уже в 2017-м был объявлен устаревшим. К тому же, в Go сборщик не уплатняющий, что приводит к фрагментации кучи и росту издержек со временем работы программы.
Иногда хочется чуть-чуть улучшить уже существующее приложение, а не переписывать с нуля его на другом языке.
Тем более, что C++ это сложный язык, а инфраструктура разработки для него в диком мире не так хорошо развита как у Java.
Если оптимизация начинается под девизом "хотим чуть-чуть улучшить" это плохая оптимизация...По опыту в 99% случаев оптимизация это :
1)Изменение алгоритмов обработки данных
2)Изменение архитектуры сервиса/сервисов и их взаимодействия
3)Выпиливание лишних/избыточных бибилотеках
В целом, инструмент под задачу подбираем )
В целом, алгоритмически все может быть уже хорошо, архитектурно - тоже, но вот уменьшить потребление памяти, не переписывая код целиком было бы неплохо.
А иногда нет возможности переработать архитектуру системы, разнеся на разные машины разные части. Возможно, из-за latency, возможно - из-за отсутствия железа. А может потому что система должна запускаться на машине конечного пользователя и никак иначе. Вот и приходится ухищряться.
Насколько мне известно, для плюсов и Go тоже бывают необходимы особые ухищрения для повышения производительности или уменьшения расхода памяти.
Это обсуждение "сферического коня в вакууме". В целом любой язык высокого уровня имеет в своем арсенале инструменты и простор для различных оптимизаций и если вы применяете их, то все отлично ....но, если начинаете "забивать микроскопом гвозди" ....применяя "черную магию", это может сработать в краткосрочную перпективу ,но в долгосрочную в любом случае придется брать "молоток для гвоздей" )
А что такого. Unsafe прекрасно работает в Java 17. Да и если когда-то смогут выпилить - все равно сделают замену. Уж слишком много на него завязано.
Интересно было бы еще сравнить с fastutil.
Статья интересная , но вопрос...зачем ?
С одной стороны, приятно почитать код, но с другой стороны нет jmh в тестах производительности, что, конечно, всё портит ((.
Было бы ещё прикольно посмотреть, как эти тесты проходит код с Reflection и погонять на разных версиях джавы, вплоть то 17.
Пожалуй, стоит добавить, что есть библиотеки, в которых поддерживаются коллекции примитивных типов, например:
Trove (больше не поддерживается);
Eclipse collections;
FastUtil;
HPPC;
Koloboke;
Neo4j Primitive Collections;
Наверняка сейчас есть и какие-то ещё.
Правда, я помню случай, про который рассказывал Сергей Куксенко, когда сравнивал ConcurrentHashMap с Trove-мапой, и нашел случай, когда ConcurrentHashMap оказался быстрее, несмотря на то, что там лежали обьектные типы. Это было потому, что для определения того в какую корзину (bucket) положить элемент, в Trove использовался оператор % (остаток от деления), а в ConcurrentHashMap – наложение битовой маски, которое работает, когда длина массива – степень двойки. И в многопоточной среде это было важно, потому операция остаток от деления может исполняться одна на ядре, а наложений битовой маски может быть несколько в параллель. В интернете можно найти таблицы для разных процессоров, у каких операций какого параллелизма можно достичь.
Мне кажется или вы пытаетесь придумать ByteBuffer?
Забавно, но что мешало просто использовать массив? Или, если уж очень-очень хочется именно List, то cделать свой IntList implements List<Integer>, в потрохах у которого был бы тот же массив int, ну и так для каждого примитивного типа. (Кстати, я подобное готовое уже в какой-то популярной либе видел.)
JVM заранее инициализирует Boolean, Byte, некоторую часть значений Integer, чтобы свести затраты по памяти до 4 байт на переменную.
Long и Short тоже.
Для оптимизации
После появления скаляризации эта оптимизация оказалась палёной.
Java: делаем Valhalla сами