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

Окружение 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 лет в этом проекте)) Тут особо нечего изучать, пул есть, потоки берем оттуда, вот и все. Просто я не хочу, чтобы один пользователь взяь больше, чем положено.

Petro, я вас очень люблю, но не разводите пожалуйста флуд в моих постах, пишите по делу или вообще не пишите

Раскрою немного деталей. Задачи, которые планируется запускать параллельно - это копирование файлов. Если еще точнее, то у пользователей есть вьювер в браузере какой-то хитрый (к нему у меня доступа нет), так этот вьювер умеет показывать файлы (pdf, tiff, 3d, там много всяких форматов). Но для показа, файл должен лежать в определенной папке в файловом хранилище. Сейчас работает так: Пользователь открывает документ, мы читаем из этого документа файл, сохраняем его на диске, и тогда вьювер его подхватывает. Но это работает медленно, заказчик хочет, чтобы мы заранее обрабатывали пачку следующих документов, которые у пользователя на подходе, т.е. которые он откроет следующие (там специфика работы оператора довольно предсказуемая). Т.е. загрузка заранее так сказать. Так вот их-то и надо запускать в несколько потоков асинхронно. Причем пользователь может вернуться к старому документу, тогда надо избежать повторного копирования. Ну и чтобы пересечений никаких не было, типа чтобы не начали копировать два одинаковых файла одновременно.
У меня возникает вопрос теперь а не станет ли файловое хранилище тонким местом? Да и вообще, может NIO попробовать, чтобы потоки вообще не держать пока копируется файл. Не хочется заморачиваться, это код "на окраине" проекта, его раз сделать и забыть.

мы не знаем, какой документ пользователь откроет, их 100500, мы не можем все закешировать заранее еще до входа пользователя. Только после того, как пользователь выбирает какой-нибудь документ, мы можем предсказать, какие он кликнет следующие, и вот тут надо начать из загружать заранее в несколько потоков. Сколько документов надо заранее скопировать - мы тоже не знаем, их может быть 5, может быть 100, зависит от того, что нам скажет предсказательный алгоритм. Но вне зависимости от этого, мы должны на эту работу выделить не более N потоков. Причем потоки я сам создавать не буду, я буду их брать из общего пула. Так вот чтобы один пользователь не окупировал весь пул, для этого и нужны "квоты"



То, что в браузере у клиента, всмысле этот вьювер, мы, к сожалению, не можем выбирать

?

PetroNotC Sharp,

дайте угадаю, вы просто случайным образом клавиши нажимаете?

PetroNotC Sharp,

имеется ввиду, что мы знаем последовательность, но не знаем количество. И если алгоритм скажет надо 100 закешировать, в такой-то последовательности, то мы должны это сделать, но не более чем N потоками (по описанным выше причинам)

мы не знаем, какой документ пользователь откроет ПЕРВЫМ, их 100500
как откроет первый - дальше уже можем предсказывать

знали бы вы что у нас за клиент)))

блин я раза три уже описал вам ситуацию, о чем вы

грубо говоря

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

Ну разве не очевидно? Один пользователь может занять все потоки собой, а другие будут лапу сосать.

А кто тут не архитектор.. каждый раз из года в год, я создаю пост, успеваю получить несколько конструктивных ответов, и через 5 часов я обнаруживаю себя спорящим с вами на какие-то вообще не имеющие отношения к топику темы. Где, кстати, blazkowicz? Он всегда по делу писал...

Зачем на миллион? достаточно 50. На 50 легко, документы могут быть прилинкованы к другим документам, иметь связи, вот по этим связям пользователь и будет ходить. 50 потоков бах ему одному, не жирно?

вы типичный представитель русского IT форума, вы не советуете, вы говорите "топикстартер - унылый тупица, я весь в белом пальто тут только". Так дело не пойдет. Вопрос, который я тут задал, он вообще не про это, там я конкретно написал, что нам нужно в данной ситуации. У нас тут может все надо менять и переписывать, думаете я не знаю? Но конкретно сейчас мне надо решить эту задачу, зачем вы уводите в сторону так далеко?