Пул потоков на веб-сервере в Java

JDK может быть хорошим местом для запуска Исполнителя или ExecutorService, это то, что вы ищете. Материал для чтения: http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutorService.html

Примеры в нем довольно полные, я думаю, но вот пример использования кода, который вы опубликовали:

public static void main(String[] args) throws IOException {




ServerSocket serverSocket = new ServerSocket(8080);
    System.out.println("waiting connections....");

    ExecutorService pool = Executors.newCachedThreadPool();

   while (true) {
        Socket socket = serverSocket.accept();
        RequisicaoRunnable req = new RequisicaoRunnable(socket);
        pool.execute(req);
    }
}

Мы создаем службу исполнителя, которая поддерживается пулом кэшированных потоков. Вы можете изменить это для любого типа пула, который вам нравится, изменив тип службы-исполнителя, которую вы получаете от Исполнителей: http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executors. HTML

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

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

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

Executors.newFixedThreadPool(x)

вы получаете бесплатную блокировку.

Вы можете использовать, например, BlockingQueue. Это является основой для сценария производителя/потребителя.

В твоем случае:

• производитель имеет гнездо сервера; он принимает новые клиентские сокеты и толкает клиентские сокеты в очередь;
• потребители захватывают клиентские сокеты из очереди и запросов процесса.

Помимо всего этого, вы также можете использовать ограниченную очередь; вы можете попробовать и нажать новый клиентский сокет в очередь; если очередь заполнена, вы можете по умолчанию использовать "no can not do".

Сценариев много. Нет ответа.

Хорошо, идея достаточно проста. В настоящий момент основной цикл создает новый объект RequisicaoRunnable и новый поток для его запуска каждый раз, когда он получает соединение от клиента. Идея пула потоков состоит в том, чтобы каждый раз создавать новые потоки.

В простейшей версии пула потоков вы создаете блокирующую очередь, и вы создаете и запускаете фиксированное количество рабочих потоков, прежде чем вводить основной цикл. Основной цикл будет выглядеть почти так же, как и у вас сейчас, но вместо запуска Thread для запуска каждого нового RequisicaoRunnable он просто добавит новый объект в очередь.

Ваши рабочие потоки одинаковы: while (! ShutdownHasBeenRequested()) {RequisicaoRunnable requisicaoRunnable = getATaskFromTheQueue(); requisicaoRunnable.run(); requisicaoRunnable.run(); } }

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

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

Если это не домашнее задание, тогда рассмотрите возможность использования java.util.concurrent.ThreadPoolExcecutor(). Нет смысла повторно изобретать колесо, когда там есть совершенно хорошее колесо, ожидающее его использования.

Изменение: как сказал fge, одним из улучшений было бы отсылать ответ "извините, попробуйте еще раз позже", когда новые соединения будут быстрее, чем вы можете их обработать. Когда в очереди слишком много ожидающих подключений (т.е. Когда вы достигаете предела BoundedQueue), это когда вы знаете, чтобы выручить и отправить ответ "попробуйте еще раз позже".