Использование автоматического выключателя в виртуальных потоках ⇐ JAVA

[Anonymous]

Наше приложение основано на Spring Boot 3.2 и работает на JDK 21. Мы сделали ставку на виртуальные потоки и не можем не хвалить их. Tomcat обрабатывает все запросы с помощью пула виртуальных потоков, использование @Async использует пул виртуальных потоков и т. д.
Моя проблема в том, что проблемы конкуренции потоков все равно могут возникнуть, если одна из наших конечных точек вызывает код, который впоследствии выполняется в невиртуальном пуле потоков. Одним из примеров является обработчик запроса, который вызывает код, окруженный методом CircuitBreaker.run(). По крайней мере, с точки зрения Reliance4J, .run() запускает Поставщика в его внутреннем пуле потоков, который по умолчанию ограничен количеством ядер ЦП. Это означает, что я мог бы иметь 100 экземпляров моего обработчика запросов, работающих в виртуальных потоках, и все они будут конкурировать за четыре потока платформы, доступные в пуле Reliance4J.
Очевидным ответом было бы увеличение используемого пула потоков. от Reliance4J. Это помогло бы, но может быть лучшим/единственным доступным решением. Меня беспокоит то, что она по-прежнему не масштабируется так же, как система, если бы она была полностью виртуальными потоками. Это не идеально, и это действительно сводит на нет преимущества, которые давали нам виртуальные потоки.
Другим вариантом было бы изучить возможность замены пула потоков Reliance4J, но, похоже, есть и другие возможности Loom. проблемы (использование ключевого слова Synchronized и т. д.), которые могут вызвать проблемы (т. е. закрепление потока) в коде-оболочке вокруг их пула потоков. Также очевидно, что команда Reliance4J еще не внедрила виртуальные потоки, и это немного похоже на злоупотребление их инструментом. Это также создает некоторые проблемы с удобством сопровождения, поскольку Reliance4J будет обновлять свой код в будущем.
Позвольте мне свести это к двум вопросам:
Does существует ли реализация автоматического выключателя, которая хорошо работает с виртуальными потоками? Работают ли какие-либо из существующих реализаций в направлении совместимости с Loom?
Какое решение я не рассматриваю? Я предполагаю, что мог бы создать свой собственный простой автоматический выключатель, который мог бы запускать выполнение в отдельном виртуальном потоке. Это сработало бы, если бы можно было вытеснить виртуальный поток. Я не уверен, что это возможно. Это вообще разумно?
FWIW: Я уверен, что кто-то сразу же укажет, что, поскольку потоки моего обработчика запросов очень длинные, виртуальные потоки не обеспечивают большую часть преимущество перед более традиционным пулом потоков. В моей ситуации обработчик запросов обычно может найти необходимую информацию в кеше и запускает код, защищенный автоматическим выключателем, только в том случае, если этот поиск не удался. Таким образом, я получил смесь коротких и долгоживущих потоков (от однозначных миллисекунд до десятков секунд), и это дает существенное преимущество.

Подробнее здесь: https://stackoverflow.com/questions/787 ... al-threads