这个类是线程安全的吗？

Question

嗨
下面的类是线程安全的吗？

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 1

在声明字段时应使用ConcurrentHashMap 而不是HashMap 和ConcurrentMap。

Answer 2

是的，它是线程安全的。它是不可变的，因此没有线程可以进行任何会干扰另一个线程的结果的更改。

注意：如果在构建过程中修改了map，你不会得到你以为通过的内容，但是之后访问map的时候，会是线程安全的。

Answer 3

如果这是整个类定义，即没有其他 setter/modifier 方法，则 map 本身的使用是线程安全的：

• 通过声明 final 来保护其初始化和可见性，
• 包含的类只有一个 getter，没有修饰方法，
• 映射的内容是从构造函数参数映射复制的，因此不能有任何外部引用可以修改。

（请注意，这仅指地图的结构 - 地图中的各个元素可能仍然不安全。）

更新

关于类在构造过程中没有被同时修改的构造函数参数的说法，我倾向于同意其他人（包括@Bozho）已经指出的观点

1. 没有已知的方法来防止这种情况（甚至没有像@Grundlefleck 建议的那样使用ConcurrentHashMap - 我检查了源代码，它的构造函数只调用了putAll()，这也没有防范），李>
2. 确保构造函数参数不被同时修改是调用者的责任，而不是被调用者的责任。事实上，任何人都可以定义处理同时修改的构造函数参数的“正确”行为吗？创建的对象应该包含参数映射中的原始元素还是最新元素？...如果开始考虑这一点，恕我直言，唯一一致的解决方案是禁止同时修改构造函数参数，而这只能由调用者来确保。

Answer 4

类本身是线程安全的。

不是类包含的地图内容。客户端获取后可以更改条目。是否使整个类线程安全取决于这个类和V之间的逻辑关系。

Answer 5

假设在构造之后没有任何改变 map 字段（因为你已经将它命名为“不可变”，我猜这就是想法）并且作为构造函数参数提供的 map 在构造期间没有改变，这是一个线程安全的类。

请注意，将条目从一个映射复制到另一个映射比迭代更简单。您可能还想查看Collections 中的一些方法来创建不可变版本的集合。当然，您首先必须复制地图，因为基础地图仍然可以更改。 “不可修改*”方法仅返回集合的视图。

Answer 6

当您复制构造函数参数的内容时，它们可能会发生变化。但实际上你无法采取任何措施来防止这种情况发生。另一个潜在问题是可变键。

另外，你可以用这个替换构造函数：

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

Answer 7

我认为它是线程安全的。您已经（有效地）创建了输入 map 的副本，并且只对其进行了只读操作。我一直坚信不可变类本质上是线程安全的。但请注意，除非您的 K 和 V 类是不可变的，否则您仍然可能遇到线程安全问题。

您也可以将其替换为：

Map<K, V> m = Collections.unmodifiableMap(Collections.synchronizedMap(map));

Answer 8

是和否，对于“线程安全”的不同值（对于迟钝的答案感到抱歉）。构造不是线程安全的，但是一旦构造函数完成，并且假设发生正确，它将是不可变的和线程安全的。

在构造过程中，map 参数可能会在调用map.entrySet 和调用entry.getKey 和entry.getValue 之间被另一个线程修改。来自Map.entrySet 的javadoc。这可能会导致未定义的行为。

来自java.util.Map javadoc for entrySet：

返回映射的集合视图 包含在这张地图中。中的每个元素 返回的集合是一个 Map.Entry。这 set 由地图支持，因此更改 映射到集合中， 反之亦然。如果地图被修改 而对集合的迭代在 进度，迭代的结果 是未定义的。该套装支持 元素移除，即移除 地图中的对应映射， 通过 Iterator.remove、Set.remove、 removeAll、retainAll 和清除 操作。它不支持 add 或 addAll 操作。

因此，根据谁对地图的引用，以及他们如何跨线程操作它，以及复制元素需要多长时间，您的行为未定义，并且可能在程序的不同执行中出现不同的行为。

对于确保它在这个类中正确构造，您似乎无能为力（例如，ConcurrentHashMap 有类似的问题）。如果您的其余代码可以确保为构造函数提供一个线程安全的映射，那么它也是线程安全的，但这比您要求的范围更广。

然而，一旦构造函数完成并安全发布[1]，它将是不可变的和线程安全的 - 尽管只是在浅层的方式 - 如果键或条目是可变的，这污点 你的类，使其既不可变也不线程安全。所以，如果你的键是String，你的值是Integer，那么它将是不可变的，因此是线程安全的。但是，如果您的键是带有 setter 的类 bean 对象，而您的值是其他可变集合类型，那么您的类不是不可变的。我倾向于将其标记为“一路乌龟”。

基本上，在您的问题未涵盖的某些超出范围的条件下，您的类可能是不可变且线程安全的。

[1] 您的类目前将被安全发布，但如果，例如，它变成一个嵌套类，或者您在构造函数期间将 this 引用传递给另一个方法，这可能成为不安全发布。