Java

Как мы использовали Codex, чтобы запустить приложение Sora под Android за 28 дней четырьмя инженерами

2025-12-20T08:05:13.357Z

Это статья из официального блога OpenAI, но подход меня так зацепил, что решил перевести для всех. Я тоже часто переношу веб-приложения на мобилки примерно таким же способом и было очень здорово увидеть такой же подход (архитектура-как-пример) у по сути создателей сильного AI. Пишу про разные похожие интересные вещи тут

В ноябре мы представили миру приложение Sora для Android, предоставив любому пользователю с Android-устройством возможность превращать короткие текстовые промпты в живые видео. В день запуска приложение заняло 1-е место в Play Store. За первые 24 часа пользователи Android сгенерировали более миллиона видеороликов.

За этим запуском стоит история: первая версия продакшн-приложения Sora для Android была создана всего за 28 дней благодаря тому же агенту, который доступен любой команде или разработчику – Codex.

С 8 октября по 5 ноября 2025 года небольшая команда инженеров, работая бок о бок с Codex и израсходовав примерно 5 миллиардов токенов (вау), провела Sora для Android от прототипа до глобального запуска. Несмотря на скорость разработки и масштаб, приложение демонстрирует показатель стабильности (crash-free) 99,9% и архитектуру, которой мы гордимся. Если вам интересно, использовали ли мы какую-то секретную модель – нет, мы использовали раннюю версию модели GPT-5.1-Codex, ту самую, которую любой разработчик или компания могут использовать уже сегодня через CLI, расширение для IDE или веб-приложение.

Принимая закон Брукса: оставаться гибкими, чтобы двигаться быстро

Когда Sora вышла на iOS, использование взлетело моментально. Люди тут же начали генерировать потоки видео. На Android же у нас был только небольшой внутренний прототип и растущее число предрегистраций в Google Play.

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

Американский архитектор ПО Фред Брукс знаменит своим предостережением: «Добавление людей в запаздывающий проект лишь делает его еще более запаздывающим». Другими словами, когда вы пытаетесь быстро выпустить сложный проект, добавление новых инженеров часто снижает эффективность из-за накладных расходов на коммуникацию, фрагментацию задач и интеграцию. Мы решили не игнорировать этот инсайт, а опереться на него. Мы собрали сильную команду всего из четырех инженеров, каждый из которых был вооружен Codex для радикального увеличения личного импакта.

Работая в таком режиме, мы выпустили внутреннюю сборку Sora для Android для сотрудников всего за 18 дней, а публичный релиз состоялся спустя еще 10 дней. Мы сохранили высокую планку инженерных практик Android, вложились в поддерживаемость кода и придерживались того же уровня надежности, которого ожидали бы от более традиционного проекта. (Мы также продолжаем активно использовать Codex и сегодня для развития приложения и внедрения новых функций).

Онбординг нового сеньор-инженера

Чтобы понять, как мы работали с Codex, полезно знать, где он силен, а где ему нужно направление. Относиться к нему как к только что нанятому сеньор-инженеру — отличный подход. Способности Codex позволили нам тратить больше времени на руководство и ревью кода, чем на его написание.

Где Codex нужно руководство

Codex пока не умеет идеально догадываться о том, чего ему не сказали (например, о ваших предпочтительных архитектурных паттернах, продуктовой стратегии, реальном поведении пользователей и внутренних нормах или шорткатах). Точно так же Codex не мог видеть, как приложение работает в реальности: он не мог открыть Sora на устройстве, заметить, что скролл «подтормаживает», или почувствовать, что флоу (поток действий пользователя) запутан. Только наша команда могла закрыть эти экспертные задачи.

Каждый инстанс (экземпляр) требует онбординга. Передача контекста с четкими целями, ограничениями и гайдлайнами «как мы это делаем» была критически важна для того, чтобы Codex работал хорошо. В том же духе, Codex иногда испытывал трудности с глубокими архитектурными решениями: предоставленный сам себе, он мог ввести лишнюю вью-модель там, где мы хотели расширить существующую, или запихнуть в UI-слой логику, которой явно место в репозитории. Его инстинкт — заставить что-то работать, а не приоритезировать чистоту кода в долгосрочной перспективе.

Мы обнаружили, что крайне полезно поручать Codex создание и поддержку большого количества файлов AGENT.md по всей кодовой базе. Это позволило легко применять единые руководства и лучшие практики (best practices) в рамках разных сессий. Например, чтобы гарантировать, что Codex пишет код в соответствии с нашими стайл-гайдами, мы добавили следующие инструкции в наш корневой файл AGENTS.md:

## Formatting and static checks
- **Always run** `./gradlew detektFix` (or for the affected modules) **before committing**. CI will fail if formatting or detekt issues are present.

Где Codex превосходит ожидания

Быстрое чтение и понимание больших кодовых баз: Codex знает практически все основные языки программирования, что упрощает использование одних и тех же концепций на разных платформах без сложных абстракций.
Покрытие тестами: Codex (уникально) с энтузиазмом пишет юнит-тесты для покрытия широкого спектра кейсов. Не каждый тест был глубоким, но широта покрытия помогла предотвратить регрессии.
Реакция на фидбэк: В том же ключе, Codex хорош в реагировании на обратную связь. Когда падал CI, мы могли просто вставить вывод лога в промпт и попросить Codex предложить исправления.
Массовое параллельное одноразовое выполнение: Большинство не упрется в лимит количества сессий, которые можно запустить одновременно. Вполне реально тестировать несколько идей параллельно и относиться к коду как к расходному материалу.
Предложение новой перспективы: В дизайн-обсуждениях мы использовали Codex как генеративный инструмент для исследования потенциальных точек отказа и поиска новых способов решения проблем. Например, при проектировании оптимизации памяти видеоплеера Codex просеял множество SDK, чтобы предложить подходы, на разбор которых у нас не было бы времени. Инсайты из «исследования» Codex оказались бесценны для минимизации потребления памяти в финальном приложении.
Освобождение для работы высокого уровня: На практике мы тратили больше времени на ревью и управление кодом, чем на его написание. При этом Codex очень хорош и в код-ревью, часто отлавливая баги до того, как они попадут в мердж, что повышает надежность.

Как только мы приняли эти характеристики, наша рабочая модель стала понятнее. Мы полагались на Codex в выполнении огромного объема тяжелой работы внутри хорошо понятных паттернов и четко очерченных границ, в то время как наша команда фокусировалась на архитектуре, пользовательском опыте (UX), системных изменениях и финальном качестве.

Закладка фундамента вручную

Даже лучший новый сеньор не обладает правильной точкой обзора для принятия долгосрочных компромиссных решений сразу же. Чтобы использовать Codex и гарантировать, что его работа будет надежной и поддерживаемой, было ключевым моментом, что мы сами контролировали системный дизайн приложения и ключевые трейд-оффы. Сюда входили формирование архитектуры приложения, модуляризация, внедрение зависимостей (DI) и навигация; мы также сами реализовали аутентификацию и базовые сетевые флоу.

На этом фундаменте мы реализовали несколько репрезентативных функций от начала до конца (end-to-end). Мы использовали правила, которым должна была следовать вся кодовая база, и документировали общепроектные паттерны по ходу работы. Указывая Codex на эти эталонные функции, мы добились того, что он смог работать более автономно, оставаясь в рамках наших стандартов. Для проекта, который, по нашим оценкам, на 85% написан Codex, тщательно спланированный фундамент позволил избежать дорогостоящего переписывания и рефакторинга. Это было одно из самых важных решений, которые мы приняли.

Идея была не в том, чтобы как можно быстрее сделать «что-то рабочее», а в том, чтобы создать «что-то, что понимает, как именно мы хотим, чтобы оно работало». Существует много «правильных» способов написать код. Нам не нужно было говорить Codex, что именно делать; нам нужно было показать Codex, что считается «правильным» в нашей команде. Как только мы установили отправную точку и то, как мы любим строить, Codex был готов к старту.

Чтобы посмотреть, что получится, мы попробовали промпт: «Создай Android-приложение Sora на основе кода iOS. Вперед», но быстро свернули с этого пути. Хотя то, что создал Codex, технически работало, продуктовый опыт был посредственным. А без четкого понимания эндпоинтов, данных и пользовательских флоу, код, написанный «с одного промпта» (single-shot), был ненадежным (даже без использования агента рискованно мерджить тысячи строк кода).

Мы выдвинули гипотезу, что Codex расцветет в «песочнице» из хорошо написанных примеров; и мы оказались правы. Просить Codex «сделать экран настроек» почти без контекста – ненадежно. Просить Codex «сделать этот экран настроек, используя ту же архитектуру и паттерны, что и вот этот другой экран, который ты только что видел» – работало куда лучше. Люди принимали структурные решения и задавали инварианты; Codex затем заполнял большие объемы кода внутри этой структуры.

Планирование с Codex перед написанием кода

Нашим следующим шагом в максимизации потенциала Codex стало понимание того, как позволить Codex работать в течение длительных периодов времени (в последнее время — более 24 часов) без присмотра.

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

Поэтому мы изменили рабочий процесс. Для любого нетривиального изменения мы сначала просили Codex помочь нам понять, как работают система и код. Например, мы просили его прочитать набор связанных файлов и саммаризировать, как работает эта фича; скажем, как данные текут от API через слой репозитория, вью-модель и в UI. Затем мы корректировали или уточняли его понимание. (Например, мы указывали, что конкретная абстракция на самом деле принадлежит другому слою или что данный класс существует только для офлайн-режима и его не следует расширять).

Подобно тому, как вы взаимодействуете с новым, высококвалифицированным коллегой, мы работали с Codex над созданием надежного плана реализации. Этот план часто выглядел как миниатюрный дизайн-документ, указывающий, какие файлы должны измениться, какие новые состояния нужно ввести и как должна проходить логика. Только после этого мы просили Codex начать выполнять план, шаг за шагом. Один полезный совет: для очень длинных задач, где мы упирались в лимит контекстного окна, мы просили Codex сохранить свой план в файл, что позволяло нам применять одно и то же направление в разных инстансах.

Этот дополнительный цикл планирования стоил потраченного времени. Он позволил нам оставлять Codex работать «без присмотра» на долгие отрезки, потому что мы знали его планы. Это упростило код-ревью, так как мы могли сверять реализацию с нашим планом, а не читать дифф (diff) без контекста. И когда что-то шло не так, мы могли сначала отлаживать план, а потом код.

Динамика ощущалась схожей с тем, как хороший дизайн-документ дает техлиду уверенность в проекте. Мы не просто генерировали код: мы производили код, который поддерживал общий roadmap.

Распределенная инженерия

На пике проекта мы часто запускали несколько сессий Codex параллельно. Одна работала над воспроизведением видео, другая – над поиском, третья – над обработкой ошибок, а иногда еще одна – над тестами или рефакторингом. Это ощущалось не столько как использование инструмента, сколько как управление командой.

Каждая сессия периодически отчитывалась нам о прогрессе. Одна могла сказать: «Я закончил планирование этого модуля; вот что я предлагаю», в то время как другая предлагала большой дифф для новой фичи. Каждая требовала внимания, фидбэка и ревью. Это было до жути похоже на роль техлида с несколькими новыми инженерами: все двигаются вперед, всем нужно руководство.

Результатом стал коллаборативный поток (flow). Чистая способность Codex к кодингу освободила нас от большого количества ручного набора текста. У нас появилось больше времени на обдумывание архитектуры, внимательное чтение пулл-реквестов и тестирование приложения.

В то же время эта дополнительная скорость означала, что у нас всегда что-то висело в очереди на ревью. Codex не блокировался переключением контекста, а мы – да. Наше «бутылочное горлышко» в разработке сместилось с написания кода на принятие решений, дачу фидбэка и интеграцию изменений.

Именно здесь инсайты Брукса раскрываются по-новому. Вы не можете просто добавлять сессии Codex и ожидать линейного ускорения, точно так же, как не можете бесконечно добавлять инженеров в проект, ожидая линейного сокращения сроков. Каждая дополнительная «пара рук», даже виртуальных, добавляет накладные расходы на координацию. Мы стали дирижерами оркестра, а не просто более быстрыми солистами.

Codex как кроссплатформенная суперсила

Мы начали наш проект с огромного подспорья: Sora уже вышла на iOS. Мы часто указывали Codex на кодовые базы iOS и бэкенда, чтобы помочь ему понять ключевые требования и ограничения. На протяжении проекта мы шутили, что изобрели идею кроссплатформенного фреймворка заново. Забудьте про React Native или Flutter; будущее кроссплатформы – это просто Codex.

Под этой шуткой лежат два принципа:

Логика портативна. Написан ли код на Swift или на Kotlin, лежащая в основе логика приложения – модели данных, сетевые вызовы, правила валидации, бизнес-логика – одинакова. Codex очень хорош в чтении реализации на Swift и создании эквивалента на Kotlin с сохранением семантики.
Конкретные примеры дают мощный контекст. Свежая сессия Codex, которая может видеть «вот как именно это работает на iOS» и «вот архитектура Android», куда эффективнее, чем та, которая работает только по описаниям на естественном языке.

Заставив эти принципы работать, мы сделали репозитории iOS, бэкенда и Android доступными в одной среде. Мы давали Codex промпты вроде:

«Прочитай эти модели и эндпоинты в коде iOS, а затем предложи план реализации эквивалентного поведения на Android, используя наш существующий API-клиент и классы моделей».

Одним маленьким, но полезным трюком было детальное описание в ~/.codex/AGENTS.md, где находятся локальные репозитории и что они содержат. Это упростило Codex обнаружение и навигацию по релевантному коду.

Мы, по сути, занимались кроссплатформенной разработкой через перевод, а не через общую абстракцию. Поскольку Codex брал на себя большую часть перевода, мы избежали удвоения затрат на реализацию.

Более широкий урок заключается в том, что для Codex контекст – это всё. Codex выдавал лучшие результаты, когда понимал, как фича уже работает в iOS, в сочетании с пониманием того, как структурировано наше Android-приложение. Когда Codex не хватало этого контекста, он не «отказывался сотрудничать»; он гадал. Чем больше мы относились к нему как к новому коллеге и вкладывались в предоставление правильных входных данных, тем лучше он работал.

Программная инженерия завтрашнего дня, уже сегодня

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

Стало ясно, что AI-ассистированная разработка не снижает потребность в строгости; она ее повышает. Каким бы способным ни был Codex, его цель – добраться из точки А в точку Б, сейчас. Вот почему кодинг с ИИ не работает без людей. Инженеры ПО могут понимать и применять реальные системные ограничения, лучшие способы архитектуры софта и то, как строить с учетом будущих планов развития и продукта. Суперсилами инженера завтрашнего дня станут глубокое системное понимание и способность работать совместно с ИИ на длинных временных горизонтах.

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

Как только Codex настроен в богатой контекстом среде, где он понимает ваши цели и то, как вы любите строить, любая команда может мультиплицировать свои возможности. Наше ретро по запуску – не универсальный рецепт, и мы не утверждаем, что решили проблему AI-разработки. Но мы надеемся, что наш опыт поможет вам найти лучшие способы дать Codex возможность усилить вас.

Когда Codex запустился в превью для исследователей семь месяцев назад, программная инженерия выглядела совсем иначе. Благодаря Sora нам удалось исследовать следующую главу инженерии. По мере того как наши модели и обвязка продолжают улучшаться, ИИ будет становиться все более незаменимой частью создания продуктов.

Что вы создадите со своей собственной командой Codex?

Источник

Опыт отладки хитрой утечки прямой памяти

2024-09-19T07:47:11.681Z

Pinterest поддерживает формирование отчётов по метрикам рекламных объявлений внешних рекламодателей и расчёт рекламных бюджетов в реальном времени. Всё это основано на потоковых конвейерах обработки данных, созданных с помощью на Apache Flink. Доступность заданий (job) Flink для пользователей находится на уровне 99-го перцентиля. Но время от времени некоторые задачи (task) «валятся» под ударами неприятных ошибок, вызванных утечками прямой памяти (Out-Of-Memory, OOM), возникающими сразу в нескольких операторах. Выглядит это примерно так:

Стек-трейс, сформированный при возникновении OOM-ошибки

Как и в случае с большинством проблем, происходящих в распределённой системе, подобное часто ведёт к целому каскаду сбоев в самых разных местах. Одна такая ошибка оставляет после себя множество ложных следов. Flink‑платформа, используемая в Pinterest, поддерживает автоматический перезапуск задания в том случае, когда объём сбоев превысит настраиваемое пороговое значение. Но, из‑за того, что такое происходит нечасто, мы, для обеспечения отказоустойчивости системы, обычно позволяем произвести автоматический перезапуск с самой свежей контрольной точки. К концу прошлого года мы начали консолидацию кластеров и подкорректировали выделение памяти во всех заданиях ради повышения эффективности использования ресурсов. Неожиданным следствием этого шага стало то, что мы, в начале текущего года, стали получать целые страницы сообщений об утечках прямой памяти. Это повлекло за собой сбои и повлияло на службы, зависящие от нашей системы. Всё более очевидным становилось то, что с этой проблемой надо что‑то делать. В этом материале мы расскажем об используемом нами процессе поиска ошибок и поделимся идеями, которые могут пригодиться при отладке любой крупномасштабной распределённой системы. Такой системы, где одних лишь разумно размещённых инструкций print для борьбы с ошибками недостаточно.

Первая часть головоломки заключалась в том, чтобы отделить симптомы проблемы от её первопричины. В ходе инцидента мы обратили внимание на высокий уровень обратного давления (back pressure) у нескольких операторов, а так же — на сбои задачи, отражённые на вышеприведённом стрек‑трейсе. Сначала нам показалось, что возможной причиной проблемы могут быть и неполадки уровня контейнера. А именно, у контейнера могла закончиться память в ходе выделения прямой памяти для сетевых буферов, используемых для организации работы каналов ввода/вывода. Это привело к первому набору действий — к искусственному вызову отказов задач и к созданию высокого обратного давления на экземпляре задания, используемого в ходе разработки. При этом мы наблюдали за тем, как всё это воздействует на потребление прямой памяти. Делалось это для того, чтобы установить причинно‑следственную связь между этими двумя событиями.

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

Модель памяти Flink

Как видно на предыдущем рисунке — конфигурацию прямой памяти Flink можно разделить на три части. Это — память фреймворка вне кучи (framework off‑heap memory), память задания вне кучи (task off‑heap memory) и сетевая память (network memory). Память фреймворка вне кучи зарезервирована для внутренних операций Flink и для структур данных. Не зная точно о том, вызвана ли OOM утечкой памяти уровня приложения, мы увеличили и память задания вне кучи и сетевую память с 2 до 5 Гб. Мы сознательно сделали столь щедрый жест, надеясь на то, что «купим» себе таким образом достаточно времени для решения проблемы.

Искусственное создание обратного давления

Так как в нашем задании Flink имеется лишь один выходной Sink‑оператор — создание обратного давления сложностей не вызвала. А именно — для этого достаточно было добавить в главный поток длинную паузу, воспользовавшись конструкцией Thread.sleep(). Так как такой оператор на обрабатывает какие‑либо входные записи, входные буферы всех операторов, находящихся перед ним, быстро переполнятся, что создаст значительное обратное давление.

