Как сериализовать/десериализовать значение long[] с помощью get/set для случайных индексов с помощью Chronicle Map?

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

Если вы хотите читать/записывать только отдельные элементы в больших списках, вам следует использовать API расширенных контекстов:

/** This method is entirely garbage-free, deserialization-free, and thread-safe. */
void putOneValue(ChronicleMap<ShortValue, LongList> map, ShortValue key, int index,
        long element) {
    if (index < 0) throw throw new IndexOutOfBoundsException(...);
    try (ExternalMapQueryContext<ShortValue, LongList, ?> c = map.getContext(key)) {
        c.writeLock().lock(); // (1)
        MapEntry<ShortValue, LongList> entry = c.entry();
        if (entry != null) {
            Data<LongList> value = entry.value();
            BytesStore valueBytes = (BytesStore) value.bytes(); // (2)
            long valueBytesOffset = value.offset();
            long valueBytesSize = value.size();
            int valueListSize = (int) (valueBytesSize / Long.BYTES); // (3)
            if (index >= valueListSize) throw new IndexOutOfBoundsException(...);
            valueBytes.writeLong(valueBytesOffset + ((long) index) * Long.BYTES,
                element);
            ((ChecksumEntry) entry).updateChecksum(); // (4)
        } else {
            // there is no entry for the given key
            throw ...
        }
    }
}

Заметки:

1. Вы должны получить writeLock() с самого начала, потому что в противном случае readLock() будет получен автоматически при вызове метода context.entry(), и вы не сможете обновить блокировку чтения до блокировки записи позже. Прочтите HashQueryContext javadoc осторожно.
2. Data.bytes() формально возвращает RandomDataInput, но вы можете быть уверены (это указано в Data.bytes() javadoc), что на самом деле это экземпляр BytesStore (это комбинация RandomDataInput и RandomDataOutput).
3. Предполагая, что предоставлены правильные SizedReader и SizedWriter (или DataAccess). Обратите внимание, что используется метод «размер соединения байтов/элемент», такой же, как в примере, приведенном в SizedReader и SizedWriter раздел документа, PointListSizeMarshaller. Вы можете основывать свой LongListMarshaller на этом примере класса.
4. Это указание указано, см. ChecksumEntry javadoc и раздел о контрольных суммах в документе. Если у вас есть только хранящаяся в памяти (не сохраняемая) карта хроники или отключены контрольные суммы, этот вызов можно опустить.

Реализация чтения одного элемента аналогична.

Отвечаю на дополнительные вопросы:

Я реализовал SizedReader+Writer. Нужен ли мне DataAccess или SizedWriter достаточно быстр для примитивных массивов? Я просмотрел ByteArrayDataAccess, но не ясно, как его портировать для длинных массивов, учитывая, что внутреннее хранилище HeapBytesStore настолько специфично для byte[]/ByteBuffers?

Использование DataAccess вместо SizedWriter позволяет сделать на Map.put(key, value) на одну копию данных меньше значения. Однако, если в вашем варианте использования putOneValue() (как в приведенном выше примере) является доминирующим типом запроса, это не будет иметь большого значения. Если важны Map.put(key, value) (и replace() и т. д., т. е. любые операции "записи полного значения"), то все же можно реализовать DataAccess для LongList. Это будет выглядеть так:

class LongListDataAccess implements DataAccess<LongList>, Data<LongList>,
        StatefulCopyable<LongListDataAccess> {
    transient ByteStore cachedBytes;
    transient boolean cachedBytesInitialized;
    transient LongList list;

    @Override public Data<LongList> getData(LongList list) {
        this.list = list;
        this.cachedBytesInitialized = false;
        return this;
    }

    @Override public long size() {
        return ((long) list.size()) * Long.BYTES;
    }

    @Override public void writeTo(RandomDataOutput target, long targetOffset) {
        for (int i = 0; i < list.size(); i++) {
            target.writeLong(targetOffset + ((long) i) * Long.BYTES), list.get(i));
        }
    }

    ...
}

Для эффективности методы size() и writeTo() являются ключевыми. Но важно также правильно реализовать все остальные методы (о которых я здесь не писал). Внимательно прочитайте DataAccess, Data и StatefulCopyable javadocs, а также Понимание StatefulCopyable , DataAccess и SizedReader и контрольный список пользовательской сериализации в учебник с большим вниманием тоже.

Является ли блокировка чтения/записи посредником при чтении и записи нескольких процессов на одном компьютере или только в рамках одного процесса?

Это безопасно для процессов, обратите внимание, что интерфейс называется InterProcessReadWriteUpdateLock.

При хранении объектов с заранее неизвестным переменным размером, как значения, которые вызовут фрагментацию из кучи и в сохраняемом файле?

Сохранение значения для ключа один раз и не изменение размера значения (и не удаление ключей) после этого не приведет к внешней фрагментации. Изменение размера значения или удаление ключей может привести к внешней фрагментации. ChronicleMapBuilder.actualChunkSize() конфигурация позволяет переключаться между внешней и внутренней фрагментацией. Чем больше чанк, тем меньше внешняя фрагментация, но больше внутренняя фрагментация. Если ваши значения значительно превышают размер страницы (4 КБ), вы можете установить абсурдно большой размер фрагмента и по-прежнему иметь внутреннюю фрагментацию, связанную с размером страницы, потому что Chronicle Map может использовать функцию отложенного выделения страниц в Linux.