如何编写线程安全但可伸缩的类

编写线程安全类时，主要问题是将数据分为多个独立的部分，并为这些部分选择合适的大小。如果部分太小，则我们的类不是线程安全的。如果部件太大，则该类不可扩展。

让我们看一个进一步说明这种情况的示例：

一个例子

假设我们要跟踪一个城市中有多少人。我们要支持两种方法，一种是获取当前居住在城市中的人数，另一种是将一个人从一个城市转移到另一个城市。因此，我们有以下界面：

由于我们要从多个线程并行使用此接口，因此必须选择实现此接口的选项。使用该类 java.util.concurrent. ConcurrentHashMap或使用该类 java.util.HashMap 和一个锁。这是使用类的实现 java.util.concurrent.ConcurrentHashMap：

方法移动使用线程安全方法计算来减少源城市中的计数。然后，使用计算来增加目标城市中的计数。count方法使用线程安全方法 get。

这是使用该类的实现java.util.HashMap：

该方法move还使用该方法compute来增加和减少源城市和目标城市中的计数。仅在这一次，因为该compute方法不是线程安全的，所以两个方法都被同步块包围。该 count方法get再次使用被同步块包围的方法。

两种解决方案都是线程安全的。

但是在使用的解决方案中ConcurrentHashMap，可以从不同线程并行更新多个城市。在使用a的解决方案中HashMap，由于锁是在complete周围HashMap，因此HashMap在给定时间只有一个线程可以更新。因此，使用的解决方案ConcurrentHashMap应该更具可扩展性。让我们来看看。

太大意味着无法扩展

为了比较这两种实现的可伸缩性，我使用以下基准：

基准测试使用jmh（一种用于微基准测试的OpenJDK框架）。在基准测试中，我将人们从一个城市转移到另一个城市。每个工作线程都会更新不同的城市。源城市的名称只是线程ID，目标城市的名称是线程ID加两个。我在Intel i5 4核心CPU上运行了基准测试，结果如下：

如我们所见，使用该解决方案的ConcurrentHashMap规模更好。从两个线程开始，它的性能要优于使用单个锁的解决方案。

太小意味着线程不安全

现在，我需要一种其他方法来获得整个城市的总数。这是使用类的实现方法ConcurrentHashMap：

要查看此解决方案是否是线程安全的，我使用以下测试：

我需要两个线程来测试该方法completeCount是否是线程安全的。一口气，我将一个人从斯普林菲尔德搬到了南方公园。在另一个线程中，我得到 completeCount并检查结果是否等于预期结果。

为了测试所有线程交织，我们使用AllInterleavings来自vmlens的类（第7行）遍历所有线程交织，将完整的测试放在while循环中。运行测试，我看到以下错误：

vmlens报告显示出了什么问题：

如我们所见，问题在于完成计数的计算是在另一个线程仍将一个人从斯普林菲尔德移到南方公园的同时进行的。Springfield的减量已经执行，但South Park的增量没有执行。

通过允许并行更新不同的城市，将completeCount和之间的组合move会导致错误的结果。如果我们有适用于所有城市的方法，则需要在此方法期间锁定所有城市。因此，为了支持这种方法，我们需要使用带有单个锁的第二个解决方案。对于此解决方案，我们可以实现一个线程安全的countComplete方法，如下所示：