Очередь Java FIFO с переносом на диск

Question

Я работаю / готовлю приложение, основанное на модели производителя / потребителя.В моем случае будет один производитель, который сгенерирует несколько миллионов (нетривиальных) задач, и будет настраиваемое число потребителей.

Связь между производителем и потребителями в основном являетсяоснован.Однако меня беспокоит потребление памяти: вполне возможно, что количество задач превысит доступную память для JVM.Поэтому я хотел бы иметь реализацию Queue, которая хранит только «top-X» количество элементов очереди в памяти и сохраняет остаток на диске.Это не обязательно должно быть отказоустойчивым, поскольку не требуется переживать перезапуск программы.

Я искал, но не могу найти реализацию Queue, которая, кажется, широко используется (тамПохоже, это действительно несколько реализаций, которые я называю проверкой концепции, но я беспокоюсь о будущей поддержке / продолжении разработки этих реализаций).Я также посмотрел на внешние приложения очереди сообщений, но (1) я не хочу запускать второй внешний процесс и (2) даже встраивание брокера сообщений в один и тот же процесс JVM кажется немного «слишком тяжелым» для этого требования.

Кто-нибудь знает о какой-либо хорошо поддерживаемой библиотеке на будущее, которая предоставляет эту функциональность?

Rgds

Answer 1

Ну, JMS кажется очевидным решением. Я не думаю, что вы найдете что-то солидное для решения этой проблемы, поскольку JMS решает ее и является стандартным решением.

Обратите внимание, что в Java также есть BoundedQueues для решения этой проблемы: измерение очереди, чтобы убедиться, что она не завершится с OOME, когда очередь заполнена, и производители будут заблокированы при попытке поместить сообщение в полностью ограниченный очередь, пока какая-либо задача не будет удалена из очереди одним из потребителей.

Answer 2

Наличие блока производителя, когда задач более чем достаточно, обычно эффективнее, чем позволить очереди расти и использовать больше памяти.например, если ваша очередь помещается в очередь, она может быть в несколько раз быстрее, чем очередь, которая этого не делает.