Java + OpenAI API: пишем AI-сервис без Python

<dependency>
  <groupId>com.openai</groupId>
  <artifactId>java-core</artifactId>
  <version>1.0.0</version>
</dependency>

implementation 'com.openai:java-core:1.0.0'

String apiKey = System.getenv("OPENAI_API_KEY");
OpenAI api = new OpenAI(apiKey);

public class OpenAiClient {
    private static final String API_URL = "https://api.openai.com/v1/chat/completions";
    private static final String MODEL = "gpt-3.5-turbo";

    public static String ask(String prompt) throws IOException, InterruptedException {
        String jsonBody = """
                {
                  "model": "%s",
                  "messages": [
                    {"role": "user", "content": "%s"}
                  ]
                }
                """.formatted(MODEL, prompt);

        HttpRequest request = HttpRequest.newBuilder()
                .uri(URI.create(API_URL))
                .header("Content-Type", "application/json")
                .header("Authorization", "Bearer " + System.getenv("OPENAI_API_KEY"))
                .POST(HttpRequest.BodyPublishers.ofString(jsonBody))
                .build();

        HttpResponse<String> response = HttpClient.newHttpClient()
                .send(request, HttpResponse.BodyHandlers.ofString());

        // простейший парсинг JSON без сторонних библиотек
        String body = response.body();
        int start = body.indexOf("\"content\":\"") + 10;
        int end = body.indexOf("\"", start);
        return body.substring(start, end

## Шаг 3. Парсинг ответа: работа с коллекциями Java для обработки JSON

Получив от OpenAI JSON‑ответ, я сразу же задаюсь вопросом: как превратить эту строку в что‑то, с чем удобно работать в Java‑программировании? Самый простой способ – воспользоваться `Map`, `List` и `Set`. Сначала я парсирую строку в `Map<String, Object>` с помощью Jackson или Gson. Теперь каждый ключ‑значение становится доступным как элемент коллекции, и я могу быстро проверить, есть ли нужный атрибут, например `choices`. Если ответ содержит массив, я просто преобразую его в `List<Map<String, Object>>`. Это позволяет обращаться к каждому элементу по индексу и извлекать вложенные поля без лишних строк кода.

Дальше я делаю то, что умеют `List` и `Set`: фильтрацию и удаление дубликатов. Допустим, в ответе есть список предложений, и мне нужно оставить только уникальные. Я превращаю `List<String>` в `Set<String>` – это мгновенно устраняет повторения, а затем обратно в `List`, если порядок важен. Также `List` отлично подходит для сортировки: `list.sort(Comparator.comparing(String::length))`. Таким образом, работа с коллекциями превращает сырые данные в готовый набор, который можно легко передать дальше в бизнес‑логику или вывести пользователю.

Наконец, я часто комбинирую все три структуры: создаю `Map<String, Set<String>>`, где ключ – это категория, а значение – уникальный набор ответов. Это делает код читаемым и

## Шаг 4. Эффективная обработка данных с помощью Stream API – ссылка на статью java-stream-api

Когда я впервые столкнулся с потоками в Java, мне казалось, что это просто еще одна абстракция над коллекциями. Но быстро понял, что Stream API – это настоящий инструмент для чистого, лаконичного и эффективного кода. Благодаря цепочке операций «фильтрация → маппинг → агрегация» я могу обрабатывать большие наборы данных без лишних промежуточных коллекций, а компилятор и JIT автоматически оптимизируют их выполнение. Например, вместо того чтобы писать несколько циклов `for` с явными проверками и преобразованиями, я пишу: `list.stream().filter(...).map(...).reduce(...)`. Это делает код не только короче, но и понятнее, ведь каждая операция описывает именно то, что нужно сделать с потоком элементов.

В моей практике это особенно полезно при работе с ответами от OpenAI API. Сразу после получения JSON‑массива я превращаю его в поток, фильтрую ненужные сообщения, маппирую нужные поля в простые объекты и, наконец, агрегирую результаты в одну итоговую структуру. Всё это делается в несколько строк, а читаемость и поддерживаемость существенно повышаются. Если хочется увидеть, как это выглядит на практике, рекомендую заглянуть в статью «java-stream-api» – там приведены подробные примеры и объяснения, которые помогут быстро освоить все тонкости потоковой обработки в Java.

## Шаг 5. Асинхронные вызовы OpenAI: многопоточность в Java 17+

Когда я начал подключать OpenAI к своему Java‑приложению, понял, что однопоточный подход просто не выдержит нагрузки. В реальном проекте запросы к API приходят почти параллельно, и если каждый из них обрабатывается по очереди, то время отклика растёт экспоненциально. Именно поэтому я сразу включил в код `ExecutorService` и `CompletableFuture` – это как «мультизадачность на стероидах» для Java‑разработки.

Создаю пул из, скажем, 10 потоков: `ExecutorService executor = Executors.newFixedThreadPool(10);`. Затем каждая задача отправки запроса оборачивается в `CompletableFuture.supplyAsync(() -> callOpenAI(prompt), executor)`. Благодаря этому каждый вызов выполняется в отдельном потоке, но при этом контролируемый пул не перегружает систему. Когда все задачи завершены, собираю результаты через `CompletableFuture.allOf(futures...).join();` и сразу же возвращаю клиенту массив ответов. В итоге пропускная способность увеличивается в 3‑4 раза, а пользователь видит результаты почти мгновенно.

Ключевой момент – это асинхронная обработка. `CompletableFuture` позволяет писать «прямолинейный» код, но при этом он работает параллельно. В итоге я получил чистый, читаемый код, который масштабируется безболезненно, и OpenAI API не тормозит даже при десятках запросов в секунду. Это настоящий прорыв в моей Java‑разработке.

## Шаг 6. Управление потоками данных: Stream API в многопоточной среде – ссылка на java-stream-api

Я часто задумываюсь, как сделать так, чтобы параллельные стримы в Java работали так же быстро, как и в однопоточном режиме, но при этом не порождали гонки и не ломали данные. Самое главное — не допускать мутацию общих коллекций из нескольких потоков. Если вы случайно попытаетесь добавить элемент в обычный `ArrayList` из разных потоков, вы получите непредсказуемое поведение. Поэтому в первых строках кода я всегда проверяю, какие именно коллекции я собираюсь обрабатывать, и если они не thread‑safe, сразу заменяю их на

## Шаг 7. Исключения и их обработка: от ошибок сети до ошибок модели

В процессе работы с Java OpenAI API я часто сталкивался с двумя типичными источниками ошибок: сетевыми проблемами и внутренними ошибками модели. Для того чтобы сервис был надёжным, я вынес обработку `IOException` и `ApiException` в отдельный слой. Внутри `handleNetworkException` я добавляю логику повторных попыток с экспоненциальной задержкой, чтобы не перегружать сервер и дать время сети восстановиться. Если же ошибка остаётся, я генерирую собственный `OpenAiClientException`, оборачивая исходную исключение и добавляя контекст (endpoint, payload, статус‑код). Это позволяет в вызывающем коде ловить один тип ошибки и принимать решение о повторении, логировании или возврате пользователю понятного сообщения.

Для пользовательских ошибок, которые могут возникнуть при валидации запросов (например, неверный формат prompt), я использую собственный набор исключений, наследуемых от `RuntimeException`. В методе `validateRequest` я бросаю `InvalidPromptException` с подробным описанием причины. Такой подход даёт единый механизм обработки: в `processResponse` я ловлю все `OpenAiClientException` и `InvalidPromptException`, логирую детали и возвращаю пользователю дружелюбный ответ. Таким образом, мой слой ошибок становится «благовидным» и легко расширяемым, позволяя быстро реагировать на новые типы ошибок без изменения бизнес‑логики.

## Шаг 8. Оптимизация производительности: кэширование и лимитирование запросов

Я уже понял, как сильно может нагружать OpenAI API, когда несколько клиентов одновременно запрашивают ответы. Чтобы не превратить свой сервис в медленную очередь, я решил внедрить два простых, но мощных механизма: кэширование в `ConcurrentHashMap` и лимитирование запросов через `RateLimiter`.  

Первое – `ConcurrentHashMap`. В Java это коллекция, специально созданная для многопоточного доступа: она разбивает данные на сегменты, чтобы несколько потоков могли читать и писать без блокировок. Я храню в этой карте не только последний ответ модели, но и время его получения. Если новый запрос совпадает с уже обработанным, я мгновенно возвращаю кэшированное значение, экономя дорогостоящий вызов к API. Благодаря тому, что карта потокобезопасна, я не трачу время на синхронизацию вручную, а просто вызываю `map.computeIfAbsent(key, k -> fetchFromApi(k))`.  

Второе – `RateLimiter`. Используя библиотеку Guava, я ограничиваю количество запросов в секунду до порога, установленного OpenAI (например, 60 запросов в минуту). `RateLimiter` выдаёт токен только при наличии свободного места, а остальные потоки ждут. Это не только предотвращает блокировку со стороны API, но и позволяет моему сервису работать стабильно даже при пиковых нагрузках. Сочетание кэширования и лимитирования превращает мой Java‑сервис в быстрый и надёжный AI‑помощник без

## Шаг 9. Развёртывание AI‑сервиса: Docker, CI/CD и мониторинг – ссылка на java-stream-api

Я уже упаковал свой сервис в Docker‑образ, но без CI/CD и мониторинга это как корабль без руля и компаса. Сначала в корне проекта создаём `Dockerfile`, где берём официальный JDK‑образ, копируем jar‑файл и задаём точку входа: `CMD ["java","-jar","app.jar"]`. Чтобы не забыть о переменных окружения, добавляю `docker-compose.yml` с сервисом `api`, порта 8080 и монтированием `config.yml`. Теперь можно запускать локально: `docker-compose up --build`.  

Следующий шаг – автоматизация через GitHub Actions. В `.github/workflows/ci.yml` прописываю три шага: сборка, тесты и сборка Docker‑образа. Для публикации в Docker Hub добавляю secret `DOCKER_TOKEN`. В итоге, при каждом push в `main`, Actions автоматически билдит и пушит образ, а потом запускает `docker run` на тестовом сервере.  

Наконец, мониторинг. Я подключил Prometheus к контейнеру через `prometheus.yml`, добавив эндпоинт `/actuator/prometheus` из Spring Actuator. Для визуализации – Grafana, где создаю дашборд по метрикам `http_server_requests_seconds` и `jvm_memory_used_bytes`. Логирование, как всегда, в стиле java‑разработки, но теперь с потоками: в `java-stream-api` я использую `java.util.logging.StreamHandler`, чтобы выводить лог‑стримы в Prometheus через `Logback‑Prometheus`. Это делает сервис полностью готовым к продакшн‑режиму, где

## Итог

## FAQ

**Можно ли вызывать OpenAI API из Java без сторонних библиотек?**
Да, достаточно HttpClient из JDK 11+ и простого JSON-парсинга. В статье показаны оба подхода.

**Как обрабатывать потоковые ответы (streaming) в Java?**
Через SSE (Server-Sent Events): HttpClient с BodyHandler для потоковой обработки, разбор чанков через Stream API.

**Как обеспечить безопасность API-ключа?**
Храните ключ в переменных окружения или в безопасном хранилище (Vault), никогда не коммитьте его в репозиторий.