Ребят, вопрос возник такой. В многопоточке я не особо силен, но иногда задачки попадаются, которые надо решать. Вот сейчас такая проблемка.

Окружение Java EE, при нажатии кнопки пользователем надо обработать параллельно N задач, но потоков можно задействовать не больше M штук, причем потоков может быть меньше, чем задач, тогда первый освободившийся поток берет следующую задачу и так далее. Если задачи кончились, то поток возвращается в пул сервера. Причем пользователь может во время всего этого еще раз нажать кнопку и добавить еще сколько-то задач в этот же пул задач. Тогда, если часть потоков уже вернулись в пул, мне надо их опять запустить на обработку (но в сумме все равно не должно быть больше M рабочих потоков).
Собственно такая задача, так как я сижу на Java EE, я могу стартовать асинхронный метод через @Asynchronous. Помимо этого могу использовать пул потоков общий серверный (его можно заинжектить как ресурс)
Нагрузка не большая, т.е. нормальное поличество задач типа 5 - 10 (не тысячи). Количество потоков - около пяти (не тысячи). Т.е. тут можно смело использовать блокирующие алгоритмы, с точки производительности можно не заморачиваться.
Пока у меня простое решение такое: задачи все складывать в thread safe set какой-нибудь (можно взять из ConcurrentHashMap)
Количество потоков контроллировать счетчиком AtomicInteger - стартую поток, увеличиваю. Поток завершается (если нет задач) - уменьшаю счетчик. При старте новой пачки задач - проверяю счетчик, не превысил ли он максимума. Если надо - дозапускаю потоки на обработку. Т.е. как-то так. Я в многопоточке не особо. Пару раз прочитал Concurrency in Practice, понимание есть, но практики мало.
Посоветуйте, может я велосипед изобретаю? Я бы создал свой пул на M потоков и все дела, но мне для каждого пользователя надо будет создавать такой пул (потому что все пользователи вообще независимы от друг друга и каждый имеет свои потоки). Так как я на Java EE сижу, это не вариант (или?).

друзья! всем спасибо за ответы!

по поводу общего пула и из него дергать потоки - ну да, это понятно. Я просто хотел еще квоты выдать на каждого пользователя, чтобы он мог из него дернуть, допустим, не больше пяти потоков в рамках своей сессии. Чтобы не получилось так, что один пользователь запустил 100 задач и все остальные сосут лапу. Хотя... когда сервер выдает потоки на обработку запросов (там отдельный пул), он же не смотрит по http сессиям, типа на эту сессию уже выделили 5 потоков, больше ей не давать - он просто выдает потоки и все, и как-то работает. Короче я склоняюсь к тому, что нужен один пул на всех пользователей, нафиг эти квоты.

так я и не хочу вообще потоки сам создавать, я хотел просто брать из пула сервера потоки, но не больше чем N для каждого пользователя

ах, спринг 😸... В JEE такого нельзя, там вообще мало что можно, плюс еще и исходники проблематично посмотреть, потому что для каждого app server они свои)

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

Во, спасибо! вы меня прекрасно поняли, именно в этом суть. Ну "квоты" слово может не самое удачное, как заметил Stanislav Bashkyrtsev



Вы предлагаете расшарить очередь задач между пользователями, наградить ее логикой, чтобы она имплементировала справедливость и приоритезировала задачи. Тут уйма вариантов выстрелить себе в ногу. Луше уж пусть у каждого пользователя будет своя очередь задач (пользователи разграничены через @SessionScoped бины). Но ваша идея отличная, я вообще на вооружение принял.

Да я ее вдоль и поперек уже всю изучил за 10 лет в этом проекте)) Тут особо нечего изучать, пул есть, потоки берем оттуда, вот и все. Просто я не хочу, чтобы один пользователь взяь больше, чем положено.