Blazkowiczkill -3 PID
можно jdk/bin/jstack PID
Сейчас 9к потоков. Как потом найти тормоза?

BlazkowiczА какой размер SESSIONS[]? По одному элементу на поток, или меньше?
13к. Но незанятые null. Что я и проверяю в цикле тоже.

BlazkowiczФига се... 9к потоков. Зачэм стока?
Ну сервер в работе :)

BlazkowiczА можно как-то поймать момент, когда соединение висит N секунд и снять в этот момент дамп потоков?
Сейчас попробую.

BlazkowiczGorloPavelНу сервер в работе :)
Дык по потоку на сессию, это как-то расточительно. Всё равно активных потоков минимум.
Это сокет соединения. Они должны быть всегда online.

BlazkowiczЕсли это game сервер и среди этих 9К сессий много активных, то вполне возможно что sendData этого потока рассылки постоянно конкурирует с остальными 9К потоков за многие synchronized.
Пессимистичные блокировки вообще в многопоточном сервере - зло.
Это сервер одного популярного приложения для OS Android. Ну ведь synchronized sendData актуален только для самого потока. Он никак не может конкурировать с остальными. Максимум с одним. Хотя... Hub.GSON.toJson это static поле в классе Hub. И насколько я понял GSON потокобезопасен, следовательно synchronized. Вот тогда он и может конкурировать с остальными 9к, так как в них существует еще несколько функций с использованием GSON. Может в этом проблема?

автор Хотя GSON вообще сам по себе очень медленный, если его использовать без кастомных мапперов.
Что посоветуете? Сейчас я пользуюсь сериализацией-десереализацией. Воде быстренько все.

BlazkowiczGorloPavelНу ведь synchronized sendData актуален только для самого потока.
Что значит актуален? У вас в SESSION, вероятно есть и другие synchronized методы, которые гарантируют целостность записи пакетов в сокет. И у вас 9К потоков, которые использую эти методы. С этим проблем нет, и даже перфоманс нормальный, благодаря Biased Locking. Но тут приходится 9К+1й поток и начинает использовать те же самые сокеты, работа с которыми синхронизирована.
В результате в 9К вызов sendData N% приводят к блокировке на synchronized.
Вот такая теория...
Кстати ещё интересно, если вдруг у вас в SESSION есть и запись и чтение, то они используют один и тот же лок. Хотя запись с чтением сокета могут происходить безопасно в разных потоках.

GorloPavel Он никак не может конкурировать с остальными. Максимум с одним.
Почему? Из 9К потоков только один активный?

GorloPavelИ насколько я понял GSON потокобезопасен, следовательно synchronized.
facepalm
Потому что в логике сервера с одним потоком может взаимодействовать только один поток. Включая вызывать его sendData со своими данными. Не понял как sendData одного потока может блокировать sendData во всех потоках?

BlazkowiczGorloPavelПотому что в логике сервера с одним потоком может взаимодействовать только один поток. Включая вызывать его sendData со своими данными. Не понял как sendData одного потока может блокировать sendData во всех потоках?
Всё, понял. Там не массовая рассылка на 9К сессий, а лишь на одного юзера? Т.е. sendData вызывается всего несколько раз?
Нет. Объясню. Есть к примеру два ПК между ними устанавливается связь средством удаленного сервера к которому они оба подключаются. Они могут инициировать вызов функций на сервере(авторизация, редактирование списка контактов и т.д) так и передавать данные друг другу(псевдо peer-to-peer) если невозможно подключение напрямую. В случае если они передают данные друг другу через сервер, то они вызывают перегруженный метод sendData(byte[]) друг у друга при получении данных который шлет пакет без изменений.