Несколько потоков против одного потока

Question

Я сейчас работаю над серверным клиентским приложением (только для целей обучения) и пытаюсь получить информацию для принятия проектного решения относительно потоков в этом приложении.

В настоящее время у меня есть один ответственный потоквсего неблокирующего с клиентами.Когда он получает какие-либо данные, он отправляет их в рабочий поток, который создает «набор инструкций» из этих байтов, а затем воздействует на них соответствующим образом.Однако, согласно набору инструкций, он может действовать на любое количество сотен объектов (каждый объект будет иметь где-то от 2 до 12 клиентов, которые могут взаимодействовать с ним).Я пытаюсь выяснить, должен ли я обрабатывать все наборы инструкций в том же потоке, и просто блокировать, пока я обрабатываю каждый набор, или мне следует создавать отдельные потоки для каждого объекта, а затем передавать каждый полученный набор инструкций вданный поток объектов для обработки.

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

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

Тем не менее, я продолжаю слышать о том, как создание и управление потоками имеет основную стоимость, поскольку ОС должна управлять ими.Таким образом, если бы я создал поток для объекта, который мог бы иметь не более 2 клиентов, способных взаимодействовать с ним, сводила бы на нет основную стоимость управления им одновременную выгоду от него, чувствовали бы, что только 2 клиента могут использовать этот параллелизм?

Как всегда, любые советы / статьи приветствуются:)

Answer 1

Я бы рекомендовал следовать примеру, установленному серверами приложений Java EE.

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

Если количество запросов превышает число потоков обработчиков, очередь позволяет им накапливаться и ждать, пока поток не станет доступным.

Этот дизайн дает вам два преимущества:

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

Параллелизм - ваш друг здесь.Это поможет сохранить ваш сервер масштабируемым.

Answer 2

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

Answer 3

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