java - 这个java代码是线程安全的吗？

Question

我打算在我的应用程序中使用这个模式，但我不确定这是否安全。

提供一点背景知识，一堆服务器将计算属于单个任务的子任务的结果并将它们报告回中央服务器。这段代码用于注册结果，并检查该任务的所有子任务是否已完成，如果已完成，则仅报告一次。

重要的一点是，所有任务都必须上报一次，并且一旦完成就只上报一次(所有 subTaskResults 都已设置)。

有人可以帮忙吗？谢谢! (另外，如果您有更好的想法来解决这个问题，请告诉我!)

*请注意，为简洁起见，我简化了代码。

解决方案一

class Task {
    //Populate with bunch of (Long, new AtomicReference()) pairs
    //Actual app uses read only HashMap
    Map<Id, AtomicReference<SubTaskResult>> subtasks = populatedMap();

    Semaphore permission = new Semaphore(1);

    public Task set(id, subTaskResult){
           //null check omitted
           subtasks.get(id).set(result);
           return check() ? this : null;
    }

    private boolean check(){
          for(AtomicReference ref : subtasks){
              if(ref.get()==null){
                  return false;
              }
          }//for
          return permission.tryAquire();
    }

  }//class

Stephen C 好心地建议使用柜台。实际上，我曾经考虑过，但我推断 JVM 可以重新排序操作，因此，在 AtomicReference (由另一个线程)设置结果之前，一个线程可以观察一个递减的计数器(由另一个线程)。

*编辑:我现在看到这是线程安全的。我会选择这个解决方案。谢谢，斯蒂芬!

解决方案二

class Task {
    //Populate with bunch of (Long, new AtomicReference()) pairs
    //Actual app uses read only HashMap
    Map<Id, AtomicReference<SubTaskResult>> subtasks = populatedMap();
    AtomicInteger counter = new AtomicInteger(subtasks.size());

    public Task set(id, subTaskResult){
           //null check omitted
           subtasks.get(id).set(result);
           //In the actual app, if !compareAndSet(null, result) return null;
           return check() ? this : null;
    }

    private boolean check(){
           return counter.decrementAndGet() == 0;
    }

  }//class

Answer 1

我假设您的用例是有多个线程调用 set , 但对于 id 的任何给定值, set方法只会被调用一次。我还假设 populateMap为所有使用的 id 创建条目值，而 subtasks和 permission真的很私密。

如果是这样，我认为代码是线程安全的。

每个线程都应该看到 subtasks 的初始化状态。映射，包含所有键和所有 AtomicReference 引用。这个状态永远不会改变，所以 subtasks.get(id)总会给出正确的引用。 set(result) call 对 AtomicReference 进行操作，因此后续的 get() check() 中的方法调用将在所有线程中提供最新的值...。任何具有多个线程调用检查的潜在竞争似乎都会自行解决。

然而，这是一个相当复杂的解决方案。一个更简单的解决方案是使用并发计数器；例如替换Semaphore与 AtomicInteger并使用 decrementAndGet而不是重复扫描 subtasks map 在check .

针对更新解决方案中的此评论:

Actually, I have considered that once, but I reasoned that the JVM could reorder the operations and thus, a thread can observe a decremented counter (by another thread) before the result is set in AtomicReference (by that other thread).

根据定义，AtomicInteger 和 AtomicReference 是原子的。任何尝试访问的线程都可以保证在访问时看到“当前”值。

在这种特殊情况下，每个线程调用 set在调用 decrementAndGet 之前在相关的 AtomicReference 上在原子整数上。这不能重新排序。线程执行的操作是按顺序执行的。由于这些是原子 Action ，因此其他线程也可以按顺序看到效果。

换句话说，它应该是线程安全的...... AFAIK。