13.4. Choosing Between Synchronized and ReentrantLock
(Java Concurrency in Practice)

ReentrantLock provides the same locking and memory semantics as intrinsic locking, as well as additional features such as timed lock waits, interruptible lock waits, fairness, and the ability to implement non-block-structured locking. The performance of ReentrantLock appears to dominate that of intrinsic locking, winning slightly on Java 6 and dramatically on Java 5.0.
...

...
ReentrantLock is an advanced tool for situations where intrinsic locking is not practical. Use it if you need its advanced features: timed, polled, or interruptible lock acquisition, fair queueing, or non-block-structured locking. Otherwise, prefer synchronized.
...

...
Future performance improvements are likely to favor synchronized over ReentrantLock. Because synchronized is built into the JVM, it can perform optimizations such as lock elision for thread-confined lock objects and lock coarsening to eliminate synchronization with intrinsic locks (see Section 11.3.2); doing this with library-based locks seems far less likely. Unless you are deploying on Java 5.0 for the foreseeable future and you have a demonstrated need for ReentrantLock's scalability benefits on that platform, it is not a good idea to choose ReentrantLock over synchronized for performance reasons.

Классы блокировки в java.util.compatible.lock — это передовой инструментарий для продвинутых пользователей и сложных ситуаций.

public class Channel {

  private Object mutexCurrent = new Object();
  private List current;

  public String build() {
    // здесь нужна блокировка на current
    synchronized(mutexCurrent) {
      current.clear();
      current.add(some...);
    }
    // здесь уже не нужна на current
  }

  public List getCurrent() {
    List ret = null;
    synchronized(mutexCurrent) {
      ret = new ArrayList(current);
    }

    return ret;
  }
}

public class ChannelMixer {

  private Channel channel;

  public synchronized String build() {
    List selected = new ArrayList();
    selected.addAll(channel.getCurrent()); // здесь нужно дождаться пока завершиться модификация current, и только затем его прочитать
  }
}

  public List getCurrent() {
    List ret = null;
    synchronized(mutexCurrent) {
      ret = clone(current);
    }

    return ret;
  }

public class Channel {
  private List current;

  public String build() {
    List nc = new ArrayList();
    nc.add(some...);

    current = nc;
  }

  public List getCurrent() {
    return current;
  }
}

R>читающий поток будет получать актуальное состояние коллекции на момент запроса — по описание не очень понял, устроит такое поведение или нет.

R>Другой простой, но вроде именно ваш вариант — использовать блокировку кода на основе java.util.concurrent.locks.ReentrantLock примерно. Суть та же, что и стандартная блокировка (synchronized) по изменяемому объекту (current), но производительность выше.

R>} И потом, самое главное — это избавить клиентский код от необходимости блокировки: потокобезопасные классы должны по умолчанию предоставлять безопасный код, то есть не требующий дополнительных проверок на вызывающей стороне.

public class Channel {
  private List current;

  public synchronized String build() {
    // здесь нужна блокировка на current
    current.clear();
    current.add(some...);
    // здесь уже не нужна на current
  }

  public List getCurrent() {
    return current;
  }
}

public class ChannelMixer {

  private Channel channel;

  public synchronized String build() {
    List selected = new ArrayList();
    selected.addAll(channel.getCurrent()); // здесь нужно дождаться пока завершиться модификация current, и только затем его прочитать
  }
}

c = getCurrent();
doSome(c);

class Channel {
...
  forEach(Visitor v) {
    synchronized(current) {
      for (o : current) {
        v.visit(o);
      }
    }
  }
...
}

    UnmodifiableCollection(Collection<? extends E> c) {
            if (c==null)
                throw new NullPointerException();
            this.c = c;
        }

    public Iterator<E> iterator() {
        return new Iterator<E>() {
        Iterator<? extends E> i = c.iterator();

        public boolean hasNext() {return i.hasNext();}
        public E next()      {return i.next();}
        public void remove() {
            throw new UnsupportedOperationException();
                }
        };
        }

synchronized (current) {
a = new ArrayList();
a.addAll(current);
return a;
}

I>>class Channel {
I>>...
I>>  forEach(Visitor v) {
I>>    synchronized(current) {
I>>      for (o : current) {
I>>        v.visit(o);
I>>      }
I>>    }
I>>  }
I>>...
I>>}
I>>

Вопрос в том, является ли присвоение атомарной операцией?

public class Channel<T> {
    private final ReentrantLock lockObj = new ReentrantLock();

    private final List<T> current = new ArrayList<T>();

    public String build() {
        lockObj.lock();
        try {
            // действия с current
        } finally {
            lockObj.unlock();
        }
    }

    public List<T> getCurrent() {
        final List<T> result = null;
        lockObj.lock();
        try {
            result = current;
        } finally {
            lockObj.unlock();
        }
        return result;
    }
}

R>public class Channel<T> {
R>...
R>    public List<T> getCurrent() {
R>        final List<T> result = null;
R>        lockObj.lock();
R>        try {
R>            result = current;
R>        } finally {
R>            lockObj.unlock();
R>        }
R>        return result;
R>    }
R>}

Безопасность потока

Для того чтобы класс был поточнобезопасным, прежде всего, он должен вести себя корректно в однопоточной среде. Если класс корректно реализован, что является другим способом подтверждения соответствия его спецификации, никакая последовательность операций (чтение или запись общих полей и вызовы общих методов) над объектом данного класса не должна быть в состоянии привести этот объект в неисправное состояние, наблюдать этот объект в любом неисправном состоянии, или нарушить какой-либо инвариант класса, входные или выходные условия.

Кроме того, для того, чтобы класс был поточнобезопасным, он должен продолжать вести себя корректно, как описано выше, в случае доступа из нескольких потоков, независимо от графика или интерливинга исполнения этих потоков средой выполнения, без какой-либо дополнительной синхронизации со стороны вызывающего кода. Влияние данных операций на поточнобезопасный объект проявится во всех потоках в фиксированном, глобально согласующемся порядке.