Почему select () занимает в моей программе так много процессорного времени?

К сожалению, это неправильная интерпретация чисел.

Я сталкивался с этой ситуацией много раз (и задаю вопрос по stackoverflow тоже).

Основная причина в том, что VisualVM не показывает правильное время процессора. Он показывает процент времени потока в состоянии RUNNING. Но из документации на Thread.State:

Состояние потока для работающего потока. Поток в состоянии выполнения выполняется на виртуальной машине Java , но он может ожидать других ресурсов от операционной системы, например процессора.

Это именно то, что происходит. Фактически, поток заблокирован внутри epoll_wait() вызова ОС. В Linux есть несколько способов подтвердить, что это так.

strace'ing поток

$ strace -tttT -f -p [thread-id]

Идентификатор потока можно получить из вывода jstack:

$ jstack [java-pid]
[...]
"Netty Builtin Server 1" #17 prio=5 os_prio=31 tid=0x00000001013dd800 nid=0xe12f runnable [0x0000700001fe4000]
  java.lang.Thread.State: RUNNABLE
  at sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method)
  at sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:198)
[...]

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

pidstating поток

$ pidstat -tu -p [java-pid] | grep [thread pid]

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

опрос состояния потока с использованием ps

$ ps -eL -o pid,tid,state | grep [thread-id]

вы увидите большую часть времени поток в состоянии S или Sl (прерывистый сон) вместо R (работоспособен).

В конце концов, вам не стоит беспокоиться об этом, если с сервисом нет проблем в работе.

Во-первых, хорошо, что у обоих приложений одна и та же проблема; это, вероятно, указывает на то, что проблема связана либо с JVM, либо с ОС, а не с вашим приложением :-)

Как упоминал jzd, у nio.select() были проблемы. Умножение {различных версий Java} x {различных платформ, версий ядра} делает эту проблему повсеместной. Надеюсь, вам понравится один из этих вариантов:

• Если вы работаете в Linux, попробуйте 2.6 ядро ​​на всякий случай, если вы используете 2.4

  , если ошибка похожа на: http://bugs.sun.com/view_bug.do?bug_id=6670302

• Используйте старую версию JRE / JDK, а не последнюю версию!

  , т.е. вернуться к JRE 6 / JDK 6 вместо 7.

Пытаться

• {более старая версия JRE (6), более старая версия ядра Linux} или
• {более новая версия JRE (7), более новая версия ядра Linux}

вместо того, чтобы смешивать их, как в {old, newer} или {newer, old}.

Одно приложение опрашивает 10 000 подключений, используя очень мало ЦП на подключение, но все вместе это может составить значительную долю времени ЦП. Все, что делает приоритет, - это позволить какой-то другой работе первой встать в очередь.

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

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

Вот ссылка на проблему Glassfish, в которой описывается возможность того, что оборудование (сеть и серверы) может быть источником проблемы.

https://www.java.net//forum/topic/glassfish/glassfish/glassfish-31-deadlock-epollarraywrapperepollwait-how-handle

Кроме того, вот еще один похожий вопрос, на который пока нет ответа: SelectorImpl ЗАБЛОКИРОВАН