Не увеличивайте пул вслепую. Проверьте active, idle, pending, время ожидания и ошибки создания соединений, затем медленные запросы, блокировки, долгие транзакции и возврат Connection. Размер задается maximumPoolSize, а бюджет нужно считать для всех экземпляров приложения. leakDetectionThreshold только сообщает о возможной утечке и не освобождает соединение.
HikariCP: при пуле из 10 соединений возникает connections not available. Что делать?
Диагностика нехватки соединений через метрики пула, длительность запросов, блокировки, возврат ресурсов и общий бюджет соединений всех экземпляров приложения.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Размер пула 10 сам по себе не объясняет ошибку. Сначала уточните полный текст исключения и момент возникновения. Если истекло ожидание getConnection(), приложение не получило пригодное соединение за отведенное время; причину нужно установить отдельно.
Сопоставьте нагрузку и метрики: число активных и свободных соединений, ожидающих потоков, длительность получения и удержания соединения. Проверьте также ошибки создания новых соединений. Полностью занятый пул и невозможность подключиться к недоступной БД могут приводить к похожему пользовательскому симптому.
Далее исследуйте медленные запросы, блокировки, долгие транзакции, сетевые проблемы и достижение лимита соединений на стороне СУБД. Проверьте, не удерживает ли приложение соединение во время длительного внешнего вызова. Убедитесь, что ресурсы возвращаются и в ошибочных ветках; для JDBC-кода обычно используют try-with-resources.
Свойство maximumPoolSize ограничивает суммарное число активных и свободных соединений пула. connectionTimeout задает ожидание получения соединения, а не универсальный таймаут SQL-запроса. Эти параметры описаны в документации HikariCP.
leakDetectionThreshold помогает обнаружить подозрительно долго удерживаемое соединение, но это диагностический сигнал: он не доказывает утечку и не освобождает ресурс автоматически. Назначение параметра указано в разделе настройки HikariCP.
Только после диагностики оценивайте изменение размера пула. Считайте общий бюджет всех экземпляров приложения и других клиентов БД. Увеличение параллелизма может усилить перегрузку, а увеличение ожидания — лишь продлить очередь. Результат исправления проверяют по снижению ожиданий и ошибок при приемлемой нагрузке на базу.