В общем:
1. Снизили кол-во использований ConcurrentLinkedQueue - перед нем поставил свой буфер в который накапливаю данные в ThreadLocal<> классе и в ConcurrentLinkedQueue помещаю сразу 10-ок пакетов за раз.
(+ отдельный поток, который по таймеру может flush делать, что бы данные сильно долго не задерживались)
2. Избавился от неявных вызовов new при encode из String в ByteArray. Массив char из String извлекается копирование в предварительно выделенный (!!!) буфер, кодируется через CharsetEncoder в предварительно выделенный (!!!) ByteArray.


Код, по словам коллег, получился не сильно простой, но вроде работает )))

По словам тех, кто проверяет (на реальной железяке) потребление процессора вроде на 30-50% уменьшилось. Т.е. вернулось к до-NIO уровню.

У меня такое чувство, что Atomic-классы при неправильном использовании жрут процессора больше, чем банальный synchronized при правильном ))). Соответственно и ConcurrentLinkedQueue достаточно прожорливая для CPU вещь. Если конкуренция за очередь маленькая, то может оказаться лучше обычную коллекцию в synchronized обернуть (пока не проверял, мучаю систему step by step)

Заменил ConcurrentLinkedQueue на synchronized + обычный LinkedList

На моем тесте (много операций, 280 Mb/s строчками по 64 символа) и при небольшой конкуренции - фиолетово. Что ConcurrentLinkedQueue на Atomic, что synchronized - при небольшом кол-во коллизий (попыток одновременного доступа) synchronized вполне себе быстрая операция.

Но поскольку в synchronized блоке можно сделать значительно больше, чем Atomic, то он даже местами выгоден.

Например: если мы хотим выбрать одной операцией все данные накопленные в ConcurrentLinkedQueue - обломись, только по одной записи, с дерганием соответствующих Atomic'ов, при synchronized - мы наложив всего одну блокировку, можем забрать все данные и обработать их одним пакетом

Ларчик просто открывался:

На многопроцессорной машине Oracle создает служебных потоков по кол-ву ядер. На машине с 40 ядрами, их кол-во просто зашкаливает. При выставлении ключа, что использовать 2 потока для JIT компилятора и 2 потока для GC - все анормальное потребление CPU при NIO исчезло.

Если раньше код с Nio проигрывал Old socket'ам раза в 2-3, то теперь соответственно стал выигрывать в 2-3 раза.

Похоже на какие-то "глюки" CFS scheduler'а в Linux, когда потоков GC и JIT'а много больше, чем собственно рабочих потоков приложения.

p.s. Особенно понравился срачь в Java конференции, где у человека на T1 сервере для "уборки" 100 Mb heap'а в тулзе мониторинга запускалось 256 потоков )))