Atomicreference pour un objet et une visibilité mutable

Le atomicreference code> ne vous aidera que par la référence à la liste, elle ne fera rien à la liste elle-même. Plus particulièrement, dans votre scénario, vous rencontrerez presque certainement des problèmes lorsque le système est sous charge dans lequel le consommateur a pris la liste pendant que le producteur l'ajout d'un élément.

Ce son est comme si vous devriez utiliser un BlockingQueue code>. Vous pouvez ensuite limiter l'empreinte mémoire si vous producteur est plus rapide que votre consommateur et laissez la file d'attente de la queue de toutes les contentions. P>

quelque chose comme: p>

static final int PROCESSES = 4;
static final int batchSize = 10;

public void process(Reader in) throws IOException, InterruptedException {

  final List<Future<Void>> tasks = new ArrayList<Future<Void>>();
  ExecutorService exec = Executors.newFixedThreadPool(PROCESSES);
  // Queue of objects.
  final ArrayBlockingQueue<Object> queue = new ArrayBlockingQueue<Object> (batchSize * 2);
  // The final object to post.
  final Object FINISHED = new Object();

  // Start the producers.
  for (int i = 0; i < PROCESSES; i++) {
    tasks.add(exec.submit(new Callable<Void>() {
      @Override
      public Void call() throws IOException {

        Processor.this.parser.parse(in, new Parser.Handler() {
          @Override
          public void onNewObject(Object event) {
            queue.add(event);
          }
        });
        // Post a finished down the queue.
        queue.add(FINISHED);
        return null;
      }
    }));
  }

  // Start the consumer.
  tasks.add(exec.submit(new Callable<Void>() {
    @Override
    public Void call() throws IOException {
      List<Object> batch = new ArrayList<Object>(batchSize);
      int finishedCount = 0;
      // Until all threads finished.
      while ( finishedCount < PROCESSES ) {
        Object o = queue.take();
        if ( o != FINISHED ) {
          // Batch them up.
          batch.add(o);
          if ( batch.size() >= batchSize ) {
            dao.insertBatch(batch);
            // If insertBatch takes a copy we could merely clear it.
            batch = new ArrayList<Object>(batchSize);
          }
        } else {
          // Count the finishes.
          finishedCount += 1;
        }
      }
      // Finished! Post any incopmplete batch.
      if ( batch.size() > 0 ) {
        dao.insertBatch(batch);
      }
      return null;
    }
  }));

  // Wait for everything to finish.
  exec.shutdown();
  // Wait until all is done.
  boolean finished = false;
  do {
    try {
      // Wait up to 1 second for termination.
      finished = exec.awaitTermination(1, TimeUnit.SECONDS);
    } catch (InterruptedException ex) {
    }
  } while (!finished);
}

Je pense que, oubliant tout le code ici, la question exacte est la suivante:

Dois-je faire une synchronisation supplémentaire lors de l'écriture (fil a) et lecture (thread b) pour assurer le thread B voit la liste de la manière dont une gauche l'a quitté, ou est-ce que cela est pris en charge par l'atomérence?

Donc, la réponse exacte à celle-ci est la suivante: oui , atomique prennent soin de la visibilité. Et ce n'est pas mon opinion mais le Documentation JDK une :

Les effets de mémoire pour les accès et les mises à jour des atomiques suivent généralement les règles de volatiles, comme indiqué dans la spécification de langue Java, la troisième édition (17.4 Modèle de mémoire).

J'espère que cela vous aidera.