У меня есть приложение, в котором есть класс / процесс, который выполняет тяжелую работу с сторонней собственной библиотекой на Си.Эта библиотека имеет некоторые собственные зависимости и данные, которые она загружает в память (около 500 МБ) при первом запуске.Загрузка занимает несколько секунд, поэтому это должно произойти только один раз.Этот управляющий класс также создает большую хэш-карту объектов, которые извлекаются из базы данных, которая используется с собственной библиотекой.
Моя проблема заключается в следующем.Управляющему классу необходимо обновить большой хэш-файл и ссылаться на него извне.Например: при внешнем обновлении соответствующему объекту в хэш-карте необходимо обновить его содержимое, а когда главному потоку необходимо использовать определенный объект в хэш-карте, ему необходим доступ к нему или его копия.Я продолжаю говорить «основной поток», но реальность такова, что основная часть приложения использует прослушиватель событий из другой нативной библиотеки, которая является многопоточной.И новые события происходят быстро (в диапазоне от 100 до 200 в секунду и, скорее всего, будут производительнее).
Мне нужен потокобезопасный способ передачи данных назад и вперед.Моей первой мыслью было использование синглтона, и это работало с небольшим количеством запросов (15 в секунду), но как только это увеличилось, у меня возникли проблемы с потоками, которые привели к сбою JVM.Моей следующей мыслью было использование очереди блокировки, но, насколько я могу судить, нет способа надежно установить двустороннюю связь.
Позвольте мне объяснить это последнее утверждение (я знаю о очереди).То, что должно произойти, - это когда процесс говорит управляющему классу «Мне нужен объект 74», он должен иметь возможность вернуть объект 74. С помощью dequeue, если два отдельных процесса запрашивают объект (скажем, 74, а другой запрашивает 89), тогданет никакого способа гарантировать, что каждый процесс получит правильный.По крайней мере, до тех пор, пока он не получит объект и не проверит, какой он.
Затем я рассмотрел шаблон прослушивателя событий в самом приложении.По сути, основной класс логики (тот, который отправляет обновления и запрашивает копии) будет передавать ссылку на класс контроллера, а класс контроллера будет реализовывать методы @Override.Я даже не уверен, что это хорошая идея, но я даже не продвинулся слишком далеко, прежде чем понял, что она не будет поточно-ориентированной.
Так что я застрял, пытаясь придумать дизайншаблон, который будет работать здесь.Обычно я могу справиться с такими проблемами, но из-за недавней смерти в семье я уставился на экран без решения.Я знаю, что это давняя проблема, которая решалась миллион раз, но сейчас я просто не могу пройти через этот процесс.
Любая помощь приветствуется.