7 Replies Latest reply: Oct 22, 2007 1:02 PM by 807603 RSS

    Concurrency with ConcurrentHashMap and synchronized methods

    800306
      Hi,

      I have a class with a private constructor that provides static methods, which add things to or remove things from a Map, which I implement as a ConcurrentHashMap. I want this class to be completely thread-safe.

      Is it satisfactory to use a static ConcurrentHashMap with static methods in the class, or do I also need to declare the methods to be synchronized? If so, why?

      Thanks,
      Dan
        • 1. Re: Concurrency with ConcurrentHashMap and synchronized methods
          807603
          The best answer I can give you is that static and synchronized have nothing to do with each other.
          • 2. Re: Concurrency with ConcurrentHashMap and synchronized methods
            800306
            cotton.m wrote:
            The best answer I can give you is that static and synchronized have nothing to do with each other.
            Well if some member variable is declared as static isn't it more prone to concurrency issues than a member variable that only belongs to a certain instance of an object, as the static variable can be accessed by multiple classes at once?

            Basically, I'm just wondering to what extent I must ensure concurrency in this class. Would you be able to elaborate more?

            Thanks for the reply.
            • 3. Re: Concurrency with ConcurrentHashMap and synchronized methods
              807603
              I think the crux of the matter is "completely thread-safe". That's too vague. For example, suppose you want to be able to look up a value based on keyone, mutate that value while removing that mapping from the map, but then add the value under keytwo, and you want that operation to be atomic. You would need to introduce a new method in your wrapper class and make it synchronized.

              So I say, forget about the implementation, that there is a map there at all, think about all the possible messages that can be sent to your object, and ask yourself which messages need to be treated as atomic operations on the object's state.
              • 4. Re: Concurrency with ConcurrentHashMap and synchronized methods
                800306
                BigDaddyLoveHandles wrote:
                I think the crux of the matter is "completely thread-safe". That's too vague. For example, suppose you want to be able to look up a value based on keyone, mutate that value while removing that mapping from the map, but then add the value under keytwo, and you want that operation to be atomic. You would need to introduce a new method in your wrapper class and make it synchronized.

                So I say, forget about the implementation, that there is a map there at all, think about all the possible messages that can be sent to your object, and ask yourself which messages need to be treated as atomic operations on the object's state.
                Alright, this makes sense. So basically the implementation, be it ConcurrentHashMap, HashMap, etc., should be irrelevant, as what I should truly be concerned about is what operations on the object should be atomic, and once I determine that part of the design, I should make those operations atomic by using synchronization?

                Thanks again.
                • 5. Re: Concurrency with ConcurrentHashMap and synchronized methods
                  807603
                  Yup, assuming that this object is going to be sent messages from different threads, and that no enclosing object has already been assigned the job of guaranteeing thread-safety for this object. Of course, if a method amounts to calling a single method on the ConcurrentHashMap, then it is already thread-safe, and there's no need to sprinkle synchronized in again.
                  • 6. Re: Concurrency with ConcurrentHashMap and synchronized methods
                    800306
                    BigDaddyLoveHandles wrote:
                    Yup, assuming that this object is going to be sent messages from different threads, and that no enclosing object has already been assigned the job of guaranteeing thread-safety for this object. Of course, if a method amounts to calling a single method on the ConcurrentHashMap, then it is already thread-safe, and there's no need to sprinkle synchronized in again.
                    Thanks, this makes sense, and answers my question.

                    As a side note, if a method has to make multiple calls to a Map as in your example, therefore requiring synchronization of the method itself, what's the point of a ConcurrentHashMap versus a normal HashMap?
                    • 7. Re: Concurrency with ConcurrentHashMap and synchronized methods
                      807603
                      As a side note, if a method has to make multiple calls to a Map as in your example, therefore requiring synchronization of the method itself, what's the point of a ConcurrentHashMap versus a normal HashMap?
                      ConcurrentHashMap has a number of added features that may make it more useful in a multithreaded context:
                      * additional methods like putIfAbsent() and replace()
                      * iterators that are guaranteed not to throw ConcurrentModificationException