并发频率计数器 - 并发问题

Question

I would like to create a concurrent frequency counter class in Java.

It's about that once a request is processed (by processRequest method), the code checks the request's type (an integer) and counts how many requests have been processed (grouped by the request's type) from a given time. The processRequest method will be called by multiple threads in the same time.

There are two other methods:

• clearMap(): It will be called by one thread in every 3 hours and clears the whole map.
• getMap(): It can be called in any time by a webservice and returns an immutable copy of the current state of the frequency map.

See below my initial plan to implement that.

public class FrequencyCounter {

     private final ConcurrentHashMap<Integer,Long> frequencenyMap = new ConcurrentHashMap<>();

     public void processRequest(Request request){
         frequencenyMap.merge(request.type, 0L, (v, d) -> v+1);
     }

     public void clearMap(){
         frequencenyMap.clear();
     }

     public Map<Integer,Long> getMap(){
         return ImmutableMap.copyOf(frequencenyMap);
     }
}

I checked the documentation of ConcurrentHashMap and it tells that the merge method is performed atomically.

So once the clear() method starts to clear the hash buckets of the map (locking as per hash bucket), it can't be invoked when another thread is between getting the value of the frequency map and incrementing its value in the processRequest method because the merge method is executed atomically.

Am I right? Does my above plan seem to be fine?

Thank you for your advice.

Answer 1

First, replace Long with AtomicLong .

Second, use computeIfAbsent .

 private final Map<Integer, AtomicLong> frequencyMap = new ConcurrentHashMap<>();

 public void processRequest(Request request){
     frequencyMap.computeIfAbsent(request.type, k -> new AtomicLong())
                 .incrementAndGet();
 }

There are a few reasons why I believe this is a better solution:

1. The code in the question uses boxed objects, ie (v, d) -> v+1 is really (Long v, Long d) -> Long.valueOf(v.longValue() + 1) .

   That code generates extra garbage, which can be avoided by using AtomicLong .

   The code here only allocates one object per key, and doesn't require any extra allocations to increment the counter, eg it will still only be the one object even if counter goes to the millions.

2. The unboxing, adding 1, boxing operation will likely take slightly longer than the tightly coded incrementAndGet() operation, increasing the likelyhood of a collision, requiring a re-try in the merge method.

3. Code "purity". Using a method that takes a "value", which is then entirely ignored, seems wrong to me. It is unnecessary code noise.

These are of course my opinions. You can make your own decision, but I think this code clarifies the purpose, ie to increment a long counter, in a fully thread-safe way.