Java中的并发字节数组访问，锁尽可能少

Question

我正在尝试减少分段数据的锁定对象的内存使用量。这里看到我的问题。或者只是假设您有一个字节数组，并且每16个字节可以（反）序列化为对象。让我们将其称为行长度为16个字节的“行”。现在，如果您从写程序线程中修改这样的行并从多个线程中读取，则需要锁定。如果字节数组大小为1MB（1024 * 1024），则意味着65536行和相同数量的锁。

这有点太多，而且我需要更大的字节数组，并且我想将其减少到与线程数大致成比例的程度。我的想法是创建一个

ConcurrentHashMap<Integer, LockHelper> concurrentMap;

Integer行索引在哪里，在线程“进入”行之前，它在此映射中放置了一个锁定对象（从此答案中得到了这个想法）。但是，无论我怎么想，我都找不到真正线程安全的方法：

// somewhere else where we need to write or read the row
LockHelper lock1 = new LockHelper();
LockHelper lock = concurrentMap.putIfAbsent(rowIndex, lock1);
lock.addWaitingThread(); // is too late
synchronized(lock) {
  try { 
      // read or write row at rowIndex e.g. writing like
      bytes[rowIndex/16] = 1;
      bytes[rowIndex/16 + 1] = 2;
      // ...
  } finally {
     if(lock.noThreadsWaiting())
        concurrentMap.remove(rowIndex);
  }
}

您看到使该线程安全的可能性吗？

我感觉这看起来像concurrentMap.computecontstruct（例如，见此答案）非常相似，还是可以使用这种方法？

map.compute(rowIndex, (key, value) -> {
    if(value == null)
       value = new Object();
    synchronized (value) {
        // access row
        return value;
    }
});
map.remove(rowIndex);

正如我们已经知道计算操作是原子的那样，该值和“已同步”是否根本必要？

// null is forbidden so use the key also as the value to avoid creating additional objects
ConcurrentHashMap<Integer, Integer> map = ...;

// now the row access looks really simple:
map.compute(rowIndex, (key, value) -> {
    // access row
    return key;
});
map.remove(rowIndex);

顺便说一句：自从我们有了Java中的此计算之后。从1.8开始 在JavaDocs中找不到此

更新：
我在这里找到了一个非常相似的问题，使用的是userIds而不是rowIndices，请注意，该问题包含一个示例，其中包含一些问题，例如missing
final，lock在try-finally-clause
内调用以及缺少缩小地图的问题。也似乎有一个用于此目的的JKeyLockManager库，但我认为它不是线程安全的。

更新2： Nicolas Filotto指出了如何避免删除该解决方案的方法似乎非常简单：

map.compute(rowIndex, (key, value) -> {
    // access row
    return null;
});

因此，这确实是减少了内存密集型的事情，但是synchronized在我的场景中，简单的段锁定至少快了50％。

Answer 1

synchronized正如我们已经知道计算操作是原子操作那样，该值和必要值是否全部存在？

我确认它不需要添加synchronized作为在这种情况下块compute方法是自动完成的，如对Javadoc表示ConcurrentHashMap#compute(Kkey, BiFunction<? super K,? super V,? extends V>remappingFunction)已经添加了BiFunction，因为Java 8，我引述如下：

尝试计算指定键及其当前映射值的映射（或者null如果没有当前映射）。 整个方法调用是原子执行的
。在计算进行过程中，可能会阻止其他线程对此映射进行的某些尝试的更新操作，因此计算应简短而简单，并且不得尝试更新此映射的任何其他映射Map。

compute如果您BiFunction总是总是null以原子方式删除密钥，那么所有尝试都将以原子方式完成，那么您尝试使用该方法实现的目标可能完全是原子的。

map.compute(
    rowIndex, 
    (key, value) -> {
        // access row here
        return null;
    }
);

这样，您将完全依靠a的锁定机制ConcurrentHashMap来同步对行的访问。