Как мы ускорили расчёт факторов ранжирования в поиске Ozon с помощью динамической компиляции

Всем привет! Меня зовут Петя Портнов, я работаю в Ozon ведущим разработчиком в команде среднего поиска — слоя, который ранжирует поисковую выдачу. Представьте, что вы вводите запрос в поисковую строку маркетплейса. За этим простым действием скрывается сложный поисковый пайплайн: миллионы товаров фильтруются, ранжируются и сортируются по релевантности. Но как именно система решает, что показать первым? В основе этого решения лежат вычисления, среди которых — сотни разнообразных формул, учитывающих цену, рейтинг, популярность, персонализацию и другие факторы. По мере развития системы таких формул становится всё больше, а сами они усложняются. В какой-то момент вычисления превращаются в узкое место: начинают потреблять значительную долю CPU, создают множество промежуточных объектов — и так для каждого поискового запроса. Возникает вопрос: как снизить стоимость таких вычислений в JVM? В этой статье я расскажу, что сделали мы, чтобы снизить нагрузку на систему: как заменили интерпретирующий движок формул на динамический компилятор, выполняющий построение эффективного байт-кода, отлично векторизующегося JIT-компилятором. Это текстовая версия доклада с Joker 2025 с дополнениями, которые не вошли в выступление или появились в проекте уже после конференции.

https://habr.com/ru/companies/ozontech/articles/1041218/

#java #поиск #оптимизация_производительности #компиляция #байткод #jvm #ozon_tech

async‑profiler в production: CPU, аллокации, lock contention и чтение flame graph

Профилирование Java‑приложений в production часто упирается не в отсутствие инструментов, а в их ограничения: CPU горит в одном месте, latency копится в другом, аллокации давят на GC, а lock contention вообще не виден в обычном CPU‑профиле. В статье разбираем, как использовать async‑profiler для диагностики реальных Java‑сервисов: снимать CPU, allocation, wall‑clock и lock‑профили, читать flame graph и понимать, где именно приложение тратит ресурсы.

https://habr.com/ru/companies/otus/articles/1039968/

#asyncprofiler #Java #JVM #профилирование #flame_graph #производительность #аллокации #многопоточность #lock_contention #latency

"Endive is a JVM native WebAssembly runtime. It allows you to run WebAssembly programs with zero native dependencies or JNI. Endive can run Wasm anywhere that the JVM can go. It is designed with simplicity and safety in mind."

https://github.com/bytecodealliance/endive

#webassembly #wasm #java #jvm

We are currently on the last meters of finalizing a new Jython maintenance release (2.7.5 beta).
A breaking change is that we finally move from javax.servlet to jakarta.servlet.
If you use Jython, make sure your setup accommodates this change!

Email announcement for javax->jakarta migration: https://sourceforge.net/p/jython/mailman/message/59305034/
Follow changes and discussions (issues and PRs) on Github: https://github.com/jython/jython
Homepage: https://jython.org
API doc: https://apidia.net/java/Jython

#jython #java #python #jvm

[Перевод] Java — быстрая. Ваш код может таким не быть

Есть такие анти‑паттерны, которые выглядят нормально и даже проходят код‑ревью, но тихо убивают производительность в горячих местах: - Конкатенация строк в циклах - String.format() в горячем коде - Автобоксинг и так далее. И каждый подобный пролёт делает приложение чуть медленнее, и в какой-то момент это рискует превратиться в критическую массу, которая больно выстрелит на следующем спайке нагрузки. Если вы пишете на Java и у вас всё вроде работает, но под нагрузкой сервисы начинают задыхаться, в новом переводе от команды Spring АйО рассмотрим конкретные паттерны, на которые стоит посмотреть.

https://habr.com/ru/companies/spring_aio/articles/1039778/

#java #kotlin #jvm #jdk #performance

Most “exciting” releases break your code. #Java26 doesn’t. It compiles, runs, and improves performance—thanks to G1 GC and HTTP/3. Lutske de Leeuw & @parttimen3rd explain why boring wins.

See why boring tech is a competitive advantage: https://javapro.io/2026/04/17/java-26-is-boring/

#Java #JVM