Кажется, у вас утечка памяти.6 темы не так много.Я подозреваю, что это потому, что ObjectInputStream и ObjectOutputStream кэшируют все передаваемые объекты.Это делает их совершенно непригодными для длительных переводов.Вы думаете, что отправляете объект, который затем gc'ed, но он действительно удерживается в памяти объектными потоками.
Чтобы очистить кэш потоков, используйте
objectOutputStream.reset()
после записиваши объекты с writeObject()
РЕДАКТИРОВАТЬ: Чтобы получить пул потоков, SocketHandler
может быть передано Executor
вместо запуска его собственного потока.Вы создаете исполнителя, например:
Executor executor = Executors.newFiexThreadPool(MaxUsers);
Исполнитель создается как поле или на том же уровне, что и сокет сервера.Затем, после принятия соединения, вы добавляете SocketHandler к исполнителю:
executor.execute(new SocketHandler(...));
Однако, если ваши клиенты долгоживущие, то это мало улучшится, так как время запуска потока мало по сравнению с количествомработа сделана на каждом потоке.Пулы наиболее эффективны для выполнения множества небольших задач, а не нескольких крупных.
Что касается повышения надежности сервера - некоторые быстрые подсказки
- гарантируют, что он запускается с достаточным объемом памяти.или, по крайней мере, максимальный объем памяти установлен таким образом, чтобы предвидеть потребность в 1000 пользователей.
- используйте среду нагрузочного тестирования, например Apache JMeter, чтобы убедиться, что она масштабируется до максимального числа пользователей.
- используйте пул соединений для вашей базы данных и не кодируйте вызовы JDBC вручную - используйте установленную среду, например Spring JDBC.
- Каждый поток начинается со стека 2 МБ по умолчанию.Итак, если у вас 1000 пользователей, то для стека будет использовано ~ 2 ГБ виртуального пространства процесса.На многих 32-битных системах это количество пространства, которое вы можете иметь, поэтому места для данных не будет.Если вам нужно больше пользователей, то либо увеличьте масштаб до большего числа процессов, с помощью балансировщика нагрузки, передающего запросы каждому процессу, либо посмотрите на серверные решения, для которых не требуется поток на соединение.
- внимание к деталям, особенно исключениеобработка.
- регистрация, для диагностики сбоев.
- JMX или другая возможность контроля состояния сервера, с уведомлением, когда значения выходят за пределы (например, использование памяти / процессора слишком долго в течение длительного времени).период или медленное время запроса.)
См. Архитектура высокопроизводительного сервера