Как мне эффективно обновить потенциально тысячи экземпляров класса одновременно?

Question

Я работаю над плагином для сервера Minecraft, где вы можете подключить Redstone к inte rnet. Плагин работает, используя встроенную в игру кафедру, чтобы иметь возможность отправлять / получать произвольные сигналы красного камня. Он связывается с inte rnet с использованием протокола MQTT.

В настоящее время у меня есть загрузчик кафедр, который называется LecternHandlers, который загружает новый экземпляр LecternHandler для каждого создаваемого аналой. Все экземпляры LecternHandler хранятся в ArrayList, отформатированном под ключом / значением <Location, LecternHandler>, где Location является местоположением кафедры (это местоположение хранит как мир, так и координаты и является встроенной функцией API Bukkit).

Что касается хранения данных, я использую MySQL, чтобы сохранить кафедры и настройки проигрывателя в двух разных таблицах. В таблице кафедры хранится такая информация, как местоположение кафедры, а также ее идентификатор. В таблице игроков хранится такая информация, как MQTT-брокер, к которому можно подключиться, подключены ли или нет использовать tls, данные аутентификации и т. Д. c ...

Что я хотел бы сделать, так это иметь возможность обновить Настройки игрока и выгрузить и перезагрузить кафедры на лету. В настоящее время я должен пройти oop через каждый LecternHandler и проверить, принадлежит ли он игроку, а затем выгрузить его и перезагрузить. LecternHandler затем извлечет новые настройки из MySQL.

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

Как я могу решить потенциальную проблему с производительностью?

Для тех, кто заинтересован, мой проект находится на Github под GPL-3, если вы хотите увидеть сам код.

Моя цель - сделать этот плагин очень эффективным при работе с большим количеством аналой, чтобы у людей не было замедления работы их сервера из-за аккуратной функции, которую они хотели бы иметь.

Answer 1

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

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

Затем мне нужно создать еще один массив для обработки ссылок на аннотации, принадлежащие указанному c игроку. Arraylist выглядел бы как <UUID, LecternHandler[]>, если бы у него был набор экземпляров LecternHandler, через который я могу пройти oop. Это поможет мне, имея только l oop через подраздел экземпляров LecternHandler вместо полного списка. Это важно, так как у каждого LecternHandler есть свой собственный клиент MQTT, который он обрабатывает (который работает сам по себе асинхронно, но мне нужно, чтобы он был лучше).

Я вижу, как создать класс данных настроек проигрывателя, который Затем на него ссылается каждый LecternHandler, принадлежащий этому игроку. Все экземпляры LecternHandler будут содержать ссылку на настройки проигрывателя, из которых он будет читать, когда он будет перезагружен. Я могу подождать с этим, поскольку я не уверен, как сделать этот поток безопасным, если он еще не безопасен.

Сам LecternHandler должен нормально обновляться асинхронно, поскольку он не зависит от Bukkit api за исключением получения данных от MQTT для обновления текущей страницы, на которой находится аналой (текущая страница изменяет выход redstone в диапазоне 1-15, а для тех, кто не знает, redstone - версия электричества Minecraft).

Единственная потенциальная проблема, которую я вижу с этой настройкой (которая уже существует в моей текущей настройке), - это потенциальное использование оперативной памяти из-за загрузки тысяч, если не десятков тысяч экземпляров класса, однако, это выходит за рамки этого вопроса.

Это позволит обновлять экземпляры LecternHandler в пакетах или порциях, которые могут обрабатываться текущим jvm, чтобы предотвратить проблемы с зависанием или зависанием, поскольку он не тратит впустую основной поток. цикл процессора.