Хроники байтов, поднимающие сегфо - PullRequest
0 голосов
/ 22 октября 2018

после принятого решения в хроникабайтных общих DirectBytesStores Теперь я настроил свой код таким же образом, как и принятый ответ.

Я генерирую 1 000 000 написанных мной объектовв MappedFile, и я хотел бы, чтобы каждый объект мог управлять своими собственными операциями чтения / записи в MappedFile:

public class DataObject {

    public static final int LENGTH = 12;
    private static final int A_OFFSET = 0;
    private static final int B_OFFSET = 4;

    private PointerBytesStore bytes;

    public DataObject(long memoryAddress) {
        this.bytes = new PointerBytesStore();
        this.bytes.set(memoryAddress, LENGTH)
    }

    public int getA() {
        return this.bytes.readInt(A_OFFSET);
    }

    public void setA(int a) {
        this.bytes.writeInt(a);
    }

    ...
}

Затем я создаю DataObject с:

MappedFile file = MappedFile.mappedFile(new File(tmpfile), 64 << 10);
MappedBytes mappedBytes = MappedBytes.mappedBytes(mappedFile);
int offset = 0;
List<DataObject> myList = new ArrayList<>();
for(i = 0; i < 1000000; i++) {
    int address = mappedBytes.addressForRead(offset);
    myList.add(new DataObject(address));
    offset += DataObject.LENGTH;
}

У меня естьобнаружил, используя код, похожий на приведенный выше, что хронические байты генерируют segfault, как только я достигаю ~ 100 000 объектов.Segfault имеет тенденцию происходить при попытке чтения или записи в PointerBytesStore, но непредсказуемо.

Это ошибка в хронических байтах или я неправильно использую библиотеку?Любая помощь / предложения / рекомендации будут с благодарностью.

1 Ответ

0 голосов
/ 23 октября 2018

MappedFile карты в кусках памяти одновременно.Если вы не сохраните эти чанки, зарезервировав их, память освобождается, когда она больше не использует их.

Одним из решений является использование большого чанка, чтобы вы когда-либо использовали только один чанк.

Другой подходдолжен использовать Chronicle Map, поскольку он будет управлять памятью по мере необходимости.

...