Эффект обратного давления на различных операторах приложения. Красные маркеры указывают на наличие обратного давления в заданный момент времени.

На рисунке показана ситуация с обратным давлением в различных операторах, возникшая после некоторого времени работы приложения. Это неизменно ведёт к нехватке прямой памяти на узлах, подверженных обратному давлению. А это, в свою очередь, вызывает отказы заданий.

Искусственный перезапуск заданий

В Pinterest Flink-приложения отправляют менеджеру ресурсов, входящему в состав YARN. Он распределяет задачи заданий по контейнерам, расположенным на машинах, которыми управляют сущности YARN NodeManager. Для того чтобы сымитировать перезапуск задач, мы останавливали случайным образом выбранные экземпляры контейнеров, используя команду yarn container -signal [container-id] GRACEFUL_SHUTDOWN, наблюдая при этом за тем, как приложение потребляет прямую память.

Паттерн потребления прямой памяти при сбоях задачи

График на предыдущем рисунке иллюстрирует воздействие искусственно вызванных сбоев на потребление прямой памяти. Он показывает заметное увеличение потребления памяти, возникающее в точности тогда, когда мы останавливаем контейнер. Это, в итоге, вело к OOM‑ошибкам, а когда останавливался кворум контейнеров одного и того же оператора, вызывало возникновение обратного давления на узлах, предшествовавших этому оператору. «Лестничный» паттерн на графике выглядит особенно интригующим, так как это — красноречивое свидетельство утечки памяти. Значит — где‑то в коде была выделена прямая память, которую не освободили должным образом.

Для того чтобы сузить сферу поиска, мы решили выяснить — является ли причиной происходящего ошибка платформы, или проблема, связанная с логикой приложения. Чтобы это сделать — мы повторили ручной перезапуск задачи на отдельном приложении, в котором не выполнялась логика нашего задания. Мы хотели понаблюдать за тем, появится ли при этом уже знакомый нам паттерн потребления прямой памяти. Это указало бы на то, что, возможно, во всём виновата ошибка уровня платформы.

Паттерн потребления прямой памяти при отказах задачи на отдельном задании

Как видно на предыдущем рисунке — в другом Flink‑приложении никаких заметных пиков в потреблении прямой памяти нам заметить не удалось. Это послужило убедительным доказательством того, что источник утечки памяти связан с ошибкой в коде нашего приложения.

Отладка кода приложения

Наше Flink‑приложение состоит из нескольких тысяч строк кода. При отладке столь масштабной кодовой базы полезно использовать подход, который можно сравнить с чисткой лука. А именно — речь идёт о том, что код разбивают на небольшие компоненты, исследуемые с целью воспроизведения проблемы. Очень упрощённая схема нашего приложения выглядит так.

Высокоуровневый обзор операторов нашего Flink-приложения

Первый слой (Layer 1 на рисунке) выполняет чтение из различных топиков Kafka, десериализует данные, формируя внутренние объекты, и передаёт их на второй слой (Layer 2), который объединяет выходные данные и производит некоторые трансформации. Этот слой, кроме того, выполняет кое‑какие RPC‑вызовы к внешнему KVStore, обращаясь к downstream‑службам, после чего передаёт данные третьему слою (Layer 3), который трансформирует данные и передаёт событие в Druid. Эти три слоя заключают в себе группу операторов, использующих прямую память. Вооружённые знаниями об архитектуре приложения, мы можем, в индивидуальном порядке, убирать некоторые из операторов и пытаться воспроизвести проблему, вручную перезапуская задачи. При таком подходе мы можем изолировать оператор, являющийся источником проблемы, и исправить код.

Убираем операторы 2 и 3 слоёв

На прерыдущем рисунке некоторые операторы из второго слоя выполняют RPC‑вызовы к внешнему KVStore с очень большими объёмами передаваемых данных. Мы подозревали, что именно эти большие объекты вызывали OOM‑ошибки в том случае, если объект DirectByteBuffer из Thrift не мог зарезервировать достаточно прямой памяти для выполнения сетевых операций ввода/вывода.

В слое 3 тоже используется память вне кучи. В ней хранятся курсы обмена валют для различных стран. Эти сведения загружаются из внешнего хранилища данных. Раньше эти вычисления выполнялись с использованием памяти кучи, на которую они создавали очень серьёзную нагрузку. Файл, хранящий обменные курсы, периодически загружался из хранилища, подвергался парсингу для извлечения из него полезной информации, трансформировался в хеш‑карту, которая потом заменяла старую (иммутабельную) хеш‑карту. Старая хеш‑карта затем перемещалась в область памяти, предназначенную для хранения сущностей старого поколения (Old Generation). Это значит, что соответствующая память не освобождалась до следующего вызова полной процедуры сборки мусора. Из‑за большого размера данных онлайн‑приложения, и из‑за того, что полная сборка мусора выполняется нечасто, мы перешли на решение, использующее память вне кучи, применив ChronicleMap. При этом проблема, связанная с освобождением этой памяти, вполне может, со временем, привести к OOM‑ошибке. В результате мы начали с того, что убрали эти блоки кода. Далее — мы перезапускали задачи, выбираемые произвольно и связанные с оставшимися операторами, наблюдая при этом за воздействием происходящего на потребление прямой памяти.

Паттерн потребления прямой памяти при отказах задач, связанных с оставшимися операторами

Как и ожидалось — мы не заметили каких‑либо аномалий в потреблении прямой памяти. Это позволило нам сузить область поиска причины утечки памяти до оставшихся операторов.

Убираем операторы слоя 3

Теперь мы удалили операторы слоя 3, использующие ChronicleMap для реализации логики приложения и повторили уже знакомый эксперимент по искусственному перезапуску задач.

Паттерн потребления прямой памяти при отказах задач на оставшихся операторах

Предыдущий рисунок иллюстрирует обнаруженное нами небольшое отклонение, но на нём не наблюдается «лестницы», которая позволила бы сделать вывод об утечке памяти в оставшихся операторах. Это показалось нам интересным, так как, в противовес исходному предположению, мы не смогли найти свидетельств утечки памяти в операторах, которые взаимодействуют с KVStore посредством RPC‑вызовов.

Убираем операторы слоя 2

Далее — изолируем операторы третьего слоя, убрав операторы слоя 2, которые тоже используют прямую память.

Паттерн потребления прямой памяти при отказах задач на оставшихся операторов

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

Исправление ошибки

После исследования проблемного оператора, мы обнаружили, что ссылка на ChronicleMap удалялась, но при этом связанная с ней память не освобождалась, что и приводило к утечке. Эта память не освобождалась до выполнения следующей полной процедуры сборки мусора, что особенно проблематично в онлайн‑службах наподобие нашей, при проектировании которых стремятся к тому, чтобы сборка мусора выполнялась бы не слишком часто.

Для того чтобы лучше с этим разобраться, разумнее всего будет поговорить о жизненном цикле задач Flink и о внутреннем механизме их перезапуска. Он используется при остановке задач из‑за сбоев. В такой ситуации JVM продолжает работу, а при выполнении Flink‑кода осуществляется переход на метод close() оператора, затронутого сбоем. После перезапуска Flink вызовет метод open(), определённый в коде оператора. Если логика ссылается на объект (вроде ChronicleMap), находящийся за пределами жизненного цикла оператора, код может непроизвольно вызвать утечку памяти.

Фрагмент кода, иллюстрирующий ручную очистку памяти

После исправления утечки мы снова организовали перезапуск задачи и понаблюдали за воздействием этого на потребление прямой памяти.

Паттерн потребления прямой памяти при сбоях задачи, наблюдаемый после исправления проблемы, связанной с утечкой памяти

Как видно на предыдущем рисунке, мы наблюдаем ровную линию, описывающую характер потребления памяти. Она сильно отличается от той «лестницы», которую мы видели в самом начале.

Итоги

Код, устраняющий утечку памяти, тесно связан с логикой нашего приложения. Но главным, универсальным результатом нашей работы стала сама процедура нахождения первопричины проблемы. На примере истории борьбы с нашим сбоем мы прошли через девять принципов отладки, которые описал Дэвид Дж. Аганс в книге «Отладка: девять незаменимых правил для обнаружения самых неуловимых ошибок в ПО и „железе“»:

Изучите свою систему.
Воспроизведите ошибку (надёжно воспроизведите).
Не предполагайте, а смотрите.
Разделяйте и властвуйте.
Вносите по одному изменению за раз.
Записывайте всё, что происходит.
Проверьте кабель.
Воспользуйтесь чьим‑то свежим взглядом.
Если вы не исправили ошибку — она не исчезла.

Источник

Memory Fences и volatile в Java: низкоуровневые гарантии порядка памяти

2024-09-17T06:34:10.978Z

Привет!

Сегодня мы рассмотрим интересную тему для тех, кто сталкивается с многопоточностью в Java – это управление порядком памяти. Базовых инструментов синхронизации, например как synchronized или блокировки, порой недостаточно. Именно здесь могут помочь низкоуровневые механизмы, такие как Memory Fences и ключевое слово volatile.

Эти инструменты позволяют контролировать порядок выполнения операций с памятью. В этой статье мы рассмотрим, как volatile влияет на поведение программы, что такое Memory Fences, и как они могут помочь в сложных ситуациях с потоками.

volatile

Ключевое слово volatile используется при объявлении переменных и сообщает JVM, что значение этой переменной может быть изменено разными потоками. Синтаксис прост:

public class VolatileExample {
    private volatile int counter;
    // остальные методы
}

Размещение volatile перед типом переменной гарантирует, что все потоки будут видеть актуальное значение counter.

Примитивные типы

Для примитивных типов использование volatile дает:

Видимость изменений: Если один поток изменяет значение volatile переменной, другие потоки сразу увидят это изменение.
Запрет переупорядочивания: Компилятор и процессор не будут переупорядочивать операции чтения и записи с volatile переменными.

Пример:

public class FlagExample {
    private volatile boolean isActive;

    public void activate() {
        isActive = true;
    }

    public void process() {
        while (!isActive) {
            // Ждем активации
        }
        // Продолжаем обработку
    }
}

Объекты

При использовании с объектами volatile обеспечивает видимость изменения ссылки на объект, но не его внутреннего состояния.

Пример:

public class ConfigUpdater {
    private volatile Config config;

    public void updateConfig() {
        config = new Config(); // Новая ссылка будет видна всем потокам
    }

    public void useConfig() {
        Config localConfig = config;
        // Используем localConfig
    }
}

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

Как volatile влияет на чтение и запись переменных

Ключевое слово volatile влияет на взаимодействие потоков с переменной следующим образом:

Чтение: Каждый раз при обращении к volatile переменной поток читает ее актуальное значение из основной памяти, а не из кеша процессора.
Запись: При изменении volatile переменной ее новое значение сразу записывается в основную память, делая его доступным для других потоков.

Пример без volatile:

public class Counter {
    private int count = 0;

    public void increment() {
        count++;
    }

    public int getCount() {
        return count;
    }
}

В многопоточной среде разные потоки могут работать с устаревшим значением count, так как оно может быть закешировано.

Пример с volatile:

public class VolatileCounter {
    private volatile int count = 0;

    public void increment() {
        count++;
    }

    public int getCount() {
        return count;
    }
}

Теперь каждый поток будет работать с актуальным значением count.

Однако будьте осторожны: операция count++ не является атомарной, даже с volatile. Для атомарности используйте AtomicInteger.

Ограничения volatile

Отсутствие атомарности сложных операцийvolatile не делает операции атомарными. Операции инкремента count++, декремента и другие сложные операции могут приводить к состояниям гонки.Пример проблемы:

public class NonAtomicVolatile {
    private volatile int count = 0;

    public void increment() {
        count++;
    }
}

Здесь count++ состоит из чтения, увеличения и записи, которые могут быть прерваны другими потоками.

2. Не обеспечивает синхронизацию доступаvolatile не заменяет блоки synchronized или объекты Lock. Он не предотвращает одновременный доступ нескольких потоков к блоку кода.

Примеры использования

Флаги остановки потоков

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

public class Worker implements Runnable {
    private volatile boolean isRunning = true;

    @Override
    public void run() {
        while (isRunning) {
            // Выполняем задачи
            performTask();
        }
    }

    public void stop() {
        isRunning = false;
    }

    private void performTask() {
        // Реализация задачи
    }
}

Почему volatile: Переменная isRunning используется для контроля цикла выполнения потока. Без volatile поток может не увидеть изменения переменной, сделанные другим потоком, из-за кеширования переменных на уровне процессора.

Метод stop() может быть вызван из другого потока, устанавливая isRunning в false. Благодаря volatile текущий поток немедленно увидит это изменение и корректно завершит работу.

Двойная проверка инициализации Singleton

Допустим, нужно создать ленивую =инициализацию Singleton без потерь производительности из-за избыточной синхронизации:

public class Singleton {
    private static volatile Singleton instance;

    private Singleton() {
        // Инициализация ресурсов
    }

