0

我们希望在一些高性能代码中最小化（如果不是消除）对象分配。这在早期版本的编年史地图（2.x 版）中很大程度上是可能的。在最新版本的 Chronicle Map (3.17.1) 中，我们在使用 ExternalMapQueryContext 时看到了显着的分配。我们在这里遵循教程：https ://github.com/OpenHFT/Chronicle-Map/blob/master/docs/CM_Tutorial.adoc

这是预期的吗？我们是否使用了正确的方法？

VOInterface voi = VO.get();

try (ExternalMapQueryContext < CharSequence, voi, ? > ctx = map.queryContext(key)) {

    if (ctx.readLock().tryLock()) {
        MapEntry < CharSequence, voi > entry = ctx.entry();
        if (entry != null) {
            // Entry is present, return
            entry.value().getUsing(voi);
            accessor.accessData(voi);
            // Key is absent
            // Need to unlock, to lock to update lock later. Direct upgrade is forbidden.
            ctx.readLock().unlock();
            return true;
        } else {
            accessor.notFound();
            // Key is absent
            // Need to unlock, to lock to update lock later. Direct upgrade is forbidden.
            ctx.readLock().unlock();
            return false;
        }
    }

    ctx.updateLock().lock();
    MapEntry < CharSequence, voi > entry = ctx.entry();
    if (entry != null) {
        entry.value().getUsing(voi);
        accessor.accessData(voi);
        return true;
    } else {
        accessor.notFound();
        return false;
    }
}

我们也可以共享分配堆栈的屏幕截图。

4

1 回答 1

0

我们有一个测试 net.openhft.chronicle.map.ChronicleMapTest#testAcquireLockedPerf 每秒执行数百万次操作。你可以运行这个

-Xmx64m -verbose:gc

对于这种情况，尽管有 64 MB 的堆，但在预热之后，测试不会触发单个 gc 以进行数亿次操作。

要弄清楚为什么您的特定案例会产生大量垃圾，需要进行更多调查。

于 2019-05-08T18:32:33.270 回答