我们希望在某些高性能代码中最小化(如果不能消除)对象分配。在以前的Chronicle Map版本(版本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;
}
}
我们还有可以共享的分配堆栈的屏幕抓图。
最佳答案
我们有一个测试net.openhft.chronicle.map.ChronicleMapTest#testAcquireLockedPerf,它每秒执行数百万次操作。您可以使用
-Xmx64m -verbose:gc
在这种情况下,预热后,即使拥有64 MB的堆,该测试也不会触发一个亿万次操作的单个gc。
要弄清为什么您的特定案例会造成大量垃圾,需要进行更多调查。