Каков наилучший способ обработки клавиш выбора?

1

При использовании каналов селектора и NIO, могу ли я иметь (фиксированные) потоки для обработки каждого из читаемых ключей? (т.е. один поток на каждый читаемый ключ каждого канала?)

например: while (true) {

int readyChannels = m_selector.select(1000);
if (0 == readyChannels)
{
    continue;
}

Set<SelectionKey> keys = m_selector.selectedKeys();                     
Iterator<SelectionKey> keyIterator = keys.iterator();

while(keyIterator.hasNext()) {  
SelectionKey key = keyIterator.next();
keyIterator.remove();

    if (key.isReadable()) {                     
    ...
             ****  WHAT CAN I WRITE HERE TO HANDLE EACH READABLE CHANNEL KEY ONCE ?
             **** BECAUSE IF I OPEN NEW THREAD IT WILL NOT FINISH TO HANDLE THE KEY AND I WILL GET
             ****  TO THIS CODE AGAIN...
    ...
    }
}

}

Теги:
multithreading
selector
pool

1 ответ

0

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

Обратите внимание, что в вашем конкретном сценарии это может не применяться на 100%, поэтому при необходимости используйте настройки.

Yow будет лучше, если вы не будете обрабатывать данные в коде ниже

Поэтому измените это на

   if (key.isReadable()) {                     
    ...
             ****  WHAT CAN I WRITE HERE TO HANDLE EACH READABLE CHANNEL KEY ONCE ?
             **** BECAUSE IF I OPEN NEW THREAD IT WILL NOT FINISH TO HANDLE THE KEY AND I WILL GET
             ****  TO THIS CODE AGAIN...
    ...
    }

К

   if (key.isReadable()) {                     
         // Sudo logic
         // Add the selection key to a thread pool with blocking queue.
         // Now your threads in the thread pool will do the heave IO task of reading bytes 
         // Once the bytes are read you if they need further processing like parsing out what 
         // Kind of message is it. You can use another thread pool that parses the data

    }

Если вы следуете двух подходам пула потоков, у вас есть два преимущества.

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

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

Я надеюсь, что это помогает :)

  • 0
    Привет спасибо за помощь но когда я использую пул потоков (ExecutorService), основной цикл, который проходит по ключам, снова вызывается с ключом isReadable перед потоком (из пула потоков, который должен обрабатывать прочитанные данные из канала). так как вы это решаете?
  • 0
    Надеюсь, я правильно понял ваш вопрос. Это не будет иметь никакого влияния. В максимуме вы добавляете один и тот же ключ в очередь задач дважды. Это означает, что при обработке того же ключа после того, как вы уже прочитали данные из канала, связанного с этим ключом, не будет данных для чтения. Это помогает?
Показать ещё 5 комментариев

Ещё вопросы

Сообщество Overcoder
Наверх
Меню