    public static Singleton getInstance() {
        if (instance == null) { // Первая проверка (без синхронизации)
            synchronized (Singleton.class) {
                if (instance == null) { // Вторая проверка (с синхронизацией)
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

Без volatile возможно переупорядочивание инструкций, при котором другой поток может увидеть частично сконструированный объект instance.

volatile гарантирует, что запись в instance происходит только после полной инициализации объекта, и все последующие чтения увидят актуальное состояние.

Кэширование конфигурации с мгновенным обновлением

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

public class ConfigurationManager {
    private volatile Config currentConfig;

    public ConfigurationManager() {
        // Инициализируем конфигурацию по умолчанию
        currentConfig = loadDefaultConfig();
    }

    public Config getConfig() {
        return currentConfig;
    }

    public void updateConfig(Config newConfig) {
        currentConfig = newConfig;
    }

    private Config loadDefaultConfig() {
        // Загрузка конфигурации по умолчанию
        return new Config(...);
    }
}

public class Worker implements Runnable {
    private ConfigurationManager configManager;

    public Worker(ConfigurationManager configManager) {
        this.configManager = configManager;
    }

    @Override
    public void run() {
        while (true) {
            Config config = configManager.getConfig();
            // Используем актуальную конфигурацию
            process(config);
        }
    }

    private void process(Config config) {
        // Обработка с использованием текущей конфигурации
    }
}

Переменная currentConfig может быть обновлена одним потоком (например, при изменении настроек администратором) и должна быть немедленно видна другим потокам, выполняющим задачи.

При обновлении конфигурации методом updateConfig новое значение currentConfig становится сразу доступным для всех рабочих потоков благодаря volatile.

Использование для одноразовых событий

Частенько volatile используется для сигнализации о наступлении определенного события, после которого необходимо изменить поведение приложения:

public class EventNotifier {
    private volatile boolean eventOccurred = false;

    public void waitForEvent() {
        while (!eventOccurred) {
            // Ожидание события
        }
        // Реакция на событие
    }

    public void triggerEvent() {
        eventOccurred = true;
    }
}

Используйте volatile для простых флагов состояния и публикации неизменяемых объектов. Избегайте сложных операций с volatile переменными без дополнительной синхронизации.

Переходим к следующей теме статьи – Memory Fences

Memory Fences

Memory Fence — это механизм, который предотвращает переупорядочивание операций чтения и записи памяти компилятором или процессором. Это означает, что операции, связанные с памятью, будут выполняться в ожидаемом порядке.

Типы Memory Fences:

LoadLoad Barrier: Гарантирует, что все операции чтения до барьера будут завершены до начала любых операций чтения после барьера.
StoreStore Barrier: Гарантирует, что все операции записи до барьера будут завершены до начала любых операций записи после барьера.
LoadStore Barrier: Гарантирует, что все операции чтения до барьера будут завершены до начала любых операций записи после барьера.
StoreLoad Barrier: Гарантирует, что все операции записи до барьера будут завершены до начала любых операций чтения после барьера. Это самый "сильный" барьер.

Java имеет несколько средств для управления барьерами памяти:

Ключевое слово volatile
Классы из пакета java.util.concurrent.atomic
Класс Unsafe (с осторожностью)
VarHandle

Рассмотрим их подробнее.

Классы из пакета java.util.concurrent.atomic

Пакет java.util.concurrent.atomic содержит классы, предоставляющие атомарные операции над переменными разных типов:

AtomicInteger
AtomicLong
AtomicReference
AtomicBoolean
И другие

Эти классы используют низкоуровневые примитивы синхронизации.

Пример использования AtomicInteger:

import java.util.concurrent.atomic.AtomicInteger;

public class AtomicCounter {
    private AtomicInteger counter = new AtomicInteger(0);

    public void increment() {
        counter.incrementAndGet(); // Атомарное увеличение значения на 1
    }

    public int getValue() {
        return counter.get(); // Атомарное получение текущего значения
    }
}

Методы Unsafe

Класс sun.misc.Unsafe предоставляет низкоуровневые операции над памятью, включая методы для установки барьеров памяти.

Класс Unsafe является внутренним API и не предназначен для общего использования. Его использование может привести к непереносимому коду и потенциальным ошибкам.

В Java 9 и выше доступ к Unsafe ограничен модульной системой.

Однако для образовательных целей рассмотрим пример:

import sun.misc.Unsafe;
import java.lang.reflect.Field;

public class UnsafeMemoryFenceExample {
    private static final Unsafe unsafe;

    static {
        try {
            Field field = Unsafe.class.getDeclaredField("theUnsafe");
            field.setAccessible(true);
            unsafe = (Unsafe) field.get(null);
        } catch (Exception e) {
            throw new RuntimeException("Не удалось получить доступ к Unsafe", e);
        }
    }

    public void storeLoadFence() {
        unsafe.storeFence(); // Применение StoreStore Barriers
        // Ваш код
        unsafe.loadFence(); // Применение LoadLoad Barriers
    }
}

Используйте Unsafe только если полностью понимаете риски и альтернатив нет.

Рекомендуется использовать VarHandle или высокоуровневые классы из java.util.concurrent.

Примеры использования Memory Fences для синхронизации потоков

Реализация неблокирующего счетчика с AtomicLong:

import java.util.concurrent.atomic.AtomicLong;

public class NonBlockingCounter {
    private AtomicLong counter = new AtomicLong(0);

    public void increment() {
        counter.getAndIncrement(); // Атомарное увеличение значения
    }

    public long getValue() {
        return counter.get();
    }
}

AtomicReference для реализации неблокирующего стека:

import java.util.concurrent.atomic.AtomicReference;

public class LockFreeStack<T> {
    private AtomicReference<Node<T>> head = new AtomicReference<>(null);

    private static class Node<T> {
        final T value;
        final Node<T> next;

        Node(T value, Node<T> next) {
            this.value = value;
            this.next = next;
        }
    }

    public void push(T value) {
        Node<T> newHead;
        Node<T> oldHead;

        do {
            oldHead = head.get();
            newHead = new Node<>(value, oldHead);
        } while (!head.compareAndSet(oldHead, newHead));
    }

    public T pop() {
        Node<T> oldHead;
        Node<T> newHead;

        do {
            oldHead = head.get();
            if (oldHead == null) {
                return null; // Стек пуст
            }
            newHead = oldHead.next;
        } while (!head.compareAndSet(oldHead, newHead));

        return oldHead.value;
    }
}

VarHandle — современный подход к Memory Fences

Начиная с Java 9, был введен VarHandle как более мощная альтернатива Atomic классам и Unsafe.

Фичи VarHandle:

Позволяет выполнять операции с разными уровнями гарантий памяти.
Более гибкий и безопасный по сравнению с Unsafe.

Пример использования VarHandle:

import java.lang.invoke.MethodHandles;
import java.lang.invoke.VarHandle;

public class VarHandleExample {
    private int value = 0;
    private static final VarHandle VALUE_HANDLE;

    static {
        try {
            VALUE_HANDLE = MethodHandles.lookup().findVarHandle(VarHandleExample.class, "value", int.class);
        } catch (Exception e) {
            throw new Error(e);
        }
    }

    public void setValue(int newValue) {
        VALUE_HANDLE.setRelease(this, newValue); // Обеспечивает StoreStore Barrier
    }

    public int getValue() {
        return (int) VALUE_HANDLE.getAcquire(this); // Обеспечивает LoadLoad Barrier
    }
}

Реализация простого счетчика с VarHandle:

import java.lang.invoke.MethodHandles;
import java.lang.invoke.VarHandle;

public class VarHandleCounter {
    private int count = 0;
    private static final VarHandle COUNT_HANDLE;

    static {
        try {
            COUNT_HANDLE = MethodHandles.lookup().findVarHandle(VarHandleCounter.class, "count", int.class);
        } catch (Exception e) {
            throw new Error(e);
        }
    }

    public void increment() {
        int prevValue;
        do {
            prevValue = (int) COUNT_HANDLE.getVolatile(this);
        } while (!COUNT_HANDLE.compareAndSet(this, prevValue, prevValue + 1));
    }

    public int getCount() {
        return (int) COUNT_HANDLE.getVolatile(this);
    }
}

Заключение

Правильное применение volatile и Memory Fences позволяет создавать эффективные и надежные многопоточные приложения.

Источник

Новое событие в JFR для диагностики использования устаревшего (deprecated) кода

2024-08-20T06:57:06.802Z

В Java есть специальная аннотация @Deprecated для маркировки уставшего кода. С определенной периодичностью такой код из JDK удаляется. Обычно о конкретных сроках удаления анонс делается заранее и в теории можно успеть подготовиться, но на практике не все так просто.

В больших проектах найти куски устаревшего кода в куче зависимостей задача не тривиальная и требующая хорошей автоматизации. В этой ситуации к нам приходит на помощь новый тип события в JFR. Он был добавлен в JDK 22.

Давайте посмотрим на простом примере как это работает.

Для начала создадим простой класс и в его методе main вызовим любой @Deprecated метод. Для примера я выбрал конструктор класса java.net.URL(String). Со списком всех методов помеченных аннотацией @Deprecated вы можете ознакомиться по этой ссылке

public class App
{
    public static void main(String[] args) throws MalformedURLException {

        URL url = new URL("https://habr.com/ru/");
    }
}

Если вы попробуете скомпилировать его при помощи javac, то получите собщение c предупреждением о том, что у вас в коде используется устаревший код.

~/IdeaProjects/Tests/src/main/java (master*) » javac App.java                                                                                                         user@user-home
Note: App.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

Если добавить в параметры запуска еще и -Xlint:deprecation вывод станет чуть более информативен.

~/IdeaProjects/Tests/src/main/java (master*) » javac -Xlint:deprecation App.java                                                                                      user@user-home
App.java:8: warning: [deprecation] URL(String) in URL has been deprecated
        URL url = new URL("https://habr.com/ru/");
                  ^
1 warning

Но таким "дедовским" способом реальные проекты никто не собирает. Обычно используются инструменты автоматизирующие сборку. На данный момент довольно широко используются Maven и Gradle.

Если сделать простой Maven проект с таким pom.xml, то к удивлению мы не получим warning при компиляции того файла.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.github.rodindenis</groupId>
    <artifactId>Tests</artifactId>
    <version>1.0-SNAPSHOT</version>

    <properties>
        <maven.compiler.source>22</maven.compiler.source>
        <maven.compiler.target>22</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

</project>

Для получегия таких warning нужно будет еще добавить параметр конфигурации showDeprecation для maven-compiler-plugin.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.github.rodindenis</groupId>
    <artifactId>Tests</artifactId>
    <version>1.0-SNAPSHOT</version>

    <properties>
        <maven.compiler.source>22</maven.compiler.source>
        <maven.compiler.target>22</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.13.0</version>
                <configuration>
                    <showDeprecation>true</showDeprecation>
                </configuration>
            </plugin>
        </plugins>
    </build>

</project>

Что будет если этот кусок кода уедет в библиотеку и мы с вами будем ее получать как уже скомпилированную зависимость? Ответ под спойлером.

Так как компилятор проверяет в момент компиляции, то соответственно warning в момент компиляции нашего кода мы не получим.

Давайте проверим? Я вынес вызов устаревшего кода в отдельный сабмодуль.

package com.github.rodindenis.jfr.event.lib;

import java.net.MalformedURLException;
import java.net.URL;

public class Printer {

    public static void print(String url) throws MalformedURLException {
        System.out.println(new URL(url).toString());
    }
}>
    </build>

</project>

Наш класс App тоже изменился

package com.github.rodindenis.jfr.event.main;

import com.github.rodindenis.jfr.event.lib.Printer;
import java.net.MalformedURLException;

public class App
{
    public static void main(String[] args) throws MalformedURLException {

        Printer.print("https://habr.com/ru/");
    }
}

Примеры pom.xml здесь не привожу. Их можно будет посмотреть в репозитории.

Как и ожидалось после компиляции класса Printer мы получаем warning, но вот когда мы уже подключаем уже скомпилированную библиотеку с этим классом как зависимость и пробуем скомпилировать App, то warning мы уже не ловим.

Для воспроизведения ситуации в скаченном из репозитория кода проведите следующие манипуляции. Сначала скомпилируйте и установитие все артефакты. На этом этапе вы увидите в логе warning при компиляции библиотеки.

mvn clean install

Так как у нас теперь локально установлена скомпилированная библиотека с кодом класса Printer, то мы можем попробовать отдельно перекомпилировать только основной код App. Эту команду выполняем только для сабмодуля main с классом App.

mvn clean package

И вот пришло время ощутить всю силу JFR.

Запускаем наше приложение с включенным JFR логированием в файл. Я перешел в каталог main/target своего проекта и из него выполнил команду

~/.jdks/temurin-22.0.2/bin/java -XX:StartFlightRecording:jdk.DeprecatedInvocation#level=all,filename=recording.jfr -cp ../../lib/target/lib-1.0-SNAPSHOT.jar:./main-1.0-SNAPSHOT.jar com.github.rodindenis.jfr.event.main.App

В текущем каталоге появился файл recording.jfr. Давайте посмотрим есть ли в нем нужное нам событие.

~/.jdks/temurin-22.0.2/bin/jfr print --events jdk.DeprecatedInvocation recording.jfr

В моем кейсе было напечатано

jdk.DeprecatedInvocation {
  startTime = 16:39:18.769 (2024-08-19)
  method = java.net.URL.<init>(String)
  invocationTime = 16:39:18.759 (2024-08-19)
  forRemoval = false
  stackTrace = [
    com.github.rodindenis.jfr.event.lib.Printer.print(String) line: 9
    ...
  ]
}

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

Источник

JPA Entity. Загрузи меня не полностью

2024-08-16T10:24:42.090Z

JPA часто подвергается критике за невозможность загружать сущности частично, что на самом деле является большим заблуждением. Spring Data JPA и Hibernate включают в себя множество инструментов по частичной загрузке сущностей.

Подготовили статью, в которой рассмотрели имеющиеся в Spring Data JPA инструменты для частичной загрузки сущностей, а также разобрали их особенности и corner-кейсы. Давайте попробуем рассмотреть все способы такой частичной загрузки сущностей на примере основных способов взаимодействия с Hibernate в Spring приложениях:

Spring Data JPA
EntityManager
Criteria API

Также существует проект Jakarta Data, который активно развивается. Однако на момент написания этой статьи вышла только первая стабильная версия 1.0.0. Рассматривать его не станем, пока не накопим достаточное количество реальных использований.

Интересует ли эта проблема сообщество

После очередного холивара в одном из Telegram-каналов про Java на тему того, как плох JPA и Hibernate в частности, как он неоптимизированно выполняет запросы и как много грузится лишних данных, я решил немного углубиться в эти вопросы и попытаться встать на защиту упомянутого выше стэка, отправившись в путешествие на Stackoverflow. Сделаем поиск по тегу [spring-data-jpa] и отсортируем вопросы по популярности. Мы увидим, что вопрос Spring JPA selecting specific columns находится на шестом месте.
В этой статье мы постараемся ответить на этот вопрос максимально широко: рассмотрим не только самые простые случаи с базовыми атрибутами, но также окунемся и в мир JPA-ассоциаций.

Задача

В проекте будет рассматриваться следующая модель данных:

Нашей задачей является загрузка нескольких базовый полей + ToOne (в нашем случае это атрибут author, ссылающийся на сущность Post) ассоциации для каждого способа частичной загрузки. Предположим, мы хотим получить все статьи, заголовок которых содержит некоторый текст, причем поиск не чувствителен к регистру, т.е. contains with ignore case. Итого выгружаем Post: id, slug, title; User(author): id, username.

Проверять результат мы будем в соответствующих тестах, итоговые запросы будут видны в консоли: лог, в котором отобразится SQL-запрос, сгенерированный силами Hibernate.

Тестовые данные

Создадим две записи Post, проинициализировав базовые поля и привязав авторов. Сервис в котором создаются и удаляются данные InitTestDataService.

toOne

Всего был найден 21 способ частичной загрузки для поставленной нами задачи.

Эти способы включают в себя разные подходы написания запроса:

Spring Data Repository derived-methods
Spring Data Repository query-methods
Entity Manager
Criteria API

Тестовый класс в котором можно увидеть все тесты с комментариями - ToOneTest.

Предисловие

Стоит внести небольшую ясность перед нашим экспериментом. Derived методы — это методы, автоматически реализуемые фреймворком на основе их имен, т.е. без явного указания аннотации @Query. Поскольку мы не указываем запрос явно, а значит у нас отсутствует возможность указать, какие именно атрибуты нам требуется загрузить, у нас есть всего один способ указания конкретных атрибутов для загрузки - это projection.

Сами же проекции бывают двух видов: основанные на интерфейсах (Interface-based Projections) и на классах (Class-based Projections). Interface-based Projections в свою очередь можно поделить на открытые и закрытые.

В закрытых проекциях геттеры объявляются явно:

interface NamesOnly {
  String getFirstname();
  String getLastname();
}

В случае открытых проекций значение геттеров интерфейсов могут высчитываться на основе SpEL выражения:

interface NamesOnly {  
    @Value("#{target.firstname + ' ' + target.lastname}")
    String getFullName();
}

Их мы рассматривать не будем, т.к. в документации явно сказано, что для них оптимизация запроса производиться не будет:

Spring Data cannot apply query execution optimizations in this case, because the SpEL expression could use any attribute of the aggregate root.

Для загрузки ToOne-ассоциаций ставим задачу проверить два варианта с flatten (плоскими) атрибутами, с nested (вложенным) классом, а также с Tuple и Map.

Для ToMany имеет смысл проверять работу с плоскими атрибутами, однако в этом случае загрузка будет со сложностью n*m. Это означает, что наш эксперимент подходит и для ToOne, и для ToMany, однако записей в случае с ToManyвыгрузится больше.

Почти все, что мы рассмотрим для ToOne, справедливо и для ToMany, однако Hibernate не способен мапить коллекционные атрибуты на DTO/Projection, в связи с чем Hibernate в силах выполнить только HQL, и для кейса с ToMany будет возвращено декартово произведение n*m. Иначе говоря, кроме выгрузки и мапинга результата нам придется еще схлопывать дубликаты записей. Если эта тема будет интересна, мы обязательно напишем дополнительный пост про частичную загрузку и с ToMany-ассоциациями. Однако с несколькими примерами можно ознакомиться в проекте в тестовом классе ToManyTest.

Все, что будет рассмотрено далее, отлично подойдет и для Embbeded-кейса, поэтому отдельно его рассматривать не имеет смысла

Derived-methods

Interface-based flat projection

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

Объявим в нашем репозитории метод:

public interface PostRepository extends JpaRepository<Post, Long> {  
	<T> List<T> findAllByTitleContainsIgnoreCase(String title, Class<T> projection);
}

Исключительно в целях удобства метод будет заточен под динамическую проекцию, чтобы не писать под каждую проекцию отдельный метод.
Создадим класс проекции:

 public interface PostWithAuthorFlat {  
    Long getId();  
    String getSlug();  
    String getTitle();  
    Long getAuthorId();  
    String getAuthorUsername();  
}

Протестируем решение, написав тест. Попробуем немного углубиться в работу проекции, воспользовавшись дебагом. Ставим breakpoint на нашем тесте:

Завершающим звеном по получению данных является работа класса TupleBackedMap, сам объект Tuple же будет содержать необходимую нам информацию. Чтобы посмотреть цепочку по получению данных, обозначим границу установкой breakpoint в методе получения значения из TupleBackedMap (org.springframework.data.jpa.repository.query.AbstractJpaQuery.TupleConverter.TupleBackedMap):

И наблюдаем следующую цепочку по получению данных:

Полученный прокси сначала дойдет до метода invoke класса MapAccessingMethodInterceptor:

В результате чего мы получаем объект класса Accessor, который предоставляет доступ к самому propertyName. Преобразованная строка будет передана в TupleBackedMap. Далее полученное значение будет нам представлено из всеми нам знакомого объекта Tuple:

Сам же объект Tuple в свою очередь предоставляет нам полный доступ к ключу и значению.

Всю схему можно описать так:
Под проекцией лежит прокси, в прокси - прокси, в прокси лежит некий target-объект, который является объектом TupleBackedMap.

Или так:
«На море на океане есть остров, на том острове дуб стоит, под дубом сундук зарыт, в сундуке — заяц, в зайце — утка, в утке — яйцо» в яйце игла — смерть Кощея!

Подводя итоги данного кейса можно сделать вывод о том, что Spring предоставляет конвертер, который сам маппит Tuple на проекцию. Этот подход отлично подходит для решения поставленной нами задачи, ведь в запросе присутствуют только те колонки, которые указаны в проекции:

Hibernate: 
    select
        p1_0.id,
        p1_0.slug,
        p1_0.title,
        p1_0.author_id,
        a1_0.username 
    from
        posts p1_0 
    left join
        users a1_0 
            on a1_0.id=p1_0.author_id 
    where
        upper(p1_0.title) like upper(?) escape '\'

Interface-based nested interface projections

Следующим способом для решения нашей задачи могло быть решение, основанное на использовании проекции, имеющей внутри себя еще одну проекцию, для получения данных об авторе поста. Это и есть тот самый nested кейс.

public interface PostWithAuthorNested {  
    Long getId();  
    String getSlug();  
    String getTitle();  
    UserPresentation getAuthor();  
}

Для базовых полей будет загружено только то, что указано в проекции. Мы получим необходимые нам id, slug, title. Однако для вложенного объекта будут загружены абсолютно все поля, что конечно, противоречит нашим требованиям. Проблема известна и даже имеет официальный ответ.

Стоит обратить внимание, что PostWithAuthorNested это все тот же прокси вокруг TupleBackedMap, а вот сам вложенный объект UserPresentation является прокси непосредственно вокруг самой сущности User:

Hibernate: 
    select
        p1_0.id,
        p1_0.slug,
        p1_0.title,
        a1_0.id,
        a1_0.bio,
        a1_0.email,
        a1_0.image,
        a1_0.password,
        a1_0.token,
        a1_0.username 
    from
        posts p1_0 
    left join
        users a1_0 
            on a1_0.id=p1_0.author_id 
    where
        upper(p1_0.title) like upper(?) escape '\'

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

Class-based flat projections

Идем далее и следующим вариантом решения задачи по частичной выгрузке полей сущности можно отметить использования в качестве проекции отдельного Record-класса (метод репозитория остается прежним)

public record PostWithAuthorFlatDto(Long id,  
                                    String slug,  
                                    String title,  
                                    Long authorId,  
                                    String authorUsername) {  
}

Сам тест:

@Test  
void derivedMethodClassFlatPrj() {  
    var posts = postRepository.findAllByTitleContainsIgnoreCase(
      "spring",
      PostWithAuthorFlatDto.class
    );  
    assertEquals(1, posts.size());  
    var postFirst = posts.getFirst();  
    assertEquals(POST1_SLUG, postFirst.slug());  
    assertEquals(POST1_AUTHOR_NAME, postFirst.authorUsername());  
}

Spring Data JPA передает result type в Hibernate, который в свою очередь производит мапинг. На плечах Spring'а только лишь грамотное формирование JPQL запроса. Этот вариант нас полностью устраивает.

Результат:

Hibernate: 
    select
        p1_0.id,
        p1_0.slug,
        p1_0.title,
        p1_0.author_id,
        a1_0.username 
    from
        posts p1_0 
    left join
        users a1_0 
            on a1_0.id=p1_0.author_id 
    where
        upper(p1_0.title) like upper(?) escape '\'

Class-based nested dto projections

Идем хорошим темпом, однако стоило бы рассмотреть и негативные, нерабочие сценарии, чтобы лучше понять логику работы с проекциями. Создадим такой record класс с вложенной DTO-проекцией:

public record PostWithAuthorNestedDto(Long id,  
                                      String slug,  
                                      String title,  
                                      UserPresentationDto author) {  
}

Вроде, все должно заработать, однако при попытке "взлететь" мы получим ошибку:

Cannot set field 'author' to instantiate 'io.spring.jpa.projection.PostWithAuthorNestedDto'

О чем нас предупреждали:

В данном случае вся логика лежит на стороне Hibernate, Spring Data здесь не оказывает никакого влияния.

Class-based nested entity projections

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

public record PostWithAuthorEntity(Long id,  
                                   String slug,  
                                   String title,  
                                   User author) {  
}

Получаем:

Hibernate: 
    select
        p1_0.id,
        p1_0.slug,
        p1_0.title,
        a1_0.id,
        a1_0.bio,
        a1_0.email,
        a1_0.image,
        a1_0.password,
        a1_0.token,
        a1_0.username 
    from
        posts p1_0 
    left join
        users a1_0 
            on a1_0.id=p1_0.author_id 
    where
        upper(p1_0.title) like upper(?) escape '\'

Query-methods

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

Interface-based flat projections

Spring богат своими возможностями, потому он, например, может обработать JPQL который мы написали самостоятельно, а затем и вовсе сформировать TupleBackedMap.

Данный способ интересен тем, что нам ничего не мешает написать обычный JPQL запрос, а в качестве возвращаемого значения указать проекцию:

@Query("""
            select  a.id as id,
                    a.slug as slug,
                    a.title as title,
                    a.author.id as authorId,
                    a.author.username as authorUsername
            from Post a
            where lower(a.title) like lower(concat('%', ?1, '%'))""")
List<PostWithAuthorFlat> findAllPostWithAuthorFlat(String title);

Сама проекция:

public interface PostWithAuthorFlat {  
    Long getId();  
    String getSlug();  
    String getTitle();  
    Long getAuthorId();  
    String getAuthorUsername();  
}

Ключевым моментом формирования JPQL-запроса является требование по указанию алиасов: они обязательно должны быть такими же, как свойства в проекции, иначе магии маппинга не произойдет. Кстати, как и ожидалось, под интерфейсом лежит все та же прокси с TupleBackedMap.

Сам результат:

Hibernate: 
    select
        p1_0.id,
        p1_0.slug,
        p1_0.title,
        p1_0.author_id,
        a1_0.username 
    from
        posts p1_0 
    join
        users a1_0 
            on a1_0.id=p1_0.author_id 
    where
        lower(p1_0.title) like lower(('%'||?||'%')) escape ''

Class-based flat projections

Данный способ по частичному получению данных является базовым для Hibernate. Нужно всего лишь создать класс-проекцию с конструктором. После чего инициализируем этот класс прямо в JPQL. Алиасы в этом случае нам не требуются. Прокси в этом случае также не создается, используется только DTO-проекция.

@Query("""
            select
                new io.spring.jpa.projection.PostWithAuthorFlatDto(
                    a.id, 
                    a.slug, 
                    a.title, 
                    a.author.id, 
                    a.author.username
                ) 
            from Post a
            where lower(a.title) like lower(concat('%', ?1, '%'))""")
List<PostWithAuthorFlatDto> findAllPostWithAuthorFlatDto(String title);

Проекция:

public record PostWithAuthorFlatDto(Long id,  
                                    String slug,  
                                    String title,  
                                    Long authorId,  
                                    String authorUsername) {  
}

Тест:

@Test  
void queryMethodClassFlat() {  
    var posts = postRepository.findAllPostWithAuthorFlatDto("spring");  
    assertEquals(1, posts.size());  
    PostWithAuthorFlatDto post = posts.getFirst();  
    assertEquals(POST1_SLUG, post.slug());  
    assertEquals(POST1_AUTHOR_NAME, post.authorUsername());  
}

Успех:

Hibernate: 
    select
        p1_0.id,
        p1_0.slug,
        p1_0.title,
        p1_0.author_id,
        a1_0.username 
    from
        posts p1_0 
    join
        users a1_0 
            on a1_0.id=p1_0.author_id 
    where
        lower(p1_0.title) like lower(('%'||?||'%')) escape ''

Class-based nested class projections

Важной особенностью метода с использованием вложенных проекций является то, что можно делать сколько угодно вложенностей. Поскольку мы используем HQL, то можем инициализировать нашу DTO как нам удобно. В том числе и создавая новые DTO объекты внутри DTO.

Напишем такой метод:

@Query("""
            select
                new io.spring.jpa.projection.PostWithAuthorNestedDto(
                    a.id,
                    a.slug,
                    a.title,
                    new io.spring.jpa.projection.UserPresentationDto(
                        a.author.id,
                        a.author.username
                    )
                )
            from Post a
            where lower(a.title) like lower(concat('%', ?1, '%'))""")
List<PostWithAuthorNestedDto> findAllPostWithAuthorNestedDto(String title);

А также пару проекций под него: проекцию для самого поста, внутри нее объявляем проекцию для автора.

public record PostWithAuthorNestedDto(Long id,  
                                      String slug,  
                                      String title,  
                                      UserPresentationDto author) {  
}

Проекция для автора:

public record UserPresentationDto(Long id, String username) {  
}

Напишем простой тест:

@Test  
void queryMethodClassNested() {  
    var posts = postRepository.findAllPostWithAuthorNestedDto("spring");  
    assertEquals(1, posts.size());  
    PostWithAuthorNestedDto post = posts.getFirst();  
    assertEquals(POST1_SLUG, post.slug());  
    assertEquals(POST1_AUTHOR_NAME, post.author().username());  
}

Непосредственно запрос:

Hibernate: 
    select
        p1_0.id,
        p1_0.slug,
        p1_0.title,
        p1_0.author_id,
        a1_0.username 
    from
        posts p1_0 
    join
        users a1_0 
            on a1_0.id=p1_0.author_id 
    where
        lower(p1_0.title) like lower(('%'||?||'%')) escape ''

Tuple, Object[], List<>, Map

Hibernate также позволяет возвращать select expression, которые мы можем написать в виде Object[], Tuple, Map, List. Подробно останавливаться на каждом не станем, разница лишь в возвращаемом значении:

@Query("""
            select
                a.id as id,
                a.slug as slug,
                a.title as title
            from Post a
            where lower(a.title) like lower(concat('%', ?1, '%'))""")
List<Tuple> findAllTupleBasic(String title);

@Query("""
            select
                a.id as id,
                a.slug as slug,
                a.title as title
            from Post a
            where lower(a.title) like lower(concat('%', ?1, '%'))""")
List<Object[]> findAllObjectWithAuthor(String title);

@Query("""
            select
                a.id as id,
                a.slug as slug,
                a.title as title
            from Post a
            where lower(a.title) like lower(concat('%', ?1, '%'))""")
List<List<?>> findAllListWithAuthor(String title);

@Query("""
            select
                a.id as id,
                a.slug as slug,
                a.title as title
            from Post a
            where lower(a.title) like lower(concat('%', ?1, '%'))""")
List<Map<String, Object>> findAllMapWithAuthor(String title);

P.S.: для Derived-методов аналогично можно указывать такие же возвращаемые значения. Spring Data все возьмет на себя и выгрузит все поля.

Entity Manager

Все способы, описанные для @Query, работают и в Entity Manager, кроме Interface-based projection, так как Interface-based projection является концепцией самого Spring, сам же Hibernate ничего про нее не знает.

Criteria API

Criteria API используется для создания типобезопасных и гибких запросов к базе данных на языке Java. Сам по себе Criteria API является "type-safe alternative to HQL".

Мы будем использовать стандартные функции CriteriaBuilder, однако, если возникнет потребность в дополнительных функциях из HibernateCriteriaBuilder, приведенные ниже примеры будут актуальны и для него.

Для начала нам нужно указать атрибуты, которые мы собираемся передать в запрос. Имя атрибута мы можем очень удобно указать с помощью константы, которая была сгенерирована автоматически с использованием зависимости:

dependencies {
	annotationProcessor 'org.hibernate:hibernate-jpamodelgen:{version}'
}

var idPath = owner.<Long>get(Post_.ID);  
var slugPath = owner.<String>get(Post_.SLUG);  
var titlePath = owner.<String>get(Post_.TITLE);  
var authorIdPath = owner.get(Post_.AUTHOR).<Long>get(User_.ID);  
var authorUsernamePath = owner.get(Post_.AUTHOR).<String>get(User_.USERNAME);

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

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

DTO

Итак, мы объявили path'ы, остается лишь написать запрос, закинуть результат в коллекцию, после чего убедиться в жизнеспособности подхода:

@Test
void criteriaDto() {
  var cb = em.getCriteriaBuilder();
  var query = cb.createQuery(PostWithAuthorFlatDto.class);
  
  var owner = query.from(Post.class);

  var idPath = owner.<Long>get(Post_.ID);
  var slugPath = owner.<String>get(Post_.SLUG);
  var titlePath = owner.<String>get(Post_.TITLE);
  var authorIdPath = owner.get(Post_.AUTHOR).<Long>get(User_.ID);
  var authorUsernamePath = owner.get(Post_.AUTHOR).<String>get(User_.USERNAME);

  query.multiselect(idPath, slugPath, titlePath, authorIdPath, authorUsernamePath)
           .where(cb.like(cb.lower(titlePath), "%spring%"));

  var resultList = em.createQuery(query).getResultList();

  for (PostWithAuthorFlatDto post : resultList) {
      assertEquals(POST1_SLUG, post.slug());
      assertEquals(POST1_AUTHOR_NAME, post.authorUsername());
  }
}

Проекция:

public record PostWithAuthorFlatDto(Long id,  
                                    String slug,  
                                    String title,  
                                    Long authorId,  
                                    String authorUsername) {  
}

В данном случае мы возвращаем множество элементов (атрибутов) и мапим их на DTO, которое указываем при создании query

jakarta.persistence.criteria.CriteriaBuilder#createQuery(java.lang.Class)

Успешный успех:

Hibernate: 
    select
        p1_0.id,
        p1_0.slug,
        p1_0.title,
        p1_0.author_id,
        a1_0.username 
    from
        posts p1_0 
    join
        users a1_0 
            on a1_0.id=p1_0.author_id 
    where
        lower(p1_0.title) like ? escape ''

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

Tuple

В случае с Tuple инициализация объекта происходит ручным способом и мы попросту не сможем создать сам объект и, конечно, поймаем ошибку ещё до запуска приложения на этапе компиляции.

Представляем вашему вниманию, пожалуй, самый безопасный способ выполнения частичных запросов:

@Test
void criteriaTuple() {
  var cb = em.getCriteriaBuilder();
  var query = cb.createTupleQuery();

  var owner = query.from(Post.class);

  var idPath = owner.<Long>get(Post_.ID);
  var slugPath = owner.<String>get(Post_.SLUG);
  var titlePath = owner.<String>get(Post_.TITLE);
  var authorIdPath = owner.get(Post_.AUTHOR).<Long>get(User_.ID);
  var authorUsernamePath = owner.get(Post_.AUTHOR).<String>get(User_.USERNAME);

  query.select(cb.tuple(idPath, slugPath, titlePath, authorIdPath, authorUsernamePath))
         .where(cb.like(cb.lower(titlePath), "%spring%"));

  var resultList = em.createQuery(query).getResultList().stream()
           .map(tuple -> new PostWithAuthorNestedDto(
                  tuple.get(idPath),
                  tuple.get(slugPath),
                  tuple.get(titlePath),
                  new UserPresentationDto(
                           tuple.get(authorIdPath),
                           tuple.get(authorUsernamePath)
                  )
            )).toList();

  for (PostWithAuthorNestedDto post : resultList) {
      assertEquals(POST1_SLUG, post.slug());
      assertEquals(POST1_AUTHOR_NAME, post.author().username());
  }
}

Сами проекции:

public record PostWithAuthorNestedDto(Long id,  
                                      String slug,  
                                      String title,  
                                      UserPresentationDto author) {  
}

public record UserPresentationDto(Long id, String username) {  
}

После формирования Path мы достаем значения из Tuple и складываем в наше DTO (если не требуются дополнительные манипуляции с выборкой). Таким образом мы получаем не только "type-safe alternative to HQL", но и безопасную и контролируемую работу с результатом нашего запроса. Концепция очень похожа на работу с Tuple в библиотеке QueryDSL.

В результате получаем запрос, удовлетворяющий наши требования. Остальные примеры для Criteria API рассмотрены вот тут. Работает все максимально типично относительно случаев, рассмотренных выше.

CriteriaDefinition в Hibernate 6.3+

UPD: Начиная с версии 6.3, Hibernate позволяет нам использовать вспомогательный класс CriteriaDefinition для уменьшения многословности criteria-запросов.

Пример с DTO будет выглядеть следующим образом:

@Test
void criteriaDefinitionDto() {
    var query = new CriteriaDefinition<>(em, PostWithAuthorFlatDto.class) {{
    var owner = from(Post.class);

    var titlePath = owner.<String>get(Post_.TITLE);
    var authorPath = owner.get(Post_.AUTHOR);

    multiselect(
              owner.get(Post_.ID),
              owner.get(Post_.SLUG),
              titlePath,
              authorPath.get(User_.ID),
              authorPath.get(User_.USERNAME)
      ).where(like(lower(titlePath), "%spring%"));
  }};

    var resultList = em.createQuery(query).getResultList();

    assertEquals(1, resultList.size());
    for (var post : resultList) {
        assertEquals(POST1_SLUG, post.slug());
        assertEquals(POST1_AUTHOR_NAME, post.authorUsername());
    }
}

Пример с Tuple:

@Test
void criteriaDefinitionTuple() {
    var query = new CriteriaDefinition<>(em, Tuple.class) {};
    var owner = query.from(Post.class);

    var idPath = owner.<Long>get(Post_.ID);
    var slugPath = owner.<String>get(Post_.SLUG);
    var titlePath = owner.<String>get(Post_.TITLE);
    var authorPath = owner.get(Post_.AUTHOR);
    var authorIdPath = authorPath.<Long>get(User_.ID);
    var authorUsernamePath = authorPath.<String>get(User_.USERNAME);

    query.where(query.like(query.lower(titlePath), "%spring%"))
            .multiselect(idPath, slugPath, titlePath, authorIdPath, authorUsernamePath);

    var resultList = em.createQuery(query).getResultList().stream()
            .map(tuple -> new PostWithAuthorNestedDto(
                    tuple.get(idPath),
                    tuple.get(slugPath),
                    tuple.get(titlePath),
                    new UserPresentationDto(
                            tuple.get(authorIdPath),
                            tuple.get(authorUsernamePath)
                    )
            )).toList();

    assertEquals(1, resultList.size());
  
    for (var post : resultList) {
        assertEquals(POST1_SLUG, post.slug());
        assertEquals(POST1_AUTHOR_NAME, post.author().username());
    }
}

Ознакомиться с результатами работы всех способов вы можете в репозитории.

Кстати, до 6 версии Hibernate Criteria API-запросы к сущностям выполнялись следующим образом:

Criteria API генерировал обычный JPQL, Hibernate же в свою очередь проводил его анализ в соответствии с грамматикой HQL, только затем генерировался SQL-запрос.

Начиная с Hibernate 6 Criteria API сразу преобразуется в SQM:

Подробнее про SQM можно почитать тут.

Выводы

Если мы пишем HQL/JPQL query, то мы контролируем запрос и возвращаем только то что мы хотим. Вопрос только в том, как мапить.
Если мы пишем HQL/JPQL всегда можно вернуть Tuple или Map и помапить с него на DTO.
"Использовать ли repository derived method?" - каждый решает сам. В простых случаях и HQL будет простым, в сложных - длина имени метода будет стремиться выйти за пределы нашей солнечной системы. В рамках решаемых задач для этого проекта, конкретно для частичной выгрузки данных, repository derived method выглядит самым небезопасным. Мы не можем контролировать запрос, а HQL может поменяться из-за изменения DTO/Projection или самой Entity.
Когда мы работаем с Tuple , очень удобным решением является использование библиотеки hibernate-jpamodelgen, что позволяет нам пользоваться автосгенерированными константами. В последней документации Hibernate данный способ используется во всех примерах, можно сказать, что это "тихая" рекомендация. Также, используя эти константы, легко создавать jakarta.persistence.criteria.Path для Criteria API.
Когда мы пишем Query в Spring Data и используем DTO, по дефолту будут валидироваться выражения с DTO: будут проверены как типы, так и количество аргументов в конструкторе. А самое главное - никакой прокси-магии.
Не знаете что вернуть? Верните Tuple. Это очень удобно.
HQL + Class-Based Projection, он же DTO, он же select new class конструкция работают всегда, включая вложенные классы.
Для ToMany, при выгрузки данных в виде Projection/DTO/Tuple нам придется решать вопрос о мердже дублирующихся данных.

Источник

Быстрое нахождение чисел Фибоначчи

2024-05-08T06:56:53.527Z

Быстрое нахождение чисел Фибоначчи

Описание способа нахождения значения произвольного элемента последовательности Фибоначчи за логарифмическое время.

Спираль Фибоначчи

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

На координатном луче, в точке с координатой 1 находится кузнечик. Этот кузнечик может прыгать только вперёд на расстояние 1 либо 2. Сколькими способами он может добраться до точки с координатой n?
Формула для решения этой задачи выводится достаточно просто.
Понятно, что до точки с координатой 0 кузнечик допрыгнуть не может - двигаться назад он не умеет. Способов попасть в эту точку 0. Попасть в точку с координатой 1, в которой он изначально находится, кузнечик может ровно одним способом - оставаться на месте. В любую другую точку с координатой n, кузнечик может добраться либо из точки с координатой n-1, либо из точки с координатой n-2. Соответственно, количество способов которыми он может достичь точки с координатой n равно сумме количеств способов которыми он может достичь точек с координатами n-1, и n-2. Иными словами, если функция f(n) вычисляет количество способов имеющихся у кузнечика чтобы попасть в точку n, то f(n) = f(n-1) + f(n-2).

Другая задача. В начале первого месяца вы получаете пару новорождённых кроликов. Через месяц, эти кролики повзрослеют. Начиная с третьего месяца и далее они будут стабильно давать приплод - ещё одну пару новорождённых кроликов. Таким образом, каждая появившаяся пара кроликов, начиная с двух месяцев после своего появления, каждый месяц порождает ещё пару кроликов. Количество кроликов никогда не уменьшается - кролики не болеют и не умирают. Задача: рассчитать какое количество пар кроликов будет у вас, на n-й месяц.
Формула для решения этой задачи, совпадает с формулой, полученной нами в задаче о кузнечике - f(n) = f(n-1) + f(n-2). Вполне очевидно, что каждый месяц к тому количеству кроликов, что было у вас в прошлом месяце прибавляется приплод, от тех кроликов которые у вас были два месяца назад, так как все они к этому моменту уже достаточно повзрослели, чтобы начать активно размножаться.
К счастью, у реальных кроликов несколько иные характеристики, иначе всего лишь через 9 лет, после появления первой пары кроликов, вся поверхность планеты была бы покрыта более чем 100-километровым плотным слоем кроличьих тушек.

Для решения обеих задач используется одна и та же формула: f(n) = f(n-1) + f(n-2). Это формула чисел последовательности Фибоначчи. Эта последовательность начинается с элемента под номером 0 и значением 0. За ним следует элемент под номером 1 и значением 1. Значения всех остальных элементов вычисляются согласно приведённой формуле - значение каждого из элементов равно сумме значений двух предыдущих.

Для неотрицательных номеров элементов значения принимают следующий вид:
0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987, 1597, 2584, 4181, 6765, 10946, 17711, ...

Однако, из формулы f(n) = f(n-1) + f(n-2) вытекает, что f(n-2) = f(n) - f(n-1). Зная это, мы можем определить значения элементов последовательности и с отрицательными номерами. Так, элемент под номером -1 имеет значение 1, элемент под номером -2 - значение -1. Мы можем представить общий вид вот так:
..., -377, 233, -144, 89, -55, 34, -21, 13, -8, 5, -3, 2, -1, 1, 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, ...

Несложно заметить, что значения элементов с отрицательными номерами, являются практически зеркальным отражением значений элементов с положительными номерами, с тем исключением, что элементы под чётными номерами имеют противоположный знак. Мы можем выразить это следующей формулой f(-n) = (-1)^(n+1)f(n). Благодаря данной формуле мы легко можем получить значение элемента под тем же номером с противоположным знаком. Доказательство корректности этой формулы оставляю в качестве небольшого упражнения читателям.

Теперь перейдём к задаче вычисления числа Фибоначчи со сколько-нибудь большим положительным номером. Скажем, 10000000.

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

package fibonacci;

import java.math.BigInteger;

/**
 * Нахождение чисел Фибоначчи.
 * <p>Класс предоставляет статический метод, для нахождения чисел Фибоначчи.</p>
 */
public class Fibonacci {

// static fields

	/**
	 * Полная форма опции печати.
	 */
	private static final String PRINT_OPTION_FULL_FORM = "--print";

	/**
	 * Короткая форма опции печати.
	 */
	private static final String PRINT_OPTION_SHORT_FORM = "-p";

// static methods

	/**
	 * Точка входа в приложение.
	 * <p>Метод, предполагая, что начальным аргументом запуска указан номер желаемого числа Фибоначчи, вычисляет это число и выводит в стандартный поток ошибок время его вычисления. Опционально, если вторым аргументом является строка {@value #PRINT_OPTION_FULL_FORM}, или {@value #PRINT_OPTION_SHORT_FORM} в стандартный поток выводится значение выбранного числа, а в поток ошибок дополнительно выводится время вывода числа. Значение числа выводится до вывода длительностей вычисления и вывода.</p>
	 * @param args Набор аргументов запуска.
	 * @throws NullPointerException Если набор аргументов запуска не существует.
	 * @throws ArrayIndexOutOfBoundsException Если набор аргументов запуска пуст.
	 * @throws NumberFormatException Если начальный аргумент запуска не является строкой, содержащей запись целого числа.
	 * @throws IllegalArgumentException Если в качестве начального аргумента запуска указанно значение {@link Integer#MIN_VALUE}.
	 */
	public static void main (
		final String... args
	) { // method body
		final int n = Integer.parseInt(args[0]);
		final boolean doPrint = (args.length > 1) && (args[1].equals(PRINT_OPTION_FULL_FORM) || args[1].equals(PRINT_OPTION_SHORT_FORM));
		Instant start;
		Instant finish;
		final Duration calculationDuration;
		Duration outputDuration = null;
		start = Instant.now();
		final BigInteger fibValue = fib(n);
		finish = Instant.now();
		calculationDuration = Duration.between(start, finish);
		if (doPrint) {
			start = Instant.now();
			System.out.println(fibValue);
			finish = Instant.now();
			outputDuration = Duration.between(start, finish);
		} // if
		System.err.println(calculationDuration);
		if (doPrint) {
			System.err.println(outputDuration);
		} // if
	} // main()

	/**
	 * Число Фибоначчи под указанным номером.
	 * <p>Метод вычисляет и возвращает число Фибоначчи под указанным номером. Номер может быть как положительным, так и отрицательным.</p>
	 * @param n Номер числа в последовательности. Не должен являться {@link Integer#MIN_VALUE}.
	 * @return Выбранное число Фибоначчи.
	 * @throws IllegalArgumentException Если указанный номер равен {@link Integer#MIN_VALUE}.
	 */
	public static BigInteger fib (
		final int n
	) { // method body
		if (n == Integer.MIN_VALUE) throw new IllegalArgumentException();
		BigInteger answer = null; // Здесь вычисляем абсолютное значение ответа, обратившись к одному из методов.
		if ((n < 0) && (n % 2 == 0)) {
			answer = answer.negate();
		} // if
		return answer;
	} // fib()

// constructors

	/**
	 * Конструктор, предотвращающий создание экземпляров класса.
	 * <p>Конструктор объявлен с единственной целью - предотвратить создание экземпляров класса.</p>
	 * @throws NoSuchMethodError При любом обращении к данному конструктору.
	 */
	private Fibonacci (
	) { // method body
		throw new NoSuchMethodError();
	} // Fibonacci()

} // Fibonacci

Рекурсия.

Мы можем напрямую воспользоваться формулой f(n) = f(n-1) + f(n-2), и выразить функцию вычисления рекурсивно.

На языке Scheme это будет выглядеть так:

(define (fib n)
        ((if (and (negative? n) (even? n))
             -
             +) (fib-naive (abs n))))

(define (fib-naive n)
        (cond ((= n 0) 0)
              ((= n 1) 1)
              (else (+ (fib-naive (- n 2)) (fib-naive (- n 1))))))

На Java можно выразиться следующим образом:

/**
 * Рекурсивное нахождение чисел Фибоначчи.
 * <p>Метод реализует рекурсивный алгоритм нахождения чисел Фибоначчи.</p>
 * @param n Номер числа в последовательности. Если номер отрицателен, то поведение метода не определено.
 * @return Значение выбранного числа Фибоначчи.
 */
private static BigInteger fibNaive (
	final int n
) { // method body
	return switch (n) {
		case 0 -> BigInteger.ZERO;
		case 1 -> BigInteger.ONE;
		default -> fibNaive(n-1).add(fibNaive(n-2));
	}; // switch
} // fibNaive()

Однако, так как рекурсия требует многократного повторного вычисления одних и тех же значений, такой подход является крайне неэффективным, хотя и позволяет получить правильный результат. Но, по причине неэффективности, о сколько-нибудь больших номерах чисел в последовательности речи не идёт. Уже запрос 45-го числа Фибоначчи, заставляет машину задуматься на заметное время, что делает нашу цель - 10000000-е число последовательности, практически недостижимой.

Итеративный подход

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

f(n) = f(n-2) + f(n-1);

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

Так, зная значения нулевого и первого элементов последовательности, мы можем получить значение второго. Зная значения первого и второго, получаем значение третьего, и так далее.

Давайте выразим всё это в коде, для упрощения реализации начиная с пары минус первого и нулевого элементов.

На Scheme можем выразиться так:

(define (fib n)
        ((if (and (negative? n) (even? n))
             -
             +) (fib-iter 1 0 (abs n))))

(define (fib-iter prev cur n)
        (cond ((zero? n) cur)
              (else (fib-iter cur (+ prev cur) (- n 1)))))

А на Java - так:

/**
 * Последовательное нахождение чисел Фибоначчи.
 * <p>Метод реализует итеративный алгоритм нахождения чисел Фибоначчи.</p>
 * @param n Номер числа в последовательности. Если номер отрицателен, то поведение метода не определено.
 * @return Значение выбранного числа Фибоначчи.
 */
private static BigInteger fibIter (
	final int n
) { // method body
	BigInteger prev = BigInteger.ONE;
	BigInteger cur = BigInteger.ZERO;
	for (int i = n; i > 0; i--) {
		final BigInteger next = cur.add(prev);
		prev = cur;
		cur = next;
	} // for
	return cur;
} // fibIter()

Теперь вычисления происходят несравненно быстрее, так как количество операций линейное. Вычислительная сложность алгоритма O(n). Для вычисления числа Фибоначчи с номером 1000000 придётся немного подождать, но оно стало достижимо. Наша цель - число Фибоначчи с номером 10000000, тоже достижима для этого алгоритма, но из-за большого числа сложений действительно больших чисел, ждать придётся достаточно времени, для того чтобы не спеша выпить чашечку кофе. Хотелось бы уменьшить это время.

Задача о быстром умножении

Для того, чтобы понять как мы можем находить числа Фибоначчи быстрее, рассмотрим следующую задачу:

Предположим, у нас имеется некий числовой тип данных, для значений которого определена только операция сложения. А нам нужно умножить значение этого типа a на не отрицательный, целый скаляр n.

Для начала, мы можем вспомнить, что операция умножения - это многократное повторение операции сложения. Так mul(a, n) = a + a + a + ... + a, где значение a повторяется n раз.

Операция сложения, может быть выражена через рекурсию mul(a, n) = a + mul(a, n-1), что на Scheme можно высказать так:

(define (mul a n)
        (cond ((zero? n) 0)
              (else (+ a (mul a (- n 1))))))

Мы можем отказаться от использования рекурсии, заменив её итерациями. Это вытекает из формулы mul(a, n) = mul(a, n-1) + a, если предположить, что к моменту совершения данного шага операции значение mul(a, n-1) уже вычислено. Выразим этот подход на Scheme:

(define (mul a n)
        (mul-iter a 0 n))

(define (mul-iter val accum count)
        (cond ((zero? count) accum)
              (else (mul-iter val (+ accum val) (- count 1)))))

Вычислительная сложность обоих этих походов, в данной задаче O(n), однако итеративный подход потребляет константное количество памяти, тогда как рекурсивному требуется O(n) дополнительной памяти для хранения промежуточных результатов.

Мы можем улучшить вычислительную сложность до O(log(n)) если вспомним, как значение скалярного числа n вычисляется из его записи в двоичной системе счисления. К примеру число 140 в двоичной системе записывается как 10001100. Значение числа из этой записи получается суммированием произведений значения каждой из цифр, на значение единиц её разряда. В случае числа 140 это выглядит как 128*1 + 64*0 + 32*0 + 16*0 + 8*1 + 4*1 + 2*0 + 1*0 = 128 + 8 + 4 = 140. Таким образом, если значение a умножается на скаляр 140, мы можем выразить это, как a*140 = a*128 + a*8 + a*4. Теперь вспомним, что степени двойки, это число 2 умноженное само на себя несколько раз. Так 128 = 2*2*2*2*2*2*2, 8 = 2*2*2 и 4 = 2*2. Получается, что выражение a*128 + a*8 + a*4 эквивалентно выражению (((((((a*2)*2)*2)*2)*2)*2)*2) + (((a*2)*2)*2) + ((a*2)*2). Используя это, а так же то, что операцию удвоения можно представить как сложение числа с самим собой, мы можем получить алгоритм умножения, работающий за логарифмическое время. Запишем его на языке Scheme:

(define (mul a n)
        (quickMul a 0 n))

(define (quickMul val accum count)
        (cond ((zero? count) accum)
              ((even? count) (quickMul (double val) accum (/ count 2)))
              (else (quickMul val (+ accum val) (- count 1)))))

(define (double a)
        (+ a a))

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

Формулы

Рассмотрев задачу о быстром умножении мы снова можем вернуться к числам Фибоначчи.

Сначала давайте подробнее рассмотрим формулу числа с номером n:

f(n) = f(n-2) + f(n-1)

Каждое из чисел Фибоначчи образовано суммой двух предшествующих чисел Фибоначчи. Каждое из двух предшествующих тоже является суммой, уже предшествующих ему чисел последовательности. Давайте попробуем последовательно раскладывать на слагаемые самый старший элемент последовательности, из правой части уравнения:
f(n) = 1f(n) = 0f(n-1) + 1f(n-0);
f(n) = 0f(n-1) + 1(f(n-1) + f(n-2)) = 1f(n-2) + 1f(n-1);
f(n) = 1f(n-2) + 1(f(n-2) + f(n-3)) = 1f(n-3) + 2f(n-2);
f(n) = 1f(n-3) + 2(f(n-3) + f(n-4)) = 2f(n-4) + 3f(n-3);
f(n) = 2f(n-4) + 3(f(n-4) + f(n-5)) = 3f(n-5) + 5f(n-4);
f(n) = 3f(n-5) + 5(f(n-5) + f(n-6)) = 5f(n-6) + 8f(n-5);
f(n) = 5f(n-6) + 8(f(n-6) + f(n-7)) = 8f(n-7) + 13f(n-6);

Обратим внимание на последовательности коэффициентов слагаемых в самой правой части уравнений. Это две последовательности чисел: 0, 1, 1, 2, 3, 5, 8, ... и 1, 1, 2, 3, 5, 8, 13, .... Не правда ли, эти последовательности схожи между собой, и по какой-то причине кажутся нам знакомыми... Неудивительно, ведь это первые числа последовательности Фибоначчи. Итак, взглянув на эти коэффициенты, мы можем предположить существование следующей формулы:

f(n) = f(x)f(n-(x+1)) + f(x+1)f(n-x); Где x - некоторое целое число. (1)

Покажем, с помощью математической индукции, справедливость этой формулы при любом значении x.

База индукции.
Покажем, что формула справедлива при x = 0:
f(n) = f(0)f(n-(0+1)) + f(0+1)f(n-0);
f(n) = f(0)f(n-1) + f(1)f(n);
f(n) = 0f(n-1) + 1f(n);
f(n) = f(n);

Индуктивный переход при увеличении значения x.
Покажем, что если формула справедлива при x=k, то формула справедлива и при x = k + 1.
Предположим, что равенство f(n) = f(k)f(n-(k+1)) + f(k+1)f(n-k) верно. Тогда, при x = k + 1:
f(n) = f(k+1)f(n-((k+1)+1)) + f((k+1)+1)f(n-(k+1));
f(n) = f(k+1)f(n-(k+2)) + f(k+2)f(n-(k+1));
f(n) = f(k+1)f(n-k-2) + f(k+2)f(n-(k+1));
f(n) = f(k+1)(f(n-k) - f(n-k-1)) + (f(k) + f(k+1))f(n-(k+1));
f(n) = f(k+1)f(n-k) + f(k)f(n-(k+1)) + f(k+1)f(n-(k+1)) - f(k+1)f(n-k-1);
f(n) = f(k+1)f(n-k) + f(k)f(n-(k+1));
f(n) = f(n);

Индуктивный переход при уменьшении значения x.
Покажем, что если формула справедлива при x=k, то формула справедлива и при x = k - 1.
Предположим, что равенство f(n) = f(k)f(n-(k+1)) + f(k+1)f(n-k) верно. Тогда, при x = k - 1:
f(n) = f(k-1)f(n-(k-1+1)) + f(k-1+1)f(n-(k-1));
f(n) = f(k-1)f(n-k) + f(k)f(n-k+1);
f(n) = (f(k+1) - f(k))f(n-k) + f(k)(f(n-k) + f(n-k-1));
f(n) = f(k)f(n-k) - f(k)f(n-k) + f(k)f(n-k-1) + f(k+1)f(n-k);
f(n) = f(k)f(n-(k+1)) + f(k+1)f(n-k);
f(n) = f(n);

Теперь, благодаря формуле (1), мы можем вывести формулу числа Фибоначчи от суммы индексов. Для этого предположим, что n = a + b. Подставим это выражение в формулу (1):
f(a+b) = f(x)f((a+b)-(x+1)) + f(x+1)f((a+b)-x);

Теперь, установим x = a, и подставим в формулу, полученную на предыдущем шаге:
f(a+b) = f(a)f((a+b)-(a+1)) + f(a+1)f((a+b)-a);
f(a+b) = f(a)f(a+b-a-1) + f(a+1)f(a+b-a);
f(a+b) = f(a)f(b-1) + f(a+1)f(b);

Таким образом:
f(a+b) = f(a)f(b-1) + (f(a-1) + f(a))f(b); (2)

Кроме того, воспользовавшись формулой (2), мы можем вывести формулу числа Фибоначчи от удвоенного индекса.

Установим в формуле (2) оба слагаемых равными n:
f(n+n) = f(n)f(n-1) + (f(n-1) + f(n))f(n);

f(2n) = f(n)(2f(n-1) + f(n)); (3)

Теперь почти всё готово для быстрого вычисления произвольных элементов последовательности Фибоначчи, на основе принципов, раскрытых при решении задачи о быстром умножении. Только перед этим следует обратить внимание на то, что в формулах (2) и (3) для вычисления нам требуется не только знание значения f(k), но и знание предшествующего ему значения f(k-1). Опираясь на формулу (2), мы легко можем вывести формулы для получения значения f(a+b-1) и, затем, f(2n-1):

В формуле (2) подставим вместо a выражение a - 1:
f((a-1)+b) = f(a-1)f(b-1) + (f((a-1)-1) + f(a-1))f(b);
f(a+b-1) = f(a-1)f(b-1) + (f(a-2) + f(a-1))f(b);

f(a+b-1) = f(a)f(b) + f(a-1)f(b-1); (4)

Подставим в формулу (4) значение n вместо значений a и b:
f(n+n-1) = f(n)f(n) + f(n-1)f(n-1);

f(2n-1) = f(n)^2 + f(n-1)^2; (5)

Теперь у нас есть всё, что необходимо для реализации быстрого вычисления чисел Фибоначчи.

Реализация быстрого вычисления. Scheme

Поскольку в формулах, как было замечено выше, для произведения вычислений требуется не только значение f(k), но и предшествующее ему значение f(k-1), будет удобно представлять элемент последовательности сразу парой чисел - самим значением элемента, и предшествующим ему. Для представления пар элементов, в языке Scheme, имеется стандартная конструкция Pair, которая, в основном, используется для создания списков, но подойдёт и в нашем случае. Для создания пары предназначена функция cons, а для доступа к полям пары - функции car и cdr. Само значение элемента последовательности будем хранить в первом поле, получая доступ при помощи функции car, а предшествующее ему значение - во втором поле, для доступа используя функцию cdr.

Действуя описанным образом, функцию быстрого вычисления элементов последовательности Фибоначчи, мы можем определить на Scheme так:

(define (fib n)
        (cond ((and (negative? n) (even? n)) (- (fib (abs n))))
              (else (qfib (abs n) (cons 1 0) (cons 0 1)))))

(define (qfib n term accum)
        (cond ((zero? n) (car accum))
              ((even? n) (qfib (halve n) (fib-double term) accum))
              (else (qfib (- n 1) term (fib-sum accum term)))))

(define (halve x)
        (quotient x 2))

(define (fib-double x)
        (cons (* (car x) (+ (* 2 (cdr x)) (car x)))
              (+ (sqr (car x)) (sqr (cdr x)))))

(define (fib-sum a b)
        (cons (+ (* (car a) (cdr b)) (* (+ (car a) (cdr a)) (car b)))
              (+ (* (car a) (car b)) (* (cdr a) (cdr b)))))

(define (sqr x)
        (* x x))

Реализация быстрого вычисления. Java

На Java, для повышения наглядности, вытесним реализацию элементов последовательности, сочетающих пару из текущего и предшествующего значений, а так же функций преобразования номера и быстрого вычисления в отдельный класс. Кроме того, воспользовавшись тем, что у нас есть быстрый доступ ко всем двоичным разрядам номера требуемого элемента, мы, для уменьшения количества вычислений, будем не удваивать номер слагаемого, проходя по битам целевого номера от младших к старшим, а наоборот - проходя от старших битов к младшим, будем удваивать номер аккумулятора, при необходимости увеличивая его на единицу. Для пояснения, вспомним пример из рассмотренной задачи о быстром умножении, где мы умножали значение a на скаляр 140. Число 140 можно представить не только как сумму (128 + 8 + 4), но и в виде выражения (((1*16 + 1)*2 + 1)*4).

Вспомогательный класс реализующий быстрое вычисление элементов последовательности Фибоначчи:

package fibonacci;

import java.math.BigInteger;

/**
 * Быстрое вычисление элементов последовательности Фибоначчи.
 * <p>Экземпляры класса являются immutable-объектами представляющими элементы последовательности Фибоначчи. Каждый из таких объектов предоставляет методы, необходимые для реализации быстрого вычисления других элементов последовательности.</p>
 * <p>Кроме того, класс предоставляет статический фабричный метод, реализующий алгоритм быстрого вычисления элементов последовательности.</p>
 */
public class QFib {

// static fields

	/**
	 * Нулевой элемент последовательности.
	 */
	public static final QFib ZERO = new QFib(BigInteger.ZERO, BigInteger.ONE, BigInteger.ZERO);

// instance fields

	/**
	 * Значение данного элемента последовательности.
	 */
	private final BigInteger cur;

	/**
	 * Значение предшествующего элемента последовательности.
	 */
	private final BigInteger prev;

	/**
	 * Номер данного элемента последовательности.
	 */
	private final BigInteger n;

// static methods

	/**
	 * Получение элемента последовательности с заданным номером.
	 * <p>Метод, реализуя алгоритм быстрого вычисления элементов последовательности Фибоначчи, находит и возвращает элемент с заданным номером.</p>
	 * @param n Номер элемента в последовательности.
	 * @return Элемент последовательности с заданным номером.
	 * @throws NullPointerException Если указанный номер элемента не существует.
	 */
	public static QFib of (
		final BigInteger n
	) throws NullPointerException
	{ // method body
		QFib accum = ZERO;
		final BigInteger absN = n.abs();
		for (int i = absN.bitLength() - 1; i >= 0; i--) {
			accum = accum.doubleN();
			if (absN.testBit(i)) {
				accum = accum.next();
			} // if
		} // for
		if (n.signum() < 0) {
			accum = accum.negateN();
		} // if
		return accum;
	} // of()

// constructors

	/**
	 * Конструктор элемента последовательности.
	 * @param cur Значение данного элемента последовательности.
	 * @param prev Значение предшествующего элемента последовательности.
	 * @param n Номер данного элемента последовательности.
	 * @throws AssertionError Если разрешены операторы контроля, и любой из аргументов не существует.
	 */
	private QFib (
		final BigInteger cur,
		final BigInteger prev,
		final BigInteger n
	) throws AssertionError
	{ // method body
		assert cur != null;
		assert prev != null;
		assert n != null;
		this.cur = cur;
		this.prev = prev;
		this.n = n;
	} // QFib()

// instance methods

	/**
	 * Значение элемента.
	 * <p>Метод возвращает значение данного элемента последовательности.</p>
	 * @return Значение данного элемента.
	 */
	public BigInteger value (
	) { // method body
		return cur;
	} // value()

	/**
	 * Следующий элемент последовательности.
	 * @return Следующий элемент последовательности.
	 */
	public QFib next (
	) { // method body
		final BigInteger nextCur = cur.add(prev);
		final BigInteger nextPrev = cur;
		final BigInteger nextN = n.add(BigInteger.ONE);
		return new QFib(nextCur, nextPrev, nextN);
	} // next()

	/**
	 * Удвоение номера элемента.
	 * <p>Метод возвращает элемент последовательности номер которого равен удвоенному номеру данного.</p>
	 * @return Элемент с номером равным удвоенному номеру данного.
	 */
	public QFib doubleN (
	) { // method body
		final BigInteger doubleCur = cur.parallelMultiply(prev.add(prev).add(cur));
		final BigInteger doublePrev = cur.parallelMultiply(cur).add(prev.parallelMultiply(prev));
		final BigInteger doubleN = n.add(n);
		return new QFib(doubleCur, doublePrev, doubleN);
	} // doubleN()

	/**
	 * Смена знака номера.
	 * <p>Метод возвращает элемент последовательности с номером равным по абсолютному значению, но противоположным по знаку номеру данного элемента.</p>
	 * @return Элемент последовательности с номером противоположным по знаку.
	 */
	public QFib negateN (
	) { // method body
		BigInteger negCur = cur;
		BigInteger negPrev = cur.add(prev);
		if (n.testBit(0)) {
			negPrev = negPrev.negate();
		} else {
			negCur = negCur.negate();
		} // if
		final BigInteger negN = n.negate();
		return new QFib(negCur, negPrev, negN);
	} // negateN()

} // QFib

Теперь, в основном классе Fibonacci, реализуем метод qfib(), использующий написанный нами вспомогательный класс для быстрого вычисления значений элементов последовательности Фибоначчи:

/**
 * Быстрое нахождение значения произвольного элемента.
 * <p>Метод, обращаясь к вспомогательному классу, находит за логарифмическое время и возвращает значение произвольного элемента последовательности Фибоначчи.</p>
 * @param n Номер элемента в последовательности.
 * @return Значение указанного элемента последовательности.
 */
private static BigInteger qfib (
	final int n
) { // method body
	return QFib.of(BigInteger.valueOf(n)).value();
} // qfib()

Теперь мы достигли своей цели: с быстрым подходом вычисления стали действительно быстрыми - поиск 10000000-го числа последовательности занимает менее секунды! Так происходит потому, что вычислительная сложность быстрого алгоритма является логарифмической - в самом деле, на каждом шаге в методе of() класса QFib рассматривается один бит номера выбранного элемента. Таким образом, число итераций, совершаемых алгоритмом для нахождения выбранного элемента последовательности, в точности соответствует числу разрядов в двоичном представлении номера выбранного элемента, что в терминах выражения количества вычислений означает, что вычислительная сложность быстрого алгоритма равна O(log(n)). Печать найденного 10000000-го числа Фибоначчи на экране занимает в четыре с половиной раза больше времени, чем его вычисление - вывод таких больших чисел требует немало времени, ведь количество десятичных цифр в выводимом значении лишь на 30% меньше, чем общее число символов в четырёхтомнике "Война и мир".

С этим алгоритмом, для нас становятся вполне достижимы элементы последовательности Фибоначчи с совсем уже "неприличными" номерами: например, вычисление 1000000000-го числа Фибоначчи, на моей машине, занимает чуть меньше шести минут, а вот формирование и вывод его десятичного представления - без нескольких секунд, 50 минут. Последнее не удивительно, так как десятичное представление этого числа состоит из 208987640 знаков.

Заключение

Использованный алгоритм по сути манипулирует номерами элементов, а не их значениями. Этот алгоритм с равным успехом может быть использован как для быстрого умножения и быстрого получения чисел Фибоначчи, так и для нахождения элементов любой подходящей последовательности за логарифмическое время. Единственным условием, для такой последовательности, является определение функции нахождения элемента от суммы номеров двух других элементов seq(n+m), либо двух функций: удвоения номера элемента seq(2n), и увеличения номера элемента на единицу seq(n+1).

В заключение хотелось бы сказать несколько слов о целесообразности применения рассмотренных нами алгоритмов к получению значений последовательности Фибоначчи. Если требуется вычислить произвольный элемент последовательности, то тут, вне всяких сомнений, пальму первенства удерживает быстрый алгоритм, так как он требует только O(log(n)) вычислений. Однако, если нам необходимо однократно вывести непрерывную подпоследовательность из m элементов, то применение быстрого алгоритма не оправдано, поскольку для этого потребуется O(m*log(n)) операций, в то время как простой итеративный алгоритм, если уже известны два начальных элемента подпоследовательности, потребует только O(m) операций. Впрочем, если начальные элементы выводимой подпоследовательности нам ещё не известны, то получить их поможет как раз быстрый алгоритм, а вот дальше за дело возьмётся итеративный. Наконец, вспомним про незаслуженно обделённый нашим вниманием алгоритм на основе методов динамического программирования, заполняющий линейный массив однажды вычисленных элементов, позволяющий заполнить этот массив за линейное время, как с помощью рекурсивной реализации использующей "ленивую динамику", так и с помощью итеративного подхода. Этот алгоритм имеет важное преимущество перед другими, получаемое в случае множественных последующих обращений к уже вычисленным элементам последовательности: поскольку результаты вычислений кешируются, то, при повторных обращениях, стоимость получения значений вычисленных элементов является константной. То есть, алгоритм на основе динамического программирования требует O(n) памяти для хранения вычисленных элементов, совершает O(n) операций при заполнении кеша, но в дальнейшем, стоимость обращения к вычисленным элементам будет составлять O(1).

Источник

Context receivers — новые extension functions

2024-03-27T06:01:17.022Z

Думаю, не раскрою большой секрет, что Ozon разработал энное количество мобильных приложений: для покупателей, для продавцов, банк и т. д. В каждом из них требуется авторизация. Для этого существует наша команда Ozon ID с SDK собственного производства. Частью команды Ozon ID являюсь я — Android-разработчик с непомерной любовью к синтаксическому сахару Kotlin.

Введение

Поговорим сегодня про context receivers — фиче Kotlin, про которую я узнал давно, но смог найти применение лишь пару месяцев назад. Расскажу о том, что такое context receivers, где их можно использовать, и, конечно же, про «успешный успех» — минус 60% самописного DI в Ozon ID SDK. Но обо всём по порядку.

Функции расширения

В коде Ozon ID SDK есть следующее расширение для ComponentActvity.

inline fun <T> ComponentActvity.collectWhenStarted(
    data: Flow<T>,
    crossinline collector: (T) -> Unit
) {
    lifecycleScope.launchWhenStarted { 
        data.collect {
            collector.invoke(it)
        } 
    }
}

Ремарка

Я знаю, что существует более надёжный способ collect’ить Flow на ui-потоке. Например, с помощью flowWithLifecycle. Но в нём больше параметров, что будет только отвлекать от основной темы.

Реализовано расширение collectWhenStarted исключительно для удобства сбора данных с множества Flow из ViewModel внутри Activity. Ниже пример использования этого расширения.

class AuthFlowActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        ...
        collectWhenStarted(viewModel.backStack) { onBackStackChanged(it) }
        collectWhenStarted(viewModel.navigationEvents) { onNavigationEvent(it) }
        ...
    }
}

Удобно? В общем-то да. Вызов бесспорно короче, чем без использования расширения. Идеально? Отнюдь. Лично мне хотелось бы видеть вызов collectWhenStarted примерно следующим образом:

class AuthFlowActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        ...
        viewModel.backStack.collectWhenStarted { onBackStackChanged(it) }
        viewModel.navigationEvents.collectWhenStarted { onNavigationEvent(it) }
        ...
    }
}

Вызвать collect* у Flow более интуитивно, чем collect* у Activity, не правда ли?

Для того чтобы реализовать улучшенный вариант расширения collectWhenStarted, технически нам понадобится, чтобы механизм методов-расширений мог принимать 2 receiver-параметра. К сожалению, JetBrains пока не реализовали такую возможность в языке Kotlin... Или реализовали?

Реализация через scope

На самом деле есть такой подход, как scope. При таком подходе метод-расширение реализуется в новом классе. В случае с Activity решение на scope можно применить следующим образом.

interface LifecycleOwnerScope : LifecycleOwner {
    fun <T> Flow<T>.collectWhenStarted(collector: (T) -> Unit) {
        lifecycleScope.launchWhenStarted { collect { collector.invoke(it) } }
    }
}

Имплементируем в Activity интерфейс LifecycleOwnerScope, и готово — у Flow появляется расширение collectWhenStarted. При этом реализация интерфейса LifecycleOwnerScope внутри Activity не требуется за счёт «реализации по умолчанию».

class AuthFlowActivity : AppCompatActivity(), LifecycleOwnerScope {
                                            // ^ Добавили scope ^
    override fun onCreate(savedInstanceState: Bundle?) {
        ...             // collectWhenStarted берётся из LifecycleOwnerScope
        viewModel.backStack.collectWhenStarted { onBackStackChanged(it) }
        viewModel.navigationEvents.collectWhenStarted { onNavigationEvent(it) }
        ...
    }
}

Подход вполне жизнеспособный. Но, как по мне, не без недостатков. Например, чтобы расширение collectWhenStarted заработало нужно собственноручно отнаследоваться от LifecycleOwnerScope. Это не так удобно, как глобальные расширения, которые IDE услужливо сама подсказывает при вводе имени.

Давайте уже перейдём к context receivers.

Context receivers спешат на помощь

Context receivers — это концепт, фича языка Kotlin. Context receivers добавлены в язык как инструмент, позволяющий преодолеть ограничения extension-функций. Технически context receivers, как и extension-функции, компилируются в статический метод с дополнительным this-параметром. То есть context receivers являются очередным синтаксическим сахаром Kotlin, но, конечно же, круче и «слаще», чем extension.

Context receivers появились аж в Kotlin 1.6.20. Вместе с context receivers в язык добавили новое ключевое слово context. Фича в версии Kotlin 1.9.22 всё ещё экспериментальная, поэтому если попытаться сходу ей воспользоваться, то IDE выдаст следующее сообщение.

The feature "context receivers" is experimental and should be enabled explicitly

Для того чтобы context receivers заработали, нужно дополнить файл build.gradle модуля, в котором будет использован context.

tasks.withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompile>().configureEach {
    kotlinOptions {
        freeCompilerArgs = freeCompilerArgs + "-Xcontext-receivers"
    }
}

Теперь можно использовать context в коде. Приступим. Будем модифицировать расширение поэтапно.

Шаг 1: Перенести receiver-параметр ComponentActvity в аргументы context.

context (ComponentActvity)
inline fun <T> /*ComponentActvity.*/collectWhenStarted(
    data: Flow<T>,
    crossinline collector: (T) -> Unit
) {
    lifecycleScope.launchWhenStarted { 
        data.collect {
            collector.invoke(it)
        } 
    }
}

Байт-код

Байт-код скомпилированной функции с context receivers получается точно такой же, как и его прямой аналог, реализованный через extension. К сожалению, декомпилировать байт-код с context receivers у меня не вышло. Может, кто-нибудь из читателей подробнее расследует данный вопрос и приведёт свои примеры в комментариях.

Ниже приведена сигнатура декомпилированной из байт-кода extension-функции. Напомню, что байт-код идентичен аналогу на context receivers.

public static final void collectWhenStarted(
    @NotNull ComponentActivity $this$collectWhenStarted, 
    @NotNull final Flow data, 
    @NotNull final Function1 collector
)

Код скомпилируется и выполнится, как и на прежней реализации через расширение. Но есть один нюанс, на котором стоит остановиться. Дело в том, что context receivers — это не extension (ваш капитан Очевидность). Функции с context receivers нельзя вызвать, как будто это метод класса. Пример в сниппете ниже.

// Реализация через extension
activity.collectWhenStarted() // компилятор позволяет вызвать функцию-расширение `collectWhenStarted`, как будто это метод класса

// Реализация через context receivers
activity.collectWhenStarted() // Ошибка: Unresolved reference: collectWhenStarted
with(activity) { // apply, run тоже подойдут
    collectWhenStarted() // Функцию с context можно вызвать только внутри "контекста" 
}

Шаг 2: Перенести аргумент data: Flow в receiver функции

context (ComponentActvity)
inline fun <T> Flow<T>.collectWhenStarted(
    /*data: Flow<T>,*/
    crossinline collector: (T) -> Unit
) {
    lifecycleScope.launchWhenStarted { 
        /*data.*/collect {
            collector.invoke(it)
        } 
    }
}

Вуаля! Готово. Теперь у Flow внутри (иначе говоря, «в контексте») ComponentActvity появится метод collectWhenStarted.

class AuthFlowActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        ...            // powered by context receivers
        viewModel.backStack.collectWhenStarted { onBackStackChanged(it) }
        viewModel.navigationEvents.collectWhenStarted { onNavigationEvent(it) }
        ...
    }
}

