Hashmap concurrency issue

后端 未结 9 785
南旧
南旧 2020-11-30 01:54

I have a Hashmap that, for speed reasons, I would like to not require locking on. Will updating it and accessing it at the same time cause any issues, assuming I don\'t min

相关标签:
9条回答
  • 2020-11-30 02:18

    When in doubt, check the class's Javadocs:

    Note that this implementation is not synchronized. If multiple threads access a hash map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally. (A structural modification is any operation that adds or deletes one or more mappings; merely changing the value associated with a key that an instance already contains is not a structural modification.) This is typically accomplished by synchronizing on some object that naturally encapsulates the map. If no such object exists, the map should be "wrapped" using the Collections.synchronizedMap method. This is best done at creation time, to prevent accidental unsynchronized access to the map:

    Map m = Collections.synchronizedMap(new HashMap(...));

    (emphasis not mine)

    So based on the fact that you said that your threads will be deleting mappings from the Map, the answer is that yes it will definitely cause issue and yes it is definitely unsafe.

    0 讨论(0)
  • 2020-11-30 02:21

    Like others mentionned use a ConcurrentHashMap or synchronize the map when updating it.

    0 讨论(0)
  • 2020-11-30 02:27

    If by 'at the same time' you mean from multiple threads, then yes you need to lock access to it (Or use ConcurrentHashMap or similar that does the locking for you).

    0 讨论(0)
  • 2020-11-30 02:31

    The importance of synchronising or using ConcurrentHashMap can not be understated.

    I was under the misguided impression up until a couple of years ago that I could get away with only synchronising the put and remove operations on a HashMap. This is of course very dangerous and actually results in an infinite loop in HashMap.get() on some (early 1.5 I think) jdk's.

    What I did a couple of years ago (and really shouldn't be done):

    public MyCache {
        private Map<String,Object> map = new HashMap<String,Object>();
    
        public synchronzied put(String key, Object value){
            map.put(key,value);
        }
    
        public Object get(String key){
            // can cause in an infinite loop in some JDKs!!
            return map.get(key);
        }
    }
    

    EDIT: thought I'd add an example of what not to do (see above)

    0 讨论(0)
  • 2020-11-30 02:37

    No, there will be no issues if you do the following:

    1. Place your data into the HashMap on the first load of a single thread before any multithreading occurs. This is because the process of adding data alters the modcount and is different on the first time you add it (a null will be returned) vs. replacing the data (the old data will be returned, but the modcount will not be altered). Modcount is what makes iterators fail-fast. If you're using get, though, nothing will be iterated on, so it's fine.

    2. Have the same keys throughout your application. Once the application starts and loads its data, no other keys can be assigned to this map. This way a get will either get stale data or data that was inserted fresh - there will be no issues.

    0 讨论(0)
  • 2020-11-30 02:38

    The conditions you describe will not be satisfied by HashMap. Since the process of updating a map is not atomic you may encounter the map in an invalid state. Multiple writes might leave it in a corrupted state. ConcurrentHashMap (1.5 or later) does what you want.

    0 讨论(0)
提交回复
热议问题