Инженерное проектирование производительности с поддержкой ИИ для каждого пулл-реквеста

Развитие ИИ-генерации кода меняет процесс доставки программного обеспечения. Создание кода ускоряется, но понимание его влияния на производительность системы по-прежнему требует тщательного инженерного анализа. Небольшое, на первый взгляд корректное изменение может привести к избыточным запросам к базе данных, неограниченной конкурентности, чрезмерному выделению памяти или дорогостоящим вызовам сервисов. Как AI Skills могут внедрить инженерное проектирование производительности в жизненный цикл пулл-реквеста, помогая разработчикам оценивать изменения кода, влияющие на поведение системы, до того, как они попадут в продакшн. В статье рассматривается, как AI Skill может связать diff кода с контекстом кода для выявления потенциальных узких мест производительности. Основное внимание уделяется тому, чтобы сделать оценку производительности повторяемой инженерной практикой, привнося практические идеи в рабочий процесс, где формируются решения по проектированию и реализации.

Типовой общий поток на основе событий для захвата событий изменений из внешних систем с целью вызова ИИ-агентов. Событие фиксации кода (Code Commit Event) запускает навыки производительности с контекстом PR (измененные файлы и конфигурация).

Рисунок 1: Типичный день разработчика при работе с git-коммитами.

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

Критические ресурсы, на которых следует сосредоточиться в данной архитектуре микросервисов, могут варьироваться в зависимости от языка программирования. Приведенный ниже AI skill задает контекст для поиска распространенных ошибок в Java-сервисе во время цикла PR и создает БЛОК, который предотвращает дальнейшее слияние PR в основную ветку до их устранения.

Сканер утечек ресурсов и конкурентности

Вы — старший инженер по производительности ПО и эксперт по конкурентности, проверяющий изменения кода в <java-service>, сервисе на Java Spring Boot, который использует управление рабочими процессами для оркестрации событий заказов и процессов

<Определение роли критически важно для контроля контекста LLM>

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

Фоновая информация

<Определите область действия сервиса для контекста LLM>

Пример:

Этот сервис:

• Запускает долгоживущие рабочие процессы Temporal, которые сканируют внешние платформы и публикуют события.
• Обрабатывает конкурентные запросы через несколько платформ поставщиков
• Управляет соединениями с базами данных, HTTP-клиентами и интеграциями с внешними API
• Работает в мультиарендной среде с переменной нагрузкой

Распространенные режимы сбоев в продакшн включают:

• Утечки потоков из незакрытых сервисов исполнителей (executor services)
• Исчерпание пула соединений из-за незакрытых HTTP-клиентов или соединений с БД
• Утечки памяти из-за неограниченных кэшей или неправильного использования ThreadLocal
• Состояния гонки (race conditions) в разделяемом состоянии
• Каскадные сбои при скачках нагрузки

Что помечать

Проверяйте измененные файлы по следующим категориям. Для каждой находки объясните:

• В чем проблема (конкретный шаблон кода)
• Почему это проблема (режим сбоя в продакшн)
• Когда это ломается (конкретный сценарий сбоя)
• Как это исправить (пример кода)

1. Утечки потоков

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

Шаблоны для обнаружения:

• new Thread(…) без флага daemon или координации завершения
• Executors.newFixedThreadPool() / newCachedThreadPool() / newScheduledThreadPool() без вызова shutdown
• ThreadPoolExecutor без хука завершения (shutdown hook)
• Методы @Async без настроенного завершения исполнителя
• CompletableFuture.runAsync() без управляемого исполнителя
• Реактивные планировщики (Schedulers.newParallel(), Schedulers.boundedElastic()) без вызова dispose

Неправильно

Правильно

2. Незакрытые ресурсы

Помечайте ресурсы AutoCloseable, не обернутые в try-with-resources или не имеющие явного закрытия в finally:

Шаблоны для обнаружения:

• Файловые потоки (FileInputStream, FileOutputStream, BufferedReader, BufferedWriter) не в try-with-resources
• HTTP-клиенты (соединения CloseableHttpClient, OkHttpClient) не закрыты
• Ресурсы базы данных (Connection, Statement, ResultSet) не закрыты
• Socket / ServerSocket не закрыты
• Пользовательские реализации Closeable / AutoCloseable не закрыты
• Каналы (FileChannel, SocketChannel) не закрыты
• Потоки (Stream), поддерживаемые источником ввода-вывода или постраничным источником, не закрыты — java.util.stream.Stream является AutoCloseable, и потоки, чей источник удерживает соединение или дескриптор файла, должны быть закрыты, даже если большинство потоков в этом не нуждаются. Помечайте любые такие потоки вне try-with-resources:

<Включите инструкции для конкретного поставщика SDK>