We need to go deeper

Приоткрою ещё немного информации относительно ключевого слова context:

context может принимать более одного аргумента. Например, context (classA, classB).
context можно прописывать над классами.

Прямо как аннотация @Component(dependencies = [...]) в Dagger, не правда ли?

Начну разбор этих пунктов с последнего — context над классом. В качестве основы для примеров возьму DI из Ozon ID SDK.

internal class RootModule(
    val application: Application
)

context(RootModule)
internal class ChildModule {

    val dependency by lazy {
        Dependency(
            /*this@RootModule.*/application,
            ...
        )
    }
}

Как видно из примера выше, внутри ChildModule можно обратиться к application, как-будто это свойство ChildModule. При этом к свойству можно обратиться и через this — this@RootModule.application. Пригодится на случай конфликта имён context receivers или ради внесения ясности в вопрос «откуда взялась эта зависимость?».

Продолжим погружение. Рассмотрим, как создавать зависимости с context receivers.

context(RootModule)
internal class SubChildModule

context(RootModule)
internal class ChildModule {
    ...

    val subChildModule by lazy {
        // with не нужен, уже в нужном контексте
        SubChildModule()
    }
}

val childModule = with(rootModule) {
    // Нужен with для создания
    ChildModule()
}

Для того чтобы создать объект класса с context receivers, нужно, чтобы вызов конструктора происходил в требуемом контексте. Контекст можно задать следующим образом:

