ConcurrentHashMap putIfAbsent : атомарность, когда следует вызов get()

Похоже, вы пытаетесь создать глобальный объект блокировки для ключа.

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

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

Если это не нормально, вы можете зациклить его.

public V getExampleOne(K key) {
    for(Object o = null, ret = null; (ret = map.get(key)) == null; )
        map.putIfAbsent(key, o == null ? o = new Object() : o);
    return ret;
}

его все еще можно удалить или заменить, как только петля существует, так что это практически то же самое, что и .

public V getExampleThree(K key) {
    Object o = new Object();
    map.putIfAbsent(key, o);
    Object ret = map.get(key);
    return ret == null ? o : ret;
}

Итак, наконец, мой вопрос; чем примеры выше отличаются по семантике?.

Разница только очевидна.

Обеспечивает ли getExampleThree атомарность, как и getExampleTwo, но правильно ли избегает нулевого возврата?

Да.

Есть ли другие проблемы с getExampleThree?

Только если вы считаете, что следующий вызов может не дать вам другое значение (если вы считаете, что его можно удалить в другом потоке).

Методы имеют разную семантику:

• getExampleOne не является атомарным.
• getExampleTwo возвращает null, если новый объект был вставлен на карту. Это отличается от поведения getExampleOne, но является атомарным.
• getExampleThree, вероятно, то, что вы хотите. Он атомарный и возвращает объект, который находится на карте после момента времени вызова putIfAbsent. Но это было проблемой, когда нули являются допустимыми значениями в вашем приложении. Тогда возвращаемое значение null будет неоднозначным.

Однако в зависимости от ситуации это может быть не фактический объект в тот момент времени, когда вы используете возвращаемое значение. Затем вам нужна явная блокировка.

Почему бы просто не использовать первую версию и не синхронизировать метод?

public synchronized V getExampleOne(K key) {
    map.putIfAbsent(key, new Object());
    return map.get(key);
}

Хотя это не обеспечит вам максимального параллелизма, верно и то, что у вас есть только две операции, и getExampleThree, хотя и правильно, менее удобочитаемо и менее понятно для кого-то другого, читающего ваш код.

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

Мне не совсем понятно, что вы ищете. Дайте мне знать, если это не так, и я изменю.

Возможно, вы ищете что-то вроде:

private final ConcurrentHashMap<String, Object> map = new ConcurrentHashMap();

/*
 * Guaranteed to return the object replaced.
 * 
 * Note that by the time this method returns another thread 
 * may have already replaced the object again.
 * 
 * All we can guarantee here is that the return value WAS 
 * associated with the key in the map at the time the entry was 
 * replaced.
 * 
 * A null return implies that either a null object was associated
 * with the specified key or there was no entry in the map for 
 * the specified key wih 'null' as it's 'value'.
 */
public Object consistentReplace ( String key, Object newValue ) {
  Object oldValue = map.get(key);
  while ( !map.replace(key, oldValue, newValue) ) {
    // Failed to replace because someone got in there before me.
    oldValue = map.get(key);
  }
  return oldValue;
}