Java并发实践-示例14.12

Question

// Not really how java.util.concurrent.Semaphore is implemented
@ThreadSafe
public class SemaphoreOnLock {
    private final Lock lock = new ReentrantLock();
    // CONDITION PREDICATE: permitsAvailable (permits > 0)
    private final Condition permitsAvailable = lock.newCondition();
    @GuardedBy("lock") private int permits;

    SemaphoreOnLock(int initialPermits) {
        lock.lock();
        try {
            permits = initialPermits;
        } finally {
            lock.unlock();
        }
    }

/* other code omitted.... */

我对上面的示例有一个问题，该示例是从Java并发实践清单14.12使用锁实现的计数信号量中提取的。

我想知道为什么我们需要获取构造函数中的锁（如图所示lock.lock（）被调用）。据我所知，构造函数是原子的（除了引用转义），因为没有其他线程可以获得引用，因此，半构造对象对其他线程不可见。因此，我们不需要构造函数的同步修饰符。此外，我们也不需要担心内存可见性，只要对象安全发布。

那么，为什么我们需要在构造函数中获取ReentrantLock对象呢？

Answer 1

（只是为了我自己可怜的头脑澄清一下——其他答案是正确的）。

这个假设的SemaphoreOnLock类的实例旨在被共享。因此线程T1完全构造了一个实例，并将其放在线程T2可以看到它的地方并调用一些需要读取许可字段的方法。关于许可字段需要注意的一些重要事项：

1. 在第一种情况下，它被初始化为默认值0

因此，如果我们想读取上次写入的值，我们需要同步。我们必须在构造函数中这样做，就像在其他任何情况下一样。（它是否为原子赋值的事实并不影响这个可见性问题）。将构造的信号量锁（SemaphoreOnLock）限制在单个线程中的策略对我们不起作用，因为使其成为线程安全的整个想法是为了我们可以安全地共享它。

本例说明的是，当将任何非静态、非最终、非易失性字段设置为其默认值以外的值时，“线程安全”也适用于对象的构造。

当然，当我们有一个@NotThreadsecurity类时，我们甚至没有义务考虑这个问题。如果调用者构造了我们，并决定在两个线程之间共享我们，那么调用者必须安排适当的同步。在这种情况下，我们可以在构造函数中做任何我们喜欢的事情，而不用担心可见性问题——那是别人的问题。

Answer 2

老实说，我在这里看不到锁的任何有效用途，除了它引入了内存Geofence这一事实。无论如何，int分配在32/64位上是原子的。

Answer 3

半构造的对象对其他线程不可见

这不是真的。如果对象具有任何非最终/易失性字段，则在构建时其他线程可以看到该对象。因此，其他线程可能会看到“允许”的默认值，即“0”，这可能与当前线程不一致。

Java内存模型为不可变对象（只有最终字段的对象）提供了初始化安全的特殊保证。对另一个线程可见的对象引用并不一定意味着该对象的状态对消费线程可见-JCP$3.5.2

从Java并发实践的清单3.15中可以看出：

虽然在构造函数中设置的字段值似乎是写入这些字段的第一个值，因此没有“旧”值可以视为陈旧值，但Object构造函数在子类构造函数运行之前首先将默认值写入所有字段。因此，可以将字段的默认值视为陈旧值。