создать экземпляр внутри класса, требуемого в context receiver;
создать экземпляр внутри независимого класса, в context receivers которого есть нужный класс. Например, как создан модуль SubChildModule внутри ChildModule;
создать внутри scope-функции c лямбдой-расширением в качестве аргумента (with, apply, run). Подойдут и собственные функции с аналогичным параметром.

Теперь рассмотрим создание объектов с несколькими context receivers.

context(RootModule, RepositoryModule, NetworkModule, CookieModule)
internal class MultiContextModule

val multiContextModule = with(rootModule) {
    with(repositoryModule) {
        with(networkModule) {
            with(cookieModule) {
                MultiContextModule()
            }
        }
    }
}

Как можно заметить, код создания экземпляра класса с несколькими context receivers может оказаться не столь изящным, как хотелось бы. Но это поправимо, потому что context можно прописывать к лямбда-аргументам. Возьмём за основу код with из стандартной библиотеки Kotlin и обогатим его context.

// Пример из stdlib
@kotlin.internal.InlineOnly
public inline fun <T, R> with(receiver: T, block: T.() -> R): R {
    contract {
        callsInPlace(block, InvocationKind.EXACTLY_ONCE)
    }
    return receiver.block()
}

// with context receivers
@OptIn(ExperimentalContracts::class)
@Suppress("SUBTYPING_BETWEEN_CONTEXT_RECEIVERS")
internal inline fun <T1, T2, R> with(c1: T1, c2: T2, block: context(T1, T2) () -> R): R {
    contract {                                           // ^^^^^^^
        callsInPlace(block, InvocationKind.EXACTLY_ONCE) // см. сюда
    }
    return block(c1, c2)
}

