高效的缓存同步

Question

考虑一下，

public Object doGet() {
    return getResource();
}

private Object getResource() {
    synchronized (lock) {
        if (cachedResourceIsStale()) {
            downloadNewVersionOfResource();
        }
    }

    return resource;
}

假设 doGet 将并发执行，并且执行很多次，并且下载新版本的资源需要一段时间，是否有更有效的方法在 getResource 中进行同步？我了解读/写锁，但我不认为它们可以应用在这里。

为什么要同步？如果缓存过时，则在第一个线程仍在刷新资源时访问该资源的所有线程都将执行自己的刷新。除了这导致的其他问题之外，它的效率也很低。

正如 BalusC 在评论中提到的，我目前在 servlet 中面临这个问题，但我对通用答案很满意，因为谁知道在什么情况下我会再次遇到它。

Answer 1

假设

1. 高效意味着 doGet() 应尽快完成
2. cachedPageIsStale() 根本不需要时间
3. downloadNewVersionOfResource() 需要一点时间

答案

同步减少了网络负载，因为只有一个线程在资源过期时获取资源。此外，它不会过度延迟其他线程的处理 - 由于虚拟机不包含线程可以返回的当前快照，因此它们必须阻塞，并且没有理由额外的并发 downloadNewVersionOfResource() 会更快地完成（由于网络带宽争用，我预计情况会相反）。

因此，同步效果很好，并且在带宽消耗和响应时间方面是最佳的。 （与 I/O 等待相比，同步的 CPU 开销非常小） - 假设调用 doGet() 时资源的当前版本可能不可用；如果您的服务器始终拥有该资源的当前版本，它可以立即将其发回。 （您可能有一个后台线程在旧版本到期之前下载新版本。）

PS

您尚未显示任何错误处理。您必须决定是将 downloadNewVersionOfResource() 引发的异常传播给调用者还是继续提供旧版本的资源。

编辑

那么呢？假设您有 100 个连接工作线程，检查资源是否过时需要 1 微秒，资源是否过时且提供服务需要 1 秒。那么，平均有 100 * 10^-6 / 1 = 0.0001 个线程尝试获取锁。几乎没有任何争论。获取未获取的锁的开销约为 10^-8 秒。当网络会导致几毫秒的延迟时，优化已经采用微发送的东西是没有意义的。如果您不相信我，请执行微基准测试以进行同步。确实，频繁、不必要的同步会增加大量开销，因此不推荐使用同步集合类。但这是因为这些方法每次调用只做很少的工作，并且同步的相对开销要大得多。我刚刚为以下代码做了一个小微基准测试：

synchronized (lock) {
    c++;
}

在我的笔记本上，这需要 50 纳秒（5*10^-8 秒），在 sun 的热点虚拟机中平均执行超过 1000 万次。这大约是裸增量操作的 20 倍，因此如果进行大量增量操作，则同步其中的每一个都会使程序减慢一个数量级。然而，如果该方法确实阻塞 I/O，例如等待 1 毫秒，则增加同样的 50 纳秒将使吞吐量减少 0.005%。当然，您有更好的性能调整机会:-)

这就是为什么，您应该在开始优化之前始终进行测量。它可以防止您花费数小时的时间来节省几纳秒的处理器时间。

Answer 2

您可能可以通过使用“锁条带化”来减少锁争用（从而提高吞吐量）——本质上是将一个锁拆分为多个锁，每个锁保护特定的用户组。
棘手的部分是如何弄清楚如何将用户分配到组。最简单的情况是您可以将任何用户的请求分配给任何组。如果您的数据模型要求必须按顺序处理来自一个用户的请求，则必须在用户请求和组之间引入某种映射。以下是 StripedLock 的示例实现：

import java.util.concurrent.locks.ReentrantLock;

/**
 * Striped locks holder, contains array of {@link java.util.concurrent.locks.ReentrantLock}, on which lock/unlock
 * operations are performed. Purpose of this is to decrease lock contention.
 * <p>When client requests lock, it gives an integer argument, from which target lock is derived as follows:
 * index of lock in array equals to <code>id & (locks.length - 1)</code>.
 * Since <code>locks.length</code> is the power of 2, <code>locks.length - 1</code> is string of '1' bits,
 * and this means that all lower bits of argument are taken into account.
 * <p>Number of locks it can hold is bounded: it can be from set {2, 4, 8, 16, 32, 64}.
  */
public class StripedLock {
    private final ReentrantLock[] locks;

    /**
     * Default ctor, creates 16 locks
     */
    public StripedLock() {
        this(4);
    }

    /**
     * Creates array of locks, size of array may be any from set {2, 4, 8, 16, 32, 64} 
     * @param storagePower size of array will be equal to <code>Math.pow(2, storagePower)</code>
     */
    public StripedLock(int storagePower) {
        if (storagePower < 1 || storagePower > 6)
             throw new IllegalArgumentException("storage power must be in [1..6]");
        int lockSize = (int) Math.pow(2, storagePower);
        locks = new ReentrantLock[lockSize];
        for (int i = 0; i < locks.length; i++)
            locks[i] = new ReentrantLock();
    }

    /**
     * Locks lock associated with given id.
     * @param id value, from which lock is derived
     */
    public void lock(int id) {
        getLock(id).lock();
    }

    /**
     * Unlocks lock associated with given id.
     * @param id value, from which lock is derived 
     */
    public void unlock(int id) {
        getLock(id).unlock();
    }

    /**
     * Map function between integer and lock from locks array
     * @param id argument
     * @return lock which is result of function 
     */
    private ReentrantLock getLock(int id) {
        return locks[id & (locks.length - 1)];
    }
}