По моему опыту, отображенные в память файлы работают НАМНОГО лучше, чем простой доступ к файлам как в режиме реального времени, так и в постоянном использовании. Я работал в основном с C ++ в Windows, но производительность Linux схожа, и вы все равно планируете использовать JNI, поэтому я думаю, что это относится к вашей проблеме.
Пример механизма сохраняемости, построенного на отображенном в памяти файле, см. Metakit . Я использовал его в приложении, где объекты представляли собой простые представления данных, отображаемых в памяти, движок позаботился обо всех вещах отображения за кулисами. Это было быстро и эффективно для использования памяти (по крайней мере, по сравнению с традиционными подходами, подобными тем, которые использовались в предыдущей версии), и мы получили транзакции фиксации / отката бесплатно.
В другом проекте мне пришлось писать многоадресные сетевые приложения. Данные были отправлены в рандомизированном порядке, чтобы минимизировать влияние последовательной потери пакетов (в сочетании с FEC и схемами блокировки). Более того, данные могут значительно превышать адресное пространство (видеофайлы размером более 2 ГБ), поэтому о распределении памяти не может быть и речи. На стороне сервера файловые секции отображались в памяти по требованию, и сетевой уровень непосредственно выбирал данные из этих представлений; как следствие, использование памяти было очень низким. На стороне получателя не было никакого способа предсказать порядок, в котором были получены пакеты, поэтому он должен поддерживать ограниченное количество активных представлений в целевом файле, и данные были скопированы непосредственно в эти представления. Когда пакет должен был быть помещен в не отображенную область, самое старое представление было не отображено (и в конечном итоге записано в файл системой) и заменено новым представлением в области назначения. Производительность была выдающейся, особенно потому, что система отлично справилась с фиксацией данных в качестве фоновой задачи, и ограничения в реальном времени были легко выполнены.
С тех пор я убежден, что даже самая лучшая программная схема не может превзойти системную политику ввода-вывода по умолчанию с отображенным в память файлом, потому что система знает больше, чем приложения пользовательского пространства, о том, когда и как должны быть данные. написано. Кроме того, важно знать, что отображение памяти является обязательным при работе с большими данными, потому что данные никогда не выделяются (следовательно, занимают память), но динамически отображаются в адресное пространство и управляются менеджером виртуальной памяти системы, который всегда быстрее, чем куча. Таким образом, система всегда оптимально использует память и фиксирует данные, когда это необходимо, за спиной приложения, не влияя на нее.
Надеюсь, это поможет.