В примере выше к типу лямбды block добавлено ключевое слово context. Параметры context — generic-типы. Подобных with можно написать больше под нужное количество context receivers. В свою очередь, это позволяет нам значительно уменьшить сдвиг кода вправо при создании MultiContextModule.

context(RootModule, RepositoryModule, NetworkModule, CookieModule)
internal class MultiContextModule

val multiContextModule = with(
    rootModule,
    repositoryModule,
    networkModule,
    cookieModule
) {
    MultiContextModule()
}

Итоги

Подведём черту под тем, что мы сегодня узнали. В этом нам поможет файл KEEP по context receivers.

Context receivers — это механизм, призванный расширить возможности extension-функций. Причём, как мы видели на примере с Flow, именно расширить, а не заменить.
Context receivers можно прописывать как над функциями и свойствами, так и над классами.
Context receivers позволяют использовать более одного receiver-аргумента.
Context receivers непонятно где и когда применять. Как минимум у меня пока не сложилось чёткого мнения, чтобы я мог однозначно сказать «вот тут extension, тут передать аргументом, а тут обязательно context». В видео в конце статьи можете найти размышления на эту тему. Я же пока в данном вопросе буду придерживаться исключительно технического момента.

Заключение

Про context receivers я узнал почти 2 года назад из видео от Jetbrains, не смог придумать им никакого полезного применения и отложил на дальнюю полку знаний про Kotlin. Однако пару месяцев назад мне довелось посмотреть доклад с Droidcon, который помог открыть глаза на всю мощь данного механизма. И тут понеслось: рефакторинг DI в Ozon ID SDK, доклад внутри мобильной команды и в результате эта статья. Надеюсь, что у меня получилось донести до читателей мощь context receivers и подтолкнуть их на дальнейший поиск применимости этой фичи.

Источник

Реализации Microkernel архитектуры с помощью Java OSGI

2024-03-21T12:42:44.013Z

