Насколько потокобезопасность - это слишком?

Используйте ConcurrentHashMap, чтобы можно было использовать putIfAbsent. Вам не нужно AtomicInteger код для синхронизации.

   public final ConcurrentMap<String, AtomicInteger> userSessions =
       new ConcurrentHashMap<String, AtomicInteger>();

   public void registerUser(String userLogin) {
       AtomicInteger newCount = new AtomicInteger(1);
       AtomicInteger oldCount = userSessions.putIfAbsent(userLogin, newCount);
       if (oldCount != null) {
           oldCount.incrementAndGet();
       }
   }

   public void unregisterUser(String userLogin) {
       AtomicInteger sessionCount = userSessions.get(userLogin);
       if (sessionCount != null) {
           sessionCount.decrementAndGet();
       }
   }

   public boolean isUserRegistered(String userLogin) {
       AtomicInteger sessionCount = userSessions.get(userLogin);
       return sessionCount != null && sessionCount.intValue() > 0;
   }

Обратите внимание, это утечка ...

Попытка получить версию без утечек:

   public final ConcurrentMap<String, Integer> userSessions =
       new ConcurrentHashMap<String, Integer>();

   public void registerUser(String userLogin) {
       for (;;) {
           Integer old = userSessions.get(userLogin);
           if (userSessions.replace(userLogin, old, old==null ? 1 : (old+1)) {
                break;
           }
       }
   }
   public void unregisterUser(String userLogin) {
       for (;;) {
           Integer old = userSessions.get(userLogin);
           if (old == null) {
               // Wasn't registered - nothing to do.
               break;
           } else if (old == 1) {
               // Last one - attempt removal.
               if (userSessions.remove(userLogin, old)) {
                   break;
               }
           } else {
               // Many - attempt decrement.
               if (userSessions.replace(userLogin, old, old-1) {
                   break;
               } 
           }
       }
   }
   public boolean isUserRegistered(String userLogin) {serLogin);
       return userSessions.containsKey(userLogin);
   }

Прежде всего: не используйте Hashtable! Он старый и очень медленный.
Дополнительно: синхронизация на более низком уровне не требуется, если вы уже синхронизируете на более высоком уровне (это верно и для элемента AtomicInteger).

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

Подход чтения / записи

Предполагая, что вы вызываете метод isUserRegistered очень часто, а другие методы только время от времени, хорошим способом является блокировка чтения-записи: разрешено иметь несколько операций чтения одновременно, но только одна блокировка записи, чтобы управлять ими всеми. (может быть получено только в том случае, если не требуется другой блокировки).

private static final Map<String, Integer> _userSessions =
  new HashMap<String, Integer>();

private ReadWriteLock rwLock =
  new ReentrantReadWriteLock(false); //true for fair locks

public static void registerUser(String userLogin) {
  Lock write = rwLock.writeLock();
  write.lock();
  try {
       Integer sessionCount = _userSessions.get(userLogin);
       if (sessionCount != null) {
           sessionCount = Integer.valueOf(sessionCount.inValue()+1);
       } else {
           sessionCount = Integer.valueOf(1)
       }
       _userSessions.put(userLogin, sessionCount);
   } finally {
     write.unlock();
   }
}

public static void unregisterUser(String userLogin) {
  Lock write = rwLock.writeLock();
  write.lock();
  try {
       Integer sessionCount = _userSessions.get(userLogin);
       if (sessionCount != null) {
           sessionCount = Integer.valueOf(sessionCount.inValue()-1);
       } else {
           sessionCount = Integer.valueOf(0)
       }
       _userSessions.put(userLogin, sessionCount);
   } finally {
     write.unlock();
   }
}

public static boolean isUserRegistered(String userLogin) {
  boolean result;

  Lock read = rwLock.readLock();
  read.lock();
  try {
       Integer sessionCount = _userSessions.get(userLogin);
       if (sessionCount != null) {
           result = sessionCount.intValue()>0
       } else {
           result = false;
       }
   } finally {
     read.unlock();
   }

   return false;
}

Плюсы: просто понять
Минусы: не будет масштабироваться, если методы записи вызываются часто.

Подход небольших атомарных операций

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

public final ConcurrentMap<String, AtomicInteger> userSessions =
   new ConcurrentHashMap<String, AtomicInteger>();
//There are other concurrent Maps for different use cases

public void registerUser(String userLogin) {
  AtomicInteger count;
  if (!userSession.containsKey(userLogin)){
    AtomicInteger newCount = new AtomicInteger(0);
    count = userSessions.putIfAbsent(userLogin, newCount);
    if (count == null){
      count=newCount;
    }
    //We need ifAbsent here, because another thread could have added it in the meantime
  } else {
    count = userSessions.get(userLogin);
  }
  count.incrementAndGet();
}

public void unregisterUser(String userLogin) {
  AtomicInteger sessionCount = userSessions.get(userLogin);
  if (sessionCount != null) {
    sessionCount.decrementAndGet();
  }
}

public boolean isUserRegistered(String userLogin) {
  AtomicInteger sessionCount = userSessions.get(userLogin);
  return sessionCount != null && sessionCount.intValue() > 0;
}

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

Подход "Блокировка на пользователя"

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

Судя по вашему коду, вашей синхронизации на _userSessions должно быть достаточно, потому что вы не открываете AtomicInteger объекты.

Дополнительная безопасность, предлагаемая AtomicInteger, в этом случае не нужна, поэтому, по сути, вы используете ее здесь как изменяемую Integer. Вы можете разместить вложенный статический класс, содержащий счетчик сеансов, в качестве единственного атрибута на карте, если вас беспокоят дополнительные накладные расходы в AtomicInteger (или немного уродливее: добавьте на карту int [1], если они не выставлен за пределами этого класса.)

Хорошая книга, недавно сам читал.

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

Лучший способ отслеживать производительность - это протестировать. Настройте автоматизированный интегрированный нагрузочный тест для ключевых областей вашего фреймворка и отслеживайте производительность. Нагрузочный тест, если он содержит достаточно широкие временные окна и богатое использование рабочего процесса, также может выявить любые тупиковые ситуации, которые вы создали.

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

Класс A блокирует ресурсы, затем вызывает B (может быть так же просто, как get / set), который также блокирует ресурс. Другой поток вызывает B, который блокирует ресурсы, а затем вызывает A, вызывая тупик.

При работе с богатой структурой полезно наметить рабочий процесс, чтобы увидеть, как взаимодействуют классы. Возможно, вы сможете обнаружить этот тип проблемы. Однако с действительно большими рамками они могут проскользнуть мимо. Лучшая защита, которую я нашел, - это изолировать блокировки до минимально возможной области и внимательно следить за вызовом вне класса, находясь внутри синхронизированного блока. Также помогает создание значительного количества нагрузочных тестов.

Я наткнулся на этот давний вопрос в поисках совета о том, как создать то, что можно было бы назвать «картой параллельного подсчета», - в частности, поиск использования ConcurrentHashMap с AtomicInteger.

Вот модифицированная версия ответа с наивысшей оценкой, в котором используется AtomicInteger и не происходит утечек. В моем (ограниченном) тестировании это кажется намного быстрее, чем версия Integer. Я также отмечу, что использование ConcurrentMap.get() до ConcurrentMap.putIfAbsent(), похоже, значительно экономит время.

private final ConcurrentMap<String, AtomicInteger> userSessions =
   new ConcurrentHashMap<String, AtomicInteger>();

public void registerUser(String userLogin) {
    AtomicInteger oldCount = userSessions.get(key);
    if(oldCount!=null && getAndIncrementIfNonZero(oldCount)>0) return;
    AtomicInteger newCount = new AtomicInteger(1);
    while(true) {
        oldCount = userSessions.putIfAbsent(key, newCount);
        if(oldCount==null) return;
        if(getAndIncrementIfNonZero(oldCount)>0) return;
    }
}

public void unregisterUser(String userLogin) {
   AtomicInteger sessionCount = userSessions.get(userLogin);
   if (sessionCount != null) {
       int endingCount = sessionCount.decrementAndGet();
       if(endingCount==0) userSessions.remove(userLogin);
   }
}

public boolean isUserRegistered(String userLogin) {
   AtomicInteger sessionCount = userSessions.get(userLogin);
   return sessionCount != null && sessionCount.intValue() > 0;
}

private static int getAndIncrementIfNonZero(AtomicInteger ai) {
    while(true) {
        int current = ai.get();
        if(current==0) return 0;
        if(ai.compareAndSet(current, current+1)) return current;
    }
}

Скорость может быть не так важна для исходной задачи плаката, но другие применения такой «карты счета» могут выиграть от эффективности.