bobo96,

вроде как в жавадоке по java.util.concurrent.ThreadPoolExecutor все есть:

ThreadPoolExecutor Queuing
Any BlockingQueue may be used to transfer and hold submitted tasks. The use of this queue interacts with pool sizing:
- If fewer than corePoolSize threads are running, the Executor always prefers adding a new thread rather than queuing.
- If corePoolSize or more threads are running, the Executor always prefers queuing a request rather than adding a new thread.
- If a request cannot be queued, a new thread is created unless this would exceed maximumPoolSize, in which case, the task will be rejected.
There are three general strategies for queuing:
1. Direct handoffs. A good default choice for a work queue is a SynchronousQueue that hands off tasks to threads without otherwise holding them. Here, an attempt to queue a task will fail if no threads are immediately available to run it, so a new thread will be constructed. This policy avoids lockups when handling sets of requests that might have internal dependencies. Direct handoffs generally require unbounded maximumPoolSizes to avoid rejection of new submitted tasks. This in turn admits the possibility of unbounded thread growth when commands continue to arrive on average faster than they can be processed.
2. Unbounded queues. Using an unbounded queue (for example a LinkedBlockingQueue without a predefined capacity) will cause new tasks to wait in the queue when all corePoolSize threads are busy. Thus, no more than corePoolSize threads will ever be created. (And the value of the maximumPoolSize therefore doesn't have any effect.) This may be appropriate when each task is completely independent of others, so tasks cannot affect each others execution; for example, in a web page server. While this style of queuing can be useful in smoothing out transient bursts of requests, it admits the possibility of unbounded work queue growth when commands continue to arrive on average faster than they can be processed.
3. Bounded queues. A bounded queue (for example, an ArrayBlockingQueue) helps prevent resource exhaustion when used with finite maximumPoolSizes, but can be more difficult to tune and control. Queue sizes and maximum pool sizes may be traded off for each other: Using large queues and small pools minimizes CPU usage, OS resources, and context-switching overhead, but can lead to artificially low throughput. If tasks frequently block (for example if they are I/O bound), a system may be able to schedule time for more threads than you otherwise allow. Use of small queues generally requires larger pool sizes, which keeps CPUs busier but may encounter unacceptable scheduling overhead, which also decreases throughput.
Rejected tasks
New tasks submitted in method execute(Runnable) will be rejected when the Executor has been shut down, and also when the Executor uses finite bounds for both maximum threads and work queue capacity, and is saturated. In either case, the execute method invokes the RejectedExecutionHandler.rejectedExecution(Runnable, ThreadPoolExecutor) method of its RejectedExecutionHandler. Four predefined handler policies are provided:
1. In the default ThreadPoolExecutor.AbortPolicy, the handler throws a runtime RejectedExecutionException upon rejection.
2. In ThreadPoolExecutor.CallerRunsPolicy, the thread that invokes execute itself runs the task. This provides a simple feedback control mechanism that will slow down the rate that new tasks are submitted.
3. In ThreadPoolExecutor.DiscardPolicy, a task that cannot be executed is simply dropped.
4. In ThreadPoolExecutor.DiscardOldestPolicy, if the executor is not shut down, the task at the head of the work queue is dropped, and then execution is retried (which can fail again, causing this to be repeated.)
It is possible to define and use other kinds of RejectedExecutionHandler classes. Doing so requires some care especially when policies are designed to work only under particular capacity or queuing policies.


бут его только конфигурит, причем евойные умолчания отличаются от спринговых

Я это место никогда не понимал и до сих пор не понимаю: вот если мы уже проделали некоторую полезную работу, а потом решили что нужно что-то выполнить асинхронно, а нам на submit выкидывают RejectedExecutionException - что с этим исключением делать? как его компенсировать? меня вот такие идеи посещают:
- выполнять задачу в текущем потоке неверно по следующим соображениям:
-- фактически таким образом мы никак не накладываем ограничения на количество одновременных потоков, т.е. смысл очереди как таковой теряется
-- мы проигрываем в throughput поскольку вместо того чтобы планировать задачи мы какую-то их часть выполняем сами, и имеем возможность планировать только после завершения
-- существуют сценарии, в которых имеет значение выполняется ли задача в другом потоке или в текущем, например использование @Transactional может приводить к разным результатам в зависимости от (в случае разных потоков мы видим разные данные, а в случае одного - одни и те же), уже не говоря о том, что у пула потоков может быть другой класслоадер
- иметь персистентную очередь с более "разумными ограничениями" на ее размер - здесь получается, что вся затея с потоками нам на самом деле и не нужна, а нужен изначально более надежный механизм
- накладывать ограничения где-то вначале стэка - однако это мало чем отличается от синхронного выполнения

guest2,

вы проблему не осознали - проходите мимо.

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


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

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

А зачем такое может понадобиться?да причин много: разные версии драйверов для БД, разные версии http-клиента и пр. - сейчас правда модно такое по разным приложениям разносить - оно вроде как одну проблему решает, однако появляются более другие.

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

вроде как базовый синхронный сценарий должен правильно ситуацию обрабатывать:
- в JDBC размер пула N
- в коте размер HTTP пула N/2 (на случай если мы где-то хотим какие-то выкрутасы делать)
- все что в размер HTTP пула не влезает тупо ждет
- на refresh браузер шлет RST и то что ждет на бэке само отваливается (я тут за произвольный браузер и F5 ручаться не готов, однако разработчики фронта мне показывали, что при должном желании можно честно оборвать висящий XHR запрос: https://stackoverflow.com/questions/24258279/internals-client-and-server-of-aborting-an-xmlhttprequest - если инфраструктура умеет мозг включать, то XHR abort может даже до БД дойти в виде OOB и оно и там запрос прервет)

Андрей ПанфиловНу значит меня можно занести в список "никто". Я в основном так и делаю асинхронщину :) Но мне не оч понятно к чему ты клонишь - вроде как говоришь что разработчики все делают плохо, но при этом ругаешься на то что в такой ситуации фича по ограничению очереди плохо работает. Но только лишь настройками пула мы не можем починить всю кривизну проекта..
на мой взгляд где-то в документации должно быть четко (большими жирными буквами) описано, что определенное API может на самом усугублять проблему, от которой пытаются избавиться за счет использования этого API, а сейчас мы имеем нечто в духе: вот здесь можно сделать пул, он позволяет что-то обрабатывать параллельно и все слово "параллельно" читают как "быстрее" вместо "непредсказуемо". Из той же оперы: есть CompletableFuture, у него есть #thenApply - где этот thenApply выполняется - хрен его знает

вот это N мы где выставили-то? Вот у нас два шага:
- что-то успешно записали в БД (тут один пул)
- отправили куда-то сообщение, что нужно сбросить кеши, перечитать и т.п. (здесь второй пул)

Вы не верите только из-за того, что разработчики редко используют фичу, уже ставшую де-факто стандартом :) (Вади не хватает, он бы все здесь разрулил) Я специально проверил и повторно убедился что оно работает, а именно:
- создал сервлет с Thread.sleep()
- вызвал его из curl, жамкнул Ctrl+C - в org.apache.tomcat.util.net.SocketWrapperBase#close приехала инфа, что клиент разорвал соединение
- вызвал из браузера и закрыл браузер - в org.apache.tomcat.util.net.SocketWrapperBase#close опять же приехала инфа, что клиент разорвал соединение

однако прежде чем бросаться проверять, убедитесь, что в коте врублен http/2 и настроен ssl, и вы хорошо дунули, а то фокуса не получится. Прерывать запросы в БД после отвала клиента - это уже дело техники, нужно всего-то уметь Statement#executeXXX ассоциировать с потоком.