Я хотел бы поделиться опытом реализации микроядерной архитектуры (microkernel) на Java с помощью OSGI (Open Service Gateway Initiative). Этот подход является промежуточным вариантом между микро-сервисной и монолитной архитектурой. С одной стороны присутствует разделение между компонентами на уровне VM с другой - межкомпонентное взаимодействие происходит без участия сети, что ускоряет запросы.

Введение

Источник: Изображение o'reilly

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

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

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

OSGI предлагает подход к изоляции плагинов с помощью разделения кода для каждого плагина на уровне загрузчика классов. Каждый плагин может загружаться отдельным загрузчиком, тем самым обеспечивая дополнительную изоляцию. Недостаток такого решения в потенциальных конфликтах классов: одинаковые классы, загруженные с помощью разных загрузчиков, не могут взаимодействовать.

В качестве высокоуровневого решения можно рассмотреть Apache Karaf, который позиционирует себя как Modulith Runtime и предоставляет интеграцию с основными фреймворками: JAX-RS и Spring Boot. Данный инструмент упрощает взаимодействие с OSGI технологией, предоставляя высокоуровневые абстракции.

Источник: Apache Keraf

В качестве альтернативных вариантов можно рассмотреть непосредственные реализации OSGI: Apache Felix, Eclipse Equinox и Knopflerfish. Использование низкоуровневых решений даст нам большую свободу в процессе проектирования.

Плагинизированная архитектура на базе Apache Felix

Контекст

Для интеграции с различными источниками данных заказчика нами использовалось решение на базе Apache Camel, которое на основе пользовательской конфигурации подключалось к произвольному источнику данных (от FTP до OPC UA) и применяло определенные пользователем трансформации над получаемыми данными. Такое решение зарекомендовало себя своей надежностью, а также легкостью в расширении для случая протоколов, которые уже есть в Apache Camel. Недостаток данного решения заключался в сложности подключения новых протоколов, которых нет в Apache Camel. Проблема была в появлении dependency hell, который состоял в появлении несовместимых транзитивных зависимостях.

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

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

READ FLOW: Чтение из системы заказчика, Преобразование, Запись в нашу систему
WRITE FLOW: Чтение из нашей системы, Преобразование, Запись в систему заказчика

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

Структура проекта

Launcher. Был выделен отдельный проект - launcher, который выполнял функцию ядра системы. Его зона ответственности была ограничена запуском osgi Framework, чтением конфигурации и динамическим подключением необходимых плагинов, которые были явно указаны в конфигурации; а также связыванием всех плагинов в единых конвейер на основе пользовательской конфигурации.

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

Shared Code. Общий код был выделен в два проекта: api - набор интерфейсов для реализации конвейерной обработки данных и parent - общий parent для всех проектов содержащий api в качестве зависимости, а также конфигурацию maven plugin, который позволял получить jar файл с кодом плагина.

Plugins. Каждый плагин размещался в отдельном maven проекте и упаковывался в jar файл со специальной структурой (bundle в терминах osgi). За генерацию правильной структуры отвечает maven плагин org.apache.felix:maven-bundle-plugin, который принимает в качестве настроек название проекта, активатор (entrypoint) и перечень private/export/import/embed зависимостей.

Структура плагина (bundle)

Каждый плагин содержит в себе activator - класс, который будет запущен в момент подключения плагина. Ожидается, что в этот момент плагин будет регистрировать свои сервисы в контексте. Каждый сервис может содержать мета-информацию, которую он запишет в Dictionary.

public class Activator implements BundleActivator {
  @Override
  public void start(final BundleContext bundleContext) {    
      Dictionary<String, Object> dictionary = new Hashtable<>();
      dictionary.put("CustomField", "API_IMPL_V1");
      bundleContext.registerService(ApiService.class, new ApiServiceImpl(), dictionary);
    }
}

Ядро приложения (Host в терминах OSGI) может обратиться к контексту с запросом на получение зарегистрированных сервисов с указанием полей метаданных:

var references =
        context.getServiceReferences(ApiService.class, "(CustomField=*)");
Map<String, ConnectorService> index = new HashMap<>();
for (ServiceReference<ConnectorService> reference : references) {
    var  service = context.getService(reference);
    index.put(reference.getProperty("CustomField").toString(), service);
}

При этом плагин будет содержать зависимости, недоступные остальным плагинам, если они будут помечены как Private.

Неочевидности, о которых хотелось бы знать

№1. Спецификация не позволяет иметь классы в default package. Данное требование распространяется не только на ваш проект, но и на все ваши зависимости. Ошибка, которая будет выведена в случае нарушения требования, не будет информативной:

[ERROR] Bundle {groupId}:{artifactId}:bundle:{version} : The default package ‘.’ is not permitted by the Import-Package syntax.
This can be caused by compile errors in Eclipse because Eclipse creates
valid class files regardless of compile errors.
The following package(s) import from the default package null
[ERROR] Error(s) found in bundle configuration

Для решения этой проблемы нужно разместить условный breakpoint в коде плагина “org.apache.felix:maven-bundle-plugin” и самостоятельно найти зависимость, содержащую неправильную структуру классов.

Подробное решение этой проблемы я разместил в отдельной статье : https://medium.com/@mark.andreev/how-to-fix-the-default-package-is-not-permitted-by-the-import-package-syntax-in-osgi-3b59a6c18e71

№2. Неочевидные обязательные настройки “org.osgi.framework.launch.Framework”. У вас не получится запустить apache felix без указания временной директории “Constants.FRAMEWORK_STORAGE”. В случае возникновения проблем ошибка не будет информативной.

№3. Отсутствие ошибки в случае проблем во время загрузки bundle. Единственный способ понять, что bundle не загрузился - это сравнить SymbolicName у bundle с null.

Bundle addition = bundleContext.installBundle(location);
if (addition.getSymbolicName() != null) {
   // TODO: add error
}

№4. Сложности в передаче библиотечных классов в плагин. Решением оказалось унификация интерфейсов в библиотеке api и использование только этих классов для общения между плагинами.

Заключение

Решение на базе Apache Felix продемонстрировало не только сложность в адаптации недостаточно популярной технологии, которое выражалось в нехватке знаний на Stackoverflow и необходимости использовать отладчик для исследования большинства проблем, что усложняет разбор инцидентов. С другой стороны, благодаря данной технологии мы получили низкую связность между компонентами системы, изоляцию плагинов на уровне загрузчика классов и более простую структуру проекта за счет выделения каждого компонента конвейера в отдельный проект; и значимое ускорение запуска.

Важно учитывать, что позитивный опыт напрямую связан со слабой связанностью между плагинами и отсутствием общих совместно используемых зависимостей помимо api library.

Если вам требуется более тесное взаимодействие, то стоит обратить внимание все же на Apache Karaf. Скорее всего вам будет удобнее не реализовывать низкоуровневое взаимодействие с OSGI, аналогичное описанному в проекте.

Послесловие

А был ли у вас опыт реализации микроядерной архитектуры? Как вы решали данную проблему?

Источник

Осознанная оптимизация Compose 2: В борьбе с композицией

2024-03-06T07:20:13.218Z

Jetpack Compose постоянно развивается, открывая перед разработчиками новые горизонты для оптимизации. С момента нашего последнего обзора, мы добились значительного прогресса, сократив задержки при скролле с 5-7% до нуля. В этом материале мы поделимся свежими находками и передовыми практиками в оптимизации Compose. Чтобы максимально углубиться в тему, рекомендуем ознакомиться с первой частью.

Серия статей:

Осознанная оптимизация Compose
Осознанная оптимизация Compose 2: В борьбе с композицией (текущая)

Композиция - низвергнутый бог

Проблема начальной композиции

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

В подкасте разработчики подчеркивают, что Compose проектировался исходя из того, что людям проще думать в категориях простых лейаутов (Box, Column, Row), а не таких сложных, как ConstraintLayout. В отличие от View, у Compose нет проблемы экспоненциального увеличения количества измерений, так как они ограничены одним проходом. Пропуски функций также способствуют решению проблемы вложенности. Но не в случае начальной композиции, когда нужно пройтись по тысяче лейаутов. Разработчики стремятся снизить и эту нагрузку: переход с версии Compose 1.4 на 1.6, по их словам, ускорит работу списков на 40%, что служит весомым аргументом в пользу обновления. Однако для уже оптимизированных списков прирост производительности может быть не так заметен.

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

Для начала давайте посмотрим, как время композиции соотносится с другими фазами Compose:

Среднее время каждой фазы. Данные для слабого устройства. Источник

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

Modifier.Node

Modifier.composed долгое время был основным инструментом для создания кастомных модификаторов. Однако, несмотря на его гибкость, этот подход имеет свои недостатки. Modifier.composed требует передачи composable-лямбды, внутри которой генерируется restartable-группа и множество других конструкций. Во время композиции под капотом вызываются эти composable-лямбды для получения конечного модификатора. Этот процесс называется материализацией, что усложняет начальную композицию. Кроме этого из-за лямбд страдало и сравнение модификаторов, так как каждый раз создаётся новая лямбда, которая не равна прошлой, следовательно цепочка модификаторов тоже считается другой из-за чего Compose делает меньше пропусков.

Теперь на помощь приходит Modifier.Node – новый, более эффективный способ создания кастомных модификаторов. Этот подход позволяет реализовать все задачи, для которых ранее использовался Modifier.composed, но без лишних накладных расходов, связанных с composable-лямбдами и композицией. Самое важное преимущество – классы, созданные с помощью Modifier.Node, могут быть сравнены и переиспользованы, что значительно улучшает производительность.

Google недавно обновила документацию, добавив множество примеров и рекомендаций по использованию Modifier.Node. Это отличный повод пересмотреть существующие реализации модификаторов в вашем проекте и заменить их на более оптимизированные Modifier.Node.

Проблемы DerivedState и remember

Как мы уже выяснили, композиция сама по себе дорогая и стоит использовать DerivedState, чтобы ограничить число рекомпозиций. Однако часто разработчики применяют его некорректно, что было подробно разобрано в первой части. Сейчас стоит объяснить, почему так важно следить за этим.

Рассмотрим время, затрачиваемое на чтение тех или иных данных, чтобы понять масштабы проблемы (источник):

Чтение локальной переменной - 1 нс
Чтение из поля класса - 5 нс
Вызов метода - 10 нс
Чтение с синхронизацией - 50 нс
map.get - 150 нс
state.value - 2 500 нс
derivedState.value - 10 000 нс

Учитывая, что для поддержания частоты обновления экрана в 120 кадров в секунду максимальное время отрисовки одного кадра не должно превышать 8 333 333 нс, становится очевидным, что неправильное использование DerivedState может значительно замедлить ваше приложение. Если такой подход не приводит к заметному уменьшению числа рекомпозиций, это может сделать код медленнее, чем при прямом обращении к исходному State<T>.

Та же логика применима и к функции remember { }. Необдуманное "запоминание" простых вычислений может неоправданно замедлить работу приложения. Например, чтобы запомнить обычное выражение, потребуется сперва сравнить ключи с их предыдущими значениями, что уже само по себе будет дороже, и это не говоря про чтение и запись в Slot Table.

// Антипримерval expr = remember(a, b, c) { a + b * c }

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

Пересядь с иглы Compose на старый добрый Kotlin

Для эффективной работы с Jetpack Compose ключевым является умение находить золотую середину между использованием возможностей Compose и стандартным Kotlin кодом. Как отметил разработчик Compose Андрей Шиков: "Изучая Compose, мы позабыли как использовать Kotlin". Давайте взглянем на его пример, демонстрирующий этот подход. В исходной версии кода использовалось множество отдельных состояний и сайд-эффектов:

@Composable 
fun MyComponent(modifier: Modifier, config: Config) {
    val interactionSource = remember { MutableInteractionSource() }
    val activeInteractions = remember { mutableStateListOf<Interaction>() }
    val config by rememberUpdatedState(config)

    LaunchedEffect(interaction Source) {
        interactionSource.interactions.collect {
            // Обновление списке взаимодействий
        }
    }

    val animatableColor = remember {
        Animatable(config.defaultColor, Color.VectorConverter)
    }

    LaunchedEffect(config) {
        // Обновление animatableColor
    }

    LaunchedEffect(interactions) {
        snapshotFlow { activeInteractions.lastOrNull() }.collect {
            // Обновление animatableColor на основе взаимодействий и конфига
        }
    }
    
    // Использование animatableColor при отрисовке
}

Этот код был оптимизирован путём объединения нескольких состояний и сокращения количества сайд-эффектов за счёт переноса логики в одну корутину:

@Composable 
fun MyComponent(modifier: Modifier, config: Config) {
    val state = remember { MyComponentState(config) }

    LaunchedEffect(state) {
        state.collectUpdates()
    }

    SideEffect {
        state.config.value = config
    }

    // Использование state.animatableColor при отрисовке
}

Благодаря такому рефакторингу удалось ускорить работу кода на 9%.

Пререндер

При первом открытии экрана приложения, время ожидания пользователя состоит из двух основных этапов: загрузки данных и отрисовки UI. Для минимизации времени ожидания появления контента на экране можно использовать технику пререндера.

Суть метода заключается в том, что во время загрузки данных параллельно происходит отрисовка экрана с использованием моковых данных. Очень важно, чтобы структура композиции UI не менялась сильно после замены моковых данных на реальные. Учитывая высокую стоимость процесса композиции, такой подход позволяет заранее "прогреть" композицию, существенно сокращая время до появления актуального контента на экране.

Один из вариантов реализации пререндеринга – использование индикатора загрузки, отрисованного поверх всего экрана:

ProductDetailScreen(state: ProductUiState) {
    // Вначале state содержит пустые данные для пререндера контента
    ProductDetailContent(state)

    // Отображение индикатора загрузки поверх контента, а не вместо него
    if (state.isLoading) {
        FullscreenLoader()
    }
}

Также можно применять эффект шиммера на моковых данных, используя модификатор placeholder из библиотеки accompanist. Этот метод не влияет на структуру композиции после загрузки реальных данных и обеспечивает плавный визуальный переход. Однако, он требует дополнительной адаптации существующих элементов для корректной отрисовки шиммера поверх контента.

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

Отложенная композиция

Ленивые лейауты используют SubcomposeLayout для определения того, какие элементы должны быть отображены на экране. Для этого происходит внутренняя композиция во время фазы компоновки (layout). Этот процесс происходит за один кадр, что может стать проблемой при работе с тяжёлыми экранами.

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

В примере ниже демонстрируется как отложить композицию части экрана, используя метод withFrameNanos { }, который аналогично delay() останавливает корутины, но делает это ровно до начала следующего кадра:

@Composable
fun ProductDetail(
    productInfo: ProductInfo
) {
    var blockState by remember { mutableStateOf(0) }

    LaunchedEffect(Unit) {
        while (blockState < 3) {
            // Откладываем композицию каждого блока на 1 кадр
            withFrameNanos {  }
            blockState += 1
        }
    }

    ProductBlock0(productInfo)

    if (blockState >= 1) {
        ProductBlock1(productInfo)
    }
    if (blockState >= 2) {
        ProductBlock2(productInfo)
    }
    if (blockState >= 3) {
        ProductBlock2(productInfo)
    }
}

Painter

Xml-иконки vs Compose-иконки

При работе с иконками в Compose существует два основных подхода: использование иконок в формате XML и прямое создание иконок с помощью кода. Рассмотрим процесс и эффективность каждого из них.

// Xml-иконка
Image(
    painter = painterResource(R.drawable.my_icon), 
    contentDescription = null
)

// Compose-иконка
Image(
    painter = rememberVectorPainter(Icons.Filled.Home), 
    contentDescription = null
)

Для XML иконки процесс загрузки включает вызов painterResource(R.drawable.my_icon), состоящий из следующих шагов:

Чтение ресурса из файла или получение его из кэша.
Преобразования XML в ImageVector.
Создание Painter с помощью функции rememberVectorPainter().

В случае с иконками, созданными непосредственно в Compose, процесс выглядит следующим образом:

Вызов Icons.Filled.Home сразу инициирует создание объекта ImageVector.
Создание Painter с помощью функции rememberVectorPainter().

Тесты показали, что иконки, созданные с помощью Compose, загружаются от 5% до 18% быстрее по сравнению с иконками в формате XML. Скорость загрузки напрямую зависит от сложности структуры иконки и размера исходного файла. Важно отметить, что общее влияние иконок на производительность приложения может сильно варьироваться в зависимости от их количества на экране и использования в ленивых списках.

Для создания собственных Compose-иконок можно воспользоваться инструментом SVG to Compose, который поддерживает конвертацию как SVG, так и XML файлов. Также стоит упомянуть, что эти иконки убавят вам проблем с ресурсами при использовании Compose Multiplatform.

Нестабильность Painter

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

Вынос Painter

Вынесение создания объекта Painter за пределы списка позволяет заметно увеличить скорость отрисовки. Это особенно критично в списках, где каждый элемент требует инициализации собственного Painter. Несмотря на наличие кэша для XML ресурсов, каждый такой вызов создает дополнительную нагрузку. Создание единого Painter для всего списка значительно уменьшает эту нагрузку. Однако, как и в случае с выносом модификаторов, может пострадать читабельность кода.

Пример до оптимизации:

@Composable
fun MyList(products: ImmutableList<ProductUiState>) {
    LazyColumn { 
        items(products) { product -> 
            // Painter внутри элемента списка
            MyProductItem(product, painterResource(R.drawable.ic_menu)) 
        } 
    }
}

Пример после оптимизации:

@Composable
fun MyList(products: ImmutableList<ProductUiState>) {
    // Выносим Painter для общей иконки из списка
    val menuPainter = painterResource(R.drawable.ic_menu)

    LazyColumn { 
        items(products) { product -> 
            MyProductItem(product, menuPainter) 
        } 
    }
}

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

Дизайн система

Создание дизайн-системы является ключевым этапом при внедрении Jetpack Compose в проекты. Разработчики на этом этапе могут столкнуться с проблемами из-за недостаточного опыта разработки на новой технологии, что ведет к появлению неэффективного кода в важнейших частях дизайн-системы.

Цветовая схема

Традиционно при создании кастомной цветовой палитры разработчики копируют подход, используемый в MaterialTheme. Однако недавние коммиты разработчиков указывают на недостатки такой реализации.

В традиционной реализации для каждого цвета создавался отдельный State<T>, что вело к необходимости подписки на изменение состояния каждый раз при его чтении. Это могло негативно повлиять на производительность, особенно если в дизайн-системе использовалось множество цветов.

Пример до оптимизации:

@Stable
class ColorScheme(
    primary: Color,
    onPrimary: Color,
) {
    // State<T> для каждого цвета
    var primary by mutableStateOf(primary)
        internal set
    var onPrimary by mutableStateOf(onPrimary)
        internal set
}

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

Переход к использованию обычного data class для описания цветовой схемы устраняет необходимость в подписках на состояние и улучшает производительность приложения.

Пример после оптимизации:

@Immutable
data class ColorScheme(
    val primary: Color,
    val onPrimary: Color,
)

Ошибки прошлого

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

AppTheme.typography создаёт новую типографию при каждом вызове, загружая шрифты и цвета из ресурсов для каждого стиля текста отдельно. Это приводило к множественным обращениям к ресурсам и чтению AppTheme.colors.textPrimary 16 раз для каждого TextStyle.