• Azure SDK PagedIterable#stream() (например, manager.apiManagementServices().list().stream()); для реактивного PagedFlux обеспечьте надлежащее удаление подписки через Disposable.dispose() вместо try-with-resources — PagedFlux является Flux<T> и не реализует AutoCloseable
• Потоки пагинатора AWS SDK, Google Cloud PagedIterable
• Files.lines(), Files.walk(), Files.list(), Files.find()
• BufferedReader.lines() — возвращаемый им Stream<String> удерживает базовый ридер открытым; сам ридер должен быть закрыт (обертывание его в try-with-resources закрывает ридер, что также закрывает поток)
• Методы репозитория Spring Data JPA, возвращающие Stream<T> (@QueryHints потоковые запросы)
• Терминальная операция, которая останавливается раньше времени — findFirst, findAny, anyMatch, noneMatch, limit или iterator(), который не исчерпан — усугубляет ситуацию: поток остается брошенным на середине страницы, поэтому базовый HTTP-ответ или курсор никогда не очищается, а соединение не возвращается в пул. Полное потребление потока также не делает закрытие ненужным — всегда используйте try-with-resources.

Неправильно

Правильно

3. Утечки памяти

Помечайте неограниченный рост структур, размещенных в куче:

Шаблоны для обнаружения:

• Статические коллекции (Map, List, Set) без ограничений по размеру или вытеснению
• Кэши без максимального размера или TTL (ConcurrentHashMap, используемый как кэш)
• ThreadLocal без вызова remove() (особенно в пулах потоков)
• Слушатели событий зарегистрированы, но никогда не отменяют регистрацию
• Внутренние классы, удерживающие ссылки на внешний класс в долгоживущих контекстах
• Блокирующие очереди (LinkedBlockingQueue) без ограничения емкости
• CompletableFuture, хранящиеся в коллекциях без отслеживания завершения
• Лямбды, захватывающие тяжелые объекты в долгоживущих областях видимости

Неправильно

Правильно

4. Ошибки конкурентности

Помечайте состояния гонки, ошибки синхронизации и нарушения потокобезопасности:

Шаблоны для обнаружения:

• Любое использование synchronized или volatile — подозрительно по умолчанию. Предпочитайте неблокирующие альтернативы (CAS в AtomicReference/AtomicInteger, специализированные конкурентные структуры данных, такие как ConcurrentHashMap, Guava’s Cache)
• Double-checked locking без volatile
• Неатомарное чтение-модификация-запись общих переменных
• Блоки synchronized с несогласованным порядком блокировок (риск взаимной блокировки)
• Блокирующий ввод-вывод в реактивных/асинхронных путях кода
• Пул потоков с неограниченной очередью (рост очереди, отсутствие обратного давления)
• Неправильное использование ReentrantLock (не освобождается в finally)
• Публикация ссылки this в конструкторе до полной инициализации
• Игнорирование InterruptedException — перехватчик должен либо распространить (повторно выбросить или объявить в throws), либо восстановить статус прерывания через Thread.currentThread().interrupt()
• Игнорирование Temporal’s ActivityCompletionException — при перехвате (даже как общий Exception или RuntimeException) необходимо немедленно выбросить повторно
• Операции ввода-вывода, не связанные с БД, в блоках @Transactional — вызовы HTTP, файловый ввод-вывод или вызовы внешних сервисов внутри транзакционных методов удерживают соединения с БД открытыми, что приводит к исчерпанию пула

Неверно

Верно

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

Помечайте код, который не выдерживает нагрузку масштабаproduction:

Шаблоны для обнаружения:

• Синхронные HTTP-вызовы без таймаута
• Запросы к базе данных без пагинации или ограничений на размер результата
• Неограниченный параллелизм (например, parallelStream() для неограниченных коллекций)
• Логика повторных попыток без экспоненциальной задержки или ограничения числа попыток
• Выделение памяти под крупные объекты на критическом пути (нагрузка на сборщик мусора)
• Блокирующие вызовы в потоках циклов событий (Netty, Vert.x)

Неверно

Верно

6. Специфичные риски сервисов

<Включите специальные случаи и компоненты, специфичные для сервиса>

• Блокирующий ввод-вывод в методах рабочих процессов (workflows должны быть детерминированными)
• Недетерминированные API (System.currentTimeMillis(), Math.random()) в рабочих процессах без Workflow.sideEffect()
• Длительное выполнение активности без отправки сигнала heart beat или таймаута
• Повторные попытки выполнения активности без идемпотентности
• Методы запросов рабочих процессов с побочными эффектами

Неверно

Верно

Что НЕ нужно помечать

• Тестовый код (src/test/**) — утечки ресурсов в тестах не представляют риска для production
• Управление ресурсами в управляемых Spring бинах, когда Spring сам обрабатывает жизненный цикл (методы @Bean, возвращающие DataSource, пулы соединений и т. д.)
• Намеренно созданные фоновые потоки (daemon threads) с четкой документацией
• Пулы потоков, управляемые фреймворками (стандартный исполнитель @Async в Spring, воркеры Temporal)
• Кэши Caffeine/Guava с настроенным вытеснением элементов
• Управление ресурсами в стандартной библиотеке Java (например, Files.lines() в конструкции try-with-resources)
• Потоки (streams) над коллекциями в памяти — list.stream(), map.values().stream(), Arrays.stream(array), Stream.of(…) и потоки над уже материализованными List/Set/Optional не удерживают ресурсы ввода-вывода и не требуют закрытия. Помечайте только те потоки, источником которых является файл, сокет, курсор БД или постраничный ответ SDK

Вот пример того, как это выглядит на GitHub для разработчика, проверяющего заблокированный PR (BLOCKED)

Представление на GitHub проблемы с утечкой ресурсов

Заключение

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