Question: Hi  

Is the class below threadsafe?

```
class ImmutablePossiblyThreadsafeClass<K, V> {

    private final Map<K, V> map;

    public ImmutablePossiblyThreadsafeClass(final Map<K, V> map) {
        this.map = new HashMap<K, V>();

        for (Entry<K, V> entry : map.entrySet()) {
            this.map.put(entry.getKey(), entry.getValue());
        }
    }

    public V get(K key) {
        return this.map.get(key);
    }
}

```

Answer: 
If this is the whole class definition, i.e. there are no other setter/modifier methods, the usage of the map itself is thread safe:

* its initialization and visibility is safeguarded by declaring it `final`,
* the containing class has only a getter, no modifier methods,
* the contents of the map are copied from the constructor parameter map, so there can be no outside references through which it can be modified.

(Note though that this refers to the structure of the map only - the individual elements inside the map may still be unsafe.)

### Update

Regarding the claim that the class is not guarded from the constructor parameter being concurrently modified during construction, I tend to agree with others (incl. @Bozho) who have already pointed out that

1. there is no known way to guard against this (not even using a `ConcurrentHashMap` as @Grundlefleck suggested - I checked the source code and its constructor just calls `putAll()`, which is not guarded against this either),
2. it is the caller's responsibility rather than the callee's to ensure that the constructor parameter is not being concurrently modified. In fact, can anyone define the "right" behaviour for processing a constructor parameter which is being concurrently modified? Should the created object contain the original elements in the parameter map, or the latest elements?... If one starts to think about this, IMHO it is not difficult to realize that the only consistent solution is to disallow concurrent modification of the constructor parameter, and this can only be ensured by the caller.
Yes and no, for different values of "thread safe" (sorry for the obtuse answer). The construction is not thread safe, but once the constructor completes, and assuming that has happened correctly, it will be immutable and threadsafe.

During construction, the `map` paramater may be modified by another thread between the call to `map.entrySet` and the calls to `entry.getKey` and `entry.getValue`. From the javadoc of `Map.entrySet`. This can result in undefined behaviour.

From the `java.util.Map` javadoc for `entrySet`:

> 
> Returns a set view of the mappings
>  contained in this map. Each element in
>  the returned set is a Map.Entry. The
>  set is backed by the map, so changes
>  to the map are reflected in the set,
>  and vice-versa. If the map is modified
>  while an iteration over the set is in
>  progress, the results of the iteration
>  are undefined. The set supports
>  element removal, which removes the
>  corresponding mapping from the map,
>  via the Iterator.remove, Set.remove,
>  removeAll, retainAll and clear
>  operations. It does not support the
>  add or addAll operations.
> 
> 
> 

So depending on who has a reference to the map, and how they manipulate it across threads, and how long it takes to copy the elements, you have undefined behaviour, and possibly different behaviour on different executions of the program.

There seems to be little you can do about ensuring it is constructed correctly *from within this class* (since, for example, `ConcurrentHashMap` has a similar problem). If the rest of your code can ensure that the constructor is given a thread-safe map, it will also be thread safe, but that's a wider scope than you asked.

Once, however, the constructor completes, and it is safely published[1] it will be immutable and thread safe - though only in a shallow way - if the keys or entries are mutable, this *taints* your class, making it neither immutable nor thread-safe. So, if your keys are `String`'s and your values are `Integer`'s, it will be immutable and thus thread safe. If however, your keys are a bean-like object with setters, and your values are other mutable collection types, then your class is not immutable. I tend to label this a "turtles all the way down" condition.

Essentially, your class **could be** immutable and thread safe, under certain, out-of-scope conditions not covered in your question.

[1] Your class will currently be published safely, but if, for instance, it becomes a nested class, or you pass the `this` reference to another method during the constructor, this can become an unsafe publication.