object AppTheme {
    @Composable
    @ReadonlyComposable
    val typography
        get() = DefaultAppTypography
}

@Composable
@ReadonlyComposable
val DefaultAppTypography
    get() = AppTypography(
        headXXL = TextStyle(
            color = AppTheme.colors.textPrimary,
            ...
        ),
        // ...
        // Создание 15 других стилей текста
    )

Эта реализация особенно заметно замедляла отрисовку на экранах с большим количеством текста и различными стилями, поскольку каждый текстовый элемент инициировал вызов условного AppTheme.typography.headXXL. Нашли мы эту проблему после исследования нескольких экранов с помощью трассировки композиции.

Решение проблемы заключалась в изменении подхода к созданию и использованию типографии. Теперь типография AppTheme инициализируется единожды и доступна через LocalAppTypography.current, что значительно сокращает количество обращений к ресурсам и ускоряет работу с типографией во всем приложении:

object AppTheme {
    @Composable
    @ReadonlyComposable
    val typography
        get() = LocalAppTypography.current
}

Форматтеры

Важно помнить о правильном размещении логики форматирования чисел и валют. Интуитивно может показаться, что использование форматирования непосредственно в коде Compose — это удобно. Однако, этот подход может привести к неожиданным проблемам производительности. Рекомендуется переносить создание и использование форматтеров в бизнес-логику вашего приложения. Такой шаг позволяет не только уменьшить нагрузку на главный поток, но и избежать излишнего дублирования объектов форматтера, обеспечивая их переиспользование между экранами. Этот совет кажется простым, но на практике часто упускается из виду, особенно когда форматирование спрятано за утилитарные функции.

Антипример форматирования в Compose-коде:

Text(
    text = productItem.price.toMoneyFormat()
)

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

Оптимизация на спичках

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

Автоупаковка

Автоупаковка примитивных типов данных может незаметно замедлить выполнение кода, особенно когда он используется в большом количестве мест. В Jetpack Compose разработчики активно стремятся минимизировать подобные затраты, применяя различные способы:

Использование специальных MutableState для примитивных типов (например, mutableIntStateOf()) помогает избежать упаковки.
Введение специальных значений (Unspecified) для определенных классов вместо null позволяет избежать автоупаковки благодаря инлайнингу value классов. Например, недавно добавили Unspecified для TextAlign, TextDirection и др., чтобы избежать null.
Замена Pair<Int, Int> на value class с полем типа Long значительно снижает затраты на хранение данных, используя стек вместо кучи. Тип Long содержит в два раза больше бит, чем Int, что позволяет ему хранить два числа типа Int и обращаться к ним с помощью побитовых операций.

Быстрые методы

Не все стандартные методы Kotlin идеально подходят для конкретных задач. Jetpack Compose предлагает альтернативы, например, fastForEach или fastFirst. О быстрых методах можно прочитать в блоге Romain Guy.

Эффективные структуры

Стандартные структуры данных в Kotlin могут быть не лучшим выбором для специализированных задач.

Например, mutableListOf использует ArrayList, что может быть избыточным, если не требуется динамическое изменение размера коллекции или использование дженериков. В критически важных частях кода лучше применять специализированные массивы (например, IntArray).
Метод mutableMapOf по умолчанию создаёт LinkedHashMap, что может быть менее эффективным, чем другие типы данных. Jetpack Compose использует, например, ScatterMap.

Внутри AndroidX Collections много оптимизированных структур, которые стоит использовать в критическом коде.

Вложенные if

При работе с условными конструкциями важно учитывать влияние вложенности на производительность. Каждая условная ветка создаёт дополнительные вызовы replaceable-группы для поддержки быстрой замены кода. Поэтому в случаях, когда вложенность условных блоков не является необходимостью, предпочтение следует отдавать плоской структуре. Это позволяет не только упростить код, но и повысить его производительность за счёт уменьшения количества операций.

Пример генерации кода для плоских if (также и для when):

if (condition1) {
    $composer.startReplaceableGroup()
    Content1()
    $composer.endReplaceableGroup()
} else if (condition2) {
    $composer.startReplaceableGroup()
    Content2()
    $composer.endReplaceableGroup()
} else {
    $composer.startReplaceableGroup()
    Content3()
    $composer.endReplaceableGroup()
}

Пример генерации кода для вложенных if:

if (condition1) {
    $composer.startReplaceableGroup()
    Content1()
    $composer.endReplaceableGroup()
} else {
    $composer.startReplaceableGroup()
    if (condition2) {
        $composer.startReplaceableGroup()
        Content2()
        $composer.endReplaceableGroup()
    } else {
        $composer.startReplaceableGroup()
        Content3()
        $composer.endReplaceableGroup()
    }
    $composer.endReplaceableGroup()
}

Нововведения

Указание стабильности внешних типов

С релизом Compose Compiler версии 1.5.5 появилась возможность явно указывать стабильность внешних типов. Это нововведение позволяет избежать использования дополнительных обёрток для обеспечения стабильности. Рекомендуем добавить в список стабильных типов такие часто используемые классы, как стандартные коллекции из Kotlin и Painter. Это нужно указать в каждом модуле, где используется Compose. Указание коллекций особенно актуально для тех, кто предпочитает не использовать immutable коллекции из-за нахождения их в альфа-версии или из-за необходимости переписывания большого объема кода.

// Все коллекции из котлин 
kotlin.collections.* 

// Painter 
androidx.compose.ui.graphics.painter.Painter

Режим сильной пропускаемости

На данный момент режим сильной пропускаемости является экспериментальным и активируется через специальный флаг. В перспективе он может стать настройкой по умолчанию. Что он даёт:

Все перезапускаемые (restartable) функции станут пропускаемыми (skippable). Для нестабильных параметров сравнение по экземплярам, для стабильных - через equals.
Лямбды, захватывающие нестабильные переменные, будут тоже обёрнуты в remember.

Инструментарий

Просмотр исходного кода Compose

Каждый раз, когда вы сомневаетесь в том, как будет работать тот или иной код после компилятора Compose, стоит просто посмотреть финальный Java код. Хоть вы и можете отлично знать генерацию Compose-кода из Jetpack Compose Internals или множества статей, это не спасёт вас от устаревания информации там. Для этого есть удобный gradle-плагин - decomposer.

Vkcompose плагин

Среди полезных инструментов есть плагины от VK для Kotlin и IDE, которые выполняют:

Подсветку нестабильных параметров и непропускаемых функций непосредственно в IDE.
Визуальное выделение происходящих рекомпозиций в UI с помощью цветных границ.
Логирование причин, по которым произошла рекомпозиция.

Detekt

Detekt, позволяет не только следить за стилем кода, но и защищать от не очень хороших практик, в том числе приводящих к проседанию производительности.

compose-rules - большой список разнообразных правил.
vkcompose - кроме плагина предоставляет правило, которое проверяет функции на пропускаемость.

Итог

Подводя итог, мы разобрались, как избегать проблемы с начальной композицией и что не стоит перегружать Compose лишней логикой, ведь за удобство и простоту приходится платить. Однако благодаря неустанной работе разработчиков, производительность Compose значительно выросла, давая нам свободу сосредоточиться на других аспектах разработки. А экраны с огромным DAU и на View приходилось оптимизировать за гранью обычных приёмов. Для Compose это далеко не предел: будущие оптимизации сделают его ещё более мощным инструментом, идеально подходящим для любых задач.

Источник

Интегрируем Kotlin сервис с AI чат-ботом с помощью Spring AI за 5 минут

2024-03-05T07:44:15.093Z

Чат-боты с генеративным искусственным интеллектом получили широкую известность после релиза ChatGPT в ноябре 2022 года. Сейчас вряд ли найдётся человек из IT, который не слышал про данный инструмент от OpenAI. Именно он вызвал настоящий бум в данной сфере, вынудив конкурентов разрабатывать свои аналоги, чтобы побороться за место на рынке. Таким образом созданная лавина изменений затронула многие языки программирования. Не обошли они и Java-сообщество. Spring Framework, один из наиболее популярных Java фреймворков обзавёлся модулем Spring AI, который обещает упростить разработку приложений с функциями ИИ.

Давайте вместе взглянем на него в деле и опробуем на демо проекте. В данном гайде мы создадим и подключим Kotlin сервис к чат-боту всего за пять минут, используя Spring AI!

Spring AI — это экспериментальный проект, цель которого — упростить разработку приложений с искусственным интеллектом (либо интеграцию с такими приложениями). На момент написания статьи актуальной является версия 0.8.1-SNAPSHOT. В неё входят следующие части:

Embeddings API. В терминах ML эмбеддинг (embedding) означает векторное представление каких-либо данных. Эмбеддинги позволяют преобразовать информацию, которую понимаем мы, в информацию, которую понимает компьютер. В том же NLP они используются, чтобы компьютер мог анализировать и/или преобразовывать текст (переводить, извлекать смысл, перефразировать частично или полностью). Embeddings API позволяет преобразовывать текст в векторы.
Chat Completion API. Данное API используется для взаимодействия с AI чат-ботами. Уже есть клиенты для OpenAI, Ollama, Microsoft Azure, HuggingFace, Google Vertex, Amazon Bedrock.
Function API. У моделей OpenAI есть интересная фича — регистрация функций. Пользователь описывает, какие входные параметры принимает его функция и модель может вывести JSON, который можно в неё передать.Это упрощает составление запросов к модели и парсинг ответов. Модель по контексту будет понимать, что вы хотите и выдавать данные в необходимом формате. Function API позволяет работать с этой фичей — регистрировать функции, описывать условия вызова и т.д.
Image Generation API. API для взаимодействия с моделями, заточенными на генерирование изображений. Есть готовые клиенты для OpenAI (DALL·E) и Stability AI (Stable Diffusion).
Prompts. Промпт (prompt) — входной текст, на основе которого модель генерирует контент. В зависимости от того, с какой моделью вы взаимодействуете, будет менятся и структура промта. В Stable Diffusion, например, есть позитивный промпт (что мы хотим получить), и негативный промпт (что мы не хотим получить), а входной текст чаще всего представляет собой набор ключевых слов (masterpiece, best quality, photo и т.д.). А в ChatGPT промпт представлен как инструкция и ассоциируется с определённой ролью. (подробнее можно почитать тут). Модуль Prompts содержит классы для работы с промптами (шаблоны, интерфейсы, утилиты).
Output Parsers. Получаемые от модели данные нужно поместить в Java классы, для этого можно использовать готовые парсеры или создать свой на основе интерфейса OutputParser.
Vector Databases. Векторая база данных — это база данных, которая заточена под хранение данных в векторном представлении. Она нужна для хранения данных, которые потом будут использоваться AI моделью. Одной из ключевых особенностей векторной базы данных является поиск данных по сходству, когда мы можем найти в базе векторы, наиболее похожие на заданный. Этот поиск играет важную роль в рекомендательных системах, распознавании изображений, языковой обработке. В Spring AI для взаимодействия с векторными базами данных используется интерфейс VectorStore. В настоящий момент есть реализации данного интерфейса для Weaviate, Redis, PineCone, pgvector, Neo4j, Milvus, Chroma, Azure.
ETL Pipeline. ETL расшифровывается как "extract, transform, load" (извлечь, преобразовать, загрузить). Это процесс, который нужен для подготовки данных для BI-систем, датасетов для тренировки моделей ИИ, долгосрочного хранения и пр. Spring AI позволяет создавать ETL пайплайны для чтения данных в "сыром" виде, преобразования их в векторы и загрузка в векторную базу данных.
Generic Model API. Данный модуль включает в себя набор интерфейсов для взаимодействия с AI моделями. Основная цель — упростить и стандартизировать поддержку новых AI моделей, которые будут добавлять в Spring AI.

В рамках данной статьи, используя Spring AI, мы создадим простой Spring сервис для анализа настроения пользователя. Алгоритм его работы достаточно прост:

Пользователем может быть как человек, так и ПО

Для создания проекта будут использованы следующие инструменты:

Kotlin версии 1.9.22.
Gradle версии 8.2.
Spring (в том числе модуль Spring AI).
Ollama (инструмент для запуска языковых моделей). В данном примере я буду использовать модель OpenChat. Она поддерживает русский язык и даёт неплохой результат для моих скромных вычислительных ресурсов.
Postman (для тестирования).

Для начала потребуется создать наш Spring проект. Можно воспользоваться Spring Initializr или сделать это вручную. Не забудьте добавить зависимость для Spring AI, указанную ниже

implementation("org.springframework.ai:spring-ai-ollama-spring-boot-starter:0.8.1-SNAPSHOT")

Далее набросаем базовые классы.
Контроллер:

@RestController
class ChatController(
    private val chatService: ChatService
) {
    @PostMapping("/chat")
    fun sendMessage(@RequestBody message: String): String {
        return chatService.exchange(message)
    }
}

Сервис:

@Service
class ChatService(
    private val client : OllamaApiClient
) {
    private val outputParser = BeanOutputParser(SentimentAnalysisResult::class.java)

    fun exchange(message: String): String {
        return client.sendMessage(message)
    }
}

Далее создадим OllamaApiClient. В Spring AI уже есть реализация ChatClient для Ollama, поэтому будем использовать её для взаимодействия с моделью.

@Component
class OllamaApiClient(
    properties: OllamaClientProperties
) {
    private final var client = OllamaChatClient(OllamaApi(properties.url))

    init {
        val options = OllamaOptions.create()
        options.model = properties.model
    }

    fun sendMessage(message: String): String {
        return client.call(message)
    }
}

OllamaClientProperties:

@ConfigurationProperties(prefix = "ai.ollama")
data class OllamaClientProperties(
    val url: String,
    val model: String
)

Адрес и имя модели указываем в application.yml.
После первоначальной настройки проверяем корректность указанных параметров и отправляем запрос на наш эндпоинт:

Чем дольше я смотрю на этот ответ, тем меньше я хочу доверить ему написание статьи

Теперь нам нужно попросить чат-бота оценивать настроение нашего сообщения. Для этого нужно добавлять дополнительную информацию к каждому запросу. Сделать это можно с помощью PromptTemplate:

private val promptTemplate = PromptTemplate("""
        Какое настроение у следующего текста:'{text}'? 
        Оно позитивное, негативное или нейтральное? 
        Укажи степень уверенности с помощью числа от 0.0 до 1.0."
    """)
fun exchange(message: String): String {
        val prompt = promptTemplateRus.create(mapOf("text" to message))
        val generation = client.sendMessage(prompt)
        return generation.output.content.toString()
    }

В зависимости от модели, которую вы используете, шаблон можно корректировать исходя из получаемых результатов.
Поскольку PromptTemplate возвращает объект типа Prompt, нам нужно изменить и метод sendMessage:

fun sendMessage(prompt: Prompt): Generation {
        val response = client.call(prompt)
        return response.result
    }

Повторяем запрос и получаем такой результат:

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

Создадим data класс для маппинга данных:

data class SentimentAnalysisResult(
    val text: String = "",
    val sentiment: String = "",
    val confidence: String = ""
)

Также добавим Output Parser чтобы сразу "упаковать" ответ в data класс:

private val promptTemplate = PromptTemplate("""
        Какое настроение у следующего текста:'{text}'? 
        Оно позитивное, негативное или нейтральное? 
        Укажи степень уверенности с помощью числа от 0.0 до 1.0.{format}"
    """)
    private val outputParser = BeanOutputParser(SentimentAnalysisResult::class.java)

    fun exchange(message: String): SentimentAnalysisResult {
        val prompt = promptTemplate.create(mapOf("text" to message, "format" to outputParser.format))
        val answer = client.sendMessage(prompt)
        return outputParser.parse(answer.output.content)
    }

Теперь наш запрос будет иметь следующий вид:

Уверенность в ответе всё возрастает

Давайте проверим, что наша программа правильно определяет заданное настроение:

Нейтральный запрос

Позитивный запрос

Негативный запрос

Результат соответствует ожиданиям! Далее, в зависимости от вашего проекта, можно настраивать модель, менять API сервиса или шаблоны для запросов.

В завершающей части хотел бы рассказать про тюнинг модели. OllamaChatClient позволяет настроить широкий спектр параметров модели, вот некоторые из них:

temperature. Параметр креативности модели. Чем выше значение, тем ответы более необычные.
frequencyPenalty. "Наказание" модели за повторения. Меньше значение — больше одинаковых словесных конструкций и выражений, меньше уникальных слов.
presencePenalty. "Наказание" модели за использование одних и тех же токенов в сгенерированном тексте. Чем меньше число, тем чаще могут попадаться одни и те же слова.
topK. У модели есть определенное количество вариантов, как можно продолжить генерируемый текст. Данный параметр ограничивает количество доступных токенов для продолжения. Меньше число — меньше возможных опций.
topP. Ограничение кумулятивной вероятности возможных токенов. Работает схожим образом с topK. Есть набор возможных токенов, которыми модель может продолжить текст. У каждого токена есть определённая вероятность, что он будет следующим. Токены добавляются в некий пул возможных токенов, где их вероятности складываются. Когда вероятность превысит P, больше токены не будут добавляться и модель будет выбирать токен из добавленных.

Из-за того, что сообщение модели подстраивается под указанный формат, нам не сильно важна креативность модели, повторяет ли она одни и те же слова или нет, ведь мы этого не увидим. Единственный параметр, который сильно влияет на выводимые данных — это topP.
Опытным путём было определено, что высокий topP приводит к тому, что модель постоянно меняет уровень уверенности в своём ответе. Для наших целей это нежелательно (иначе проще просто генерировать случайное число самим). Поэтому topP стоит сделать 0.25 или ниже. По остальным параметрам выбор не принципиален и не повлияет на оценку текста (по крайней мере для выбранной мной модели).

Внесём итоговые правки в код.
application.yml

ai:
  ollama:
    url: "http://localhost:11434"
    options:
      model: "openchat"
      temperature: 0.8f
      top_k: 100
      top_p: 0.25f
      frequency_penalty: 0f
      presence_penalty: 0f

Класс конфигурации

@ConfigurationProperties(prefix = "ai.ollama")
data class OllamaClientProperties(
    val url: String,
    val options: OllamaOptions
)

data class OllamaOptions(
    val model: String,
    val temperature: Float,
    val topK: Int,
    val topP: Float,
    val frequencyPenalty: Float,
    val presencePenalty: Float
)

Конструктор для OllamaApiClient

init {
        val options = OllamaOptions.create()
        options.model = properties.options.model
        options.temperature = properties.options.temperature
        options.topK = properties.options.topK
        options.topP = properties.options.topP
        options.frequencyPenalty = properties.options.frequencyPenalty
        options.presencePenalty = properties.options.presencePenalty
        client.withDefaultOptions(options)
    }

Вот и подошёл к концу гайд. В нём мы рассмотрели базовые компоненты Spring AI, связанные с интеграцией AI чат-бота в ваше приложение. Конечно, Spring AI не ограничивается представленными возможностями, это обширный проект, к которому регулярно выходят обновления. Получит ли он широкое распространение, неизвестно, но попробовать его в действии как минимум интересно, а, возможно, оно пригодиться не только для пет-проектов.

Исходники проекта вы можете посмотреть в репозитории

Источники

Документация Spring AI
Ollama
Про настройку модели

Источник