ThreadPoolExecutor - использовать потоки перед очередью

Question

Я заменяю унаследованный пул потоков java данными ThreadPoolExecutor. В устаревшем пуле потоков при запуске создаются 600 сто потоков. Но в ThreadPoolExecutor, используя концепцию основных потоков, максимальных потоков и prestartAllCoreThreads(), количество потоков при запуске может быть ограничено.

Теперь

1) Если меньше, чем corePoolSize нити работают, Исполнитель всегда предпочитает добавлять новый поток, а не массового обслуживания. 2) Если corePoolSize или более потоки запущены, Исполнитель всегда предпочитает очередность запроса, а не добавляет новый поток. 3) Если запрос не может быть поставлен в очередь, создается новый поток, если это не будет превышать maximumPoolSize, и в этом случае задача будет отклонена.

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

так что я хочу CoreThreads -> Non-CoreThreads -> Queue вместо CoreThreads -> Queue -> Non-CoreThreads.

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

Теперь одним из способов этого является расширение класса ThreadPoolExecutor и переопределение метода execute, но тогда я должен почти скопировать полный класс. Это грязный способ, о котором я мог думать. Может ли кто-нибудь предложить любой другой способ.

Примечание: Я не могу использовать cachedThreadPool, так как количество потоков должно быть ограничено.

Answer 1

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

Использовать нить для уменьшения задержки или увеличения пропускной способности. Учитывая, что вы создаете 600 потоков, это больше подходит для увеличения пропускной способности на сервере. Однако любой современный сервер не имеет 600 ядер процессора, и вы сильно пострадали от контекстного переключателя. Легче и эффективнее иметь фиксированное число потоков, работающих с множеством очередей.

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

По существу, если действительно, действительно оправдано, я не думаю, что создание новой нити является хорошим решением, чем очередность в системах реального времени.